Optiboot upload speed for 8MHz MCU

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

#from
atmega328_pro8: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'
#to
atmega328_pro8: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=57600'

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.

Uploading works at 57600?

One possibility is the error (7.8% vs 3.7%)... http://www.wormfood.net/avrbaudcalc.php

[quote author=Coding Badly link=topic=91180.msg684839#msg684839 date=1328830023]

Uploading works at 57600?

One possibility is the error (7.8% vs 3.7%)... http://www.wormfood.net/avrbaudcalc.php

[/quote] Yes, seems to work fine. Saw some similar baud rate error numbers in the AVR datasheet and wondered if that wasn't the issue.

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%.

I suggest using a baud rate of 250000.

I'm just curious why 115200 was in the Makefile as it didn't seem to work.

Optimism? Perhaps it works using the SW serial code? Most likely: when it was written, the author didn't have an 8MHz unit to actually test it on... Sigh. http://code.google.com/p/optiboot/issues/detail?id=58

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.

Thanks again for everything!

Hah! No, I hadn't seen that discussion before. Something similar is described here: http://code.google.com/p/arduino/issues/detail?id=273

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...

I'm good with that. I did think it at least deserved documenting, so that's done. And yes that other issue does sound related.

BTW, Optiboot is happily uploading @ 57600bps on an 8MHz m328P here tonight XD

[quote author=Jack Christensen link=topic=91180.msg684644#msg684644 date=1328820103] 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. [/quote]

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. http://arduino.cc/forum/index.php/topic,64105.msg469540.html#msg469540

The only difference is the upload timeout.

Even that shouldn't change, since it's run off of the watchdog timer.

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

//Old code:
// (implements "if (which == 81 || which == 82)  out = 4 else out = 3; putchr(out)"; )
    7e6c:	02 38       	cpi	r16, 0x82
    7e6e:	11 f0       	breq	.+4      	; 0x7e74
    7e70:	01 38       	cpi	r16, 0x81
    7e72:	11 f4       	brne	.+4      	; 0x7e78
    7e74:	84 e0       	ldi	r24, 0x04	;  load '4'
    7e76:	01 c0       	rjmp	.+2      	; 0x7e7a <main+0x7a>
     7e78:	83 e0       	ldi	r24, 0x03	; 3
    7e7a:	8d d0       	rcall	.+282    	; 0x7f96 <putch>

//New code
//(implements "if (which == 81)  out = 4 else if ( which == 82) out = 5 else out = 3; putchr(out)"; )
    7e74:       82 38           cpi     r24, 0x82       ; 130
    7e76:       11 f4           brne    .+4             ; 0x7e7c
    7e78:       85 e0           ldi     r24, 0x05       ; load 5
    7e7a:       05 c0           rjmp    .+10            ; 0x7e86 
    7e7c:       81 38           cpi     r24, 0x81       ; 129
    7e7e:       11 f4           brne    .+4             ; 0x7e84
    7e80:       84 e0           ldi     r24, 0x04       ; load 4
    7e82:       01 c0           rjmp    .+2             ; 0x7e86
    7e84:       83 e0           ldi     r24, 0x03       ; load 3
    7e86:       81 d0           rcall   .+258           ; 0x7f8a <putch>

That's very neat indeed!