I’m happy to report that nanoEFI’s RPM resolution is ±1RPM! Verified via oscilloscope.
Here’s what that looks like on the bench tach:
The readout above is updated at the maximum refresh rate of the OLED display, not slowed or averaged. So what you’re seeing can be taken as a good real-time measurement of engine speed by the ECU while being fed a simulated 3600RPM trigger signal. Nice and stable.
"What is that ~16667 number at the top of the display… and why is it above the RPM count…?"
It’s almost as if that number were actually more important than RPM. Hmm… 
Well… that’s because it is more important!
That 16667 at the top line indicates the number of microseconds (μs, millionths of a second) that pass between each complete 360° revolution of the crankshaft at a given engine speed.
The ECU doesn’t actually think in terms of “RPM”. Instead, calculates and schedules injection/spark events based counting the number of microseconds (μs) over the course of each combustion cycle. In this example 3600RPM equals 16667μsPR (microseconds per revolution).
Ultimately, “RPM” is really just the human readable format you see on your display representing engine speed, but isn’t actually used for calculating much of anything internally.
Taking this a step further… even thinking in terms of μs per revolution is its own layer of abstraction. It’s the unit I decided to make standard across all functions in the coding, so it’s easier for me to work on the system. However, the true measurement of time and engine speed is of course, in processor clocks.
In our 328p processor running at 20mhz, one μs equals ~20 CPU clocks. the If the number 16,667μs wasn’t already large enough, multiply that by 20 and you’ll finally be thinking of engine speed on the processor’s terms. So next time your screaming along all-out at WOT and pegging the governor, remember the ECU is quickly counting up to well over 300,000 in the time your relatively slow crankshaft is able to spin just once. 
Accuracy and Linearity
Accuracy is different than resolution (or precision), as the ECU could be calculating 3601RPM when the engine is actually spinning at 3620. So far, the decoder has been tested accurate to ±1RPM as well, via oscilloscope.
I should note that there is currently some non-linearity at specific and repeatable RPM points with the V-Twin decoder pattern. This doesn’t affect the single-pulse pattern. As additional patterns are added, I’ll post up a chart of what to expect from each.
Challenge
Who wants to figure out the refresh rate of the tachometer OLED screen judging by ONLY the animation below? The video capture was taken on an iPhone 8+ with default video settings. First person to get it right will get rights to flex their own unique forum title “Pixel Perfect” 
Alright, that’s enough hints. Don’t cheat and look it up. Show how you arrived at the answer 
Larger original GIF [here]
Yep, one roll takes exactly 15 frames and each frame of the GIF is 0.04 seconds.
