EXAMPLE CODE IS SLOPPY THEREFORE TAKES DEFAULTS
The module was built with pins that fit onto a Raspberry Pi Pico board, thus the code examples are built for this. This includes a call to initialize the SPI link (spi_init) which sets the pins wired to the controlled devices, and the clock rate to be used. .
However, there are important parameters for SPI beyond just the clock rate. The state of the clock when idle (CPOL) and the edge of the clock when the master output should be sampled (CPHA) are essential for successful communication. The size of the data being transmitted in bits is also fairly important.
These would be defined by a call to set the parameters, but that is not included in the C or Python examples. Thus, these are the defaults that will be taken by the Raspberry Pi Pico and not clearly marked in the code. Since a Cyclone V or any other device may have different defaults, it is sloppy to not assert the choices explicitly.
RASPBERRY PI PICO DOCUMENTATION DOES NOT SHOW DEFAULTS
I then went to the Software Development Kit (SDK) documentation for the Pico to see what defaults are chosen for the SPI parameters. Not one word about this in the documentation. I know how to set the choices, but not what they are if I don't issue a set command.
MODULE DOCUMENTATION DOES NOT SPECIFY THE PARAMETERS
Nothing shipped with the module tells me the clock rate, CPOL, CPHA, bit size or any other factors other than the pins assigned to SCLK, MOSI, MISO and SS. One could always experiment, varying the parameters to see if they work with the module. One could run the example code and use a scope or logic analyzer to figure out the answers. You just can't learn it by reading anything I could find.
SCHEMATICS AND DATA SHEETS TO THE RESCUE
The module maker did offer a wiki with the example code, a schematic for the module and datasheets for the two major chips used - LCD panel driver and touch screen interface. Neither of those chips use SPI protocol, but they were adapted on the module to be compatible.
The LCD driver has a 16 bit parallel input, so there are four 7400 series chips that shift in the SPI bit stream to create the parallel signals for the LCD chip , as well as toggling everything to lock in the value and trigger the LCD chip. Using the data sheets for the 7400 series chips and the datasheet for the LCD panel driver chip, I determined that the CPHA value is 0 and the CPOL is 0, with a frame size of 16 bits.
The touch pad interface chip has a clocked serial input that works properly with CPOL/CPHA of 0/0 however I see that the clock rate for talking to the touch pad chip is lower than the clock rate used in the example code for the LCD driver chip. Since my interface will not have rapidly changing output, I will write my code to use 2.5MHz for both, the lower speed I discovered.
INTERESTING DISCOVERY
I had assumed that the example code would have instantiated an interrupt handler for the pen touch interrupt that comes from the LCD module, but in looking at the code they simply loop sampling the interrupt pin as if it were a pushbutton. That is an option for me as well.
The user interface is only active when the drive is not read/in use. At startup or when the drive is off, we can just looping looking at the touch pin and act accordingly to update the UI on the LCD screen. Once the user selects a file, we will be busy for some time while loading the cartridge image into SDRAM by communicating with the FPGA, but generally we are looping.
When we see that the drive has attempted to load heads (pick signal) and we have successfully set up the cartridge image in SDRAM, we turn on the drive_ram signal in the FPGA and no longer need to worry about touch interrupts. When the pick signal turns off we are going to tell the user we are unloading the cartridge, suck the changes back through the FPGA to the image file, and then resume the user interface loop looking for touches.
No comments:
Post a Comment