Replies: 109 comments 1 reply
-
|
For example, with the xml files from the archive here, the original Microchip AVROSP.exe seems to work with ATmega328P (quite slow though). I verified with USBASP as well. The xml files from this github repo has even more parts (193 parts, including xmega parts). |
Beta Was this translation helpful? Give feedback.
-
|
@mcuee ... do these xml files contain the (or an?) avr910_devcode and if so, under which name? |
Beta Was this translation helpful? Give feedback.
-
|
I understand that AVR910 based programmers have largely been replaced with more modern programmers (eg: USBASP, USBtinyISP, etc), even though AVR109 based bootloaders seem to be still popular (but not as popular as STK500v1/v2 based bootloaders). If you think there is no point doing this, then I will close the issue as not planned. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I have no real opinion on that. The only AVR910 programmer I know of is the bootloader (actually, a separate chip, used to be AT90S1200, later ATtiny2313) on the STK500. If one can still by them at Aliexpress, it might be worth the while. Biggest issue IIRC is that the protocol uses a single byte to identify the target controller, and that single ID byte has only ever been standardized for very old AVRs. |
Beta Was this translation helpful? Give feedback.
-
|
I bought the serial AVR910 from AliExpress: the thing is rather cheap but shipping is rather expensive compared to the part cost. The good thing is that there is a jumper for you to upgrade the FW of the ATtiny2313. BTW, I bought the other three low cost items from the same shop.
Pictures of the 4. BTW, I have ordered another USB AVR910 from Taobao and it is quite a bit more expensive (still on the way). I believe it is similar to the following AliExpress item and based on ATmega8535. Not really worth buying -- I am just getting it for testing avrdude. |
Beta Was this translation helpful? Give feedback.
-
|
I think we should make sure we at least can support targets that have an "established" AVR910 device code. @mcuee do you know if there exist other AVR910 implementations other than the official one? avrdude.conf.in contains a list of various AVR910 device codes. However, it seems like some devices have multiple device codes. I'm not sure what's correct here. Here's what I suggest we do:
From avrdude.conf: |
Beta Was this translation helpful? Give feedback.
-
I think most of the AVR910 implemnetations are quite closely based on the official one mentioned above in terms of both core HW (AVR910 AN Figure 4-1) and FW. In terms of HW, there are new ones with USB to Serial converter to replace the serial interface. Then there are some implementations with a bit more features like opto isolation. Most of them still use AT90S1200/ATtiny2313. There are also V-USB based implementation using ATmega8/8A/8L. This kind of implementation will usually not working under Windows 10/11 due to the use of low speed bulk transfer (USB CDC-ACM, not compliant to USB spec) even though they may work with Linux. I am not so sure if any of them use USB HID to work under Windows 10/11. Very rare high cost implementation is based on USB Serial chip plus ATmega8535. This is very much similar to STK500 already and I was quite surprised to see such implementation from a Chinese vendor (which also produce the STK500 High Voltage programmer based on either ATmega8535 or an STC 8051 MCU). That is why I ordered it even though they raised the price by about about US$3 due to chip shortage. In terms of PC application, the original official one from Atmel is Then after that there is the official AVR911 (AVROSP) PC application from Atmel, and other implementations like AVROSP2. It seems that quite some xml files have been created for AVROSP, as shown here. |
Beta Was this translation helpful? Give feedback.
-
|
I've created a simple table where I've gathered all known AVR910 device codes. It looks like no part has more than two known device codes, and all of them are unique, which definitely helps. The problem is that the AVR910 programmer has to be aware of all the device codes.
The only AVR910 bootloader alternative I've found is The bootloader can only store 14 device codes, and suggest using Avrdude's -F flag: From USBVirtualSerial-AVRISP.h /* AVR Device Codes - Can have a maximum of 14 but can be any you want.
Note that these are completely irrelevent. If AVRdude supports a device,
then that device is programmable. Use -F switch to ignore device codes. */
#define AVRDEVCODE01 0x55 /* ATtiny12 */
#define AVRDEVCODE02 0x56 /* ATtiny15 */
#define AVRDEVCODE03 0x5E /* ATtiny261 */
#define AVRDEVCODE04 0x76 /* ATmega8 */
#define AVRDEVCODE05 0x74 /*ATmega16 */
#define AVRDEVCODE06 0x72 /* ATmega32 */
#define AVRDEVCODE07 0x45 /* ATmega64 */
#define AVRDEVCODE08 0x74 /* ATmega644 */
#define AVRDEVCODE09 0x43 /* ATmega128 */
#define AVRDEVCODE10 0x63 /* ATmega162 */
#define AVRDEVCODE11 0x78 /* ATmega169 */
#define AVRDEVCODE12 0x6C /* AT90S4434 */
#define AVRDEVCODE13 0x38 /* AT90S8515A */
#define AVRDEVCODE14 0x65 /* AT90S8555 */ |
Beta Was this translation helpful? Give feedback.
-
|
The original AVRProg.exe seems to have the "BOOT" device mentioned. Probably because it supports both AVR109 and AVR910. Replacement of AVRProg is AVROSP (AVR911). |
Beta Was this translation helpful? Give feedback.
-
|
BTW, the following is from AVROSP2 5.47 version (last release from Mike Henning). It seems to support Osp2 protocol along with AVR911 (AVR109/AVR910). I guess that osp2 bootloader protocol is not popular and not supported by avrdude. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see avr910 support modern devices with avrdude (instead of using avrospII.exe in windows). I can modify the avr910 firmware easily, just knowing what codes to implement for each device or just to satisfy avrdude is the difficult thing for me. |
Beta Was this translation helpful? Give feedback.
-
|
Just got a USB AVR910 programmer and it is actually not too slow. |
Beta Was this translation helpful? Give feedback.
-
|
@mcuee do have the source code or at least a list of the targets the programmer supports, so we can figure out what all the unknown targets are? As I stated in a previous post, a single part may have one or two device codes. It would be great if Avrdude could support both, and send the one the programmer wants. However, How can Avrdude know what code the programmer wants if there's more than one to choose from? For instance, @mcuee's programmer supports 0x76 (atmega8), but also 0x77 (unknown, but probably atmega8?). |
Beta Was this translation helpful? Give feedback.
-
|
The latest source code I've seen for avr910 is V38B and it's in asm. Looking at the post above it appears that is the version in the programmer you just received. I understand the reason avrospII programs modern devices using an avr910 programmer is because it ignores the device codes sent out from the avr910 programmer and uses the universal 4 bytes SPI packets. So correct me if I am wrong, I think the only way to make this work is to modify avrdude to program the same way (like avrospII). |
Beta Was this translation helpful? Give feedback.
-
|
@MCUdude
There are many different avr910 firmware codes, most of them are following Microchip and use AT90S1200/ATtiny2313. The one I find from Microchip is probably version 23 for AT90S1200. I belive they use the same code and hex file for the ATtiny2313 when they upgrade the HW for STK500 (AT90S1200--> ATtiny2313; AT90S8535 --> ATmega8535). Then there are new FW (latest is v38b, Last updated 26-Feb-2006 ) which is based on Microchip implementations by Klaus Leidinger. Then the Sourceforge project "AVR ISP: AVR910 programmer firmware" which seems to be based on the above. Then there are other ports -- but most of them seem to be based on Klaus Leidinger's codes. I agree with @avrfreak, it is probably good to ignore the device codes if we want to support many more chips like avrosp/avrospii. |
Beta Was this translation helpful? Give feedback.
-
|
Just to archive the FW source codes from the above. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the AVR910 firmware for the UNO board @ 16Mhz. |
Beta Was this translation helpful? Give feedback.
-
|
Programming a 64K file in Fast Mode: Programming a 64K file in Slow Mode: |
Beta Was this translation helpful? Give feedback.
-
I suspect this can be done in a private @avrfreak appears to reuse an existing There seem to be firmware variants: @MCUdude has suggested the use of two different device codes, probably based on the observation that different firmware/bootloaders have made a different assignment and that so far no part gets assigned more than two different device codes. I suspect this is not quite as simple. Given a particular part, AVRDUDE needs to know which of the two device codes a programmer/firmware/protocol has assigned to it... The cleanest solution is to have a device code variable for each programmer/firmware/bootloader that has made their own extension of the AVR910 device code assignment. That is difficult to track down though (and how would a user know which firmware their AVR910 programmer has?)
There are quite a few post. If that is your current full avrdude.conf file it would not be clear what you have changed. As @mcuee said, if you submit a PR the it's much clearer what you have done, and it can instantly be tested. |
Beta Was this translation helpful? Give feedback.
-
|
avrdude.zip |
Beta Was this translation helpful? Give feedback.
-
Thanks. I installed that avrdude.conf file locally. Turns out its mapping of 96 parts to So, nothing more to do for AVRDUDE? BTW, here the inverse mapping in a bash loop: for code in $(avrdude -p*/St | grep 910_dev | sort | cut -f4 | sort -u); do
echo $code: $(avrdude -p*/St | grep 910_devcode.$code | cut -f2 | sed -es/ATmega/m/ -es/ATtiny/t/|tr A-Z a-z)
done
0x13: at90s1200
0x20: at90s2313 t87 t167 ata5505 ata6616c ata6617c ata664251 t25 t45 t85 t24 t24a t44 t44a t84 t84a t441 t841 t43u
0x28: at90s4414
0x30: at90s4433
0x34: at90s2333
0x38: at90s8515
0x3a: m8515
0x41: m103
0x43: m128 m128a
0x45: m64 m64a
0x48: at90s2323
0x4c: at90s2343
0x56: t12 t15
0x5c: t28
0x5e: t26 t2313 t2313a t4313
0x60: m161
0x63: m162
0x64: m163
0x68: at90s8535
0x69: m8535
0x6c: at90s4434
0x72: m32 m32a
0x74: m16 m16a m324p m164p m164pa m164a m324pb m324pa m324a m644 m644a m644p m644pa m1284 m1284p m325 m325a m325p m325pa m645 m645a m645p m3250 m3250a m3250p m3250pa m6450 m6450a m6450p
0x75: m329 m329a m329p m329pa m3290 m3290a m3290p m3290pa m649 m649a m649p m6490 m6490a m6490p
0x76: m8 m8a
0x78: m169 m169a m169p m169pa
|
Beta Was this translation helpful? Give feedback.
-
|
yes I did nothing new on the config file, the config file is from last year. |
Beta Was this translation helpful? Give feedback.
-
|
This is the run log for my modified You can see it works with ATmega328PB. Relevant entries for ATmega328/328P/328PB |
Beta Was this translation helpful? Give feedback.
-
This does not seem to work for me. So I was still using the older hex file (910-328p_16MHz_Rst_PB2.hex, from last year) in the previous run log. Failed run log with the latest hex file |
Beta Was this translation helpful? Give feedback.
-
|
I suggest you stop using avrdude 7.1 in my opinion it is nothing but trouble especially when trying to use a real RS232 serial port (not a TTL adapter), IT DOESN'T WORK. As for the error messages, "mosi is deprecated" now what is that supposed to mean? I guess the config file is not compatible with the avrdude version you are using. The only reason for uploading a new hex file is to allow the programmer to increase the SCK rate to 2MHz if PD6 & PD7 are joined. I use avrdude V6.3 with the config file I posted. Since I don't have a great deal of time to spend on this because of my job, anything after avrdude V6.3 has been too troublesome and time consuming for me to bother with. |
Beta Was this translation helpful? Give feedback.
-
I will for sure not use the ancient avrdude 6.3 version. You are missing really a lot of features if you stick to the 6.3 version. But anyway, that is your choice... If you have issues with real serial port, please create the issue. But I do not have PCs with real serial port now so I can not test that.
Yes, that is just for quick testing -- I reuse the old configuration file last year, which will cause warnings.
Thanks for the information. |
Beta Was this translation helpful? Give feedback.
-
This is a good point. I guess this issue is probably not worth the efforts in the end. But still thanks for your contribution. Maybe someone may find it useful in the future. |
Beta Was this translation helpful? Give feedback.
-
|
In this case, I will move this to discussion. If someone helps to create a PR then we can start from there again. |
Beta Was this translation helpful? Give feedback.
-
|
It may be good to support parts like ATmega2560 if possible. |
Beta Was this translation helpful? Give feedback.
-
|
@flyandancexo has the following based on AVR910 (FW source codes not available). There are another discussion here. |
Beta Was this translation helpful? Give feedback.
-
|
In the end, I think it is probably not worth the efforts. Close this. |
Beta Was this translation helpful? Give feedback.
-
Just got a serial port AVR910 prog (based on AT902313 and use some passive components for the serial interface) from AliExpress (along with a serial port based SI-Prog).
Currently avr910 only supports limited parts. Alternative PC applications like AVROSP2 supports many more parts. Microchip/Atmel original avrosp can support more parts as well with the proper xml files.
Beta Was this translation helpful? Give feedback.
All reactions