You give me wayyy too much credit, Todd. The Palm code is written in a
Basic-like language called CASL which is actually interpreted, not
compiled. Yes, you are right that the limiting factor is speed (we DO
check long and lat values when recording with a PC). And I'm rather
certain that a compiled C program would get us additional speed.
However, I'm much more interested in using that possible-newfound-speed
to get us 20Hz sampling rates from the Cube. I'm not so worried about
polling both lat and long values in the AutoStart loop. I haven't had
any trouble with this...has anyone else?
--Byron
Todd Green wrote:
> While we are on the subject of Palms, what is the limiting factor in the
> Palm that prevents checking both long and lat values for
> autostart/stopping? Assuming it is cycle bound, have you looked at the
> assembly output of the compiler to see if you could hand optimize the
> code?
>
> Todd
|