I’ve done a good deal of work with its larger 324 and 328 cousins, and have recently picked up my first baby orangutan. Lacking a display, I’ve got a pair of LEDs hooked up to C1 and C2 as a rudimentary output. Using these I’ve been able to verify that (a) I can indeed program this just like its big brothers, (b) I can drive these control lines just fine, and © the OrangutanTime methods don’t work at all for me any more.
Specifically, if I call OrangutanTime::delayMilliseconds(), the call never returns. If I call OrangutanTime::ms(), I always get the same value back–zero. Is there something unusual in how these methods work with the baby-o that I’m missing, or do I perhaps have a bum device? Is there anything stupid I might’ve done while soldering on the pins that would break some internal clock while leaving the rest of the device functional?
Further experiments have clarified the behavior somewhat. Here’s my main program:
Indicator indicator (HARDWARE_INDICATOR);
// uint32_t start = OrangutanTime::ms();
int main (void)
walk.run(); // heh; little fun there
The Indicator class just controls the lights; nothing exciting there. Here’s the fun part: see that commented-out line that says, “uint32_t start = OrangutanTime::ms();” ? If I leave that line commented out, then the main loop makes both lights blink over and over. If however I enable that line, then the delayMilliseconds method never returns and my lights stay off forever.
How can this be?
Ah. Never mind; figured it out.
For anyone else who might hit a similar problem: I was linking with the wrong library–treating this device as if it were a 324, not a 328. Fixing that resolved the issue and the time library is working normally for me now.
I’m glad you figured it out. Thanks for sharing the answer with us. I’ve made this mistake before too, and I was surprised at how much of the program worked even when linked with the wrong library.