Debugging the small BMP display routine - used for up and down arrows

DRIVER CODE SET UP TO INTERCEPT LCD LIBRARY CALLS

I don't yet have the SPI link to the actual LCD Module debugged, but I built a mainline routine that would expose the same library calls as exist in the actual library, so that my code to display the BMP could execute. I would intercept each library call and show diagnostic information about that invocation. 

The three call types that are used by my code are LCD_Clear, LCD_SetWindow and LCD_WriteData which set the display to a uniform background, establish the size of the window within the screen for our output, and outputs each pixel. The scan direction is set up so that pixels are placed Left to Right in a line, then Up to Down for successive lines - L2R_U2D mode in the library. 

In an early version of the program I output the 16 bit hex value for each pixel - our display module uses a cut down color space with 5 blue, 6 green and 5 red bits squeezed into a 16 bit value. This chewed up a lot of space on the terminal with almost 17,000 lines output to represent the bitmap image. 

INITIAL PROBLEM WITH COLOR DEPTH

My code rejected the initial BMP file because it was not a 24 bit color depth. I realized that the MS Paint application, which offers only the options of 'black and white' or 'color', was generating 32 bit color depth. I found an online converter that would make the bitmap 24 bit, repaired my files and was then able to work with them using my code. 

SUCCESSFUL TEST OF THE CODE

My code displayed the calls to narrow down the window for the arrow to a specific 130 x 130 area starting at x value 300 and y value 40, representative of what my user interface will do. It then counts each time we enter with a 16 bit word that sets the color of one pixel in the window. At the end we see that the count was 16,900 and we called to reset the drawing window back to the entire 480 x 320 screen area. 

I may have an issue if the bitmap file is ordered from bottom row to top or some other way compared to my L2R_U2D orientation, but if that is so I can either modify the bitmap or call the library routine to switch the screen mode to whatever is appropriate. This will have to wait until I see the bitmap on the actual LCD screen.