Now that I have investigated how to count really fast und even faster here are some afterthoughts.

First have a look at the videos. When I created them I already had both counters implemented. Soon after I forgot which video belonged to which counter. But how to find out? A simple way would have been to film a small piece of paper telling me which one is which. However I only realized this afterwards. As it turns out there are at least two ways to find out which one shows the fast and which one shows the faster counter.

Have a look at both videos to figure out on your own. Or read on below to learn my solutions.

As I computed in the fast counter experiment the counter will exhibit a period length of 16.963 seconds for a prescaled clock. So if the faster counter is ~1% faster it will be faster by 0.17 seconds per period. At 30 frames per second this is about 5 frames. So this can be easily noticed during video cutting.

However there is a more subtle effect which is easily visible without cutting software. Have a look at both videos. In both videos the LEDs to the right are “always on”. Actually they are toggled so fast that they appear to be always on. The LEDs to the left are visibly blinking. However in the middle the LED above the “en” of the Blinkenlight print behaves differently. It seems to fade in and out. The speed at which this happens is clearly different in both videos. The interesting thing is why this happens and how this allows to infer which video shows the faster counter.

In order to understand what is going on let us have a look at the toggle frequencies of the different LEDs. Keep in mind that the clock was prescaled for the videos with a divider of 256.

As it turns out the “fading” LED is LED 9 which happens to blink at 30.18Hz (fast counter) or 30.49 Hz (faster counter). These two frequencies are suspiciously close to the frame rate of the video which happens to be 30 Hz. What we can observe is the also known as beat frequency, Moiree pattern or heterodyne. The nice thing about it is that the beat frequencies are easily computed. The lower of the beat frequencies is the difference. Thus in the video LED 9 will have an beat frequency of 30.18 Hz – 30 Hz = 0.18 Hz for the fast counter. For the faster counter it will have of course a beat frequency of 30.49 Hz – 30 Hz = 0.49 Hz. With other words for the fast counter it will fade in and out roughly every ~5 seconds. For the faster counter it will fade in and out every ~2 seconds.

If you think this is overdoing video analysis have a look here to learn how to stretch video analysis 😉

The second afterthought is the question if there could be further optimizations. After all it seems that there is no more room left for any. There are actually two approaches for further optimizations.http://www.youtube.com/

The software approach would be to squeeze the remaining overhead out of the code. Since the only remaining overhead are subroutine calls these would have to be substituted with “jump” statements. In order for the program to still work this implies that the stack would have to be prepared in such a way that the “return” statements would always find the proper return address. After each cycle it would be necessary to properly set the stack pointer (but nothing else). This is doable but some math shows that this yields almost insignificant benefits.

The mixed software/hardware approach would be to use the AVR PWM feature to toggle some counter bits in hardware. Since we cannot choose which pins the counters are connected to this implies to move the lowest significant bits “inside” the display. But there are 3 counters. Thus we could need to toggle only bit 3-19 in software. This allows to implement a counter that really counts each cycle. Why I don’t do it? Because it is to expensive (effortwise) for me. As I already noticed before it is much cheaper to just hook a crystal oscillator to a hardware counter chip.

The last after thought is “what is this actually good for?” As I mentioned at the beginning of the counting experiments I wanted to exhibit aggressive performance optimizations and why it does not pay of to squeeze the last drop of juice out of the hardware. However are there any applications for my counters? The answer is of course yes. The first one is to measure the shutter speed of my DSLR. Not very interesting for a camera where you can explicitly set the speed. But extraordinary interesting if you need to measure the shutter speed of a camera where you can not read this from some camera setting. The typical example is if you want to achieve a non standard shutter speed by triggering your camera through “bulb” mode with an external trigger. Then this question pops up rather naturally.