rp-rs / rp-hal

A Rust Embedded-HAL for the rp series microcontrollers
https://crates.io/crates/rp2040-hal
1.33k stars 223 forks source link

Wireless connectivity functionality for Raspberry Pi Pico W #376

Open smituk opened 2 years ago

smituk commented 2 years ago

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?

9names commented 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.

9names commented 2 years ago

Note: even the driver in the C sdk does not support bluetooth yet.

jannic commented 2 years ago

Some C drivers which could act as blueprints (but respect the licenses!):

9names commented 2 years ago

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

Dirbaio commented 2 years ago

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!

jannic commented 2 years ago

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.

xabra commented 1 year ago

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.

9names commented 1 year ago

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

Erik1000 commented 1 year ago

Can confirm. Used SPI1 with rp-pico on my Pico W

xabra commented 1 year ago

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. :-)

jannic commented 1 year ago

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.

knutaf commented 1 year ago

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.

collosi commented 1 year ago

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?

jannic commented 1 year ago

I need to take a closer look, but I think embassy-net is still missing.

collosi commented 1 year ago

Maybe I'm misunderstanding what's needed. I'm looking at this:

https://github.com/embassy-rs/embassy/tree/master/embassy-net

jannic commented 1 year ago

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.

xabra commented 1 year ago

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?

Dirbaio commented 1 year ago

@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.

jannic commented 1 year ago

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.

xabra commented 1 year ago

@Dirbaio: rp2040-hal and embassy-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

smkhalsa commented 11 months ago

@jannic it looks like https://crates.io/crates/embassy-net is now published.

tazz4843 commented 9 months ago

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?

jannic commented 9 months ago

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.

tazz4843 commented 9 months ago

Oh I thought embassy didn't implement embedded-hal traits. That saves me a lot of time. Thanks for the guidance :)

thewh1teagle commented 6 months ago

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!

jannic commented 6 months ago

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.

tanekere commented 5 months ago

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.

ithinuel commented 5 months ago

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.

jannic commented 5 months ago

Does it support BLE, or only Wifi?

9names commented 5 months ago

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.