MicroPython feature/psram, pico2_rp2350 v0.0.7 on 2024-09-11; Raspberry Pi Pico with RP2350
Type "help()" for more information.
>>> import pico2wireless
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'pico2wireless'
Does it have to be MicroPython? Because with CircuitPython you should have no problems. In CP, the drivers are not baked into the base firmware, so no problem adding anything you like.
Ok so I’ve got the rgb_http.cpp example code building - pulling in drivers/esp32spi and libraries/pico_wireless from the pimoroni_pico repo.
It works just fine on a pico. Each ‘…’ appears after ~1 second and is accompanied by the ESP board flashing red, then steady green when it connects:
Firmware version Nina 1.7.3
Connecting to <blah>...
...
...
...
...
...
...
Connected!
Starting server...
Server listening on <ip>:80
RP2350 builds (both ARM and RISCV) don’t work though. In both cases, I see:
<long pause>
Firmware version Nina
<long pause>
Connecting to <blah>...
<long pause>
...
<long pause>
so it like its running ~100x slower than it should be. Plus no LED action, and the firmware version is empty. So guessing there’s some low-level (SPI?) issue, but totally out of my depth here on the hardware side.
I’m going see if I can just get the wireless board LED to work and perhaps learn something that way… but hoping my findings above might give someone with more of a clue some ideas as to what’s wrong.
If it is a low-level SPI issue I don’t expect better results with CircuitPython. After all, the code has to communicate with the same low-level commands with the co-processor.
Maybe I come around and test it, I have both the Pico2 Plus and the Wireless Pack.
Fair point. Didn’t get very far with the LED. Creating and init’ing an Esp32Spi instance doesnt immediately trigger the slowdown, but a call to its analog_write method - in the case of the LED - seems to take around 15s to return. The code on the pico board itself is running fine depite the delays.
I installed the 9.2.0-beta of CP for the Pico2-Plus, copied a sample of the ESP32SPI library and adapted the pins according to the shop page.
Some speculation from my side: some of the pins of the Pico Wireless Pack are part of the new “HSTX” interface. Maybe the MP-firmware claims some of these pins?!
I’ve dug a bit more and its timing out in SpiDrv::wait_for_esp_ack which is called via SpiDrv::send_commandafter successfully returning from wait_for_esp_ready
Means nothing to me but hoping will give a clue to someone…
bool SpiDrv::wait_for_esp_select(uint32_t timeout_ms) {
if(!wait_for_esp_ready(timeout_ms)) {
WARN("!wait_for_esp_ready(timeout_ms)\n");
return false;
}
esp_select();
if(!wait_for_esp_ack(timeout_ms)) { <--- times out here
WARN("!wait_for_esp_ack(timeout_ms)\n");
esp_deselect();
return false;
}
return true;
}
Trying now to replicate @bablokb’s working example but scratching my head a bit here when it comes to circuitpython, I can install the uf2 and get a REPL but - how do I mount the device so I can copy code onto it? On linux (not a ras pi), ideally without having to install a load of cruft…
FWIW with micropython I just use the rshell package for this, is there anything similar?
Cheers!
PS The pins used by the C++ code and the circuitpython example seem to be the same
CircuitPython exposes a drive. Try sudo fdisk -l and you should see it. You can mount (use -o sync) and copy your files either with cp or rsync or whatever. Very simple. sudo lsblk or sudo blkid will also help.
You should also install circup (using pip). This little tool helps to install all necessary libraries. It is very smart and can analyze your main.py or code.py (both are valid top-level files) and install all required libraries automatically.
@babklob yes was very simple, completely missed it because I was expecting something more complicated!
I had no problems getting your example working, so that rules out any hardware problems - it must be a bug** in the pimoroni-pico C++ code
** bit unfair - the code was written before the pico2 existed after all. Perhaps just a lack of pico2 support - but if so what actual differences are there between the devices when it comes to (presumably) SPI? I’ve had no such problems with the ST7789 display with the pico2
If I can get hold of the source of adafruit_esp32spi.mpy I might try porting it to C++ (or micropython) and see how I get on…
I have a dual Display Pack setup that worked just fine on a Pico. Display Pack, Display Pack 2 and Display pack 2.8’s. Not so much on a Pico 2, I had to add 10k pullups to the CS pins to get them both to work on SPI.
This has nothing to do with Pico vs. Pico2. This is just “good luck” on the Pico vs. “bad luck” on the Pico2. You had floating pins, and these pins just happened to float in the correct direction on your specific Pico. With a different unit or some other circumstances (humidity, noise in VBUS/VSYS or whatever) you would have seen this with a Pico too.
The E9 bug is about input pins. CS are output pins. You only need pullups on CS if you have multiple devices on the same SPI bus. Normally, after device initialization, the pullup isn’t normally necessary because the driver is in charge of driving the pin. But during initialization (or in the short period after power on and end of initialization), the pins can float. And since you have to initialize all devices serially, chances are that one of the devices misinterprets commands that were meant for a different device.
I had the problem with a display and SD-card. While initializing the SD-card my display started to flash and wasn’t usable afterwards.
Just a thought, perhaps it’s the ACK PIN that needs a pullup then?
As per driver code I posted above, wait_for_esp_ready seems to work but wait_for_esp_ack times out. Delving deeper into the code, The first is waiting for the ACK pin to go low, the second for it to go high.
Progress! I forced ACK low before initialising the SPI driver and now its responsive, I can get the FW version, but RGB LED isn’t doing anything, and not tested the wifi yet… so still work to do, will update in due course