Open smituk opened 2 years ago
Not yet. Need to:
then we need to either
or
It's only been a few days since the board was announced, it will take some time. Progress on the PIO driver is here: https://github.com/ithinuel/cyw43-bus-pio-spi-rs Nothing else to talk about at this stage.
Note: even the driver in the C sdk does not support bluetooth yet.
Some C drivers which could act as blueprints (but respect the licenses!):
There is also the Linux FullMAC driver. A port of this code is out of the question, but it should be a well-tested reference for hardware interaction. https://github.com/Infineon/ifx-linux-wireless https://github.com/Infineon/ifx-wireless-drivers/tree/RTM/v5.10.9-cynder/drivers/net/wireless/broadcom/brcm80211/brcmfmac
I've been hacking at it for the past few days, and It's finally (mostly) working now.
https://github.com/embassy-rs/cyw43/
Next is fixing the TODOs, changing it to use IRQs instead of busypolling, and probably removing rp-specific stuff from it. I'm not sure if it'll be able to work on top of standard embedded-hal SPI because of the cursed way the pico-w board shares pins though!
The strange sharing of pins is not a property of the cyw chip and doesn't need to be known by the driver. So the driver could just take an embedded-hal SPI trait, and that would just work if the chip was attached via standard SPI to some MCU.
In the specific case of pico-w, there would be another crate (or a module inside the pico-w BSP) which provides the embedded-hal SPI traits for some struct implementing the lower-level wire protocol with the shared pins. That one could also contain the optimized transport using PIO.
Aside from the wireless functionality, will the current rp-pico crate work on a Pico W board? I understand there is a change in the LED pin, and I could imagine the wireless hardware might cause problems for the crate in other ways, but I don't know.
Yep, existing crate and Pico demos should work fine. You should switch any code using gpio25 as led to one of the other pins that are broken out
Can confirm. Used SPI1 with rp-pico on my Pico W
Let me make a plea for support of Pico W wireless functionality as soon as possible. The python guys are making Pico W web servers and I am deeply envious. :-)
There is WIP support at https://github.com/jannic/rp-hal/tree/pico-w, but it depends on several embassy crates which have not yet been released: embassy-time, embassy-sync, embassy-executor and embassy-net.
I am by no means an expert but am interested in helping collaborate on this work, if possible. I've got the WIP pico-w blink sample running and have a picoprobe debugger setup working too. I see that it reliably blinks the on-board LED but if I ask it to join my WPA2 network, it mostly seems to hang. Logs seem to indicate it's in the firmware download step or some part of initializing the network driver.
I was planning on debugging and chipping away at seeing that work reliably, but wanted to make sure I wasn't duplicating work and wanted to check if there was something else more useful to start with. I could also get on email or the chat server if that's the normal way to discuss something like this.
There is WIP support at https://github.com/jannic/rp-hal/tree/pico-w, but it depends on several embassy crates which have not yet been released: embassy-time, embassy-sync, embassy-executor and embassy-net.
@jannic it looks like these are available now. Is this something I could help get across the finish line?
I need to take a closer look, but I think embassy-net is still missing.
Maybe I'm misunderstanding what's needed. I'm looking at this:
https://github.com/embassy-rs/embassy/tree/master/embassy-net
Yes, and that crate isn't published yet. https://crates.io/crates/embassy-net only contains an empty version 0.0.0 used as a placeholder.
Caveat: I am at the Rust api user level, not an api builder.
@Dirbaio also referenced above a WiFi crate for Embassy that already exists (https://github.com/embassy-rs/cyw43/), but its not yet part of the official Pico HAL, I guess
My current project is built on RTIC, not Embassy. I am sure I could migrate it to Embassy, but I was hoping whatever WiFi network api is developed for the picoW is independent of the choice of multitasking framework (if that is even possible-I don't know).
What do you all think: should I migrate to Embassy in anticipation of a networking functionality will ultimately be tied to Embassy?
@xabra: part of the official Pico HAL
rp2040-hal
and embassy-rp
are both HALs written by the community for the RP2040. Neither of them is "official".
BTW, RTIC 2.0 adds async support, and embassy-rp
and cyw43
work on it. No need to switch to embassy-executor
. You can also use embassy-executor
inside the idle task of RTIC 1.0, though that's a bit more involved to setup.
Exactly. I'd like to have a version of the cyw43
driver working on stable rust, but I don't want to reinvent the wheel. Currently, all I could do would be an uglier clone of that driver and parts of embassy-net. If I even had enough time to get it working. So I think you are better of by just using embassy or cyw43
on RTIC 2.0, unless you really need to avoid a nightly compiler.
@Dirbaio:
rp2040-hal
andembassy-rp
are both HALs written by the community for the RP2040. Neither of them is "official".
Sorry. By 'official' I meant part of this community's released rp2040-hal crate (wasn't referring to the Pi foundation).
Trying to get my head around what the software 'stack' looks like and how these pieces all do/can/will fit together... Thanks @Dirbaio and @jannic
@jannic it looks like https://crates.io/crates/embassy-net is now published.
Another API consumer here who doesn't know too much about the low level stuff.
I'm digging through the history of this thread, and I'm wondering if I should be using the embassy
or embedded-hal
/rp-hal
ecosystem for networking on the PicoW right now. It seems like embassy
's networking is more ready for use today, but there's overall less of an ecosystem made for it, so I would have to port a bunch of stuff over (which is fine). Should I start with embassy
or should I wait a bit longer for cyw43/PicoW support in the embedded-hal
/rp-hal
ecosystem?
I'd go with embassy if you want to do networking. In theory, porting code shouldn't be difficult, as both implement embedded-hal traits. The ecosystems have a large overlap, if they are separate at all.
Oh I thought embassy didn't implement embedded-hal traits. That saves me a lot of time. Thanks for the guidance :)
Just checking, is there a way now to use ble
/ hid
/ cdc
on PI pico W with Rust?
I'm using pico c++
sdk, and it's feels bad to write in c++
in 2023!
As the rust cyw43 driver (https://github.com/embassy-rs/embassy/tree/main/cyw43) doesn't seem to support BLE yet, there is probably no easy way to use it with rust at the moment, sorry. If you want to use Pico W, BLE and Rust your best bet is probably to use the C SDK for BLE and then use the Foreign Function Interface to write your application logic in Rust. However, I'm not sure if the overall development experience would be better than with a pure C / C++ firmware.
Hey guys, Just wanted to ask if there is anyone working on BLE support?
I am starting a pretty big project and really want to use rust for it.
I started it a long time ago and hit some short commings around PIO, so I started working on it too but stalled to cover part of async.await support in rp2040-hal. If you’re in urgent need for it, I’d recommend looking at embassy for now.
Does it support BLE, or only Wifi?
Only wifi. There's an open PR for adding Bluetooth support. https://github.com/embassy-rs/embassy/pull/1820 If you're looking for ble right now, I don't think this is going to help you.
Raspberry Pi Pico W now support WiFi & Bluetooth. https://datasheets.raspberrypi.com/picow/connecting-to-the-internet-with-pico-w.pdf
Is it possible to connect using rust?