Reshuffle of pin assignments and very minor hitch

NO LONGER NEED THE EXTRA FEATURES OF THE FPGA LINK TO THE SPI HARDWARE

I originally brought the SPI hardware out to the FPGA side because that offered me four slave select lines as well as an input to block the SPI clock in case more than one SPI master was sharing the line. Gradually those features were not needed or didn't work as I expected.

The input block signal never seemed to work, so I moved over to a different way of detecting that the -pick signal had gone back to high state. I had planned to leverage two of the slave select lines to provide the LCD Reset and LCD Command/Data signal to the LCD Module, but realized they didn't activate when I set them, only while bytes were being transmitted by the SPI link. I found other means to control those signals as well. 

At this point I only need the major SPI signals clock, MOSI and MISO, not even slave select since I am ignoring that output and using a different means of sending slave select to the LCD and touch controller chips. There is no longer an advantage and in fact since I had to instantiate buffer elements in the FPGA to drive the GPIO pins from these signals, I was introducing some delays that might be impacting the SPI behavior. 

LTC CONNECTOR DESIGNED TO PROVIDE SPI OR I2C CONNECTION

The Linear Technologies Corporation (LTC) connector was a means of connecting some peripherals to embedded systems, with many of those peripherals using I2C or SPI serial signaling over the connector. Terasic provided an LTC connector on the DE10-Nano board and this seemed the more natural and reliable way to connect my SPI lines. 

The connector is a two row by seven pin (2x7) but using 2mm spacing and smaller .5mm square pins that the usual 2.54mm style such as the GPIO 1 and GPIO 2 connectors on the board. Of the 14 pins, LTC customs mean that we have 3.3V, 9V and ground supplied taking up at least 4 of the 14. In addition, this board connects three more to ground, thus we have only seven pins available for signals.

The seven pins provide the clock, MOSI, MISO and slave select for SPI plus a clock and data line for I2C. However, they also implemented a pin called HPS_LTC_GPIO for general purpose input output in case a module connected to the LTC needed a discrete control line in addition to serial communications. 

The astute reader realizes that these come to a total of 8 signals over only 7 pins. This introduces a wrinkle, in that two of the pins are actually connected through a solid state DPDT relay, controlled by the state of the GPIO pin. 

If GPIO is low, pins 4 and 7 are connected to the SPI clock and MOSI inside the chip. If GPIO is high, pins 4 and 7 are connected to I2C clock and data. The I2C clock and data are also connected to pins 11 and 9 directly. This means that you can always connect the I2C but depending on the use of the GPIO pin, you might not be able to use the SPI. 

SMALL COMPLICATION

The connector uses smaller pins which means my current jumper wires won't connect reliably. The connector ends of the jumpers are also too wide to fit side by side if I need to hook them to adjacent pins. This blocked me from checking the SPI behavior with the scope until I resolve this.

I have a proper connector and cable for the LTC specs coming as well as jumpers that fit on 2mm pins then the other side fits on the more usual 2.54mm pin. Once I have these I can wire up the module and also observe with the scope. My testing has to wait a couple of days until I have all of this in hand. 

ONE WORRY

I had observed a few odd behaviors about the LTC connections and SPI in prior tests. This raises the possibility that some driver in Linux is already controlling SPI and the GPIO pin; I would need to disable this driver in order to have unimpeded access to both. 

I had tried to use the FPGA connection to SPI as a way of injecting the -pick signal to the master contention signal so that it would block clock output but also be detectable by reading the status registers of the SPI. I was never able to see that signal in the status register no matter what I did.

At another point I had hoped to use the HPS_LTC_GPIO pin as a input to detect the interrupt request from the touch controller on the LCD Module. Although I attempted to control it both as input and output, I was not successful. 

Now, this may have been due to a misunderstanding I had earlier about how to connect to the HPS side connectors. They are attached to the HPS side of the chip and one would presumable have access without needing the FPGA logic to be involved. However, that is not the case. 

Even when using HPS features purely from the HPS, one has to set the peripheral pin settings in the Platform Designer, connect the resulting signals inside the FPGA logic to the HPS signal pin, in order for this to work. If I have idle time I may do a test with HPS_LTC_GPIO now that I understand the nonintuitive connectivity process. It is not an urgent matter so no definite plan to check this.