[C.CC USERS] heartbeat run failiure on Windows XP

[Matt Jadud]

On Fri, Jan 28, 2011 at 00:26, ljam10 at juno.com <ljam10 at juno.com> wrote:
>  "Using port com4 at 57600
>  tvm-arduino: program loading failed".

Christian and I figured this out this morning. We understand why the
error happened, and what we need to do to prevent this from happening
again.

This summer, we did a lot of work to automate the build processes for
all three operating systems (Mac, Linux, Win). Christian also got
WinSparkle working, which was also good -- we wanted tools that would
update automatically for users.

The most recent fix illustrated something about our build that was
still not good. I made a change on the Linux build (the address),
which showed up as a parameter passed to "configure". That parameter
was the bytecode location, which gets set in the VM *at compile time*.
Because that particular script was not used on the other platforms, we
ended up with the following situation:

* Linux got the right address at compile time and in the .conf file.
* Mac got the wrong address at compile time, but the right one in the
.conf file.
* Windows got the wrong address at compile time, but the right one in
the .conf file.

(The Uno got the wrong address in the .conf file for all platforms.)

Now, this is because:

* The address is in two places. That accounts for the Uno problem.
* The address was specified in a fragile way on a per-OS basis. That
accounts for different firmwares being generated on different
operating systems.

In other words, it is entirely a "build bug." We are now going to do
the following:

* Script the build of firmwares in exactly the same way for all
operating systems. That is, the exact same process will build all
firmwares on all operating systems.
* Drive the build of firmwares from the .conf files. This way, we can
do per-board customization if necessary.
* Build a unique firmware for every supported device. That way, if we
need to make the Uno unique in some way, we can, and it has its own
firmware---even though it is 99.999% the same as the previous
Arduinos.

Now, the big "human boo-boo" is that we didn't do enough testing
before the update that broke things; that's just "our bad." Perhaps we
need a big "DEVELOPMENT VERSION WARNING" on all our software...
because it is. But, we can 1. be a bit more careful, and 2. as I've
described, improve the automated process so that it is less likely
that human error can creep into the build.

So, thank you, Lar (and others) who reported this error. We actually
were having a really hard time figuring out why my code was working
just fine under Linux and other platforms were breaking. We were
afraid it was due to bootloader differences on the different Arduino
platforms, or something similarly difficult/impossible to detect. It
turns out to just be us, which... is usually the first place you
should look. :)

Many thanks for your patience, and the next auto-update will include
firmwares and config files that make the process happy for all
platforms. (Or, we think it will.) The Uno will probably not get a
baud-rate fix (yet) in this push, as we want to fix one problem at a
time for a moment. However, given that the baud rate on the Uno has a
workaround (declare half-speed in your occam-pi code), we can let that
rest for just a moment.

Many thanks,
Matt