Hmmmm, I've been looking at the optiboot.c source code, mainly because I'm interested in the possibility of of doing wireless uploading, and I'm kind of surprised that you guys are able to get 1-Mbaud comms at all. Namely, serial Rx is done using polled I/O and not interrupt-driven I/O, as far as I can tell, so I'm surprised the bootloader can even keep up with the incoming datastream, and not lose characters at those speeds, considering how the main-loop is written with so many if...elses that need filtering.
If you look at the source, you'll see that Rx comms is done using the getch() function, which is defined as follows at the end of the file [unneeded bits removed]. Also, ignore the LED_DATA_FLASH bits [they just slow it down a bit more].
uint8_t getch(void) {
uint8_t ch;
#ifdef LED_DATA_FLASH
#ifdef __AVR_ATmega8__
LED_PORT ^= _BV(LED);
#else
LED_PIN |= _BV(LED);
#endif
#endif
while(!(UCSR0A & _BV(RXC0)))
;
if (!(UCSR0A & _BV(FE0))) {
/*
* A Framing Error indicates (probably) that something is talking
* to us at the wrong bit rate. Assume that this is because it
* expects to be talking to the application, and DON'T reset the
* watchdog. This should cause the bootloader to abort and run
* the application "soon", if it keeps happening. (Note that we
* don't care that an invalid char is returned...)
*/
watchdogReset();
}
ch = UDR0;
#endif
#ifdef LED_DATA_FLASH
#ifdef __AVR_ATmega8__
LED_PORT ^= _BV(LED);
#else
LED_PIN |= _BV(LED);
#endif
#endif
return ch;
}