WAVESHARE PICO RESTOUCH LCD 3.5
This is the module I bought https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5#Setup_environment and it is serving my needs adequately although it is missing the ability to read anything from the LCD controller chip which would have been handy in debugging and experimentation.
HILLBILLY STYLE SERIAL INTERFACE GRAFTED TO THE LCD CONTROLLER
As I have mentioned in some detail before, this particular module has introduced an odd duck serial interface, not quite SPI, not I2C, but one that can be driven by (some) SPI implementations on microcontrollers and microprocessors. The LCD controller supports serial interfaces but the designer of this module chose to configure it in 16 bit parallel mode, then convert incoming serial to parallel with a hodgepodge of TTL chips.
Anyone think I have used enough pejoratives describing this? Hodgepodge. Hillbilly. Odd Duck. Oddball. Previously I did characterize it as Rube Goldberg-ish but really it is not that sophisticated an kludge. Enough already!
This clocks in serial data from the SPI MOSI line into a 16 bit latching SIPO shift register. It is able to handle frame (word) sizes of both 8 bit and 16 bit. It introduces rules for the SPI Slave Select line that help drive the LCD controller chip but are outside of SPI protocols.
Most seriously, since it is not really SPI, it has no means of sending data back from the LCD controller to the host over the SPI MISO line. This is unfortunate because the LCD controller has a rich set of commands that return internal state, configuration information and memory contents, all of which are unavailable.
The parallel interface of the controller chip would place the outgoing data on the 16 signal lines, but there are no TTL chips or wiring to receive them. The existing shift register could make use of its output enable pin to stop driving the parallel outputs, thus allowing the tristate LCD controller signals to output during a read.
Read and write operations on the 16 parallel pins of the LCD controller are effected by rising edge signals on the write enable (WRX) and read enable (RDX) lines. The TTL assemblage that is converting serial to parallel does toggle the WRX line to cause it to capture the data or commands coming from the host. The RDX line is hard wired to 3.3V and thus never has an edge to drive a read output.
POSSIBLE ENHANCEMENT TO SUPPORT READING FROM THE LCD CONTROLLER
One could imagine that additional circuitry could be added with a second board and the RDX line redirected from 3.3V to this new circuitry. The challenge is that the parallel interface and the command structure of the LCD controller would require a sophisticated state machine to determine when to strobe the RDX line, based on what commands had been transmitted and when those would be returning data.
For example, the command 0x09 will read out the status of the LCD controller and screen. One would write the 8 bit command to the device, then write up to four 16 bit words whose value doesn't matter because we are capturing the returning data from the MISO line.
The nature of SPI is that we are simultaneously sending the bits from host to controller (MOSI) and from controller to host (MISO), like ships passing in the night. Thus one cannot respond over MISO to something that is coming over MOSI since you will not have seen the MOSI data yet, all responses need to be sent over subsequent transfers. This command sends x09 and ignores MISO, then sends four more irrelevant transfers over MOSI while watching for returns from MISO.
A peculiarity of the controller chip means that for many read type commands the data is not yet ready to return when the second transfer begins (the first data transfer after the command is sent). Thus we are essentially doing a dummy exchange of MOSI and MISO as the first data transfer. The second and subsequent data transfers is when the MISO information is being returned.
My state machine would need to read every command sent, determine what the pattern of returned data will be, then block the WRX on the data transfers and instead toggle RDX to latch in the returning data. If done properly, a second (PISO) shift register could clock out that data on the MISO line fulfilling the expected behavior.
Note that the 8 bit command and values are part of the 16 bit parallel interface, we just ignore the high order 8 bits. The wacky protocol they devised transmits a short 8 bit word rather than a 16 bit word with zeroes at the top, when sending commands, but sends the full 16 bits when transmitting data.
This is far too much effort for little practical benefit. I will not be attempting it, but I burned the brain timing musing over it and decided to share it just in case this helps someone with a similar design issue.
No comments:
Post a Comment