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

BATTLING THROUGH TO SPI SIGNAL OUTPUTS

After some more changes, such as removing the device from the device tree entry for spim1, I decided to revert back to using the FPGA routing for spim0 since that had some effects initially. This time I routed the signals out of the GPIO pins directly without buffers, to avoid the timing problem I suspected would occur because of the buffers I had been inserting.

I had also created a diagnostic monitoring function to show the state of all the relevant SPI registers. This showed me that I had the SPI capability properly configured and the status was good. I then hooked up the scope to the new 

The loop I wrote showed me good activity on the clock, MOSI, MISO and hardware slave select lines. I hooked up the LCD Module but still had nothing visible. I did notice that the SPI link is operating at 5MHz rather than the 2.5MHz rate I thought I was configuring. I corrected the constants in my initialization routine and corrected this minor flaw. 

NEXT STEP - ENSURE OUR BIT ORDER AND OTHER FACTORS ARE CORRECT

What I saw on the scope confirmed that the bits on MOSI changed at the correct clock phase, that the clock polarity is correct and that the bits I see are in fact the data I am transmitting. The most significant bit is transmitted first in every byte. Since the library and my code handle the two bytes of a 16 bit word explicitly there is no issue with the little-endian nature of the ARM processor as I send the high byte first. 

CHECKING THE FPGA GENERATED SIGNALS THAT ARE PART OF THE COMMUNICATIONS

I produce four signals that are important for communicating with the LCD controller. LCD Reset is used to produce the desired initial state when we start up the program. LCD Command/Data tells the controller chip whether we are transmitting an 8 bit command or 16 bit data/parameter words. LCD Select is used to enable the logic to receive our SPI communications and transfer it in parallel to the controller chip. Touch Select is used to instead enable communications with the touch screen controller chip. 

These all work as intended. I can see a transaction bounded by my LCD Select signal, with the actual SPI link sending 8 bits at a time bounded by the hardware slave select. My LCD Select governs however to comply with the wacky protocol this device uses. 

I send MSB first so a xC2 goes out as 1 1 0 0 0 0 1 0 and these get shifted into the first SIPO shift register such that D7 is a 1 and D0 is a 0. The LCD controller chip is wired so that our data is appearing in the lower half of its 16 bit parallel input with D0 being the least significant bit. The LCD controller defines commands such that the 0xC2, Power Control 3, is represented with a 1 at D7 and a 0 at D0 which again confirms we are transmitting the bytes exactly as the controller chip wants to see them. 

As I deassert my LCD Select signal after the transmission of the one byte 0xC2, this triggers the LCD controller chip to latch this in and read it as a command, while resetting the logic outside to receive subsequent bytes or words. Again everything appears correct to be communicating with the LCD controller and sending the proper sequence to initialize it

TEST PROGRAM COMMANDS AND RESPONSE

I did discover some logical issues concerning what I need to do in order to use the LCD library provided by Waveshare which I have heavily modified in order to port it to the DE10-Nano. When I try to clear the screen to a fixed color I selected, nothing was transmitted over SPI. After instrumenting the library routines, I see that it does a check on the input parameters and skips clearing because the start and end points are all the same. 

It appears that I don't have some important initialization done for the screen data structure as it has the end points of the X and Y range as 0 instead of their correct 479 and 319 for the full extend of the screen. I will chase down where this should have been set and make sure that happens. 

Similarly, my tests writing fixed strings on the screen are failing because of this issue with screen data structure initialization. I may also need to issue some commands to set the current cursor or writing point before I start - this is an area I don't fully understand.