-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No display output with MicroPython v1.17 and v1.18 #67
Comments
Just found old closed issues from v1.14 on this. Just added from machine import Pin, SPI
import st7789
spi = SPI(2, baudrate=30000000, polarity=1, phase=1, sck=Pin(18), mosi=Pin(19), miso=Pin(14))
display = st7789.ST7789(
spi, 135, 240,
reset = Pin(23, Pin.OUT),
cs = Pin(5, Pin.OUT),
dc = Pin(16, Pin.OUT),
backlight = Pin(4, Pin.OUT),
rotation = 1)
display.init()
display.fill(65535) Maybe an update to the working example code https://github.com/russhughes/st7789_mpy#readme would help future explorers? miso is not explicit defined there. |
Thanks for the follow up. Saved me a few minutes! |
Hello, I am using hardware SPI#1 channel with 14,13,12 pins. I can not see anything on the display. When I use the same settings with softSPI, it properly works but it is too slow. it takes 2 seconds to draw jpeg file in size of 240x240
In addition there is a problem with FAST mode in jpg draw.
|
Decoding a 240x240 jpg using the FAST method requires a lot of memory (240x240x2 bytes) to buffer the entire decoded jpg. If your device does not have PSRAM, it probably won't have enough free memory for the buffer. The SLOW method trades speed for lower memory usage. What hardware are you using? |
Hello I am using ESP32-CAM and it has an PSRAM. I dont know what has been changed but it works now properly. |
I'm seeing this too. I'm using Raspberry Pi Pico on a custom PCB (Pico module is soldered onto the PCB). It's important to mention, that I only use the SPI for the display - for nothing else than that. I got my Pico from an official Raspberry Pi distributor and works with neither of them. When using Hardware SPI, I only get a blank screen - nothing is drawn onto the (Chinese) ST7789 without the CS pin, but there is a catch - Software SPI works (but is insanely slow) - same pinout as on Hardware SPI, except I'm initializing it as I had a look at other issues in this repository. I've tried following, all with no success:
Then, I found this library. I've immediately decided to try it out, as it might resolve my problems - spoiler alert: I was wrong! After a bit of modifying my code, the results were the same. My Software SPI was working, but the Hardware SPI wasn't (on the same pins). I decided to revert all my changes and use this library again. So, I tried (as suggested), downgrading to MicroPython 1.12, but surprise surprise - Raspberry Pi Pico wasn't even out when v1.12 was released 😓... First MicroPython release with Pi Pico support was v1.14, but due to lack of support for so called "f strings", the first version I got working was v1.15, but guess what?! Again the same issue - no display output on Hardware SPI, meanwhile the Software SPI is working fine (but slow). This is my configuration for Hardware SPI (not working - blank screen): from machine import SPI, Pin
import st7789
display_bus = SPI(0, baudrate=62_500_000, polarity=1, mosi=Pin(19), sck=Pin(18), miso=Pin(16))
display = st7789.ST7789(display_bus, 240, 240, reset=Pin(20, Pin.OUT), dc=Pin(17, Pin.OUT))
display.init()
display.fill(st7789.RED) This is my configuration for Software SPI (working - red screen is displayed) (NOTE: Baudrate doesn't matter at SoftSPI - MicroPython will limit it to maximum of 800kHz (as far as I've read)): from machine import SoftSPI, Pin
import st7789
display_bus = SoftSPI(baudrate=62_500_000, polarity=1, mosi=Pin(19), sck=Pin(18), miso=Pin(16))
display = st7789.ST7789(display_bus, 240, 240, reset=Pin(20, Pin.OUT), dc=Pin(17, Pin.OUT))
display.init()
display.fill(st7789.RED) Due to the fact, that two (very) different libraries don't work with Hardware SPI and the fact, that (as mentioned above), ESPs also don't work, I'm pretty confident that this isn't an issue within the pico-sdk or the esp-idf frameworks, but is instead an internal issue within MicroPython itself. If the v1.12 works, but other versions don't work with Hardware SPI, this confirms my suspicions even more. They've probably changed the way they handle SPI after 1.12. I think this should be reported to MicroPython developers and the MicroPython repository. Let me know what you think. |
Have you tried omitting the underscore separators from baud rate? Or
omitting the baud rate specification altogether?
…On Sun, 24 Jul 2022, 16:21 Mitja, ***@***.***> wrote:
I am using hardware SPI#1 channel with 14,13,12 pins. I can not see
anything on the display. When I use the same settings with softSPI, it
properly works but it is too slow.
I'm seeing this too.
I'm using Raspberry Pi Pico on a custom PCB (Pico module is soldered onto
the PCB). It's important to mention, that I only use the SPI for the
display - for nothing else than that. I got my Pico from an official
Raspberry Pi distributor and works with neither of them. When using
Hardware SPI, I only get a blank screen - nothing is drawn onto the
(Chinese) ST7789 without the CS pin, but there is a catch - Software SPI
works (but is insanely slow) - same pinout as on Hardware SPI, except I'm
initializing it as SoftSPI, instead of SPI. I even tried decreasing
Hardware SPI frequency down to (slow) 400 kHz (which is even slower than
the Software SPI), but it still wouldn't work.
I had a look at other issues in this repository. I've tried following, all
with no success:
- https://forum.micropython.org/viewtopic.php?t=5969 (add phase=1
and/or polarity=1 - polarity=1 is required for Chinese ST7789-based
displays (such as mine), as suggested in another issue, I cannot find
anymore)
- #60 <#60> (remove
reset pin from initialization)
- Decrease frequency (as Software SPI is limited to 800kHz)
Then, I found this library
<https://github.com/peterhinch/micropython-nano-gui>. I've immediately
decided to try it out, as it *might* resolve my problems - spoiler alert:
I was wrong!
After a bit of modifying my code, the results were the same. My Software
SPI was working, but the Hardware SPI wasn't (on the same pins). I decided
to revert all my changes and use this library again.
So, I tried (as suggested), downgrading to MicroPython 1.12, but surprise
surprise - Raspberry Pi Pico wasn't even out when v1.12 was released 😓...
First MicroPython release with Pi Pico support was v1.14, but due to lack
of support for so called "f strings", the first version I got working was
v1.15, but guess what?! Again the same issue - no display output on
Hardware SPI, meanwhile the Software SPI is working fine (but slow).
This is my configuration for Hardware SPI (not working - blank screen):
from machine import SPI, Pin
import st7789
display_bus = SPI(0, baudrate=62_500_000, polarity=1, mosi=Pin(19), sck=Pin(18), miso=Pin(16))
display = st7789.ST7789(display_bus, 240, 240, reset=Pin(20, Pin.OUT), dc=Pin(17, Pin.OUT))
display.init()
display.fill(st7789.RED)
This is my configuration for Software SPI (working - red screen is
displayed) (NOTE: Baudrate doesn't matter at SoftSPI - MicroPython will
limit it to maximum of 800kHz (as far as I've read)):
from machine import SoftSPI, Pin
import st7789
display_bus = SoftSPI(baudrate=62_500_000, polarity=1, mosi=Pin(19), sck=Pin(18), miso=Pin(16))
display = st7789.ST7789(display_bus, 240, 240, reset=Pin(20, Pin.OUT), dc=Pin(17, Pin.OUT))
display.init()
display.fill(st7789.RED)
Due to the fact, that two (very) different libraries don't work with
Hardware SPI and the fact, that (as mentioned above), ESPs also don't work,
I'm pretty confident that this isn't an issue within the pico-sdk
<https://github.com/raspberrypi/pico-sdk> or the esp-idf
<https://github.com/espressif/esp-idf> frameworks, but is instead an
internal issue within MicroPython itself. If the v1.12 works, but other
versions don't work with Hardware SPI, this confirms my suspicions even
more. They've probably changed the way they handle SPI after 1.12. I think
this should be reported to MicroPython developers and the MicroPython
repository <https://github.com/micropython/micropython>.
Let me know what you think.
—
Reply to this email directly, view it on GitHub
<#67 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7TCRLN5SKCMY4VVDLM6FLVVVNEHANCNFSM5RWBTITA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I indeed did both of that. |
This is working for me using the PICO's hardware SPI connected to a no-name st7789 240x240 display without CS running MicroPython v1.19.1 from firmware/RP2/firmware.uf2.
|
Hmmm. That's strange. I tried your code (a little bit modified) on the latest firmware, as you said: from machine import Pin, SPI
import st7789
def config(rotation=0, buffer_size=0, options=0):
return st7789.ST7789(
SPI(0, baudrate=62500000, polarity=1, sck=Pin(18), mosi=Pin(19), miso=Pin(16)),
240,
240,
reset=Pin(20, Pin.OUT),
dc=Pin(17, Pin.OUT),
rotation=rotation,
options=options,
buffer_size=buffer_size)
tft = config()
tft.init()
tft.fill(st7789.RED) and it still doesn't seem to be working. If I init using Anyways, thanks for your help |
My configuration is like below but it just works in SoftSPI mode. I can not get it work on Hardware SPI mode. What could be the problem ?
|
Hi, I'm experiencing the same issue on two PI Pico - a black screen with no error messages :/ I've used the same configuration and tried the toasters demo
And I tested the screen on Arduino Uno, it works. Photo |
I used the precompiled MicroPython binaries v1.12 for my TTGO T-Display since June 2020 and it works very well. Recently I downloaded the binaries v1.17 and v1.18 and the same code no longer works. Flashing back to v1.12 and it works as intended. No error message, the backlight can be switched on with display.on() and display.off() but no pixel output. This simple example only provides a black screen with v1.17 and v1.18:
With v1.12 it is a white screen. No error message with v1.17 and v1.18.
The text was updated successfully, but these errors were encountered: