Moving SPI0 to SPI1 works ok, the display continues to work.
However, how do I move the BL_EN which is by default GP20 (which I assume is pulsed to alter brightness) to a different GPIO so display.set_backlight() will work?
This is where I’m stuck…I assume I need to create an ST7780 object so I can alter the backlight pin but I’m unclear how to create a ST7780 object. I’m assuming I’ll need an an import/from but unsure what to use.
Sorry, I was looking at C-level code. In the Python wrapper, they don’t expose the ST7789-driver and create the ST7789 display driver internally, so you cannot change the pwm-pin.
Here is some code I used on my Pico Breakout Garden Pack to run dual displays. It might help as it sets the Cs and BL pins for each LCD. This is just a snippet of code from the full file.
In the end I’ve decided to use CircuitPython and their driver bundles. I have the Pico Display working using Pico’s SPI1 (rather than SPI0). I just need to get the Wiznet5k bit working next.
CircuitPython currently only supports the W5500-EVB-Pico. The pinout for the W55RP20-EVB-Pico seems to be a bit different. Porting to the latter should be straightforward though. Just let me know if you need some help. I don’t have the device so I cannot test a suitable CP version, but I could aid you in doing the necessary steps.
There’s something a bit odd with the W55RP20-EVB-Pico with CircuitPython. Whilst the Wiznet MicroPython samples use the default SPI 0, their CircuitPython samples use a hand coded PIO to create a SPI bus master.
It’s not helped by the Wiznet docs which don’t really make it clear which RP2040 GPIO pins are connected to the on-chip W5500.
What I don’t understand is why their CircuitPython samples use hand coded PIO rather than the default SPI.
The W55RP20 does not have two separate chips (W5500 and RP2040) as the W5500-EVB-Pico has. It is an integrated chip and they document only the external visible GPIOs.
Nevertheless, there are still internal connections between sub-components of the integrated chip. It seems they choose a specific set of pins that are not linked to SPI hardware units of the RP2040 and therefore they must use PIO. Which btw. is also used by their MicroPython examples, see
The selected pins seem strange, but that might be due to the internal routing within the chip.
Yes, that makes sense now. I could see the unconnected pins on the Pico pinout and assumed they were using the RP2040’s SPI 0. The internal connections between the RP2040 and W5500 would make a helpful addition to their datasheet!
I kind of have Ethernet UDP working with the Wiznet CircuitPython sample code (as you included) and I can successfully send a UDP packet to my server - that was my main aim.
However, the Wiznet W5500 “driver” in wiznet5k_pio.py is absolutely minimal, for example not even implementing DHCP, only static IP. It’s well short of the standard W5500 driver included in CircuitPython which is a shame, even their MicroPython PIO driver at least implements DHCP.
At least I have my Pico Display working on SPI1 and can send a UDP packet…just need to get DHCP working and I’ll have enough to get away with it.
I have the Pico Display LED and buttons now working in CircuitPython so I can now plug a Pico Display onto a Wiznet w55rp20-evb-pico board and just need to use wire wrap to connect the display to SPI0 (4 wires shown below). This is only possible thanks to the fact that pins 21, 22, 24, 25, 26, 27 and 29 are not connected to anything on a w55rp20-evb-pico board. I can then use the Wiznet CircuitPython library to get network connectivity working.
I really hope Wiznet will release much better support in CircuitPython as the W55RP20 is a great little chip that’s ideal for Ethernet connected projects.
If anyone is interested in the CircuitPython code let me know.
Wiznet support tell me they are working on a more comprehensive CircuitPython implementation. I look forward to it being available as the RP2040+W5500 on a single chip should be a great combination for Ethernet connected projects, particularly if PoE is an option.
This is a PR to core CircuitPython version 10 (currently alpha). Once merged, you will have a downloadable uf2-image specific for the board. But of course there needs to be a parallel update of circuitpython.org, currently, it does not list this board, see Downloads
Currently the build for the board fails, but it seems this is a problem only for languages other than en_US and en_GB (so I assume some of the translations are missing). Once that is sorted out, you can already download the uf2-image from S3 Bucket Listing Generator (scroll down to the bottom to the wiznet boards). The S3 area will also have bleeding-edge images of PRs that aren’t even merged.