How to Connect arduino in LCD mode SPI

I have an LCD display (16x2) in SPI mode and I would like to know how to connect the display pins on my arduino Nano, also, how to configure them with the U8Glib library.

Réf LCD : MC21605C6W-BNMLWS-V2

Since you have a 2 line 16 character display you would use

U8Glib is for graphic displays.

The adafruit 292 board does not really use/support SPI.
It is a serial shift register with a latch pin that uses 4 outputs on the shift register to control the LCD in 4 bit mode.
While Adafruit calls it "SPI" isn't SPI and anything that controls the LCD through the 292 board using the "SPI" mode will not work with a LCD that actually uses a SPI interface.

--- bill

What's in a name?
Nothing on the LCD is labelled MOSI or MISO either.
So how "SPI" can is that?

RS - register select
/CSB - chip select
SCK - clock
SID - data in
Maybe I2C is the better fit?

Apparently, RW1063 controller is used in this display .

I tried to adapt this program but it does not work :
CFAH2004AP use also RW1063 controller .

Just knowing that it is a RW1063 isn't enough.
That controller can be strapped to run 3 different modes:

  • 4/8 bit pin control
  • I2C
  • SPI

First you need an accurate datasheet for the display you actually have.
You need to know which mode it is configured for.
Then, if it is strapped for i2c or SPI mode, you will to know how to encode the bytes across the interface bus to control the hd44780 signals and send instructions to control the the LCD.
All this should be in a full datasheet or you can get it from a RW1063 datasheet.
Once you know the mode and how the hd44780 instructions are encoded it is possible to see if there are any libraries already written that support it.

If it strapped for 4/8 bit mode you can use the LiquidCrystal library.
If it is strapped for I2C you can use the hd44780 library with the hd44780_I2Clcd i/o class
If is strapped for SPI, I think you may be out of luck.
I looked at the RW1063 datasheet.
And while the interface is kind of sort of SPI like it it isn't actually SPI.
The biggest issue is that you can't control the LCD using only the data and clock pins.
You must also use the RS pin (pin 5) to select between character writes and commands. The "SPI" interface simply transfers 8 bit data bytes.
The RS pin must also be used in this mode.
This is pretty screwy and I've never seen a LCD interface that works this way before.
Normally when you have a real SPI interface you clock the data bits in and the data stream includes everything you need to control the LCD. For an hd44780 type interface it would be the control signals like RS as well as the LCD data bits.

I've not ever seen a library that works with this type of interface.
Not to say one doesn't exist but I've never seen one.

If I had that LCD, I would look very closely at it to see if I could restrap it to run i2c mode instead.

It wouldn't be that big of deal to write an i/o class for it for my hd4780 library that supports this screwy "SPI" mode but I don't have one of those "SPI" LCD devices to test it.
Given I've never seen an LCD that uses this type of "SPI" interface, I'm guessing that it isn't very common.

--- bill

The first diagrams already shows its pinned out for "SPI".

Normally when you have a real SPI interface you clock the data bits in and the data stream includes everything you need to control the LCD. For an hd44780 type interface it would be the control signals like RS as well as the LCD data bits.

It's actually a good idea to have the RS bit separately from the data stream, or else you would have to either send an extra byte for each command/data stream to account for this bit, or somehow make it work in extended SPI (8+ bit mode). Some ST7789 work in this mode, and that extra D/C bit makes the driver a lot more complicated

There are a lot of ways to transmit data.
What I was saying is that when there are extra control signals outside of the data stream, such as an RS signal wire in this case, it is no longer a SPI interface bus as defined by Motorola and IMO, should not be called SPI.

--- bill

The RS signal is not a control signal for the SPI interface, but for the LCD controller itself. SPI bus makes no assumptions of any connection other than the four defined by the standard. I can guarantee that with or without the RS signal, the SPI communications between the host and the LCD controller would still work. The LCD might not behave as desired, but the LCD would still be able to decode the bits put in by the master in the SPI bus.

For this LCD device, the RS signal must be used to tell the LCD if the data byte being sent is a data/character write or an instruction/command.
I've been saying that if you are having to use additional signals outside of the SPI data stream, to control the device, the device is not really using SPI - it may be similar to SPI by using similar cs, data, clk signals but it is not SPI.
Such is the case for this LCD device.
On a REAL SPI slave device you can fully control the slave device using nothing but the SPI bus data stream.
The real spec uses 4 pins (SCK, MOSI, MISO, SS or CS)
For an output only device you can limit that to 3 pins CS, SCK, MOSI
This LCD needs another signal outside of the SPI bus data stream (outside the SPI spec) to control it since the h/w interface is not really SPI but just a serial byte latch.

And for sure you will have to properly set the RS signal prior to sending data to the LCD since you must tell the LCD whether the serial data being transferred is a character write or a command write.
If you don't dynamically control RS then you would only be able to send commands or only data depending on which constant level you set it to.
The LCD is unusable if you can't send both commands and characters.
I guess technically you might be able to use it if the default power up mode was what you needed, set the RS level to send characters and you always sent 80 characters to fully load DDRAM each time you wanted to update the display.

--- bill

So the long and short of this is that you do not/ can not provide library support for it and the OP is essentially "up the creek without an oar"? :face_with_raised_eyebrow:

Does the display actually use or resemble the HD44780 in any way?

Note that if you are using serial data, there is clearly no point implementing any form of 4-bit mode. :roll_eyes:

I wouldn't say I can't provide support for in the hd44780 library but as of today there is not support for the serial psuedo SPI mode for this device.

Yes completely. The issue is the serial psuedo SPI mode.
My library doesn't support it and I've not yet seen a library does does.
There might be one, I'm just not aware of one.
The device uses a RW1063 chipset.
As I mentioned previously
That controller can be strapped to run 3 different modes:

  • 4/8 bit parallel pin control
  • I2C
  • serial (psuedo SPI mode)

In 4/8 bit mode it works just like a typical hd44780 and can work with the IDE supplied LiquidCrystal library or any library that supports talking to an hd44780 display using direct pin control including the hd44780 library hd44780_pinIO i/o class.

For i2c mode, it resembles a PCF2119x, PCF2116 and the hd44780 library hd44780_I2Clcd i/o class can control it over the i2c bus.

It is the serial mode that is funky for this device.
If it were me, I'd look closely at the LCD PCB and see if the IF0 and IF1 pins on the RW1063 chip can be located to re-strap it for i2c mode.
That way it could at least work with the existing hd44780 library.

The RW1063 chipset claims to only support the 4 bit mode when strapped for the parallel 4/8 bit mode. When in i2c or psuedo "SPI" mode it claims to only supports 8 bit mode. My guess is that it still supports 4 bit mode but you will always have to send it all 8 bits, so as you said there is no point to use 4 bit mode in i2c or serial mode.

--- bill

This is hilarious. You would have to use that term for just about any device now that has other control signals other than the SPI bus. The HOLD, WRITE_PROTECT, CHIP_ENABLE, INTERRUPT, ADDRESS, RS, D/C pins are the more popular signals "outside" of the SPI pins.

Again the SPI bus was defined by Motorola and consists of
(some devices use an Interrupt back signal)
Chip enable is the same as SS and is part of SPI.
If a SPI slave device supports slave addressing to allow the sharing of a single CS/SS pin, then that address is fixed/strapped on the slave. For that type of device the master selectes which slave by including the address information in the data stream. The address pins are NOT additional control information that affects the data being transferred to that slave like the use of an RS signal on this LCD device.

There are many devices and products that use the term SPI but are not really SPI bus slaves.
The biggest thing they lack is the ability to fully control them through the data stream.
And THAT is what I'm talking about for this LCD device.

This particular device has what it calls SPI mode but it does not implement a SPI bus slave. This LCD device requires using additional signal, RS, since the data stream is only 8 bit data bytes and has no control information.
While code can be written to support it, the device is definitely not using a SPI bus.
In fact if the Arduino code used to control the LCD use the Arduino h/w SPI library to push the data bytes to this device, the arduino processor would still have to burn an additional pin for MISO signal because that signal is part of the SPI bus protocol and cannot be disabled.

I'm done talking about this LCD device not being a real SPI bus slave.

--- bill

For your device it is more complicated than just how to wire it up.
How to wire it up electrically should be fairly obvious.
If using h/w spi you would hook up:
LCD pin 12 CSB to the Arduino SPI SS pin
LCD. pin 13 SCLK to the Arduino SPI SCK pin
LCD pin 14 SID to the Arduino MOSI pin
You have to make sure to not use the Arduino MISO pin anything.
LCD pin 4 RS to some other Arduino pin.

But that is just the electrical connections.
You then need to either write your own code to control the LCD or find a library.
But like I previously said, this LCD is a bit strange in how it is controlled when the RW1063 chip is configured for this "SPI" mode since it requires using and additional pin outside of the SPI bus.
I've not seen a library for this LCD device. one may exist but I've not seen one.

If you can figure out how to restrap the LCD module to run i2c then you could run it with the hd44780 library.

--- bill

Again, the SPI bus protocol does not care and makes no assumption on the type of data being transferred in the bus, much like Ethernet does not care whether it's IP, Appletalk, etc for the PDU. It is just a bus protocol and not a control protocol. The SPI bus protocol does not specify nor require that the slaves must be fully controllable only via the bus. If you can point me to literature that somehow describe the "full control only via SPI to make it real SPI" aspect of SPI, then I will gladly start referring to the tens of SPI devices that I wrote driver for as "pseudo SPI" even though every single datasheet and reference manual from the manufacturer calls it SPI.

Yes, lots of CLCD, GLCD, OLED, TFT controllers have different styles of "SPI" interface.

Some with 9-bit data, some as 8/16-bit with separate DC/RS line, some with an 8-bit "control-byte", some with a bidirectional SDA pin, ...

I would not get too upset by the terminology. Just accept that every microcontroller can handle an 8-bit data.
However AVR, SAMD, PIC18, ... can not handle 9-bit in hardware. Nor bidirectional data, ...

Every "display controller" that I have met can be driven with just lcd_command() and lcd_data() functions. And the RW1063 chip looks much the same.

Whichever interface is used, implementing lcd_command() and lcd_data() is trivial. Ideally by using the microcontroller hardware SPI peripheral.
And changing interface is equally trivial.


@samuel34 if you still need help,

  • link to the page where you have bought your display
  • upload the datasheet you are following
  • upload a clear picture of your display/Arduino wiring. Each and every wire must be visible.
  • upload YOUR sketch you are using,
  • show a picture what your display is showing with your sketch
  • if you are using an unmodified library, give a link.
  • If you have modified just one single line, mark what you have changed and upload the full library to the forum.

if you have solved your issue on your own, please provide the solution.

Sure the SPI bus interface does not care about the type of data that is transferred because SPI is a physical and datalink layer.
But do not confuse or intermix the physical layer and datalink layer (the h/w layer - which in this case is the SPI bus) with higher layers of the communication like transport, and session layers that start to look at the data bytes/bits and parse them.
i.e. Ethernet is physical and datalink layers while IP and Appletalk are higher communication layers typically implemented in s/w that are above the hardware layer. These type of protocols can run on many different types of hardware interfaces.

Imagine if in order to use Ethernet, a device required running additional wires to communicate additional control or synchronization information to the device.
This would no longer be an Ethernet device likewise for something like SPI if you run additional wires it is no longer just SPI.
It is using a proprietary extension of SPI.

Actually by definition it does.
The original spec was written by Motorola.
From Wikipedia:

SPI Bus was originally defined by Motorola. The original defining document was Motorola Application Node AN991. When Freescale spun out of Motorola, the responsibility for AN991 went with Freescale. When NXP acquired Freescale, NXP also acquired responsibility for AN991 which was last revised in January of 2002 as AN991/D[13] and still serves as the "official" defining document for SPI Bus.

Here are some links about SPI and to AN991 documents.
These link to the original SPI spec that goes back to 2002.
The AN991/D app note by Freescale:

The AN991/D note maintained by NXP:

If a device needs or depends on other signals for control or data synchronization than what is provided by the SPI bus, then technically it is stepping outside the SPI bus interface as defined by Motorola.

Unfortunately, there was never an actual world-wide ISO standard for SPI bus, it was just a "defacto" standard.
Because of this, there are slaves that exist that are not actually SPI bus devices, but say they use SPI in their datasheets.
Just because they call it SPI in their data sheet and can transfer bytes over serial pins the same way as SPI bus using a data signal and a clock does not mean it really is a SPI bus device.
A device may use the same method of transferring bytes with clock and data signals as SPI but once they start doing things like depending on additional signals they are no longer SPI bus devices as they have extended the SPI bus in a proprietary way.

Just like a device that needs additional signal wires beyond the Ethernet connection to use Ethernet communication is not really an Ethernet device.

It doesn't mean that these proprietary SPI extensions are not useful and helpful for devices. To the contrary, in many cases these extensions can make things simpler and faster but it does come at the expense of being a proprietary extension to the SPI bus that needs additional signal wires.

It can also create some complexity in communication in certain environments.
Consider the case where you have h/w driven SPI that allows you to queue up multiple bytes and the h/w feeds it to the SPI slave in the background freeing up the processor to do other things while this transfer is happening.
For a device like this LCD, where you have to use an additional signal outside the SPI bus you could not always take advantage of this capability.
You have to wait for all the character bytes to finish before you send any command bytes to the h/w and likewise you would have to wait for the command bytes to finish before you could send any characters.
Not that it can't be worked around, but this is the kind of stuff you step into once the device is not just using the SPI bus for data communication.

--- bill

Yes, I quite agree that the 8-bit SPI + DC line model requires the DC value to be stable at the time the last data bit is clocked.
This is shown in the device Timing diagrams.

An exact "parallel behaviour" as you see in a 8-bit parallel interface.

In practice this complicates DMA. Hey-ho, you just have to live with it. The alternatives have a slower throughput.

If you are presented with timing diagrams in a datasheet, you just make best use of the available hardware peripherals. It should be trivial to drive the RW1063 "4-wire SPI".

But I certainly agree that the terminology is confusing. However timing diagrams clarify.

Let's face it. Most of the Silicon comes from China or Taiwan. They do a pretty good job of translating into English with probably less errors than U.S. and European companies .