Replies: 23 comments 80 replies
-
|
The following page is a good summary of AVR programmers (in German but Google Translate seem to work well). It has some benchmarks as well with avrdude 5.5. The test file was 29704 bytes in size. Target is an ATmega6490 clocked at 8MHz by the RC oscillator. All this was tested with an AVRDUDE 5.5. |
Beta Was this translation helpful? Give feedback.
-
|
From #1106, results from @MCUdude using STK600: reading the ATmega2560 in 12.8s. This beats my AVRISP mkii result of 14.52s. @MCUdude thinks that the reason is probably because of the use of a USB AVR in STK600 vs the use of an non-USB AVR plus a USB controller in AVRISP mkii. |
Beta Was this translation helpful? Give feedback.
-
|
Results for USBasp, reading of ATmega2560 in 40.34s, without using |
Beta Was this translation helpful? Give feedback.
-
|
USBtinyISP result: reading of ATmega2560 takes 186.50 seconds. |
Beta Was this translation helpful? Give feedback.
-
|
PICKit 4 result in ISP mode, same results with and without |
Beta Was this translation helpful? Give feedback.
-
|
Same test cases using STK500v2 clone. |
Beta Was this translation helpful? Give feedback.
-
|
Different clones seem to have quite different performances. Another clone. Yet another clone: |
Beta Was this translation helpful? Give feedback.
-
|
You may be limiting the speed by using -B1 flag. -B1 is forcing a 1us clock, whick might not be the fastest option a programmer can reach. Try -B0.5 or -B0.25 and see if this is faster. Use -v to see what the actual clock speed ends up as. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tip. I will try. Interestingly I found that |
Beta Was this translation helpful? Give feedback.
-
|
Indeed
click for detail run log |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
For
|
Beta Was this translation helpful? Give feedback.
-
|
I compared three programmers last year using ATmega328P as the target with a 32KB hex file, in Nov 2022.
|
Beta Was this translation helpful? Give feedback.
-
|
See my results #1528 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Just for info if others are interested to boost the performnace of `Arduino as ISP', you can check out the repo by Martin. |
Beta Was this translation helpful? Give feedback.
-
|
The sketch is very well optimized and it is very fast. I have tested it with ATmega328PB and ATmega2560. ATmega328PB: 32KB Flash, write 6.78s and verification (read) 5.50s |
Beta Was this translation helpful? Give feedback.
-
|
I had no peace before I also optimised the writing of the EEPROM in my nanoSTK_V1 - now I write the EEPROM data page by page instead of single bytes
|
Beta Was this translation helpful? Give feedback.
-
|
@Ho-Ro Looks cool. There is more to consider than speed. For example, eeprom has only a limited number of write cycles. Perhaps consider an advanced method to read the eeprom contents before writing to make a decision whether the cell needs changing at all (and if nothing needs doing that is much faster, too ;) This can lead to a trade-off when writing an EEPROM page, though, when for example only 5 cells of an 8-byte page need changing. For me, not wasting unnecessary EEPROM programming cycles wins. |
Beta Was this translation helpful? Give feedback.
-
According data sheet the risk of destroying the memory via ISP is less, frequent writing of the AVR appliction firmware to the same address is more likely to destroy the EEPROM. However, there are good wear-leveling algorithms against this. Datasheet (e.g. m328p): The Flash memory has an endurance of at least 10,000 write/erase cycles.
There's an easy solution, see this part from data sheet: The EEPROM array is programmed one page at a time. The Memory page is loaded one byte at a time by supplying the 6 LSB of the address and data together with the Load EEPROM Memory Page instruction. The EEPROM Memory Page is stored by loading the Write EEPROM Memory Page Instruction with the 7 MSB of the address. When using EEPROM page access only byte locations loaded with the Load EEPROM Memory Page instruction is altered. The remaining locations remain unchanged. Remark: According to Table 28-19 6 LSB is wrong, it must be 2 LSB, also 7 MSB must be 10 MSB for m328p with 1024 byte EEPROM:
Solution for my nanoSTK_V1 code: EEPROM page writestatic uint8_t write_eeprom( uint16_t length ) {
uint16_t ee_addr_wr = here; // write address of EEPROM
if ( use_arduino_protocol ) {
// arduino bootloader protocol sends word addresses also for EEPROM
// calculate the EEPROM byte address
ee_addr_wr *= 2;
}
fill( length ); // get EEPROM page data
uint16_t ee_addr_rd = ee_addr_wr; // read address of EEPROM
bool page_has_changed = false;
for ( uint16_t pg_idx = 0; pg_idx < length; ++pg_idx ) {
uint8_t data = buff[ pg_idx ];
if ( data != read_eeprom_byte( ee_addr_rd++ ) ) {
load_eeprom_page( pg_idx, data );
page_has_changed = true;
}
}
if ( page_has_changed ) {
write_eeprom_page( ee_addr_wr );
delay( wait_delay_EEPROM );
}
return Resp_STK_OK;
}This decreases the writing time for 1024 byte identical EEPROM content from 2.8 s down to 1.8 s, the serial and ISP transfer becomes more and more the bottleneck :) |
Beta Was this translation helpful? Give feedback.
-
|
Well done! The code looks good (but I am sure you'll test it too). |
Beta Was this translation helpful? Give feedback.
-
|
100232/3.62=27688 bytes per second with my FDxboot_1.51x on an Atmega128a. This is a typical upload test, the maximum upload speed is 31K bytes recorded. This is at 1Mbps. I am able to get it upload even faster at 2Mbps, but it failed because AVRdude apparently has a too short delay timer because the full page is sent back to it, so the data is written fine at 2Mbps, but read back is incorrect. This is probably not the place to ask for help? |
Beta Was this translation helpful? Give feedback.
-
|
You should try the same test with the latest Avrdude 7.2 and see if that helps |
Beta Was this translation helpful? Give feedback.
-
|
Some other test results from @flyandancexo for his optimized AVR910 programmer. |
Beta Was this translation helpful? Give feedback.
-
|
As per @flyandancexo, mingw64 build is slower than msvc64 build for his optimized AVR910 programmer. My tests using avrdude 7.3 release show this is indeed correct too for usbasp programmer. |
Beta Was this translation helpful? Give feedback.
-
|
Same for avrdude 7.2 release. |
Beta Was this translation helpful? Give feedback.
-
|
The arduino version for avrdude 7.2 is closer to msvc64 build. Same for avrdude 7.3 release. |
Beta Was this translation helpful? Give feedback.
-
|
I am guessing this has something to do with compiler optimization. I will see if I can build the MSYS2 mingw64 with better compiler optimization to see if that helps. The arduino version is with older version of gcc whereas MSYS2 mingw64 version is with very new gcc compiler version. msvc64 version is using VS2022 and using avrdude-libusb instead of the standard libusb-1.0 (or libusb-compat-0.1) with the MSYS2 and arduino build. |
Beta Was this translation helpful? Give feedback.
-
|
MSVC build is optimized. |
Beta Was this translation helpful? Give feedback.
-
|
urboot bootloader test results -- CH340G based Uno Clone. |
Beta Was this translation helpful? Give feedback.
-
|
Old avr109 xboot results from @MCUdude, 115200bps, back in Sept 2022. Another xboot avr109 bootloader result here, using FT22RL based adapter, with 2M baud rate. This was tested in Jan 2024 by @MCUdude. |
Beta Was this translation helpful? Give feedback.
-
|
urboot is not too slow. Previous tests were done with auto-baudrate. The following is with faster baudrate. |
Beta Was this translation helpful? Give feedback.
-
Not sure if you're joking or not. Unlike Optiboot, Urboot uses a protocol specifically designed for SPM bootloaders, where the Avrdude side is doing the heavy lifting. That greatly reduces the size of the actual binary and the upload speed. The STK500 protocol was designed to be a protocol between an ISP programmer and the PC. Thus, a bootloader that emulates the STK500 protocol will not be as efficient, because the protocol isn't optimized for SPM. @mcuee bear in mind that the CH340 USB to serial adapter is in my experience quite slow, and driver settings may play a big role here. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that CH340x is not as good as the others but it is the one used most often in the cheap Uno or Mega clones. It is also used in the Nano 4808 clones. I will try to test with other USB to TTL converters. |
Beta Was this translation helpful? Give feedback.
-
|
When you have some time, please post your results with urclock and other bootloader as well and compare CH340 vs CP2102 or FT232R. Majority of my USB to TTL converters and boards come with CH340. |
Beta Was this translation helpful? Give feedback.
-
8235B/s is much faster, but still very slow, actually extremely slow for a big mcu like that. My bootloader doesn't need an IO pin to enter bootloader mode. It automatically enters bootloader mode after the MCU resets itself and return to application after 500ms to 4s (the compiled hex has a 1 second delay), so the first upload is free, since there is no code in the application section. The second upload, you need to press the reset button. AVR109 doesn't issue an DTR or RTS signal on serial, so auto upload is not possible with avr109. |
Beta Was this translation helpful? Give feedback.
-
|
2MHz it will fail. |
Beta Was this translation helpful? Give feedback.
-
|
Same for avrdude 7.2 MSVC64 version. |
Beta Was this translation helpful? Give feedback.
-
|
urboot stk500v1 bootloader (STK500v1), 1M baud rate. |
Beta Was this translation helpful? Give feedback.
-
|
Similar result for urboot with another Arduino Nano clone with ATmega328P and CH340x. Tested with Acer Swift 3 Windows 11 Laptop (2021 model, Core i5-1135G7, 16GB RAM, 512GB SSD). |
Beta Was this translation helpful? Give feedback.
-
|
Similar results with the optimized AVR109 bootloader as well. 1M baud is okay but not 2M baud. |
Beta Was this translation helpful? Give feedback.
-
You may want to elaborate to see how avrdude can be improved. Please help to take a look as well. Thanks. |
Beta Was this translation helpful? Give feedback.
-
If you really want to get things done, you have to do it yourself. The 2M bug has been spotted on finally and bypassed. It's very stable at 2Mbps now, using the exact same CH340g and same boards. Here are the test results and the re-compiler bootloader for atmega328p at 2Mbps. You double check if the error has really been gone or not. The upload speed should be 27kB/s and download 50kB/s now for the atmega328p at 2M. Please update the record after you have confirmed it and re-think about how great the CH340g is. Ch340x is probably better than other. I don't know how fast other chips can go, but CH340g can go 2Mbps, and I have confirmed it here. PS. SPM is very efficient already. The quote that you took from other people is dumb and false, and it's probably just marketing slang to entice you to use their bootloader. FDxboot 1.62@2Mbps with CH340G: Atmega16: Atmega128A: |
Beta Was this translation helpful? Give feedback.
-
|
So the conclusion based on the above test is that avrdude has no 2M baud bug. CH340 seems to be the bottleneck. Note: please set FT232RL adapter latency timer to 1ms (Windows and Linux) before carrying out the benchmark test. ATmega328P, avrdude 7.3 release msvc64 binary urboot 1M baud rate (CH340) urboot 1M baud rate (Uno ATmega16U2) urboot 2M baud rate (Uno ATmega16U2) urboot 2M baud rate (Nano FT232RL) FDxboot optimized avr109 at 1M baud rate (1.61beta) (CH340) FDxboot optimized avr109 at 2M baud rate (1.62beta stable) (CH340) FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (Uno ATmega16U2) FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (Nano FT232RL) STK500v1 (from urboot) at 1M baud rate (CH340) @flyandancexo's results are a bit better for the CH340, probably different CH340x adapter and different computer. FDxboot 1.62@2Mbps with CH340G: Atmega16: Atmega128A: |
Beta Was this translation helpful? Give feedback.
-
|
@flyandancexo mentioned below.
The test results shows that the above is indeed achieved, but not with CH340, rather it is with another USB to Serial implementation. FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (Uno ATmega16U2) |
Beta Was this translation helpful? Give feedback.
-
I have another Arduino Nano clone using ATmega328P and FT232RL adapter. It is also working well with the fast version of FDxboot. FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (ATmega328P, FT232RL), msvc64 binary mingw64 version will be slightly slower. |
Beta Was this translation helpful? Give feedback.
-
|
With FT232RL, it also works well with urboot at 2M baud. Again, mingw64 version is a bit slower than MSVC version. |
Beta Was this translation helpful? Give feedback.
-
|
Note: please set FT232RL adapter latency timer to 1ms (Windows and Linux) before carrying out the benchmark test. If not you will get 16ms latency timer and the speed is very slow. Example under Ubuntu Linux 20.04. |
Beta Was this translation helpful? Give feedback.
-
And... what was the bug? |
Beta Was this translation helpful? Give feedback.
-
|
In the end, there is no 2M bug, rather CH340x is the culprit. |
Beta Was this translation helpful? Give feedback.
-
|
Dr Azy has some interesting data for serialupdi here for modern AVRs.
|
Beta Was this translation helpful? Give feedback.
-
|
I have done the tests under Ubuntu 20.04 Linux yesterday, CH340 is not good under Linux either. It is actually slower than Windows 11 on the same laptop (dual boot). I will try under my Mac Mini M1 2020 as well (latest macOS 14.3.1). |
Beta Was this translation helpful? Give feedback.
-
|
make sure the latest CH341 linux driver has been installed. If avrdude is not the case of the 2M bug, then it could be from the driver. Linux driver could be worst than windows'. |
Beta Was this translation helpful? Give feedback.
-
|
@flyandancexo Same ATmega168P board, using urboot autobaud firmware with the onboard CH340 it does not work. With an external FT232R adapter it works with 2M baud. You may want to use another USB to serial adapter (eg: FT232R, FT232H, FT2232H, etc) and try again. Then you can see by yourself whether CH340 is the problem or not. |
Beta Was this translation helpful? Give feedback.
-
Just build the latest version of CH340/CH341 under Linux. (version 1.7) and it does not help. Same results with the FDxboot 1.62 FW. |
Beta Was this translation helpful? Give feedback.
-
|
So all my tests show that CH340 chip is the issue, under both Linux and Windows. I do not expect the thing to change under macOS. So WCH does know the potential issues and that is why in the datasheet they recommend users not to exceed 1M baud for single direction and 500K baud for dual direction. FYI, I am a professional HW engineer with 23+ years of experiences in the industrial automation field so I know the importance of following the datasheet. |
Beta Was this translation helpful? Give feedback.
-
Here is the readback function. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, case closed for the investigation of the relationship between USB serial chip vs bootloader speed. I will probably close this discussion (too long) soon and open another one with summary of test data from this thread (programmers and bootloaders). |
Beta Was this translation helpful? Give feedback.
-
|
The problem is not the chip, but the lack of error recovery on AVRdude. All type of communication should expect error and have algorithm to deal with it. It's normal to have error. It's not normal not to have some kind of mechanism to deal with it, so it's so common to see communication error using bootloader written by amateurs. @mcuee Real investigation should be focus on understanding what the problem is instead of doing few upload tests and jump to conclusion. Don't forget the bootloader written by me with the delay works at 2Mbps on a CH340g. That is a fact, so the question is why. @stefanrueger you are free to use my delay code on your bootloader, so people using a CH340g with your bootloader could have more stable read back. It should be beneficial even at 500kbps. As for your question, I have 2 different bootloaders for MCUs with or without the need to involve ZRAMP, so the code that you said here is for less than 128-byte page MCU. It's more optimized that way. You can try different delay value and block size from 8-64; 32-bytes delay is more efficient and stable. You can add up to 1ms delay without it being too slow. |
Beta Was this translation helpful? Give feedback.
-
|
No need to argue about the chip. FYI, within the avr project admins, I am not doing much at the real development side as I do not know much about coding. I do not even know AVR chips very well as I do not use AVR chips in reality. What I do in the open source projects (since 2005) almost have almost nothing to do with my day job (HW development for industrial automation product, mainly Distributed I/O modules). My involvement with avrdude project was mainly due to the fact that I am heavily involved in the dependancy libraries (libusb, hidapi and libftdi). And then I got more and more interested. My focus is on the testing side and technical support side (same for other projects I am involved), with other contributions like Wiki updates and simple github CI script changes. @stefanrueger and @MCUdude know AVRs very well and they are the two main developers as of now. Then @dl8dtl has all the histories of avrdude and also knows AVR very well. Of course we also get help from other contributors, for example, @dbuchwald is the main developer of serialupdi code for avrdude. I think one thing you are right is that the current avrdude avr109 code is old and lack the error recovery. I am sure there are many improvements which can be done for avr109 code. If you want to contribute to avrdude project to make the avr109 codes better, you are welcome to come out with PRs. |
Beta Was this translation helpful? Give feedback.
-
Well, the problem originates with the chip, that much is clear. There are a number of workarounds:
You'd have to ask WCH that question. They will know. AVRDUDE does provide a number of workarounds for buggy programmer hardware or firmware, but in this case
So, I prefer to focus on more interesting problems |
Beta Was this translation helpful? Give feedback.
-
|
All good points. Just one comment.
There are still some usages of AVR109 which can not be replaced by urboot.
Reference: |
Beta Was this translation helpful? Give feedback.
-
|
Please continue in #1705. |
Beta Was this translation helpful? Give feedback.
-
|
I have updated the FAQ to recommend urboot bootloader for classic AVRs, also add some USB to Serial chip info. Please take a look as well and feel free to update the FAQ page to add more info. |
Beta Was this translation helpful? Give feedback.
-
|
@mcuee Brilliant! I would replace "may be flaky" with "has been known to not work reliably" Could you link "change the default latency from 16ms to 1ms" to a page that shows how to do that? |
Beta Was this translation helpful? Give feedback.
-
|
FTDI Latency timer settings -- default 16ms. For Windows, go to device manager and find the FTDI serial port. Open the properties. Click "Advanced..." and then change latency timer value from 16ms to 1ms. |
Beta Was this translation helpful? Give feedback.
-
|
Done. FTDI latency timer changing info -- only for Windows and Linux now. I will check macOS and BSDs later. |
Beta Was this translation helpful? Give feedback.
-
So far I have the STK500v2 clone (HVPP capable, with ATmega8535 as main control MCU, PL2303HXA USB to serial chip) to be the fastest wthout using
-B 1option. With-B 1, an AVRISP mkii clone seems to be the fastest.Beta Was this translation helpful? Give feedback.
All reactions