Some time ago I had acquired an ATtiny2313 breakout board and was running into memory limitations.
I ordered 2 ATtiny4313 on ebay, but could compile any code for them. As it turns out after a longer odyssey, it seems that the patches Atmel applied to ‘their’ version of WinAVR were not widely know. I’ve also failed to build a working avr-gcc using the latest sources of gnu gcc and the manual provided on the avr-libc website. It compiled all right, but the resulting cross-compiler was completely unaware of the ATtiny4313.
F*CK !!
There’s also quite a heated discussion on avrfreaks.net as to why Atmel has (again) ignored the wish of the community to produce a true cross-platform tool-chain, which includes device support for everything.
There was a download/build/install script for linux to be found on avrfreaks.net as well, but it didn’t produce a working compiler for me.
F*CK !!
BUT NOW… thanks to ‘Bingo600’ this has changed. There’s a new one available here and it works ;-)
Now I’m happily coding and compiling for my new ATtiny4313 chips.
Still you’ll want to apply a patch to avrdude.conf to make it aware of that chip. Just add it to avrdude.conf after the ATtiny2313 block. I assume you’re using version 5.10 or later.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 |
#------------------------------------------------------------ # ATtiny4313 #------------------------------------------------------------ part id = "t4313"; desc = "ATtiny4313"; has_debugwire = yes; flash_instr = 0xB2, 0x0F, 0x1F; eeprom_instr = 0xBB, 0xFE, 0xBB, 0xEE, 0xBB, 0xCC, 0xB2, 0x0D, 0xBA, 0x0F, 0xB2, 0x0F, 0xBA, 0x0D, 0xBB, 0xBC, 0x99, 0xE1, 0xBB, 0xAC; stk500_devcode = 0x23; ## Use the ATtiny26 devcode: avr910_devcode = 0x5e; signature = 0x1e 0x92 0x0d; pagel = 0xD4; bs2 = 0xD6; reset = io; chip_erase_delay = 9000; pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1", "x x x x x x x x x x x x x x x x"; chip_erase = "1 0 1 0 1 1 0 0 1 0 0 x x x x x", "x x x x x x x x x x x x x x x x"; timeout = 200; stabdelay = 100; cmdexedelay = 25; synchloops = 32; bytedelay = 0; pollindex = 3; pollvalue = 0x53; predelay = 1; postdelay = 1; pollmethod = 1; pp_controlstack = 0x0E, 0x1E, 0x0E, 0x1E, 0x2E, 0x3E, 0x2E, 0x3E, 0x4E, 0x5E, 0x4E, 0x5E, 0x6E, 0x7E, 0x6E, 0x7E, 0x26, 0x36, 0x66, 0x76, 0x2A, 0x3A, 0x6A, 0x7A, 0x2E, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00; hventerstabdelay = 100; progmodedelay = 0; latchcycles = 5; togglevtg = 1; poweroffdelay = 15; resetdelayms = 1; resetdelayus = 0; hvleavestabdelay = 15; chiperasepulsewidth = 0; chiperasepolltimeout = 10; programfusepulsewidth = 0; programfusepolltimeout = 5; programlockpulsewidth = 0; programlockpolltimeout = 5; memory "eeprom" size = 256; paged = no; page_size = 4; min_write_delay = 4000; max_write_delay = 4500; readback_p1 = 0xff; readback_p2 = 0xff; read = "1 0 1 0 0 0 0 0 0 0 0 x x x x x", "a7 a6 a5 a4 a3 a2 a1 a0 o o o o o o o o"; write = "1 1 0 0 0 0 0 0 0 0 0 x x x x x", "a7 a6 a5 a4 a3 a2 a1 a0 i i i i i i i i"; loadpage_lo = " 1 1 0 0 0 0 0 1", " 0 0 0 0 0 0 0 0", " 0 0 0 0 0 0 a1 a0", " i i i i i i i i"; writepage = " 1 1 0 0 0 0 1 0", " 0 0 x x x x x x", " a7 a6 a5 a4 a3 a2 0 0", " x x x x x x x x"; mode = 0x41; delay = 6; blocksize = 4; readsize = 256; ; memory "flash" paged = yes; size = 4096; page_size = 64; num_pages = 64; min_write_delay = 4500; max_write_delay = 4500; readback_p1 = 0xff; readback_p2 = 0xff; read_lo = " 0 0 1 0 0 0 0 0", " 0 0 0 0 0 a10 a9 a8", " a7 a6 a5 a4 a3 a2 a1 a0", " o o o o o o o o"; read_hi = " 0 0 1 0 1 0 0 0", " 0 0 0 0 0 a10 a9 a8", " a7 a6 a5 a4 a3 a2 a1 a0", " o o o o o o o o"; # The information in the data sheet of April/2004 is wrong, this works: loadpage_lo = " 0 1 0 0 0 0 0 0", " 0 0 0 x x x x x", " x x x x a3 a2 a1 a0", " i i i i i i i i"; # The information in the data sheet of April/2004 is wrong, this works: loadpage_hi = " 0 1 0 0 1 0 0 0", " 0 0 0 x x x x x", " x x x x a3 a2 a1 a0", " i i i i i i i i"; # The information in the data sheet of April/2004 is wrong, this works: writepage = " 0 1 0 0 1 1 0 0", " 0 0 0 0 0 a10 a9 a8", " a7 a6 a5 a4 x x x x", " x x x x x x x x"; mode = 0x41; delay = 6; blocksize = 32; readsize = 256; ; # ATtiny4313 has Signature Bytes: 0x1E 0x92 0x0D. memory "signature" size = 3; read = "0 0 1 1 0 0 0 0 0 0 0 x x x x x", "x x x x x x a1 a0 o o o o o o o o"; ; memory "lock" size = 1; write = "1 0 1 0 1 1 0 0 1 1 1 x x x x x", "x x x x x x x x 1 1 i i i i i i"; read = "0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0", "x x x x x x x x x x o o o o o o"; min_write_delay = 9000; max_write_delay = 9000; ; memory "lfuse" size = 1; write = "1 0 1 0 1 1 0 0 1 0 1 0 0 0 0 0", "x x x x x x x x i i i i i i i i"; read = "0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0", "x x x x x x x x o o o o o o o o"; min_write_delay = 9000; max_write_delay = 9000; ; memory "hfuse" size = 1; write = "1 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0", "x x x x x x x x i i i i i i i i"; read = "0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0", "x x x x x x x x o o o o o o o o"; min_write_delay = 9000; max_write_delay = 9000; ; memory "efuse" size = 1; write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0", "x x x x x x x x x x x x x x x i"; read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0", "x x x x x x x x o o o o o o o o"; min_write_delay = 9000; max_write_delay = 9000; ; # The Tiny4313 has calibration data for both 4 MHz and 8 MHz. # The information in the data sheet of April/2004 is wrong, this works: memory "calibration" size = 2; read = "0 0 1 1 1 0 0 0 0 0 0 x x x x x", "0 0 0 0 0 0 0 a0 o o o o o o o o"; ; ; |
You’ll also need to make sure you have access to the programmer, quite possibly by adding udev rules accordingly. For openSUSE, you’ll need something like this for the most common ones. This file is installed automatically, if you have avrdude from the repositories on your machine. If you build it on your own, you need to add it by hand.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# this should go into /etc/udev/rules.d or equivalent KERNEL=="parport*", MODE="0666" ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", MODE="0666" # AVRISP mkII ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", MODE="0666" # AVR-Dragon ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2103", MODE="0666" # JTAG ICE mkII ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2106", MODE="0666" # STK600 ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", MODE="0666" # USBASP (www.fischl.de) ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="c7b4", MODE="0666" # USBASP old VID/PID ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffa", MODE="0666" # AT90USB ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666" # AVR910 ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", MODE="0666" # USBtiny ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", MODE="0666" # PL2303 USB to serial adapter |
Have fun. Use at your own risk ;-)
Edit:
If you’re planning to go this way, you need to patch
|
1 2 3 4 5 6 7 8 9 10 11 12 |
/* $Id: delay.h.in 2189 2010-10-13 09:39:34Z aboyapati $ */ #ifndef _UTIL_DELAY_H_ #define _UTIL_DELAY_H_ 1 #ifndef __HAS_DELAY_CYCLES #define __HAS_DELAY_CYCLES 1 #endif #include <inttypes.h> #include <math.h> // add this line ! #include <util/delay_basic.h> |
This also affects the ‘Arduino IDE’ + subroutines on linux.
As pointed out in one of the comments, there is a potential security risk when running the script I’ve linked to. Therefore, please memorize the next line and make it part of your ‘kernel’.
Be sure you have valid, verified and functional backups of all your vital data before running external (and potentially harmful) code on your system. The backup(s) must be on an external medium. Everything else is worthless.
I hope you made note of the potential havok Bingo’s scripts can wreak before running them…minor issues like backing up toward the root of the drive, executing rm -rf * along the way. Given that the official responses when given a clear explanation of how the problem can occur and how it could easily be fixed were “it hasn’t happened before (that I know of) so it must not be a big problem”, and “I run them in a VM, so I don’t care”, I strongly, strongly suggest never running anything written by Bingo600.
You have a point there. At least the download/build phase shouldn’t require any root privileges at all.
But when running ‘make install’, usually as root for system wide installation, you’re in the same situation again. If the makefile triggers fatal commands, they’ll just happen. You may be lucky if you have locked down your system with AppArmour/Tomoyo, but otherwise you’d be f*cked as well.
So backups are vital…
I do hope people make regular backups. I do. To an external hard disk for the usual stuff and in addition off-site backups for truly vital data. I haven’t been ‘hit’ yet, but as I was once responsible for all the data of a whole department at my former uni, making backups is in my blood now. It’s shocking how little people used to care for their most vital stuff.
In this case – getting a working avr-gcc for my ATtiny4313 – I personally took the risk.
I do hope that at the end of this process we all will have access to an updated version of this piece of software, accessible through the tested repositories of our favourite linux distributions.
I was fortunate enough to have recent backups, but still lost much of a day’s work between what was deleted and the time spent doing the restore. The scripts came with no guarantees and I’m not complaining about inconvenience or data loss, but I find his dismissive response to the issue to be completely unacceptable.
The problem was entirely avoidable, too…the scripts simply took a fundamentally unsafe approach: untarring archives/creating directories, cd’ing into them (which could fail if the unpacking failed), cd’ing into the containing directory (which would then be the home or root directory in most cases), and executing rm -fr * (with root privileges, if you were following the instructions). They could easily be restructured so the rm is done on a temporary directory at a known location rather than wherever execution has left the working directory, and this would never happen.
I have not looked at the new scripts to see if they have the same problem, but given their author’s attitude toward issues like the above, I have to strongly discourage anyone from running anything written by Bingo600, regardless of how well backed up their system is. At least use a sacrificial VM set up for the purpose.