Skip to first unread message

Hanah anees

unread,
Sep 21, 2019, 7:34:24 AM9/21/19
to BeagleBoard

I have SPi0 and SPI enabled in device tree. I looped back shorting MISO and MOSI and Can receive the send messages provided its all 8 bit word length

The issue is I am trying to talk to St7735S display driver over SPI ,it needs 9 bit command and data transfer.

So I am trying to send tx1[6]={0x01AA,0x0177,0x0188,0x0100,0x01FF,0x0166}; , defined as short int (2 bytes) . but when I receive response its

01AA 5577 and so on. its not correct and nothing happens on display? Any help

Robert Heller

unread,
Sep 21, 2019, 8:13:00 AM9/21/19
to beagl...@googlegroups.com, BeagleBoard, Robert Heller
At Sat, 21 Sep 2019 04:34:24 -0700 (PDT) beagl...@googlegroups.com wrote:

>
>
>
>
>
> I have SPi0 and SPI enabled in device tree. I looped back shorting MISO and
> MOSI and Can receive the send messages provided its all 8 bit word length
>
> The issue is I am trying to talk to St7735S display driver over SPI ,it
> needs 9 bit command and data transfer.

Are you sure about that?

The Adafruit Arduino St7735S driver library seems to use 8-bit data and
commands and is doing 8-bit SPI transfers. And I know that works, because I am
using it with both an Adafruit Feather M0 express and an Adafruit Metro Mini
project (both programed via the Arduino IDE, but the driver code could be
ported to Linux easily enough).

>
> So I am trying to send tx1[6]={0x01AA,0x0177,0x0188,0x0100,0x01FF,0x0166};
> , defined as short int (2 bytes) . but when I receive response its
>
> 01AA 5577 and so on. its not correct and nothing happens on display? Any
> help
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Hanah anees

unread,
Sep 21, 2019, 8:46:56 AM9/21/19
to BeagleBoard
I am using ST7735S.It has a 3 wire serial mode which is 9 bit in every "byte transaction, 9th bit 1 for command and 0 for data.
It does have a 4 wire configuration (which would have made my life much easier), but the hardware vendor wanted it to be 3 wire mode. Can we even do this over SPIDEV in user space? I have set 9 bit word size and nothing seems to help.

Robert Heller

unread,
Sep 21, 2019, 10:44:56 AM9/21/19
to beagl...@googlegroups.com, BeagleBoard, Robert Heller
At Sat, 21 Sep 2019 05:46:56 -0700 (PDT) beagl...@googlegroups.com wrote:

>
>
>
> I am using ST7735S.It has a 3 wire serial mode which is 9 bit in every
> "byte transaction, 9th bit 1 for command and 0 for data.

Oh, so instead of the D/C control line, it gets a 9th serial bit...

> It does have a 4 wire configuration (which would have made my life much
> easier), but the hardware vendor wanted it to be 3 wire mode. Can we even

Yes, the 4 wire configuration greatly simplifies things -- you would be able
to just snag the Adafruit driver and replace the low-level SPI I/O to use the
Linux ioctls. What is the reasoning for wanting a 3 wire over a 4 wire? Is
there a shortage of GPIO lines (eg the GPIO lines are all committed to
something else).

> do this over SPIDEV in user space? I have set 9 bit word size and nothing
> seems to help.

Well, /usr/include/spi/spidev.h on my Raspberry Pi actually talks about
sending 9-bit messages in its comments... So, I am *presuming* that it is
possible...

>
> On Saturday, September 21, 2019 at 8:13:00 AM UTC-4, Robert Heller wrote:
> >
> > At Sat, 21 Sep 2019 04:34:24 -0700 (PDT) beagl...@googlegroups.com
> > <javascript:> wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > I have SPi0 and SPI enabled in device tree. I looped back shorting MISO
> > and
> > > MOSI and Can receive the send messages provided its all 8 bit word
> > length
> > >
> > > The issue is I am trying to talk to St7735S display driver over SPI ,it
> > > needs 9 bit command and data transfer.
> >
> > Are you sure about that?
> >
> > The Adafruit Arduino St7735S driver library seems to use 8-bit data and
> > commands and is doing 8-bit SPI transfers. And I know that works, because
> > I am
> > using it with both an Adafruit Feather M0 express and an Adafruit Metro
> > Mini
> > project (both programed via the Arduino IDE, but the driver code could be
> > ported to Linux easily enough).
> >
> > >
> > > So I am trying to send
> > tx1[6]={0x01AA,0x0177,0x0188,0x0100,0x01FF,0x0166};
> > > , defined as short int (2 bytes) . but when I receive response its
> > >
> > > 01AA 5577 and so on. its not correct and nothing happens on display? Any
> > > help
> > >
> >
> > --
> > Robert Heller -- 978-544-6933
> > Deepwoods Software -- Custom Software Services
> > http://www.deepsoft.com/ -- Linux Administration Services
> > hel...@deepsoft.com <javascript:> -- Webhosting Services

Dennis Bieber

unread,
Sep 22, 2019, 12:29:55 AM9/22/19
to BeagleBoard

For some reason all my responses of the last week via gmane.comp.hardware.beagleboard.user have been getting rejected at the Google Groups interface; I had to join the group using the Web interface...

On Saturday, September 21, 2019 at 8:46:56 AM UTC-4, Hanah anees wrote:
I am using ST7735S.It has a 3 wire serial mode which is 9 bit in every "byte transaction, 9th bit 1 for command and 0 for data.
It does have a 4 wire configuration (which would have made my life much easier), but the hardware vendor wanted it to be 3 wire mode. Can we even do this over SPIDEV in user space? I have set 9 bit word size and nothing seems to help.


If I understand the documentation https://www.crystalfontz.com/controllers/Sitronix/ST7735S/437/ the 3-wire mode uses the SAME pin for both input and output data. If so,you can NOT rely on a "loopback" echoing the output command/data as you'd be reading bits from your own output, possibly delayed by a half clock or so.

How does one even wire this? Processor MISO and MOSI both connected to one pin (SDA) of the display?

The documentation indicates that 1) you should only be reading display output after sending a "read command" and 2) the output from the processor needs to go tri-state (float/open) at the end of said command before reading the display return value. You need to keep chip select and clock going through this cycle.

That's a half-duplex mode, where each side takes turns putting data on the bus. I don't think SPI operates that way -- SPI is full-duplex, with both sides putting data on the bus on each clock cycle. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Three-wire_serial_buses
"Few SPI master controllers support this mode; although it can often be easily bit-banged in software. "

You might have to code the protocol using a PRU, with some interface to the main processor for sending/receiving data. Though, given that the protocol only transfers on clock transitions, just using GPIO from Linux may be sufficient -- a longer clock cycle from the OS pre-empting your code shouldn't matter.

Robert Heller

unread,
Sep 22, 2019, 9:29:03 AM9/22/19
to beagl...@googlegroups.com, BeagleBoard, Robert Heller
At Sat, 21 Sep 2019 08:41:25 -0700 (PDT) beagl...@googlegroups.com wrote:

>
>
>
>
> For some reason all my responses of the last week via
> gmane.comp.hardware.beagleboard.user have been getting rejected at the
> Google Groups interface; I had to join the group using the Web interface...
>
> On Saturday, September 21, 2019 at 8:46:56 AM UTC-4, Hanah anees wrote:
> >
> > I am using ST7735S.It has a 3 wire serial mode which is 9 bit in every
> > "byte transaction, 9th bit 1 for command and 0 for data.
> > It does have a 4 wire configuration (which would have made my life much
> > easier), but the hardware vendor wanted it to be 3 wire mode. Can we even
> > do this over SPIDEV in user space? I have set 9 bit word size and nothing
> > seems to help.
> >
> >
> If I understand the documentation
> https://www.crystalfontz.com/controllers/Sitronix/ST7735S/437/ the 3-wire
> mode uses the SAME pin for both input and output data. If so,you can NOT
> rely on a "loopback" echoing the output command/data as you'd be reading
> bits from your own output, possibly delayed by a half clock or so.
>
> How does one even wire this? Processor MISO and MOSI both connected to one
> pin (SDA) of the display?


That is NOT SPI, that sounds like I2C, which is a completely different
interface...

Looking at the Adafruit 1.8" TFT Display Breakout and Shield documentation,
which also has a ST7735S embeded in it, it looks like Adafruit just wired MOSI
(through a level shifter) to "SDA". The Adafruit ST7735S does not perform any
readback functions. Eg. it is treated as a write-only device (Adafruit has it
configured as a 4-wired SPI).

>
> The documentation indicates that 1) you should only be reading display
> output after sending a "read command" and 2) the output from the processor
> needs to go tri-state (float/open) at the end of said command before
> reading the display return value. You need to keep chip select and clock
> going through this cycle.
>
> That's a half-duplex mode, where each side takes turns putting data on the
> bus. I don't think SPI operates that way -- SPI is full-duplex, with both
> sides putting data on the bus on each clock cycle.
> https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Three-wire_serial_buses
> "Few SPI master controllers support this mode; although it can often be
> easily bit-banged in software. "

Given the pin names (SCL and SDA), this *sounds* like an early incarnation of
I2C somehow mixed with SPI.

>
> You might have to code the protocol using a PRU, with some interface to the
> main processor for sending/receiving data. Though, given that the protocol
> only transfers on clock transitions, just using GPIO from Linux may be
> sufficient -- a longer clock cycle from the OS pre-empting your code
> shouldn't matter.

Or you can do what Adafruit did: use it in write-only mode. Or not use the
hardware SPI at all, and just bit-bang some GPIO pins. I think the GPIO pins
can be set to a bi-directional mode.

Dennis Bieber

unread,
Sep 22, 2019, 12:21:52 PM9/22/19
to BeagleBoard


On Sunday, September 22, 2019 at 9:29:03 AM UTC-4, Robert Heller wrote:

That is NOT SPI, that sounds like I2C, which is a completely different
interface...  

I wouldn't be surprised if it was... Looking deeper into the ST7735S spec sheet (sheet? 201 pages is a sheet?) even the four-wire mode is still using a single data line. What is different is that, instead of using a leading 9th bit to identify data/command, it uses the fourth wire to carry that status while clocking out the 8bit information.

However, as the Wikipedia article shows -- there IS/WAS a barely supported 3 wire SPI protocol. And the spec sheet does call it a SPI mode:
"""
The ST7735S is a single-chip controller/driver for 262K-color, graphic type TFT-LCD. It consists of 396
source line and 162 gate line driving circuits. This chip is capable of connecting directly to an external
microprocessor, and accepts Serial Peripheral Interface (SPI), 8-bit/9-bit/16-bit/18-bit parallel interface.
"""

There is no I2C address information used in the protocol, so one couldn't substitute I2C for SPI.


Or you can do what Adafruit did: use it in write-only mode.  Or not use the
hardware SPI at all, and just bit-bang some GPIO pins.  I think the GPIO pins
can be set to a bi-directional mode.


Bit-Bang via GPIO or using PRU is probably going to be required if the application needs to use read commands. To my understanding, SPI expects to send bits at the same time it receives bits, and the clock only runs while bits are being transferred. Even if the chip is wired to both MOSI and MISO, to run the clock during the return data time frame would require sending data of equivalent bit-length. One would need some way to "disconnect" MOSI so those bits don't interfere with the return data.

With the clock running via GPIO, one could "stall" the clock phase at the end of the output command/data, toggle the GPIO from output to input, then resume the clock reading the returned data.

Hanah anees

unread,
Sep 24, 2019, 12:30:15 PM9/24/19
to BeagleBoard
i wrote the code using spidev on PocketBeagle and can see 9bit data and clock going out and messages seems to be correct.
I think the driver puts only 9 bits when we define as 2 byte word and give instruction to send 9 bit spi. The TI AM335X MCspi controller does have control registers to load and send 9bit "data". For me the display is still not working and I think its something else. but if anyone has done 9 bit code, i will like to compare. I will post my code soon for others as well

Dennis Lee Bieber

unread,
Sep 24, 2019, 4:00:57 PM9/24/19
to Beagleboard
[Default] On Tue, 24 Sep 2019 09:30:15 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Hanah anees
<hanahtechnology-Re5...@public.gmane.org> wrote:

>i wrote the code using spidev on PocketBeagle and can see 9bit data and
>clock going out and messages seems to be correct.
>I think the driver puts only 9 bits when we define as 2 byte word and give
>instruction to send 9 bit spi. The TI AM335X MCspi controller does have
>control registers to load and send 9bit "data". For me the display is still
>not working and I think its something else. but if anyone has done 9 bit
>code, i will like to compare. I will post my code soon for others as well
>

If you haven't, download the TRM for the chip (I'm not certain what
document that would be for a PocketBeagle. For the BeagleBone Black, it is
TI's www.ti.com/lit/pdf/SPRUH73 which is the document I'll be quoting from.

First surprise -- the BBB chip DOES support single-data pin mode! (Page
4887 of SPRUH73P)

"""
24.3.1.2 Single Data Pin Interface Mode

In single data pin interface mode, under software control, a single data
line is used to alternatively transmit and receive data (Half duplex
transmission).

McSPI has a unified SPI port control: SPIDAT [1:0] can be independently
configured as receive or transmit lines. The user has the responsibility to
program which data line to use and in which direction (receive or
transmit), according to the external slave/master connection.

As for a full duplex transmission, the serial clock (SPICLK) synchronizes
shifting and sampling of the information on the single serial data line.
"""

The examples assume a transmit-only or receive-only system. Using a
command to read the display may require some interesting tricks -- namely
after the command is sent, changing the pin direction, and then specifying
a read operation.

Pages 4895-4896 cover the transmit-only/receive-only functions. Page
4897 mentions constraints for switching direction (mainly, keeping the
enable line active, and only changing SPI parameters [direction] between
words).

AND on page 4898 is what you probably really need to read...
"""
24.3.2.7 Start Bit Mode

The purpose of the start bit mode is to add an extended bit before the SPI
word transmission specified by word length WL. This feature is only
available in master mode.

This mode is programmable per channel using the start bit enable (SBE) bit
of the register MCSPI_CH(i)CONF).

The polarity of the extended bit is programmable per channel and it
indicates whether the next SPI word must be handled as a command when SBPOL
is cleared to 0 or as a data or a parameter when SBPOL is set to 1.
Moreover start bit polarity SBPOL can be changed dynamically during start
bit mode transfer without disabling the channel for reconfiguration, in
this case you have the responsibility to configure the SBPOL bit before
writing the SPI word to be transmitted in TX register.
"""

IOWs -- leave the word length at 8-bits, but activate the start bit
feature, and set the proper phase value for command/data.

--
Dennis L Bieber

Reply all
Reply to author
Forward
0 new messages