Testing the touch screen interface and dual speed SPI logic

QUICK TEST TO VALIDATE MY DUAL SPEED SPI OPERATION

My code now has functions to set the SPI link into two different clock rates, since the touch controller needs a relatively slow 2.5MHz while the LCD controller needs to be much faster to eliminate objectionable delay redrawing screens. I am using 25MHz for LCD communications.

In order to change the speed (baud rate), one simply has to disable the link, store a new value in the baud rate register and then enable the link for operation at the new speed. The baud rate is generated by dividing the 200MHz internal clock by the divisor we stored in the register. In my case, the value 8 which causes the SPI to operate at 25MHz. Storing the value 80 will instead give us the 2.5MHz rate.

To minimize the number of variables being changed, my first test will simply slow down SPI and redraw the LCD screen at the slower rate as well as at full speed. By visual comparison I can verify that the SPI link is operating properly at both slow and fast speeds and able to switch without a hiccup.

This worked perfectly, with a clear difference in the speed of clearing the screen to a different color. I started fast with cyan, slowed down and drew red which was noticeably slower, then sped back up and drew blue which was again fast. 

TESTING THE DETECTION OF TOUCH ON THE PANEL

The touch controller raises an interrupt request line whenever the stylus or a finger is touched to the surface. I am not using this to cause actual interrupts in the Linux system, but using the PIO function in my FPGA logic to see if a touch has and is occurring. PIO will set a bit to show whether an event has ever happened since the last reset of that detector. 

Thus I can read from the memory location tied to the PIO to tell if a touch was done, validate that it is still active by looking at the current status of that wire, and take appropriate action. That action would involve communicating with the touch controller over SPI at slow speed asking it to reach the location of the touch. My first test is simply to see that we do detect touches by reading the PIO registers. 

The first test, once I resolved an oopsie with pointer arithmetic, did successfully register a touch when I first tapped with the stylus. Unfortunately, it kept registering a touch and interrupting even when I had removed the stylus. That too was caused by a small error in my program, which  I corrected rapidly.

I am seeing the touch signals immediately as well as the latched in falling edge. Due to some bounce I did sometimes get a spurious additional edge captured. If the stylus is held in place, we get one edge initially but then only see the continued touch state. I think that my best bet is to look for both edge detection and a current touch to trigger a request to the touch controller for coordinates. 

ENSURING I CAN COMMUNICATE WITH THE TOUCH CONTROLLER

When a touch is taking place, the touch controller can take a voltage reading from both the X and Y resistor networks on the touch panel. We request this with a message over SPI. The library from Waveshare that was provided with the LCD Module reads these values several times to get an average position. It is up to my code to then use that reading to assign the touch to one of the arrows or the button if the user is requesting an action. 

This part of the testing only verifies that the touch controller responds with some location information while I am touching the panel and interrogating the controller over SPI. It doesn't yet tell me if the data is valid or useful but does prove I can talk to the controller chip.

This is failing. I seem to get nothing back but bytes of all zero. There can be many reasons for this which I need to start researching.