Oof. Well, I have no need for wireless capability just yet anyway.The Raspberry Pi Pico is not available in Australia at this time. Once RCM is approved, we'll start taking orders (1-3 months - no firm ETAs right now).
I don't think so, as Raspberry Pi is usually about keeping components and boards very stable - industrial users would have to recertify otherwise.
Oh I haven't seen that. Sure it's not the best idea. A good reason must be behind, driving the wifi chip?
Reading the docs doesn't make it clear to me if the new Micropython code copes with pico and pico W when dealing with the led, and whether you need 2 different codes..
Code: Select all
>>> import machine
>>> led = machine.Pin("LED", machine.Pin.OUT)
>>> led.off()
>>> led.on() 
Unlikely, these are optional BT 5.2 features most hardware doesn't implement while still being compliant. And it does need extra hardware support in the radio part.
It's released:
Code: Select all
pico-sdk$ git pull --recurse-submodules
[...]
pico-sdk$ git show
commit 2e6142b15b8a75c1227dd3edbe839193b2bf9041 (HEAD -> master, tag: 1.4.0, origin/master, origin/HEAD)
Author: graham sanderson <[email protected]>
Date: Wed Jun 29 22:56:27 2022 -0500
SDK 1.4.0 release
I believe this was necessary to expose the other pins of the RP2040, as on the Pico before - Rpi chose to sacrifice some code compatibility for exposing more pins ...
I don't think any more pins are exposed, but GPIOs 23, 24, 25 and 29 are now used internally to interoperate with the WiFi chip. From the PicoW datasheet (ch 2.1):
A few RP2040 GPIO pins are used for internal board functions:
GPIO29: OP/IP wireless SPI CLK/ADC mode (ADC3) to measure VSYS/3
GPIO25: OP wireless SPI CS - when high also enables GPIO29 ADC pin to read VSYS
GPIO24: OP/IP wireless SPI data/IRQ
GPIO23: OP wireless power on signal
WL_GPIO2: IP VBUS sense - high if VBUS is present, else low
WL_GPIO1: OP controls the on-board SMPS power save pin (Section 3.4)
WL_GPIO0: OP connected to user LED
Of course, that's why not yet here in OzAustralia - just waiting for compliance testing to be completed.
BT not yet enabled. Was hard enough getting the wireless working apparently!
Er, yes, I believe that is why it is not yet available in Oz. Compliance testing can take a while and we also do multiple countries in parallel. We get stuff out to as many countries as we can as quickly as we can. Because that is what makes money.Gavinmc42 wrote: ↑Thu Jun 30, 2022 10:07 amOf course, that's why not yet here in OzAustralia - just waiting for compliance testing to be completed.
BT not yet enabled. Was hard enough getting the wireless working apparently!
Interesting, still using the blobs.
https://github.com/georgerobotics/cyw43 ... n/firmware
WiFi and BLE combined?
More stuff to learn
In the meantime, look for AoA receivers, track those future PiCows around the house and garden?
If they're already working, why get rid of them?
It seems MicroPython, CircuitPython and everything else, currently will need separate UF2 firmware files depending if running on a Pico or Pico-W.
Code: Select all
CMake Warning at /home/pi/pico/micropython/lib/pico-sdk/src/rp2_common/cyw43_driver/CMakeLists.txt:15 (message):
PICO_CYW43_DRIVER_PATH specified but content not present.
It hasn't hit the nightly builds yet, but there was a check-in to ports/rp2/machine_pin.c a few hours ago that looks like it does the needful for both Raspberry Pi Pico boards. It would be nice if all MicroPython boards* had something like this, like Arduino's LED_BUILTIN macro.