I have full confidence it will come good in the end. This is for information and to manage expectations.
It will be a week to ten days before I see mine. I’ll be doing some testing when I get my hands on it for sure.
On reflection my code might be based on Peter Hinch’s excellent GitHub examples so perhaps I need to revisit the basic R Pi documented examples.
I see some action here, looks like a new uf2 has been created.
Workflow runs · pimoroni/pimoroni-pico-rp2350 (github.com)
Have received Pico+2W board and installed pico_plus2_rp2350 v0.0.10
Cannot get standard WiFi access going
This code:
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(WiFi[‘SSID’], WiFi[‘pw’])
Throws:
[CYW43] Failed to start CYW43
Githhub Releases · pimoroni/pimoroni-pico-rp2350 · GitHub) has a note on custom pins and code:
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 I am not sure this applies and in any case it throws error
wifi in use
either way I seem to be “stuffed”
Others seem to access WiFi with normal code. Perhaps my board is borked?
advice appreciated
SOLVED
Set up second board with headers and worked fine.
Went back to problem board and went over under microscope.
Wifi module edge had metallic scrim shorting two pads. Scaped with scalpel and problem fixed.
Sigh
Sorry to trouble you all
BTW anyone having any luck with machine.lightsleep()?
I have read that the sleep-modes of the RP2350 are not yet supported by the Pico-SDK (and therefore they are not implemented downstream). Not sure if this is still true, it has been a while and I expect some progress here.
Wifi module edge had metallic scrim shorting two pads. Scaped with scalpel and problem fixed.
That doesn’t sound ideal - if you have a close up photo from before you fixed the board please could you fire it over to support@pimoroni.com so we can pass it on to our production team?
Thanks hel
The edge scraped clean and it’s now pristine. So a non-issue. Trivial to find and fix…
cheers and thanks for the suggestion. Lovely to see the Crew is alert! Love the products (of which I use quite a few). Wish I could get my 1st generation Pico’s to sleep as efficiently as the InkyFrame!
cheers
R
1 Like
Have a look at GitHub - bablokb/pcb-pico-power-switch: Suport PCB to switch battery power - designed for a Raspberry Pi Pico. This is at least as efficient as the InkyFrame circuit. I measured 350nA in off mode.
Thanks for sharing!
I used an RTC interrupt driven system as part of a network of solar powered pico-based tank level sensors. But - as with the switch shim - more hardware was needed and more time at the lab bench.
I am hoping the RP2350 will provide a software only route to low-power sensors…
Cheers from Oz
My expectation: the RP2350 will improve on the RP2040, but will still be nowhere near other processors.
But in my projects I discovered that “on”-time is the main driver for current consumption. For example swapping LoRa for WLAN will save so much more power compared to other measures, only because it does not need to connect to any network.
After a break working on other things I tried Pimoroni Micropython Version 0.0.10 - Why so blue, RM2? Success. I now have a rudimentary but working asyncio “file server” based on R Pi example code (3.9.3). That is all I need to move forward. Many thanks to Gadgetoid. It has been quite a year.
Great! Do you have throughput figures available? I just opened an issue with the CircuitPython team because the throughput of the device is so bad. It is as bad/as good as with the Pico-W so I assume it has something to do with how CP drives the chip.
The scenario is slightly different (webserver), but it seems the download of files is slow. And I don’t think it is something on application side, because then the RP2350-based boards would show some improvements as compared to the Pico-W.
So having some figures from a different implementation could add some insights.
Sorry, but I am only downloading a simple HTML form and I have not noticed any significant lag. I then set servos from form buttons. All very simple with negligible latency. I have been testing the asyncio code with an RP2040 this morning. Will try a Pimoroni Pico Plus 2 W next.
Too bad. The only thing I found was this post: https://forums.raspberrypi.com/viewtopic.php?t=339512
They claim
near 10 Mbits/sec at data size greater than 1 MByte
But this is with the Pico-W running as a client and a huge datasize for a MCU, so this is not a realistic benchmark IMHO.