Farrukh:
It appears that you have become somewhat confused as to the purpose of the bitmap buffer.

This buffer is not an array of conventional 8052 type "bit memory" variables. Instead it is an image of the raw bits that specify the on and off states of all the bits on the LED display.

This buffer is used to de-couple the process of showing the LEDs from the process of putting new content into the display.

The part of your code that others have suggested to tie to a timer interrupt is the code that updates the LEDs. This code should be closely organized to the hardware connection format of the LED multiplex matrix and needs to be very fast. Since, as Erik says, the total refresh time of the display must be at least 100 Hz then you must be able to invoke this code quite rapidly. If your display is organized as follows:



Then the timer interrupt wants to be organized to run at a period of 700 Hz. At each timer interrupt the 8052 program goes to the bitmap buffer and pulls out the bits for a particular row and shifts them all out to the shift register. It then will activate the 1 of 7 row drivers for that particular row. The next timer interrupt comes along and repeats all this for the next row. For a display with 7 rows as shown above you get a NET duty cycle on any LED of 1/7.

The bitmap buffer is convenient to organize so that each byte of the buffer represents one display data column on the display. Each time a timer interrupt occurs it will start at the beginning of the buffer and visit each byte in this buffer. Each byte is ANDed with a mask that has one bit set that corresponds to the active column for this current timer interrupt. The result of this AND operation determines the bit value to shift out to the shift register for that column. As a sequence of 7 timer interrupts occurs this mask will cycle through values of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, and 0x40. Note that for a 7 row display you do not use one bit in each byte of this bit map display buffer.

The logic to update the contents of the buffer with new display data, including the conversion of character code data to corresponding 5x7 character glyph data is done by a separate process in your 8052 that is not directly connected to the timer interrupt logic discussed above!!

Someone suggested that this bitmap buffer be organized two times longer than the total number of rows in the display. This scheme makes it very easy to logically scroll the LED display image. What happens is that the timer interrupt is designed to not always start at the beginning of buffer at each interrupt. Instead a start index is used that tells the timer logic where to begin the display update image. To scroll the display this index is changed by one count at a time. The rate at which this index is changed will control the display scrolling speed!! Normally the changing rate would be at some multiple of the display update rate (the 100 Hz target rate and not the 7x row display rate). As this index is changed it is allowed to go from zero to a value 2x the length of the display in colomns. Logic in the the timer interrupt needs to wrap the scanning logic back around to the beginning of the 2X long bitmap image buffer.

The separate process that handles the update of the bitmap image buffer now has the additional job of making sure that the parts of the buffer that are scrolling into view in the near future are kept up to date with the proper data.

This bitmap image buffer needs to be in RAM that is directly accessible to the processor. For smaller display matrix sizes it may be possible to use internal DATA memory of the processor. When the number of display columns gets over some count, say 32 columns, then it is necessary to move this image buffer out to XDATA space. This is one reason that the use of one of the 8052 derivatives that has 4K or 8K of on-board XDATA space is a good choice for making a simple multiplexed LCD display.

Michael Karas