Can optiboot (or any bootloader) support a 115200 baud upload speed on an 8MHz MCU? I only ask because the Makefile in the \hardware\arduino\bootloaders\optiboot directory would seem to indicate so, specifically the atmega328_pro8 target.
I could not get uploads to work, until I changed the Makefile
and rebuilt the bootloader, and now all is well. Not complaining, this is perfectly satisfactory, I'm just curious why 115200 was in the Makefile as it didn't seem to work.
My suspicion is that the person who created the makefile assumed 115200 would work. In theory, serial communications should work up to an error of ±10%. The error calculation on that website is based on ideal clocks (exactly 8MHz compared to exactly 115200 baud). In the real world, if either or both clocks are a bit off, the actual error can easily exceed ±10%. For what it's worth, I try to keep the error on each side below ±4.5%.
Thanks guys, didn't realize I was in uncharted territory! I've been fiddling with this 8MHz project, and Optiboot has worked well for me @ 16MHz, so I thought I'd give it a go. I do see that the 8MHz entries in boards.txt have upload speeds ? 57600bps, which was a clue. I may try 250K just for yuks (or 500K!)
@westfw, don't shoot me, I entered another issue that we found late last year (#59), not sure whether you noticed it. CB described it as a perfect storm between AVRDUDE and Optiboot. No idea how often it's encountered, it's an insidious one, but worthy of more attention than the baud rate IMHO.
As far as I'm concerned, it's always fine to submit official "Issues" against the google code project. Even if I decide that the issue is not a bug and/or never fix it, it still serves to document a behavior that someone did not expect...
Same experience here. NB you can of course use the 16MHz 115200-baud Optiboot binary on an 8MHz chip at 57600-baud without recompiling. The only difference is the upload timeout.
Ah-ha, thanks for the correction. There is however a small difference between the 8MHz and 16MHz binaries - on looking closer at the source I guess this is caused by LED-flashing code, which is dependent on CPU frequency.
BTW, whilst checking this I noticed that the compiled binaries for Optiboot v4.5 on the ATmega328 have changed and grown slightly (by 4 bytes) since v4.4. Oddly this seems to be caused by the update to MINVER, which ought only to affect a single byte in the binary. Any ideas why this should be?
this seems to be caused by the update to MINVER, which ought only to affect a single byte in the binary. Any ideas why this should be?
In the old version, MINVER and MAJVER were equal (both 4), so the code that reads:
if (which == 0x82) {
/*
* Send optiboot version as "minor SW version"
*/
putch(OPTIBOOT_MINVER);
} else if (which == 0x81) {
putch(OPTIBOOT_MAJVER);
} else {
/*
* GET PARAMETER returns a generic 0x03 reply for
* other parameters - enough to keep Avrdude happy
*/
putch(0x03);
}
optimizes differently. (The optimizer is quite good at this sort of thing!) I think it was able to get rid one load immediate and one jump associated with an 'else'
(actually, I can check... Yep!)
I've been fiddling with this 8MHz project, and Optiboot has worked well for me @ 16MHz, so I thought I'd give it a go. I do see that the 8MHz entries in boards.txt have upload speeds ? 57600bps, which was a clue. I may try 250K just for yuks (or 500K!)