@dcb: clock is already done in my modded (and running) v0.86 code... it's dead-silly accurate, based only on an unsigned int counting loops since start. I actually compensated for it in the code, but even if the counter did loop after about 25 years, it'd still be accurate
The skew due to the functional "rounding-up" at the end of the main loop, though, I haven't even been able to identify after a week of running... it's a pretty reliable software clock from what I've seen!
@bobski: Here, lemme illustrate... here's the LCD, and underlined are the places I want the cursor to land when I hit the left or right buttons:
Code:
MPG I:24 C:26.2>
MPH35.2 MS20.33<
That would equate to a tabStops array:
{0,0+tabLine2,8+tabLine2,tabEnd}
(which would compile to {0,128,136,255})
The purpose is to quickly describe the positions I want each display screen to have "selectable", which makes selecting and identifying UI functions *VERY* easy within the code:
leftButtonPressed() {
byte x = 0;
if (currentTab > 0) currentTab -= 1;
else {
// find end
while (currentTabStops[x] != 255) x++;
// set current tab to one element before end
currentTab = x-1;
}
rightButtonPressed() {
// increment blindly
currentTab++;
// did we hit a wall? back to 0
if (currentTabStops[currentTab] == 255) currentTab = 0;
}
...
randomDisplayFunctionHandler() {
// if the middle button is pressed to perform that action, perform the action for that selection.
if (middleButtonPressed()) performAction(currentTab);
}
displayHandler() {
displayFuncs[currentDisplay]();
setCursor();
}
setCursor() {
byte row, col;
row = currentTab >> 7; // 129 for row 1 col 1 = b10000001 shift to b1
col = currentTab & (!tabRow2) // 129 "and" 127 = 1
lcd.setCursor(row,col);
}
See why I want to make this work?
Oh, and the "master array" would reside in PROGMEM, and would be memcpy_p'd to the currentTabs array when the screen is switched (using that handler, which may also update a "currentTabsLen" var). It makes things a lot easier, if I could just find a way to unify that "master array" in a sensible way... maybe I could just cram them all together, separated by 255's, and use the memcpy_p's routine to sort them out at runtime?