I used the expansion pins to connect to a wareshare screen vi SPI. The settings of the SPI are:
SCK - GPIO 26
MOSI - GPIO 27
MISO - GPIO 28
DC - GPIO 0
Rst - GPIO 1
CS - GPIO 19
And that works fine and I can use the screen OK
I can connect to the wifi in the normal way, if thats the first thing I do, but as soon as I then use the SPI to run the screen, or I have already connected the screen (via SPI) and then I attempt to connect to the wifi, then I get the following error:
The micropython version I running is:
MicroPython feature/psram-and-wifi, plasma2350 v0.0.10 on 2024-11-18; Pimoroni Plasma 2350 (LTE + WiFi) with RP2350
Hello bablokb, Iām powering the Waveshare display with 5v via the 5v pin on the expansion block of pins. The display is designed for the pico and its runs ok when powered with a picoW and no issues with the picoW wifi whilst running the screen.
The Waveshare display run Ok with no issues on the Plasma board, but the Plasma boardās wifi will not work whilst using the display. I donāt think its a power issue as, so far,l Iāve only got the screen connected to the Plasma and Iāve not yet hooked up any LED strips.
I think the problem is probably to do with GPIO pin conficts. I see from the info about the wifi module Pimoroni produce as a stand alone that the wifi pins for the wifi can be established with
wlan = network.WLAN(network.STA_IF, pin_on=32, pin_out=35, pin_in=35, pin_wake=35, pin_clock=34, pin_cs=33)
But if I do that then I just get a bad pin error. In any case theres no mention of needing to assign pins when using the Plasma wifi. Maybe something is wrong in the version of micropython that Pimoroni produce for the Plasma board?
Powering from 5V is no problem. There are some displays that use 3V3, and that could potentially cause trouble.
You can find the pins used for the Wifi-module from the schematic. They are not exposed on the header, so they cannot interfere with your use-case.
It might indeed be that the UF2 does not yet support the plasma2350w variant. You might want to try the 0.0.11, but the labeling is not very clear for me (e.g. there are two different flavors available for Pico and Pico-W, but not for the plasma).
@bablokb
To be clear, the wifi does work, and the provided cheerlights.py example that uses the wifi works ok. Its just when using the SPI pins on the extension header row of pins (to connect to the Waveshare screen) that the wifi then issues the error messages and stops working.
@alphanumeric, you may be correct that the RM2 uses SPI to communicate with the RP2350, but I would assume that would not stop the SPI pins being used as the boards pin diagram clearly labels which pins can be used for SPI. If SPI cannot be used then why show the SPI labels on the PlasmaWās pin diagram.
SPI is not shown on the actual Plasma 2350 W breakouts. The Pinout does show it as you have mentioned though? I suspect that the RM2 is talking (in the background) on the bus at the same time as your SPI code is trying to talk to the display. Thatās my guess anyway?
I agree that the SPI of the RM2 is not in any way related to the SPI on the exposed pins. Even if it would use the same bus, that would be no problem for the SPI-bus because the CS-pins take care of that.
If you look at the schematic you can see that there is only a single pin on the RP2350 (GP24) that is used for three RM2 pins (data in, data out and irq). So this is not a normal SPI-bus. Probably implemented using PIO.
One more question: you mentioned that the display works fine with a Pico-W. Do you have a chance to test it with a Pico2-W?
Ok, looks like I guessed wrong. Not the first time.
I donāt have a plasma 2350 W. I do have a Pico Plus 2W though, and a display Pack, that I can test code on.
@bablokb - yes I have tested it with a pico2-W and the Waveshare screen and wifi both work OK. The rpi pico2-W had the following pimoroni micropython installed: MicroPython feature/psram-and-wifi, pico2_rp2350_wireless v0.0.10 on 2024-11-18; Raspberry Pi Pico 2 (LTE + WiFi) with RP2350
The Waveshare screen, which works ok with both the pico2-W or the plasma 2350 W, is the Pico-Res Touch LCD-3.5 screen. Its just that when its used with the plasma board the wifi does not work as previously described (the pin connections used are detailed in my first post). But the wifi does work on the plasma board if the Waveshare screen is not in use.
@alphanumeric Yes possibly, but the pico2-W is working OK, but I did load the V0.0.10 version dated 2024-11-18. However I donāt think whatever the version is on the picoW or pico2 W is relevant because its the plasma 2350 W board that has the problem.
On the plasma 2350 W board the version from the āWhy so blueā list of releases is the plasma2350-v0.0.10-pimoroni-micropython.uf2. Pimoroni has combined the wireless and wifi boards into the one micropython release for the plasma, and indeed the wifi does work, just not if I use the SPI pins as shown in my first post. You can also see from my first post, when I connect the board to Thonny, the version of mp shows up as the V0.0.10 version dated 2024-11-18. So the latest release, and I suspect something is not quite right in that release.
My mistake, in Thonny I see the following.
MicroPython feature/psram-and-wifi, pico_plus2_rp2350 v0.0.10 on 2024-11-18
I didnāt clue in that, that was what you posted, I got fixated on the downloaded file name. Sorry about that. My concentration is lacking today.
@SirFico: I do have the same display, but I only have the Plasma2350 (not the W type). As far as I can see, the Pico2-W and the Plasma2350W use the same pin layout. So this is very strange.
How do you wire and arrange the display and the Plasma2350W? Is the display near the RM2 or are the devices side-by-side?
When using the Plasma2350W, as it does not have the same pin arrangements as the pico2W I have the plasma on a breadboard and jumper wires to the waveshare. The connection arrangement is as follows
plasma 2350 Waveshare
SPI GPIO Physical Pin GPIO Pin
1 5v 39 VSYS (not VBUS!)
2 gnd 38 GND
3 tx RX 0 0 11 gpio 8
4 rx CSn 0 1 20 gpio 15
5 3v3 -
6 sda RX 0 20 - for uart or i2c
7 scl CSn 0 21 - for uart or i2c
8 int TX 0 19 12 gpio 9
9 gnd -
10 a0 SCK 1 26 14 gpio 10
11 a1 TX 1 27 15 gpio 11
12 a2 RX 1 28 16 gpio 12
And with that connection arrangement the waveshare screen works OK. (its just that if the screen is used, then the wifi will not work. In fact if the screen has been used, and then the wifi used by another program without a board reboot, then still the wifi will not work. (the wifi does work after a reboot if the screen is not used.) Note: obviously Iām not using the touch or the SSD card on the waveshare when using it with the plasma as theres not enough spare pins for those facilities.
Edit - the table showing the connections gets rather jumpled up but I hope you can see the connections OK :)
@ZodiusInfuser: I think this needs someone with a higher Guru-levelā¦ š¤ļøšļø Could the SPI-pins/traces introduce noise into the traces to the RM2?!
Wireless support for the Pico 2 W has only just been merged as of 4 hours ago (https://github.com/micropython/micropython/pull/16313), so Iāve got something of a tangled mess of rebasing to do in order to get our code up to speed and release a new update. I donāt know if this will fix the issues youāre seeing, but thereās no point trying to diagnose them on a beta beta beta release when we can use a beta beta one instead.
Since Plasma 2350 W is basically vanilla Pico 2 W, we can probably also do a āproperā release without any downstream hacks.
@gadgetoid
Thanks for the update. I will await a new update as I see thereās enough betaās going on to make an Abba song :) All together now - ābeta beta beta its an rp i songā .
That looks suspiciously like SPI has put a critical wireless pin into the wrong state and totally mucked up the driver. Might be something as silly as the default SPI pins being poorly chosen, or the āreserved pinā functionality for wireless not throwing an error when you try to muck with its special magic all-the-things pin.
Hm, then I wonder why it is working on a a vanilla Pico 2 W and not on a Plasma2350W. Maybe it is time to blame someone elseā¦ maybe the board?! So if the new release does not fix the problem, I would suggest to throw some hardware at it and provide @SirFico with a second unit?
@SirFico : do you have a different SPI display to test with, e.g. a simple ST7735 or ST7789 based display? You could also try to change the SPI-speed the driver for the current display is using.