pico-examples

pico-examples copied to clipboard

ST7789 Pico Example

I am testing the example out of the box on a 1.3" IPS LCD ST7789 display. Display Pinout

Full board to review. ST7789 1.3" IPS LCD

The board, pic above, has the following pinout.

GND
VCC
SCL
SDA
RES
DC
BLK

The code defines the following pins.

#define PIN_DIN 0
#define PIN_CLK 1
#define PIN_CS 2
#define PIN_DC 3
#define PIN_RESET 4
#define PIN_BL 5

I connect in this fashion.

PIN_DIN 0          SDA
PIN_CLK 1          SCL
PIN_CS 2            NOT CONNECTED
PIN_DC 3           DC
PIN_RESET 4      RES
PIN_BL 5            BLK

The result is the screen lighting up the backscreen however producing no image.

Without the CS pin on the board I tried driving it to VCC and GND and still no effect.

Is this display not compatible? Is so, why not?

If that is the case what exact board was this code written for?

@kromych I saw you made a mod recently, do you have any idea?

Thanks in advance!

Mine is Waveshare 320x240. It would not work at first, too, with similar symptoms. For me, that turned out to be timing and signal integrity. The fix was:

1. decrease the frequency, or
2. not use the Dupon wires, and instead use a breadboard with short patch wires b/w Pico and the display unit.

I used the pinout as in the example, now have switched to this one:

The display	The Pico
BL	GP20
RST	GP21
DC	GP16
CS	GP17
CLK	GP18
DIN	GP19

The change:

-#define PIN_DIN 0
-#define PIN_CLK 1
-#define PIN_CS 2
-#define PIN_DC 3
-#define PIN_RESET 4
-#define PIN_BL 5
+//      LCD           |    Pico
+
+#define PIN_DIN 19      // SPI0 TX  (MOSI)
+#define PIN_CLK 18      // SPI0 SCK
+#define PIN_CS 17       // SPI0 CSn
+#define PIN_DC 16       // SPI0 RX
+#define PIN_RESET 21    // GPIO
+#define PIN_BL 20       // GPIO

@kromych thank you for getting back to me. I slowed the SERIAL_CLK_DIV 0.1f even tried 0.5f and still did not work. I do not have a CS pin on this device. I am unable to get it to function even after your suggested remapping.

I am testing the example out of the box on a 1.3" IPS LCD ST7789 display. Display Pinout

Full board to review. ST7789 1.3" IPS LCD

Understood, thanks! The omission of the CS pin on the board makes me think the manufacturer might have pulled it up/down or mux'ed with another signal? The code in the example flips the CS back and forth when sending the commands. I'll go ahead and order what you have as this has piqued my curiosity :)

Couldn't find a datasheet for the part. Planning also at rummaging through other example code out there (verilog/c++/rust) to see if anyone has come across such specimen.

I can't tell you how much this means @kromych! I am in the process of using this in a badge and am stuck. If you can get this working on this specific device it would be huge for me.

Goal 1)have a utility to convert a color png or jpg to a .h file (assume RGB565) 2)have the display have a font to print text (as this example currently does not) 3)have the display actually display the .h image converted file.

@kromych possible datasheet? datasheet

Thanks! That's a datasheet for the display driver; would be great to have one for the SPI interface used in the board you got. From the absence of CS, the polarity and the phase used for sampling SPI data most certainly have to be adjusted (4 combinations, spi_set_format in the SDK).

Adding spi_init and spi_init_format to this particular example looks like butchering it as in all fairness the example serves another purpose as much as I understand. Changing polarity can be done with inverting the signal (see the adjacent PIO SPI example) whereas the phase is harder to handle to me using PIO due to my current ~low experience with PIO. Hopefully someone with the solid knowledge of PIO comes across this thread and adds support for adjusting the polarity and phase employing the PIO in a natural way. Until then, I'll keep poking at this.

Workflow-wise, a more precise title of this issue (currently "ST7789 example does not function") could be "ST7789 example does not support boards with no CS pin", and folks could debate if this PIO example is the right place to add support for boards that don't have the CS pin.

updated title, looking forward to what you come up with @kromych

Hi, this example claims to work for the pico using a ST7789 display without a CS pin. If that doesn't work, I managed to get the exact same CS-pin lacking display working for a raspberry pi zero project a while ago after many hours of attempts, and put some findings in the README and in the display.py file there. Best of luck, that display is cursed 😅

For me polarity = 1, phase = 0 works for both - with or without CS. Phase and polarity = 0 is the same like that, but without extra dummy clock cycle (or half of it) at the start. Compare here: https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html. Maybe that will be easier to implement to PIO driver.

I have gotten some time and CPOL=1 worked for me with either value of CPHA, with CS or without CS. There is a more generic sample for SPI in the PIO samples, perhaps it could help out. If using hardware SPI, here is an example that I wrote to test the display: https://github.com/kromych/pico-bites/blob/e5b2335f95ec81e3c2ad63850f1132b9630ab034/examples/e05-lcd-st7789.rs#L75

The TFT_eSPI library might be a better starting point for advanced graphics. It has provisions for RP2040+SPI+PIO, and lots of drivers: https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/pio_SPI.pio.h. Speaking of drivers, the Linux kernel tree has some code, too, as another reference point: https://github.com/torvalds/linux/tree/master/drivers/staging/fbtft

I have the solution for this. I have the same display and problem as the OP. I would like to get the experience of contributing to the repository. But I want to know: 1) Do I fork the develop branch or the master? 2) Does making changes to my fork update the upstream fork? I'd like to know the sequence of steps. I'm an experienced programmer, but have never contributed to Github before.

Do I fork the develop branch or the master

Fork develop

Does making changes to my fork update the upstream fork

No - you can do what you like in your fork. When you're happy with what you're done, get some commits ready in a branch and then raise a pull request (PR) asking to merge the changes in that branch into our develop. You can't make changes to upstream, your changes have to be pulled into upstream by someone who has the rights to do that.

Thanks!

No - you can do what you like in your fork. When you're happy with what you're done, get some commits ready in a branch and then raise a pull request (PR) asking to merge the changes in that branch into our develop. You can't make changes to upstream, your changes have to be pulled into upstream by someone who has the rights to do that.

The reason I ask about making changes is that my change is simple and I was going to do it directly online, but it asks if I want to commit or not and I didn't want to cause any problems.

Ok, give it a go and see what happens.

Pull request #418.

I should explain what the problem and fix are. Some of these displays, like the one OP and myself have - and perhaps this is only the ones without a CS pin - need to have the communication polarity inverted. I duplicated a code snippet from another PIO example project in this repo. I made that simple change to the pio file. And I changed the c file to allow for the option. I have the polarity defaulted to 0, so that it's just like before the change. And those that need the inverted polarity will need to set the #define to 1. Very simple. I hope my comment in the code is clear.

Thanks for your help!!! Your approach makes sense to me: I saw the CPOL=1 would make it work as reported above, and the the CPHA would not matter.