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
On Sunday, September 22, 2019 at 12:21:52 PM UTC-4, Dennis Bieber wrote: > > > > 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. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee126a7a-e089-4464-9106-38a5b17ef8b8%40googlegroups.com.
