search

avrdudes / avrdude

AVRDUDE is a utility to program AVR microcontrollers
GNU General Public License v2.0
697 stars 136 forks source link

AVR910 programmer enhancment to support more parts #1060

Closed mcuee closed 1 year ago

mcuee commented 2 years ago

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.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM5 -b 115200 -qqp m328p
Found programmer: Id = "AVR ISP"; type = S
    Software Version = 3.8; Hardware Version = 1.2
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize = 64 bytes.

Programmer supports the following devices:
    Device code: 0x13 = AT90S1200
    Device code: 0x20 = AT90S2313
    Device code: 0x28 = AT90S4414
    Device code: 0x30 = AT90S4433
    Device code: 0x34 = AT90S2333
    Device code: 0x38 = AT90S8515
    Device code: 0x48 = (unknown)
    Device code: 0x4c = AT90S2343
    Device code: 0x51 = (unknown)
    Device code: 0x55 = ATtiny12
    Device code: 0x56 = ATtiny15
    Device code: 0x68 = AT90S8535
    Device code: 0x6c = AT90S4434
    Device code: 0xffffff86 = (unknown)
    Device code: 0xffffff87 = (unknown)
    Device code: 0x04 = (unknown)
    Device code: 0x05 = (unknown)
    Device code: 0x06 = (unknown)
    Device code: 0x07 = (unknown)
    Device code: 0x1a = (unknown)
    Device code: 0x1b = (unknown)
    Device code: 0x1c = (unknown)
    Device code: 0x1d = (unknown)
    Device code: 0x23 = (unknown)
    Device code: 0x31 = (unknown)
    Device code: 0x33 = (unknown)
    Device code: 0x37 = (unknown)
    Device code: 0x39 = (unknown)
    Device code: 0x3d = (unknown)
    Device code: 0x3e = (unknown)
    Device code: 0x3a = ATmega8515
    Device code: 0x3b = (unknown)
    Device code: 0x41 = ATmega103
    Device code: 0x43 = ATmega128
    Device code: 0x44 = (unknown)
    Device code: 0x45 = ATmega64
    Device code: 0x46 = (unknown)
    Device code: 0x5e = ATtiny26
    Device code: 0x60 = ATmega161
    Device code: 0x61 = (unknown)
    Device code: 0x62 = (unknown)
    Device code: 0x63 = ATmega162
    Device code: 0x64 = ATmega163
    Device code: 0x66 = (unknown)
    Device code: 0x69 = ATmega8535
    Device code: 0x6a = (unknown)
    Device code: 0x72 = ATmega32
    Device code: 0x73 = (unknown)
    Device code: 0x74 = ATmega16
    Device code: 0x75 = ATmega329
    Device code: 0x76 = ATmega8
    Device code: 0x77 = (unknown)
    Device code: 0x78 = ATmega169
    Device code: 0x79 = (unknown)

avrdude.exe: error: selected device is not supported by programmer: m328p
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.
mcuee commented 2 years ago

I made the program faster but it certainly won't work at 16 MHz because the data blocks are 256 bytes going to the programmer from avrprog. Surely there will be problems at 115200 baud rate with 16MHz.

Thanks for the clarification.

Lowering the baud rate will defeat the purpose. I did manage to get avrdude to program the atmega328p using the avr910 programmer.

I understand. Thanks for the help.

mcuee commented 2 years ago

https://avrdudes.github.io/avrdude/7.0/avrdude_39.html#Troubleshooting

Looks like baud rate is not the only problem.

Problem: I’m using Linux and my AVR910 programmer is really slow. Solution (short): setserial port low_latency

Solution (long): There are two problems here. First, the system may wait some time before it passes data from the serial port to the program. Under Linux the following command works around this (you may need root privileges for this).

setserial port low_latency

Secondly, the serial interface chip may delay the interrupt for some time. This behaviour can be changed by setting the FIFO-threshold to one. Under Linux this can only be done by changing the kernel source in drivers/char/serial.c. Search the file for UART_FCR_TRIGGER_8 and replace it with UART_FCR_TRIGGER_1. Note that overall performance might suffer if there is high throughput on serial lines. Also note that you are modifying the kernel at your own risk.

Problem: I’m not using Linux and my AVR910 programmer is really slow. Solutions: The reasons for this are the same as above. If you know how to work around this on your OS, please let us know.

avrfreak commented 2 years ago

Here is a hex file for the UNO or NANO that uses a 16MHz crystal. The reset pin has been moved to pin 10 (PB2). pin 11 = MOSI, pin 12 = MISO, pin 13 = SCK. I tested it with avrdude, avrprog and avrospII, all are working. This will make it easier for those who want to test straight away without mods to the board.

The buffer size has been changed to 256 bytes. This increases the speed of this programmer a great deal! The baud rate is 115200. The bootloader is also included. I added a bunch of previously unsupported devices mainly the atmega328p. You must use the attached avrdude.conf for the new devices to work.

Edit: use this one instead: 910-328p_16MHz_Rst_PB2.zip avrdude.zip

Please post any bugs or other problems.

mcuee commented 2 years ago

@avrfreak I need to find a good setup (probably some good ribbon cables, or to dig out the ISP shield) to test the hex file. My quick setup using ribbon cables do not work (device signature reading errors).

But the good thing is that your modified avrdude.conf works fine with avrdude 7.0 release and git main binary, using my USB AVR910 (only 19200 bps). That is a very good progress towards the main goal of this issue which is to extend the chip support.

Note: ignore the warnings from git main about the avrdude.conf file since you are still using old avrdude.conf as the starting point.

C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910> .\avrdude_git -c avr910 -P COM7 -b 19200 -p m328p
 -U .\910-328p_16MHz_Rst_PB2.hex
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:5828:
 ATmega329's flash writepage misses a necessary address bit a13
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:6054: 
ATmega649's flash writepage misses a necessary address bit a14
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:9244: 
AT90PWM2's eeprom writepage misses a necessary address bit a8
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11098:
 ATtiny44's eeprom writepage misses a necessary address bit a7
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11280: 
ATtiny84's eeprom writepage misses a necessary address bit a8
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
a4 would normally be expected to be a5
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
a3 would normally be expected to be a4
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
a2 would normally be expected to be a3
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
a1 would normally be expected to be a2
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
a0 would normally be expected to be a1
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11563: 
too few opcode bits in instruction
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11582: 
ATtiny43u's eeprom read misses a necessary address bit a5
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:11768: 
ATmega32U4's eeprom writepage misses a necessary address bit a2
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:12163: 
AT90USB1286's eeprom writepage misses a necessary address bit a11
avrdude_git.exe: warning at C:\work\avr\avrdude_test\avrdude_bin\avrdude_avr910\avrdude.conf:14919: 
ATtiny1634's flash writepage misses a necessary address bit a5

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 3.8; Hardware Version = 1.2
avrdude_git.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude_git.exe: Device signature = 0x1e950f (probably m328p)
avrdude_git.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
                 To disable this feature, specify the -D option.
avrdude_git.exe: erasing chip
avrdude_git.exe: reading input file .\910-328p_16MHz_Rst_PB2.hex for flash
                 with 2596 bytes in 2 sections within [0, 0x7fff]
                 using 21 pages and 92 pad bytes
avrdude_git.exe: writing 2596 bytes flash ...

Writing | ################################################## | 100% 2.40s

avrdude_git.exe: 2596 bytes of flash written
avrdude_git.exe: verifying flash memory against .\910-328p_16MHz_Rst_PB2.hex

Reading | ################################################## | 100% 1.34s

avrdude_git.exe: 2596 bytes of flash verified

avrdude_git.exe done.  Thank you.
avrfreak commented 2 years ago

there are no warnings when using both the new firmware & avrdude 6.3.

mcuee commented 2 years ago

Do not worry about the warnings in this case. It is the feature of the latest git main. In fact there is no warning with avrdude 7.0 release either.

Still it is better to base on the latest avrdude git version, or at least the 7.0 release. 6.3 version is a bit too old.

mcuee commented 2 years ago

Just compared the Arduino as ISP and my USB AVR910 programmer (both at 19200 bps), the speed does not differ much. Actually AVR910 is slightly faster reading back the full hex file than Arduino as ISP (19.91 seconds vs 21.17s). So stk500v1 protocol may not really be faster than avr910 protocol.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM5 -b 19200
 -p m328p -U .\910-328p_16MHz_Rst_PB2.hex
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 3.8; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\910-328p_16MHz_Rst_PB2.hex for flash
             with 2602 bytes in 2 sections within [0, 0x7fff]
             using 21 pages and 86 pad bytes
avrdude.exe: writing 2602 bytes flash ...

Writing | ################################################## | 100% 2.45s

avrdude.exe: 2602 bytes of flash written
avrdude.exe: verifying flash memory against .\910-328p_16MHz_Rst_PB2.hex

Reading | ################################################## | 100% 1.38s

avrdude.exe: 2602 bytes of flash verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM5 -b 19200
 -p m328p -U flash:r:readbackavr910.hex:i
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 3.8; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading flash memory ...

Reading | ################################################## | 100% 19.91s

avrdude.exe: writing output file readbackavr910.hex

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c stk500v1 -P COM3 -b 19200 -p m328p
 -U .\910-328p_16MHz_Rst_PB2.hex

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\910-328p_16MHz_Rst_PB2.hex for flash
             with 2602 bytes in 2 sections within [0, 0x7fff]
             using 21 pages and 86 pad bytes
avrdude.exe: writing 2602 bytes flash ...

Writing | ################################################## | 100% 2.56s

avrdude.exe: 2602 bytes of flash written
avrdude.exe: verifying flash memory against .\910-328p_16MHz_Rst_PB2.hex

Reading | ################################################## | 100% 1.48s

avrdude.exe: 2602 bytes of flash verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c stk500v1 -P COM3 -b 19200 -p m328p
 -U flash:r:readback_arduinoasisp.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading flash memory ...

Reading | ################################################## | 100% 21.17s

avrdude.exe: writing output file readback_arduinoasisp.hex

avrdude.exe done.  Thank you.
mcuee commented 2 years ago

@avrfreak

Using the same Arduino as ISP testing setup (an Uno CH340G clone plus an AVR ISP Shield), I can finally get your hex file working reliably. Nice. And it is three time faster than the above results in terms of reading the flash. Very nice!

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM3
 -b 115200 -p m328p -U .\910-328p_16MHz_Rst_PB2.hex
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 6.0; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\910-328p_16MHz_Rst_PB2.hex for flash
             with 2602 bytes in 2 sections within [0, 0x7fff]
             using 21 pages and 86 pad bytes
avrdude.exe: writing 2602 bytes flash ...

Writing | ################################################## | 100% 0.86s

avrdude.exe: 2602 bytes of flash written
avrdude.exe: verifying flash memory against .\910-328p_16MHz_Rst_PB2.hex

Reading | ################################################## | 100% 0.51s

avrdude.exe: 2602 bytes of flash verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM3 
-b 115200 -p m328p -U flash:r:readback_avr910_115200bps.hex:i
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 6.0; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading flash memory ...

Reading | ################################################## | 100% 6.78s

avrdude.exe: writing output file readback_avr910_115200bps.hex

avrdude.exe done.  Thank you.
mcuee commented 2 years ago

@avrfreak I think the Uno/Nano 16MHz hex is very nice. It will give people using Arduino as ISP a good upgrade path (much faster), if we can enhance the chip support. So I can say that your goal of making things faster with easily available HW has been achieved. Thanks a lot for the great work!

The next step is probably more on the chip support which is anyway the main goal of this issue.

If the only change required is avrdude.conf file (seems to be the case as I can actually use the latest avrdude git main), please help to provide the detail of change required based on your experiences. I think @stefanrueger can probably help to automate the required change.

mcuee commented 2 years ago

Just in case if people are interested, my AVR ISP Shield is something like the following. https://www.aliexpress.com/item/32853007180.html

avrfreak commented 2 years ago

thanks @mcuee. I can make it faster but I am sure the reliability will be compromised. There are still communication errors because of the 16MHz crystal, but those errors aren't that serious (I think it's under 2%).

I tested avrdude7 and it was nothing but trouble for (REAL RS232) serial port based programmers. Now maybe I didn't have the "official" version when I tested. This is why I continue to use avrdude6.3 because it works for my needs, even with the jtag2updi and avrdx parts.

I cannot test every single device because I don't have them all. I am relying on everyone to test any of the devices and report back here. I did test the atmega328p and it programs just as fast (or faster) than usbasp.

The programmer should now support these devices as long as the avrdude.exe and avrdude.conf files are used: ;added 33 new devices: ;atmega328, atmega328p, attiny2313/4313, atmega162 ;atmega2560,atmega2561 (not sure how avrdude or avrprog will handle the extended address?) ;atmega3250,atmega6450,atmega1284/p ;atmega1280,atmega1281 ;ATtiny261,ATtiny461,ATtiny861 ;ATmega48,ATmega88,ATmega168,ATtiny88 ;AT90PWM2,AT90CAN128,AT90CAN64,AT90CAN32 ;ATtiny25,ATtiny45,ATtiny85 ;ATtiny24,ATtiny44,ATtiny84 ;ATmega640,ATmega645,ATmega32u4

mcuee commented 2 years ago

I think 115200 bps is a good compromise for the Uno/Nano at 16MHz.. For faster speed, I think it is better to switch to other crystal values to avoid communication errors.

Just curious, with the configurations you mentioned before, can you achieve above 115200bps, say double the baud rate? 1) ATmega328p and ATmega128 using 14.7456 MHz crystal 2) ATmega8 & ATmega8535 using 7.3728 Mhz crystal (probably not difficult to port to ATmega16/32 with the same crystal)

BTW, I tested with ATmega128A and indeed the Uno AVR910 at 115200 bps is more or less as fast as usbasp when reading the flash.

MCUdude commented 2 years ago

Why not try 250000 or 500000 baud? At 16 MHz there's 0% error.

mcuee commented 2 years ago

I tested ATmega32U4 (official Arduino Leonardo board) and it works fine.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM3 -b 115200
 -p m32u4 -U .\hex\blinky_leonardo.ino.with_bootloader.leonardo.hex
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 6.0; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9587 (probably m32u4)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\hex\blinky_leonardo.ino.with_bootloader.leonardo.hex for flash
avrdude.exe: writing 32730 bytes flash ...

Writing | ################################################## | 100% 20.20s

avrdude.exe: 32730 bytes of flash written
avrdude.exe: verifying flash memory against .\hex\blinky_leonardo.ino.with_bootloader.leonardo.hex

Reading | ################################################## | 100% 6.74s

avrdude.exe: 32730 bytes of flash verified

avrdude.exe done.  Thank you.
mcuee commented 2 years ago

Testing results for ATmega2560: both reading and wrting will fail due to the extended address. But @stefanrueger may be able to find the workaround (just like usbtiny).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM3 -b 115200
 -p m2560 -U flash:r:m2560_avr910_uno_readback.hex:i
...
Found programmer: Id = "AVR ISP"; type = S
    Software Version = 6.0; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9801 (probably m2560)
avrdude.exe: reading flash memory ...

Reading | ################################################## | 100% 45.49s

avrdude.exe: writing output file m2560_avr910_uno_readback.hex

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude  -c usbasp -p m2560 
-U flash:v:m2560_avr910_uno_readback.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9801 (probably m2560)
avrdude.exe: verifying flash memory against m2560_avr910_uno_readback.hex

Reading | ################################################## | 100% 41.73s

avrdude.exe: verification error, first mismatch at byte 0x0000
             0x0d != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude63_avr910.conf -c avr910 -P COM3 -b 115200
 -p m2560 -U .\blink-mega2560+lext-test.hex
...

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 6.0; Hardware Version = 1.2
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9801 (probably m2560)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\blink-mega2560+lext-test.hex for flash
             with 1346 bytes in 4 sections within [0, 0x3106d]
             using 7 pages and 446 pad bytes
avrdude.exe: writing 1346 bytes flash ...

Writing | ################################################## | 100% 0.38s

avrdude.exe: 1346 bytes of flash written
avrdude.exe: verifying flash memory against .\blink-mega2560+lext-test.hex

Reading | ################################################## | 100% 0.20s

avrdude.exe: verification error, first mismatch at byte 0x11000
             0x40 != 0x42
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.
avrfreak commented 2 years ago

Why not try 250000 or 500000 baud? At 16 MHz there's 0% error.

Because avrprog won't support that baud rate. (please correct me if i am wrong)

avrfreak commented 2 years ago

Testing results for ATmega2560: both reading and wrting will fail due to the extended address. But @stefanrueger may be able to find the workaround (just like usbtiny). I knew about this, however since we can't change avrprog.exe I suggest we leave it alone.

So far I tested: m328p, m162, t4313, t2313, t861, m168 (not "p" since i don't have any) t25, t44 all with 100% success

I expect the above and their counterparts (i.e. t45/85 and t24/84) to also work.

MCUdude commented 2 years ago

Because avrprog won't support that baud rate. (please correct me if i am wrong)

But avrprog is long EOL, and since Avrdude supports all baudrates, I don't see why we shouldn't try.

avrfreak commented 2 years ago

Because avrprog won't support that baud rate. EDIT: I tested it and it won't support anything higher than 115200 same with avrospII.

But avrprog is long EOL, and since Avrdude supports all baudrates, I don't see why we shouldn't try.

well all the hard part is done now. I can just change the usart configuration and we can give it a whirl.

avrfreak commented 2 years ago

It works at 250K baud only with avrdude, however it's no faster than 115200 (well it is, 0.8 sec faster when writing a 2K file) . Surely this will make the larger mcu's program a little bit faster. 910-328p_250K_16MHz_NoBootloader.zip I think the only way to make it REALLY faster is to increase the SPI speed. For this we need to implement the hardware SPI again so this means that the reset pin would have to be moved back to PB1 (pin 9). This will cause a lot of headaches with slower target clock speeds and especially virgin chips.

This is why I like the avr910 programmer in the first place - it's reliable and you don't have to always change the B value like usbasp. This log is from an ATtiny25 @ 115200 bps. `avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9108 (probably t25) avrdude: erasing chip avrdude: reading input file "2K.hex" avrdude: input file 2K.hex auto detected as Intel Hex avrdude: writing flash (2048 bytes):

Writing | ################################################## | 100% 2.07s

avrdude: 2048 bytes of flash written avrdude: verifying flash memory against 2K.hex: avrdude: load data flash data from input file 2K.hex: avrdude: input file 2K.hex auto detected as Intel Hex avrdude: input file 2K.hex contains 2048 bytes avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.90s

avrdude: verifying ... avrdude: 2048 bytes of flash verified avrdude: reading input file "128.hex" avrdude: input file 128.hex auto detected as Intel Hex avrdude: writing eeprom (128 bytes):

Writing | ################################################## | 100% 2.23s

avrdude: 128 bytes of eeprom written avrdude: verifying eeprom memory against 128.hex: avrdude: load data eeprom data from input file 128.hex: avrdude: input file 128.hex auto detected as Intel Hex avrdude: input file 128.hex contains 128 bytes avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.44s

avrdude: verifying ... avrdude: 128 bytes of eeprom verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done. Thank you.`

This log is from the same ATtiny25 @ 250000 bps. You can see it's not much faster.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9108 (probably t25) avrdude: erasing chip avrdude: reading input file "2K.hex" avrdude: input file 2K.hex auto detected as Intel Hex avrdude: writing flash (2048 bytes):

Writing | ################################################## | 100% 1.99s

avrdude: 2048 bytes of flash written avrdude: verifying flash memory against 2K.hex: avrdude: load data flash data from input file 2K.hex: avrdude: input file 2K.hex auto detected as Intel Hex avrdude: input file 2K.hex contains 2048 bytes avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.30s

avrdude: verifying ... avrdude: 2048 bytes of flash verified avrdude: reading input file "128.hex" avrdude: input file 128.hex auto detected as Intel Hex avrdude: writing eeprom (128 bytes):

Writing | ################################################## | 100% 2.18s

avrdude: 128 bytes of eeprom written avrdude: verifying eeprom memory against 128.hex: avrdude: load data eeprom data from input file 128.hex: avrdude: input file 128.hex auto detected as Intel Hex avrdude: input file 128.hex contains 128 bytes avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.45s

avrdude: verifying ... avrdude: 128 bytes of eeprom verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done. Thank you.`

avrfreak commented 2 years ago

I just tested programming an atmega1284 with a 128K flash hex file and a 4K eeprom hex file.

at 115200 bps flash programs in 20.84 seconds and the eeprom programs in 55 seconds at 250000 bps flash programs in 17.76 seconds and the eeprom programs in 53.5 seconds using usbasp with bitclock setting 187.5 KHz (it won't work otherwise on a virgin chip) the flash programming time = 38 seconds (twice as slow as the modded avr910)
the eeprom programming time = 44 seconds (11 seconds faster than the modded avr910)

The eeprom programming routine has a 10mS delay between each byte. I can try to speed this up, however I think with most devices you need at least 5 mS delay (depending on the specific device). IIRC the older 90S devices really needed this 10 mS delay. I didn't see a page write in the eeprom programming routine. I have to investigate.

avrfreak commented 2 years ago

Here is a log @ 500,000 bps programming 128K flash and 4K eeprom. Not much faster, one second faster fro the flash 3 sec faster on the eeprom

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9706 (probably m1284) avrdude: erasing chip avrdude: reading input file "128K.hex" avrdude: input file 128K.hex auto detected as Intel Hex avrdude: writing flash (65552 bytes):

Writing | ################################################## | 100% 16.36s

avrdude: 65552 bytes of flash written avrdude: verifying flash memory against 128K.hex: avrdude: load data flash data from input file 128K.hex: avrdude: input file 128K.hex auto detected as Intel Hex avrdude: input file 128K.hex contains 65552 bytes avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.06s

avrdude: verifying ... avrdude: 65552 bytes of flash verified avrdude: reading input file "4K.hex" avrdude: input file 4K.hex auto detected as Intel Hex avrdude: writing eeprom (4096 bytes):

Writing | ################################################## | 100% 51.69s

avrdude: 4096 bytes of eeprom written avrdude: verifying eeprom memory against 4K.hex: avrdude: load data eeprom data from input file 4K.hex: avrdude: input file 4K.hex auto detected as Intel Hex avrdude: input file 4K.hex contains 4096 bytes avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 4.08s

avrdude: verifying ... avrdude: 4096 bytes of eeprom verified

avrdude: safemode: Fuses OK (E:FF, H:99, L:62)

avrdude done. Thank you. 910-328p_500K_16MHz.zip

MCUdude commented 2 years ago

Looks like there's no real need to go beyond 115200 baud them.

But is there no way to program other devices than the ones that are listed in the programmer's device code list? The AVR910 may be reliable, but it's inconvenient as a general-purpose programmer if it's limited to ~13 or something targets. I use the ATmega324 a lot, and there exist 4(!) different variants with different signatures. There are A, P, PA, and PB models.

(Sorry for the dumb questions, I've just not used the AVR910 all that much)

avrfreak commented 2 years ago

Looks like there's no real need to go beyond 115200 baud them.

But is there no way to program other devices than the ones that are listed in the programmer's device code list? The AVR910 may be reliable, but it's inconvenient as a general-purpose programmer if it's limited to ~13 or something targets. I use the ATmega324 a lot, and there exist 4(!) different variants with different signatures. There are A, P, PA, and PB models.

(Sorry for the dumb questions, I've just not used the AVR910 all that much)

I agree, Keep it at 115200 baud and it works for guys like me who use a real RS232 port. As for the devices, avrospII can program them all but very slow.

Here is a communication log between the host and the programmer from when avrospII starts up. Avr-Osp_Startup.zip Here is one from avrprog.exe. You can see that avrprog.exe sends the device list to the host while avrospII does not. AVRProg_Startup.zip

I can't get the post code function working on this site which is why i am posting the files. The logs are very short, you can compare the two to see how each app communicates with the programmer. I have logs of all operations (prog flash, eeprom, fuses, lock, etc) if you are interested.

The code can be modified and new devices added to the list easily, but its how avrdude interprets the device list that makes or breaks this programmer. So what is really needed is someone who knows the inner workings of avrdude. Maybe it's just a matter of editing the conf file with the new device codes. We have tons of room in the atmega328p for tables (the code take up only 2K so we have 30K left over!) We can add as many devices we want to the list AS LONG AS avrdude can interpret the device list or don't use the device list at all, allowing avrdude to take more control over the programming operations. I am no expert when it comes to avrdude and the conf files.

Maybe creating another programmer name called avr910PRO, adding this to avrdude so that it will accept the new device codes without losing support for the legacy version.

As it is now, it's fine for all the devices I use. Because my programmer uses a db9 connection, the programmer sits on my desk, is always connected, uses no power until I turn it on, and does not tie up a usb port.

mcuee commented 2 years ago

I see two options. 1) Extend existing avr910 codes to support new chips --using the device list and edit avrdude.conf to support new chips (with no or minor changes to the avr910 codes). It may require programmers with better CPU and not the original ATtiny2313. This should not be a problem at all as the Uno/Nano clones are cheap enough (with CH340G USB-TTL). And for those who prefer DIY, ATmega8A/88A/16A + Crystal + USB-to-TTL converter are also very cheap.

2) Create a new avr910pro which do not use device list at all.

Maybe short term Option 1 is good to go. Option 2 is probably the better ways in the long run.

avrfreak commented 2 years ago

Here is the final version for the UNO at 16 MHz using PB2 as reset. I corrected some minor errors. Also added attiny48. You will need the new avrdude.conf file. avrdude.zip 910-328p_16MHz_Rst_PB2.zip

If you want to program your UNO from the bootloader download the 910-UNO.zip. Run it, enter your com port and it will program your UNO using the bootloader when the UNO is connected to the USB port. 910-UNO.zip

avrfreak commented 2 years ago

I see two options.

  1. Extend existing avr910 codes to support new chips --using the device list and edit avrdude.conf to support new chips (with no or minor changes to the avr910 codes). It may require programmers with better CPU and not the original ATtiny2313. This should not be a problem at all as the Uno/Nano clones are cheap enough (with CH340G USB-TTL). And for those who prefer DIY, ATmega8A/88A/16A + Crystal + USB-to-TTL converter are also very cheap.
  2. Create a new avr910pro which do not use device list at all.

Maybe short term Option 1 is good to go. Option 2 is probably the better ways in the long run.

I think option 2 is the better way to go,

mcuee commented 2 years ago

Quick test using my test setup (Uno CH340G clone + AVR ISP Shield, target another Uno CH340G clone) and a 32KB hex file. Indeed the differences between 115200 bps and 500000 bps are not significant.

Baudrate Flash writing Flash verification
115200 22.43 s 6.8 s
250000 20.62 s 6.63 s
500000 20.16 s 6.65 s
mcuee commented 2 years ago

@avrfreak

However I see a big advantage of the 250k baud and 500k baud version, they are more tolerant to the setup (due to less serial communication timing error). My ribbon cable setup (which has no issues with Arduino as ISP and ScratchMonkey) could not work with 115200 version, but they work flawlessly with the 250k/500k baud verrsion.

The only setup I can get the 115200 baud version work is with the "AVR ISP Shield". I am ordering three more shields so that I can easily test Uno AVR910, Arduino as ISP and ScratchMonkey at the same time.

Please help to provide your hex files with 250k/500k baud corresponding to the last version. Thanks.

avrfreak commented 2 years ago

My ribbon cable setup

What is this cable? Between the programmer and the target or the programmer and the PC? I posted the files already. Those are the latest versions. I only changed some minor errors in the 115200 16 MHz version.

mcuee commented 2 years ago

My ribbon cable setup

What is this cable? Between the programmer and the target or the programmer and the PC? I posted the files already. Those are the latest versions. I only changed some minor errors in the 115200 16 MHz version.

Thanks for the clarification for the hex files. Good that the 250k/500k baud hex files are already the latest.

By ribbon cable I mean the connection between the programmer and the target. The interface to the PC is always USB.

mcuee commented 2 years ago

Comparison of Uno based programmers using the "ribbon cable" setup and same 32KB hex file.

Interestingly ScratchMonkey is faster than AVR910 in terms of flash writing but not flash verification. Arduino as ISP only works for 19200 baud so it is always the slowest.

Programmer Flash writing Flash verification
Uno AVR910 500000 bps 20.11 s 6.65 s
ScratchMonkey stk500v2 14.59 s 14.34 s
AVR ISP shield stk500v1 19200bps 36.75 s 20.47 s
avrfreak commented 2 years ago

That cable will have nothing to do with the baud rates or changes to the baud rate. The PC communicates with the programmer, then the programmer relays the data to the target via SPI. The speed is controlled by the programmer. (there is only one speed, not adjustable like the USBASP programmer)

If you are having communication issues with the PC it's probably the board you are using. I have had good luck with the CH340G but the PL2303 are total garbage. Every single one I have tried is unreliable. Maybe because it's difficult to file a genuine Prolific PL2303 device anywhere, I don't know.

mcuee commented 2 years ago

Indeed it may have something to do with my paticular setup (Windows 11 laptop, USB Type C port and then a 4-port USB Hub). Anyway, that is just my experience.

It has nothing to do with the USB chipset either. I tested 4 Uno clones, 2 are using ATmega16U2 (same as official design) oand the other two are using CH340G. And all 4 of them have the same results: ribbon cable setup works with 250k/500k baud FW but not 115200 baud FW. AVR ISP Shield setup works with all FW (115200/250k/500k baud).

The setup is probably a bit messy. testsetup_avr910

mcuee commented 1 year ago

@avrfreak

Would you please create a pull request to modify avrdude.conf.in to support more classic AVR parts for the AVR910 programmers based on your avrdude.conf 6.3 version? If you are not willing to do that, I will give that a try. Thanks.

mcuee commented 1 year ago

Here is the modified avrdude_avr910.conf as well as the latest git main version of the avrdude mingw64 version, using my USB AVR910 programmer (PL2303+ATmega9535, it seems to only run in 19200 bps).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git.exe -C .\avrdude_avr910.conf -c avr910 -P COM19
 -p m328p -U .\hex\Blink.ino.with_bootloader.standard.hex

avrdude_git: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude_git: device signature = 0x1e950f (probably m328p)
avrdude_git: Note: flash memory has been specified, an erase cycle will be performed.
             To disable this feature, specify the -D option.
erasing chip
avrdude_git: reading input file .\hex\Blink.ino.with_bootloader.standard.hex for flash
             with 1426 bytes in 3 sections within [0, 0x7fff]
             using 12 pages and 110 pad bytes
avrdude_git: writing 1426 bytes flash ...

Writing | ################################################## | 100% 1.20s

avrdude_git: 1426 bytes of flash written
avrdude_git: verifying flash memory against .\hex\Blink.ino.with_bootloader.standard.hex

Reading | ################################################## | 100% 0.66s

avrdude_git: 1426 bytes of flash verified

avrdude_git done.  Thank you.

avrdude_git_avr910.zip

avrfreak commented 1 year ago

you have to specify the baud rate -b 115200 or it defaults to 19200

mcuee commented 1 year ago

you have to specify the baud rate -b 115200 or it defaults to 19200

My USB AVR910 has a lower frequency crysgtal and it can not support 115200bps.

mcuee commented 1 year ago

Comparison of Uno based programmers using the "ribbon cable" setup and same 32KB hex file.

Interestingly ScratchMonkey is faster than AVR910 in terms of flash writing but not flash verification. Arduino as ISP only works for 19200 baud so it is always the slowest.

With optimization (comment out all the LED related codes), Arduino as ISP can work well with 115200bps.

Programmer Flash writing Flash verification
Uno AVR910 500000 bps 20.11 s 6.65 s
ScratchMonkey stk500v2 14.59 s 14.34 s
AVR ISP shield stk500v1 19200bps 36.75 s 20.47 s
AVR ISP shield stk500v1 115200bps 21.99 s 11.51 s 
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c stk500v1 -P COM5 -b 115200 -p m328p -U flash:w:.\zeros32KB.hex:i

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
erasing chip
avrdude: reading input file .\zeros32KB.hex for flash
         with 32768 bytes in 1 section within [0, 0x7fff]
         using 256 pages and 0 pad bytes
avrdude: writing 32768 bytes flash ...

Writing | ################################################## | 100% 21.99 s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against .\zeros32KB.hex

Reading | ################################################## | 100% 11.51 s

avrdude: 32768 bytes of flash verified

avrdude done.  Thank you.
mcuee commented 1 year ago

@avrfreak

Just wondering if you are still interested to create a PR to modify avrdude.conf.in to support more parts. Thanks,

avrfreak commented 1 year ago

I don't know a lot about avrdude and the conf files.

I did however create another file for the UNO board that will work at a faster programming speed. I got it to program a 64K file in about 3 - 4 seconds. You just need to add a jumper wire between pins 6 & 7 for fast mode, leave it off for normal mode. Most files are not 64K in size so they will program in 1 or 2 seconds.

The code works with an unmodified UNO @ 16MHz with the reset pin configured for the programming sheild. I will try and upload it in the next few days.

stefanrueger commented 1 year ago

It is slightly unclear to me how to do this:

So this can be done for one firmware extension at the expense of other incompatible firmware extensions.

mcuee commented 1 year ago

It is slightly unclear to me how to do this:

  • The AVR910 protocol only defines a small number of old parts
  • The used device code is one byte, so max 256 parts even if there was a single authoritative list how to allocate codes
  • It is a protocol, so both the new firmware and new AVRDUDE code/config file need to agree. Are there competing different firmware extensions by different people?
  • How should the protocol be extended to deal with flash memories in excess of 128 kB?

So this can be done for one firmware extension at the expense of other incompatible firmware extensions.

@stefanrueger

I may be wrong but I tend to think if we ignore the AVR910 IDs (changing avrdude codes), we can support the classic AVRs which support ISP, without touching the firmware.

From what I see the different firmware is just to adapt to different AVR used and different clock speed.

http://ww1.microchip.com/downloads/en/appnotes/atmel-0943-in-system-programming_applicationnote_avr910.pdf

avrfreak commented 1 year ago

The avr910 firmware in the programmer defines a small number of older parts. You would have to change avrprog.exe or avrdude.conf to allow more entries. Since we can't change avrprog.exe the only way to do it is with avrdude.conf.

As I mentioned before, I have little knowledge of the avrdude.conf file.

IIRC, I used similar avr910 codes for similar devices. For the attiny2313, I used the AVR910 Attiny26 device code. For the atmega328, I used the Atmega32 code. The avrdude.conf file was modified with the similar device code. Then the page sizes and fuse bytes, signature bytes, etc, etc, etc were all checked with each datasheet.

The page sizes must be the same if you are using avrprog.exe but they can be changed in avrdude.conf when newer devices are added. You can see what I have done in the avrdude.conf file I posted above.

For avrospII.exe you just install the latest microchip studio. (I think you have to delete the dat file then restart avrospII.exe and the devicelist.dat will regenerate. The problem with avrosp.exe is that it is very slow. I don't remember why, (I think avrosp sends the data one byte at a time from the PC to the programmer.

AVRprog supports Atmega128. You can select Atmega128 for use with atmega1284.

What I just did recently was added a jumper setting just like the old USBASP firmware where it allows you to select slow SCK. IIRC, Slow SCK = 125 kHz and fast SCK = 4MHz. The faster speed is mainly for programming AVR's with a large crystal (like the UNO's, 16 MHz)

I don't think this modification is for everyone, especially when you can just buy a USBASP for under $3 which will support newer devices with avrdude.

avrfreak commented 1 year ago

910-328p.zip

Here is the AVR910 firmware for the UNO board @ 16Mhz. Please read the readme.txt.

avrfreak commented 1 year ago

Programming a 64K file in Fast Mode:

C:\910-UNO>avrdude -c avr910 -p m644 -P com3 -b 115200 

-C avrdude.conf -e -U flash:w:64K.hex:a
avrdude: AVR device initialized and ready to accept 

instructions

Reading | 

################################################## | 

100% 0.01s

avrdude: Device signature = 0x1e9609 (probably m644)
avrdude: erasing chip
avrdude: reading input file "64K.hex"
avrdude: input file 64K.hex auto detected as Intel Hex
avrdude: writing flash (65536 bytes):

Writing | 

################################################## | 

100% 11.70s

avrdude: 65536 bytes of flash written
avrdude: verifying flash memory against 64K.hex:
avrdude: load data flash data from input file 64K.hex:
avrdude: input file 64K.hex auto detected as Intel Hex
avrdude: input file 64K.hex contains 65536 bytes
avrdude: reading on-chip flash data:

Reading | 

################################################## | 

100% 7.88s

avrdude: verifying ...
avrdude: 65536 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:CE)

avrdude done.  Thank you.

Programming a 64K file in Slow Mode:

C:\910-UNO>avrdude -c avr910 -p m644 -P com3 -b 115200 -C avrdude.conf -e -U flash:w:64K.hex:a

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9609 (probably m644)
avrdude: erasing chip
avrdude: reading input file "64K.hex"
avrdude: input file 64K.hex auto detected as Intel Hex
avrdude: writing flash (65536 bytes):

Writing | ################################################## | 100% 27.89s

avrdude: 65536 bytes of flash written
avrdude: verifying flash memory against 64K.hex:
avrdude: load data flash data from input file 64K.hex:
avrdude: input file 64K.hex auto detected as Intel Hex
avrdude: input file 64K.hex contains 65536 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 19.42s

avrdude: verifying ...
avrdude: 65536 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:CE)

avrdude done.  Thank you.
stefanrueger commented 1 year ago

the only way to do it is with avrdude.conf

I suspect this can be done in a private ~/.avrduderc file (in Windows the file avrdude.rc in the directory where avrdude.exe resides).

@avrfreak appears to reuse an existing avr910_devcode for every new part that can be programmed with the existing (original?) AVR910 firmware. That is reasonable and these codes could be added to avrdude.conf.

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?)

You can see what I have done in the avrdude.conf file I posted above

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.

avrfreak commented 1 year ago

avrdude.zip this is the one. Just look for "avr910_devcode" in the file.

stefanrueger commented 1 year ago

look for "avr910_devcode" in the file

Thanks. I installed that avrdude.conf file locally. Turns out its mapping of 96 parts to avr910_devcode numbers is already the same as that of git mainline:

$ avrdude_avrfreak -p*/St | grep 910_devcode | sort >/tmp/1
$ avrdude_git_main -p*/St | grep 910_devcode | sort | diff - /tmp/1

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
avrfreak commented 1 year ago

yes I did nothing new on the config file, the config file is from last year.