possible bootloader/uploader mods for XBee programming

This post didn't gain any traction on the other thread, so I thought I'd toss it out over
here ... something to think about, from
http://arduino.cc/forum/index.php/topic,136963.0.html

oric_dan(333):

westfw:

There seems to be so many 1000s of people having the same problem

It's not "the same problem." It's a generic error message that gets reported for LOTS OF DIFFERENT PROBLEMS.

I'm pretty sure that the R3 boards have the same bootloader and speeds as the previous Unos.

Yeah, I know, still there are so many problems with uploading, especially with the newer
boards, that it seems someone might do some rethinking along the lines I mentioned.

ALSO - it would be nice if the bootloader and uploader-dude s.w. were more conducive to
wireless programming, using XBees for instance. This would probably entail adding:

  1. ability to choose lower upload baudrate.
  2. ability to use shorter packets.
  3. adding longer turnaround ack wait times.

I would do this myself, as I use XBees all the time, but my knowledge of AVR assembler
and the tool chain s.w. is extremely limited.

The max message size is currently around 64 bytes; isn't that short enough?
A shorted message would require a different protocol; right now the message size matches the flash page size.

I've done a bunch of playing around with trying to upload via XBee to the UNO bootloader
chip. I thought the msg size was 128 bytes, but so far I haven't been able to crack ...
... (A) the protocol and all the dependencies in the files in the IDE and GCC and avrdude.
Everything seems dependent on everything else. I've spent hours pouring through different
IDE subdirectories and source code and make files and include files and IDE files, on and on.

I was able to mod the UNO bootloader source code and the board file in the IDE to change
the transfer rate to 9600 and 19200, but it still wasn't reliable. I figure what's happening
is the packet [msg] size is too large, the XBee buffer fills and transfers the packet, and
avrdude bombs out waiting for an ack from the bootloader while the RF transmission
and responses are in progress, but most of this is just surmise.

Due to the complexity mentioned in (A), I'm afraid it would probably be easier for me to
totally rewrite the bootloader code and my own transfer protocol program [outside of
the IDE] than to try and figure out what is happening with avrdude and optiboot.

However, since XBees are so popular, and many people would like to be able to do wireless
uploading, I figure someone knowledgeable with optiboot and avrdude could generate
something along the lines in my first post fairly easily [probably also including the ability
to resend bad packets multiple times], and it would still work within the IDE framework.
Then, it also would be official and everyone would have it, instead of some hack I
cobbled together on my own.

Just a thought.