This is my first attempt at the program. Note how I am asking the display to do things for me. I have created a function which will display messages. It accepts two parameters, the numeric value to be displayed and the number of the display unit to use:

void display ( unsigned char digit,
unsigned char pos ) { /* turn on the required LED unit */ PORTA = enable [pos]; /* set the pattern on the LED */ PORTB = patterns [digit]; }

If I want to display the value 0 on display number 3 (which is the last unit since I have numbered them from 0, I would use:

display ( 0, 3 ) ;

However, this is perhaps confusing, so I would probably end up doing something like this:

#define DIGIT0 0
#define DIGIT1 1
#define DIGIT2 2
#define DIGIT3 3

display ( 0, DIGIT3 ) ; 

I tend to write things this way out of reflex, because this provides me with a way that I can drive a display with any number of digits very easily, but keeps the code as clear as possible. If you think about it, having a single function like this is much easier to manage that four separate functions.

Note also that I am using arrays to hold the patterns of the digits, and also the mapping of the bits to the enable lines in PORTA. There is method in my madness here as well, in that if I change to different displays or the way that I address the ports changes

Unfortunately..

The only problem with my elegant code is that it doesn't work very well. Perhaps you can see why. What you see was that the digits are barely recognizable, with parts of one number "smeared" over the next. Connect up the LED unit and run the Exercise 4.1 and you will see what I mean. The problem is due to the order in which I turn the signals on and off:

void display ( unsigned char digit,
               unsigned char pos )
{
 /* turn on the required LED unit*/
 PORTA =  enable [pos] ;
 /* set the pattern on the LED   */
 PORTB = patterns [digit] ;
}    

I enable the output for a digit before I load the pattern. This means that for an instant, before the second line which sets up the patterns, the wrong pattern (that of the previous LED) is being delivered. Switching the order of the two statements helped, but what I really needed was a delay to let the LED hold the display for a fraction of a second, before I move on to the next.