Optimize optiboot.c for manual m328 reset

[GoogleCodeExporter]

I'm using an Arduino Uno v3 to upload sketches to an in-system atmega328 in 
which I put the optiboot bootloader.  Because of some HW design constraints I 
need to manually time and perform the trigger resets and it's proving difficult 
to get the timing right (old reflexes, I guess).  I compiled (and loaded) a new 
version of optiboot because I needed the upload speed to be 19200 (another HW 
constraint) rather than 57600.  I'm wondering if there are other possible 
modifications I can make to optiboot.c in order to make the manual reset timing 
a little more forgiving.  I'm willing to sacrifice system startup time.  Any 
ideas?

What version of the product are you using? 4.4
On what operating system? Mac OS X 10.6.8

Original issue reported on code.google.com by VinnieMa...@gmail.com on 2 Sep 2012 at 3:52

[GoogleCodeExporter]

Change the line that reads:

  // Set up watchdog to trigger after 500ms
  watchdogConfig(WATCHDOG_1S);

to use WATCHDOG_8S instead, and you'll have 8 seconds after hitting reset to 
start the upload...

Original comment by wes...@gmail.com on 1 Oct 2012 at 9:52

• Changed state: Done

[GoogleCodeExporter]

I experimented with increasing the watchdog but was unsuccessful. Here are the 
steps I followed:
1. Changed the watchdog delay to 8 seconds.
2. Tested the change by resetting the chip and observed that after exactly 
eight seconds the main program began.
3. Reset the chip again and then immediately started the Arduino upload 
process.  The upload process started but failed after the usual 3x avrdude send 
commands and I observed that the chip started the main program prematurely 
(<8secs).
I had a hunch, based on some Google searches that maybe the problem had 
something to do with the MAC OS resetting connections and/or garbage characters 
being sent but I wasn't able to come up with an experiment to test these 
hunches.  I thought that maybe a garbage char is sent and the final catch all 
"else" statement in the main loop in optiboot.c calls verifySpace resulting in 
an abort/reset.  I was wondering if there was a better (more forgiving) way to 
handle the final "else" statement and stay within the 512bytes and not run the 
risk of a runaway optiboot.  No worries, I've gotten very good at timing the 
resets and uploads.

Original comment by VinnieMa...@gmail.com on 2 Oct 2012 at 12:09