3-wire and 4-wire SPI variations for LCDs

[thm_w]

Looking at SPI LCDs recently, they all seem to have their own flavors of pinout.

The most common is:
- SPI MOSI (maybe duplexed, unsure of this)
- SPI Clk
- CS
- Data/command pin

So its basically write only for most applications, and data/command pin is set depending on what is being sent. Which is easy to coordinate with DMA/SPI peripherals since you'd be sending a lot of display data at once.

The odd variation I see has the following (link below):
- SPI MOSI, Clk, CS
- SPI WR/A0

Ignoring the WR pin we have 3L for SPI connection instead of 4, and a pin is saved by sending the DC pin state as an extra bit (9-bit vs 8-bit). OK kind of makes sense if you are strapped for IO.
Now the confusing part to me is they also have a WR/A0 pin, normally it would mean DC (data command), but in this case not as its 9bit. They seem to reference it as a second SPI data bit, so two lane SPI? But optional.

Why would you go to the effort of saving a pin, slowing down SPI transmission with that extra bit, then adding back another pin again?
Are there any micros that actually support two bit SPI transmission? Some do support 9bit transfer, but others do not (STM32 can only do 8bit or 16bit). So if your hardware doesn't support it you've wasted 7 bit times.


https://www.aliexpress.com/item/4000466055741.html
https://www.eevblog.com/forum/beginners/half-duplex-spi-over-two-wires/

[T3sl4co1l]

Well, there are some possibilities:
- It's junk.  An extra pin they brought out from the controller, that you'll never have to touch.  Leave it NC.
- It's actually BS1 or something, and has to be tied high/low to set the correct signal mode.  (Often, a few configuration pins are provided, to select from parallel, serial 8/9 bit, etc. modes; in this case, you'd be screwed if either of the former modes were selected, since there's no D/C# pinned out.)
- It's mislabeled, and yes it's the D/C# pin as usual.
- It's mislabeled, and it's actually MISO.
- It's mislabeled, and it's actually SDA2 or something, a second lane.

There are indeed multi-SPI controllers; small MCUs tend not to have them, but most(?) ARM Cortex M0 and up have them, for example.  SD cards use this as the primary operating mode for example -- 4 lanes, half duplex, quite fast (50MHz+?).  (The 1-bit SPI mode I think is more of a fallback, but is still part of the standard.)

And yes, SDA often means, "MOSI except when it's MISO".  The "when" has to be specified somewhere, somehow.  For example, it might be that, after sending a particular command, the very next data byte that's asserted, the panel asserts SDA.  This may not be available in 3-wire mode, or serial at all; depends.

Once you've looked at enough LCD panels and controllers, you'll see these options as typical patterns --
- Sometimes the panel is dumb, just row and column drivers, and you need to stream graphics to it in real time.  Usually lots of pins, or LVDS lanes (serdes).  Needs a controller or FPGA to drive, or heroic work on a pretty fast MCU.
- Sometimes there's an onboard controller (chip on glass), or both (integrated controller-driver).  This seems pretty common; the flex comes off the glass and there's maybe some chip R/Cs on it, that's it.  Often, the full interface pinout is exposed, so you have your choice of 8/16 bit parallel, 8/9 bit serial, etc.  The config pins may be on the flex (so you need to order it with the correct jumper resistors, or move them yourself) or taken out to the connector for your convenience.
- Sometimes there's an offboard controller (chip on flex), or a PCB strapped to the backside or whatever, and the flex connects to that; or there's a socket on the board, and you use a flex jumper or something.  Similar options as above (although, I've seen one panel that's the first kind, but built in this way -- it has an LVDS serdes on PCB, and drivers elsewhere; yuck!).
- And there are high level ones, that may contain drawing routines and stuff.  Sometimes these are thanks to extremely featureful controllers (FT800 comes to mind), other times just with an MCU and proprietary implementation.  Typical interfaces are parallel, SPI, async (via TTL, RS-232 or RS-485), I2C, etc.  And even further towards industrial applications: CAN, Modbus, Ethernet and so on.

Often, the latter is an entire sub-goal of a project; it's rather handy to have a dedicated display driver, and to just pass it messages from time to time, not having to mind the display at every step.   (Why not get the off-the-shelf box?  Development time versus production cost tradeoff, of course.)

Anyway, try to find what controller it uses.  Sometimes they put it on the mech drawing, for some reason.  Sometimes they hide it as well as they possibly can.  Read the datasheet very carefully.  There are a lot of dumb copies of controllers out there, and as many variations as there are bug fixes, I'd bet...

If you don't have a datasheet, or the correct one, or it's incomplete, and you don't even have any example code, your job is pretty much impossible.  The prospects aren't even all that great with a complete one...

Tim

[thm_w]

Appreciate the info, it helps a lot.

There are indeed multi-SPI controllers; small MCUs tend not to have them, but most(?) ARM Cortex M0 and up have them, for example.  SD cards use this as the primary operating mode for example -- 4 lanes, half duplex, quite fast (50MHz+?).  (The 1-bit SPI mode I think is more of a fallback, but is still part of the standard.)

Good point, I did not consider SD peripherals with multilane. That would make a lot of sense as you'll often need to use SD and LCDs together.

And yes, SDA often means, "MOSI except when it's MISO".  The "when" has to be specified somewhere, somehow.  For example, it might be that, after sending a particular command, the very next data byte that's asserted, the panel asserts SDA.  This may not be available in 3-wire mode, or serial at all; depends.

Once you've looked at enough LCD panels and controllers, you'll see these options as typical patterns --
- Sometimes the panel is dumb, just row and column drivers, and you need to stream graphics to it in real time.  Usually lots of pins, or LVDS lanes (serdes).  Needs a controller or FPGA to drive, or heroic work on a pretty fast MCU.
- Sometimes there's an onboard controller (chip on glass), or both (integrated controller-driver).  This seems pretty common; the flex comes off the glass and there's maybe some chip R/Cs on it, that's it.  Often, the full interface pinout is exposed, so you have your choice of 8/16 bit parallel, 8/9 bit serial, etc.  The config pins may be on the flex (so you need to order it with the correct jumper resistors, or move them yourself) or taken out to the connector for your convenience.
- Sometimes there's an offboard controller (chip on flex), or a PCB strapped to the backside or whatever, and the flex connects to that; or there's a socket on the board, and you use a flex jumper or something.  Similar options as above (although, I've seen one panel that's the first kind, but built in this way -- it has an LVDS serdes on PCB, and drivers elsewhere; yuck!).
- And there are high level ones, that may contain drawing routines and stuff.  Sometimes these are thanks to extremely featureful controllers (FT800 comes to mind), other times just with an MCU and proprietary implementation.  Typical interfaces are parallel, SPI, async (via TTL, RS-232 or RS-485), I2C, etc.  And even further towards industrial applications: CAN, Modbus, Ethernet and so on.

Often, the latter is an entire sub-goal of a project; it's rather handy to have a dedicated display driver, and to just pass it messages from time to time, not having to mind the display at every step.   (Why not get the off-the-shelf box?  Development time versus production cost tradeoff, of course.)

Anyway, try to find what controller it uses.  Sometimes they put it on the mech drawing, for some reason.  Sometimes they hide it as well as they possibly can.  Read the datasheet very carefully.  There are a lot of dumb copies of controllers out there, and as many variations as there are bug fixes, I'd bet...

If you don't have a datasheet, or the correct one, or it's incomplete, and you don't even have any example code, your job is pretty much impossible.  The prospects aren't even all that great with a complete one...

Tim

Datasheet page 55 lists the 3-lane options as:
- SDA (bi-directional), SCL, CS
or
- SDA, SCL, SDO, CS

So as you explain it can be bidirectional when in a certain mode. Hard part is figuring out what mode its set to, and probably impossible to change it, as none of these config pins are available on the flex.

Relevant register would need to be enabled for the second data lane:

Code: [Select]

SPI2EN (E7h): SPI2 Enable
2-wire data lane serial interface use: CSX (chip enable), DCX (serial clock) and SDA (serial data input/output 1), and WRX (serial data input 2). To enter this interface, command E7h need set 10h
Which means, if config pin is set to 9-bit mode, we can guarantee this pin is only able to be used as a second lane. Making it essentially useless for me (stm32 only supports 1-bit or 4-bit SD card protocol).

Its amazing how many features this chip has and not all of them are used. For example, it has a PWM LED output. How nice would that be to save another IO pin and have the LCD handle your LED backlight? But I've not seen this routed out.

https://www.newhavendisplay.com/appnotes/datasheets/LCDs/ST7789V.pdf

[T3sl4co1l]

Heh, there ya go, it's just about all of the above.

8.4.1 says WRX is D/C# and DCX is SCK in 4-wire mode.  So yep, they rename them.  Hurray for confusing names (and broken english datasheets..).

They discuss 2-lane mode very lightly indeed, and don't provide a format or timing diagram. Is it bit-interleaved, is it byte-interleaved, is it MSB or LSB first?  At least that's not something most or any users will care about...

The Newhaven datasheet should say which IMx are set on the flex.  Probably they sell a bunch of variants for these options; not all of which may be stocked at a distributor, of course.

Tim