https://hackaday.com/2021/12/01/the-555-timer-contest-returns

There's a category for "Shouldn't've used a 555"...

This dang calculator doesn't have a high-speed timer of any sort, it seems, at least accessible by the CPU instructions.

That's why all these UART and other tasks have been really quite difficult, counting T-States.

One of my earlier thoughts was maybe there's an R/C circuit used to create the 200Hz interrupt. In which case I could tack an ADC on to get say 200×256 40,000ish ticks per second. It was mostly a joke, but I might've done it just to say I did, and maybe even figured out goofy ways to deal with those ticks' having different durations due to the RC charging curve. I'd've done it IF those beautiful ceramic and gold Analog Devices DIPs in my collection all these years were ADCs. Alas, they're DACs. Anyhow, Actually, now I think that 200Hz 200Hz interrupt is generated by the LCD driver). 

But, 555's apparently go up to 100khz, which is even more ticks! Obviously, feed that into a TTL counter/divider, and yer set! But... inspired by the "Shouldn't have"... I actually hadn't thought of the TTL counter until just now. Heh.

Instead my brain went straight to trying to create the counter FROM 555's. And, actually, now that I think of it, even /that/ could probably be done... ripple-counter, each 555 has a latch. Probably, yep.

Nono, that's not where my brain went first, it went to trying to set up say 8 555 oscillators each oscillating at half the frequency of the previous. Yahknow, darn-near impossible to achieve precisely.

So, then it went to even weirder ideas, like vernier-scales and gray-code and beating... e.g. 8 slightly-detuned free-running oscillators (I'm choosing 8 because that's the bus width, not because I expect 256 values)... maybe even far slower than 100khz.

I hadn't really gotten much further than that before becoming /pretty sure/ something along those lines would be plausible... though a beast to decode in software, eh? Just the sorta way *not* to do a timekeeper...

OK, so, what, now?

I dunno, say you had three analog wall clocks with dying batteries. The second-hands would tick at slighly different rates, close to but not a second. Sometimes they'd seem to be in sync, other times completely out of sync...

No, shoot, this is exactly the opposite, right? Here's a fast pulsing, and a slow measurement from it.

No, wait, that works with the ~100KHz idea.

Right, so, the relative phases indicates the count of "seconds."

Heck yeah.

'cause, the whole point is there's ziltch liklihood I'd be able to read the port at 100khz to catch every tick. Especially when doing other calculations like bit-shifting serial data. But, we don't want to write that data bit to the port until 1/9600th of a second after the last one, so now when the bit is ready we can start polling our 100khz tick-counter to see when enough time has passed...

OK, I think there's something to work with, there... But, in the clock example one has to sit and watch the relative times between the /changes/ of the various second-hands to determine their relative phases, and /those/ occur *faster* than one second...

OK, now this is becoming a real challenge, the sort my brain won't be able to let go of.

... So, to recap: Analog wall clocks are a bad example. Just look at the position of the second-hand, or the friggin' minutes hand, if you want to know how much time passed since last you looked.

OK three metronomes.

This is a bad example, too, because allegedly they'll sync and stay synced(?!)

Pretend that's /not/ the case (seems absurd, would rule-out "beating").

OK, so, if they're all close to one second and they're all started at the same time... then for the first few toggles, they'll all pretty much be at the same positions at the same times...

I should start with two.

And I want....

To look at their /end-positions/ in order to determine how much time has passed.

So, if they're off by 0.25 seconds... then after 2 seconds pass they'll be at opposite end-positions, and after 4 seconds back to the same. 

L L 0sec

R L 1sec

R R 1.25

L R 2sec

L L 2.5

R L 3sec

R R 3.75

L R 4sec !=0

R L 5sec =1

Wait, what?

Ok, so...

We're talking about interfacing this to a data bus, which would probably be best done via a latch that latches alongside *one* timer/metronome's transitions... the computer will only read back states at full "seconds" (why?)

LL, RL, LR, ... Wait... what?

L L 6

L R 6.25

R R 7

R L 7.5

L L 8

L R 8.75

R R 9

L L 10

LOL, I've got a friggin graphing calculator right here...

Anyways, i think i'mma wind-up mulling this over quite a bit more, whether I want to or not... but i think you can see the gray-code in there, eh? Also, quadrature (heh, was just thinking of #anaQuad! )

...

Somewhere in the vague-idea was the thought that maybe having 8 of them might mean that enough timing information could be extracted from them that their actual misalignment wouldn't particularly matter. Though, somewhere else in there it may be that we'd benefit from several 8bit latches to either store previous states or associate a separate 8-bit latch with each timer's toggling. Hmmm... nice thing... there's still a whole 1MB address-space available with its own dedicated chip-select! Hah, this is ridiculous... mind not switching off it, though. There's something interesting here, I just don't know what, yet....

Oh, something... that fractional *and* multiple tick measurements can be derived (from a single snapshot)? The 2-bit example only has 4 states, but with those we get both a multi-tick resolution of up to 2 and a fractional-tick resolution, as well.

So, e.g. say we need to measure up to a 4 second window with 1 second resolution, we could set one to 2sec and the other to 3sec (sacrificing the first second) hmmm.