hi folks,
i just found a good example of how leaving crufty code in applications
can give you a good headache.
when i first began testing msp430-gcc-4.x, i noticed that it broke a
couple of things that were timing-critical. after spending some time
trying to debug drivers, i realized that the 8mhz clock itself was
broken by a faulty bit of code in its initialization routine (no mea
culpa here, the snippet of c came directly from the mcu manufacturer's
app note).
to make a long story even longer, i fixed fastclock and committed it
before announcing the compiler upgrade last month.
unfortunately, the init routine in fast clock came from a function
called initialize_8mhz_clock(), which was still used in two released
apps until five minutes ago. and, someone else had cloned that, so i
found this in two more; oh, and two in swtest.
the bottom line: i just checked in -contrib updates to
apps/JustFATLogging
apps/HostTimeLogging
apps/AccelGyro
apps/AccelECG
swtest/GyroBoard
swtest/SerialTime
initialize_8mhz_clock() is out; fastclock is in. note that the two apps
that ran smclk at 1mhz instead of the default 4mhz use manual
initialization of the clock instead of direct wiring to softwareinit.
please pick them up when you get a chance:
cd tinyos-2.x-contrib/shimmer
cvs update -d
and, if anyone used the initialize_8mhz_clock routine in an application,
you should replace it with the corresponding fastclock code.
post questions at will,
steve
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
