PeterH:
SteveOr:
Something like this for example:I don't see what the switch statement is achieving there.
What it was acheiving for me was making the structure simpler for me to understand. Yet it lacks a time function which might be the complicated part. As some one new to all this I'm still trying to figure out how to meld all these functions to produce a coherent system.
PeterH:
All you need is to apply range checks to the time value to decide which display format to use, followed by a call to the corresponding output function. You already have the range checks in the code there, and if you throw away the switch and simply run through the sequence of if / else if statements it should do what you want.
OK. I'll work on my if/else functions some more to figure this out. Last night I tried different approaches using my limited skills and I think I bruised my brain.
dhenry:
Should I lean in that direction?
That approach is a lot easier to code and provides better brightness - as the display is essentially is static.
The sketch I referred to only confused me (more so than the cluster I'm dealing with now). Since I don't have a CD4021 this is a last resort. Plus my display is plenty bright. In fact I had to set the brightness at the lowest level to prevent burning my retinas.
CrossRoads:
No, your approach fine. I did similar, recoginizing the various situations and rolling over the upper digits as needed:...The buttons & stuff can be read during the intervals when it is Not time to decrement the 1/10th second counter:
if (100mS elapsed){
// do the digit changing & display updating stuff via MAX7219 SPI.transfer commands
//
}
// rest of the time, read buttons, do other stuff - there is a lot to processing time left to do that stuff.
Lots of things will happen when time is not running - incrementing the score, the period counter, buzzing the score indicator, etc.
So did use use all the millis() if statements to do your timeline or some other timing method?
Thanks everyone,
Steve