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

LCD MODULE AND TOUCH CONTROLLER USE SPI LINK

Serial Peripheral Interface (SPI) links consist of a signal running from the controlling (formerly master) side to the controlled (formerly slave) entity, called MOSI, a second signal in the reverse direction called MISO, a clock produced by the controlling side and a select signal for each controlled entity. 

We have two controlled entities, one for the LCD module and the other for the touch pad interface atop the screen. We can read or write to the entity by asserting its select line and then sending or receiving 16 bit words serially over MOSI/MISO. It is up to each controlled device what the data means - the protocol and bit definitions are up to the designer of that device.

I have example libraries from the company that sold the LCD Module, which I had to convert from Raspberry Pi Nano to classical Linux SPI and the interface used on the Cyclone V at the heart of my DE10-Nano board. I think I have this properly converted but it is possible that I introduced errors. 

In addition to the SPI link the LCD module has additional signal wires. One is used to define whether a particular word being transmitted is a command or data, the distinction being relevant to the way the LCD module works. Another is a reset signal that puts the LCD module in a known state. Lastly the touch controller will activate its interrupt line whenever the user touches the screen, thus that is another signal wire being used. 

If I have the SPI link configured properly, which is a set of choices that must be in sync between controlling and controlled entities, then basic data will seen or transmitted from the controlled entities properly. Clock phase, clock polarity, baud rate and word size are among the parameters that must match. 

Just talking to the devices is not enough, I have to send command and data streams that are meaningful to them in order to draw on the screen or read coordinates of the last touch on the pad. This is another area where my changes may have introduced bugs. 

Lastly, I have to correctly understand the addressing and rules for drawing characters or shapes on the screen. Is a vertical address the middle of a character, the top or the bottom? Same kind of question for horizontal addresses. Will I draw the text from left to right, or at a right angle or upside down? This part is not clearly spelled out in any of the documentation; I had to impute it from the code. This requires verification. 

Thus my first test programs will be writing text at a chosen location to verify the addressing and direction. It will draw a shape for the same purposes. I will touch a few points and check that a) I get an interrupt and b) the coordinates returned match my mental picture of the screen layout. All these tests will first have to test the lower levels, from the basic parameters upwards and validate all my conversion changes to the libraries. 

TESTING SETUP

To test I will need to hook up ten jumpers from the LCD Module to the DE10-Nano board. Using an oscilloscope as well as other diagnostic methods I can start to check out the communications from the most basic level on up, which might need to be done before a single thing appears on the LCD screen.  

With it all wired up and a good test program running, I saw that it stalled inside the LCD initialization call. I did some tracing and it appears that a routine to set up the registers for the module does special command to request the module ID - but it is blocking so we are not completing an SPI transaction. 

Next up I will double check polarities of the various signals to the module and then hook up the scope to see what is actually happening on the wires. Don't yet know what kind of SPI mismatch or misconfiguration or other error is at the root of this, but I did expect to have to fight through this before I was actually debugging my GUI screen images.