By this, you indirectly calls Aamir a complete idiot.

I did tell Aamir to use an array instead of a switch statement. But a switch statement is probably the smallest problem. A good compiler could even convert a switch to a computed goto depending on target processor capabilities.

The really big problem here - if we ignore matching of algorithm with hardware - is What is taking time here is this part:


Point 7 turns on a row (scanline) and point 8 is the light time before switching to the next scanline.

Point 12 takes care of the 5 scanlines (tiny 5x5 characters).

Point 13 takes care of what? The 7 characters to scroll. But the iteration through the 7 characters has to be done in 3 to 11. When the five scanlines in point 12 are done, then every LED in the display should have been driven once (possibly to the "off" state).

This indicates that Aamir is trying to light one character at a time, instead of turning on all characters in the row, so the use of switch is a small problem.

The above was one of the reasons why Aamir should first emit something trivial, such as a fixed pattern, just to test how to emit data without having to care about a character generator or how to extract the data from the character generator into a bitmap or directly to the output with real-time performance.

Doing simple experiments and then increase the problem level has been shown to work better than starting from the other end. It is possible to go to big solutions immediately, but that introduces large amounts of stress and requires that a student are at very high concentration levels for an extended time. But trying for too big steps very often fails, and failure makes people think they are stupid, when the problem is that they just tried it the wrong way.

Readability is important when working with algorithms.

In this case, the description of the algorithm was loop-unrolled and did not in a good way should the iterations. And the posted source must have been indented with both tabs and spaces, because the indentation made it impossible to read. A good graphical view of the algorithm would help making sure that the inner loop emits a bit at a time, but do not contain any delay. The delay is for the scanline loop. The final loop would be the current scroll position, but since this loop is outside the per-frame part, it will not affect he output speed, unless the code incorrecty clips invisible characters to the left or right of the visible area.

Simpler loops to emit the data have been suggested, but I don't remember if that was before or after this post. There should be at least one suggestion in this thread, and another in his interrupt thread.

In this case, a very good exercise to do when working with multiplexed signs is to write a tiny program that shows a vertical bar that gets scrolled left-to-right or right-to-left.