Drawing on the LCD screen to test functions I need - part 7

FOUND THE PROBLEM AFFECTING THE LCD MODULE

As a quick test I wired one of my new LCD Modules instead of the original one, simply to eliminate the chance that some hardware failure on the board was causing the problem. The behavior was identical. That does point me back at my DE10-Nano either in the Verilog for the FPGA side or the C code on the Linux HPS side. 

Up next was a more complete oscilloscope examination of the signal lines. Previously I had monitored the three SPI function output signals (SCLK, MOSI and SS) as well as my software driven pseudo Slave Select for the LCD module. Those worked properly.

Other signals essential to the operation of the LCD Module are LCD Reset, LCD Data/Command Mode, and Touch Select. First up was the reset since a faulty reset, held low, would keep the LCD controller chip from responding. A clean initial reset and then steady unasserted (high) levels were seen. Next was the LCD Data/Command Mode which when low tells the controller chip that a command is being sent, while high the controller expects parameters or other data. 

That signal was frozen in the high position. It never emitted a low state, which it must in order for the controller to reset, turn on and accept the other commands I was sending. That output would completely explain why the screen remained dark. 

This line is controlled by writing bits to the memory block in Linux that is transmitted to the FPGA's PIO output module, that in turn outputs the bit on the external I/O pin. This same method is used to send the reset command, which worked, and to send the LCD Select pseudo-SS which worked, thus the issue must be some subtle flaw. 

I did find it! There was a defined constant in my code that was wrong, thus I wasn't toggling the LCD Data/Command Mode bit when I thought I was. This was fixed in a trice and the screen came to life. I discovered a few issues with the user interface but can write what I want on the screen which is what is important.

ISSUES I SPOTTED IN THE FIRST TEST WRITING ON THE SCREEN

The first thing I attempted was to write a text string to the X and Y address 0,0 in order to see whether the letters are cut off at the edges. The text was sideways starting from the bottom left corner, not in the orientation I expected. 

The second observation was that 8 point font is very tiny indeed which will be hard for a user to read when they are selecting virtual cartridge file names. I will need to increase the size, which limits the number of file names on the screen as well as the maximum length of a name I can display. 

There was an error in how I used the GUI function to write the strings, which I attempted to use to list the file names found on the SD card. I received out of range errors, which I think means that I have to set the window boundaries properly or pass proper parameters. Same with the arrow bitmaps. 

Finally I drew a rectangle on the screen. I believe I have the position and orientation wrong, similar to how the text was misoriented with the earliest strings I wrote. 

PLAN TO CORRECT THE DISCOVERED FLAWS

I will chase down the reason for the strange orientation of the objects on the screen, then correct it. That should cause my text to run from left to right, with the lines going from top down to bottom. That should also put the rectangle in a better place.

I will experiment with larger fonts, finding the smallest that is acceptable and then sorting out the number of lines and max name size based on that. This will change a fair amount of the user interface code.