Skip to content

TaskList for Supporting RaspberryPi Pico peripherals #53810

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
32 of 52 tasks
soburi opened this issue Jan 16, 2023 · 36 comments
Open
32 of 52 tasks

TaskList for Supporting RaspberryPi Pico peripherals #53810

soburi opened this issue Jan 16, 2023 · 36 comments
Assignees
@soburi @yonsch
Labels
Enhancement Changes/Updates/Additions to existing features Meta A collection of features, enhancements or bugs platform: Raspberry Pi Pico Raspberry Pi Pico (RPi Pico)

Comments

@soburi
Copy link
Member

soburi commented Jan 16, 2023 •
edited
Loading

A task list for hardware support for the RaspberryPi Pico. (Inspired by #38657.)

Peripherals

Peripherals RP2350

PIO

System

System: RP2040

System: RP2350

  • RP2350 Hazard3 core
    Adding new supports
  • TrustZone
    Adding new supports
  • AON Timer
    Adding new supports

Boards: RP2040

Boards: RP2350

Wifi/Bluetooth support
@soburi
Copy link
Member Author

soburi commented Jan 16, 2023 •
edited
Loading

@yonsch @andrei-edward-popa @burumaj @petejohanson
I made a list to check the support status.
Please comment if there is something that should be fixed.

@andrei-edward-popa
Copy link
Contributor

@soburi Here is also the counter driver for Pico which uses RTC. #52312

@petejohanson
Copy link
Contributor

And this PR I opened last night: #53811 for reboot support into bootloader.

@henrikbrixandersen henrikbrixandersen added the Meta A collection of features, enhancements or bugs label Jan 17, 2023
@ajf58
Copy link
Collaborator

ajf58 commented Jan 19, 2023

I've been working on adding support for hardware_timer as I'm generally interested in adding a bit more support for the RP2040 and the RPi Pico and Pico W to Zephyr. Is there a way to throw my hat into the ring on this?

@DaAwesomeP
Copy link

@soburi issue for MPU support: #44318

@soburi
Copy link
Member Author

soburi commented Jan 19, 2023

Hi, @ajf58

Is there a way to throw my hat into the ring on this?

Thank you for your interest.

The best way is creating PR as draft and add the the number of it to this list.
I think this list can edit by anyone, please tell me if not so.
I'll update it.

@soburi
Copy link
Member Author

soburi commented Jan 21, 2023

@DaAwesomeP

I created a PR to fix the issue.
#53973

@yonsch
Copy link
Collaborator

yonsch commented Jan 26, 2023

@soburi Thank you for this list. I've edited this list to add a few items, but mainly to remove entries that seemed redundant. Here are the ones removed with the reasons for the removal:

  • hardware_base - Necessary headers for the HAL, does not require any work on our side
  • hardware_claim - A util library for resource management, not required
  • hardware_exception - Zephyr already handles it for us, not required
  • hardware_pll - Already covered by clock control
  • hardware_sync - A util library for resource management, used by the hal but does not require any work on out side
  • hardware_xosc - Already covered by clock control
  • bootstage2 - Already in use
  • pico_base - Could not find it in pico-sdk
  • pico_binary_info - Can be handled by Zephyr
  • pico_divider/double/float/int64_ops - Already covered by divider

@DaAwesomeP
Copy link

Possibilities to add:

  • pico_rand is a new method that will be supported soon
  • pico_bit_ops: is this covered by pico_divider/double/float/int64_ops?

I found pico_base, not sure if it is really useful.

@yonsch
Copy link
Collaborator

yonsch commented Jan 30, 2023

@DaAwesomeP

raspberrypi/pico-sdk#1111 is a new method that will be supported soon

As far as I can tell this is a pure software implementation (the RP2040 does not have and RNG). The only thing about it that is "optimized" to the Pico is that it uses the flash's unique ID for generating numbers (as far as I can tell). So in that case I think we would better stick to Zephyr's implementation.

pico_bit_ops: is this covered by pico_divider/double/float/int64_ops?

No, but I agree that it might be useful so I'll add it

@DaAwesomeP
Copy link

@yonsch The pico version seems to make use of the ROSC as an entropy source as well as the Bus Performance Counter. I'm not certain if the latter is pico-specific or an M0+ feature.

I agree that the Zephyr implementation is probably best, but I do wonder if there is a way to input additional sources of entropy to the Zephyr methods. At a quick glance, it doesn't seem like the Zephyr version has a way to make use of that as a source of entropy (this was a very surface level check). I can look into this more later if there is interest.

@soburi
Copy link
Member Author

soburi commented Feb 1, 2023

@soburi Thank you for this list. I've edited this list to add a few items, but mainly to remove entries that seemed redundant. Here are the ones removed with the reasons for the removal:

Thank you for updating this list.
It was helpful because I was not confident in my judgment.

We got many functions are now available.
It seems PIO is a difficult piece. I wish to discuss and make progress about it.

@rp1231
Copy link

rp1231 commented Jun 1, 2023

Are there any plans to support bluetooth functionality on the pi pico wireless?
Thanks

@yonsch
Copy link
Collaborator

yonsch commented Jun 1, 2023

Are there any plans to support bluetooth functionality on the pi pico wireless?
Thanks

@rp1231 Once the interface to the cyw43 (SPI over PIO) is supported, support for both wifi and Bluetooth will be possible.

@ThreeEights
Copy link
Collaborator

@soburi - Can you add this pull request for SPI via PIO to the list? #60395 I'm not sure whether it should be listed under SPI or PIO.

@PatrickE94
Copy link

Hey everyone,

I'm also interested in both Zephyr and Pico W support. I jumped over a few steps in creating proper support and wrote a small wifi driver using the cyw43-driver library from pico sdk (via the hal module). I say jumped over since I mostly ported the SPI over PIO from pico sdk.

This is all working, at least in some sense. Running the samples/net/wifi sample successfully with DHCP and communication over both TCP and UDP. I'm currently fiddling with the interrupt for the wake-pin.

I would be happy to contribute to this in any way for proper support. I'm completely new to Zephyr, my main experience is not mainly embedded but I have a few years of professional embedded on FreeRTOS and many years C programming.

Can anyone point me in a good direction forward? Should I push my early driver as a draft PR, or begin switching to @ThreeEights SPI over PIO implementation?

Thanks

@ThreeEights
Copy link
Collaborator

Hi, @PatrickE94 - Of course, I'd be most pleased if you work with my SPI via PIO implementation. :-) You should know that it currently doesn't support the 3-wire SPI configuration needed to access the WiFi chip on the Pico W. I'm trying to debug that today. We also have a project in our team to complete a Zephyr driver for the CYW43439 chip, though that's still some weeks away from being ready.

Meanwhile ... welcome to Zephyr!
Steve

@PatrickE94
Copy link

Hi, @PatrickE94 - Of course, I'd be most pleased if you work with my SPI via PIO implementation. :-)
You should know that it currently doesn't support the 3-wire SPI configuration needed to access the WiFi chip on the Pico W. I'm trying to debug that today.

Neat, then perhaps I will start at the other end :-)

We also have a project in our team to complete a Zephyr driver for the CYW43439 chip, though that's still some weeks away from being ready.

I found that out a few hours ago. Since that's the Infineon guys doing a more generic implementation (with more features, AMDPU etc) than the one in pico sdk, I agree that's the right way! Quickly checking their wifi-host-driver concept, it doesn't look to intimidating to implement a SPI HAL layer which should enable their driver on the pico.
They've done a good job documenting it.

Meanwhile ... welcome to Zephyr! Steve

Many thanks!
Patrick

@henrikbrixandersen henrikbrixandersen added Enhancement Changes/Updates/Additions to existing features and removed Hardware Support labels Aug 31, 2023
@JohnConnett
Copy link

Hi @ThreeEights, @PatrickE94,

I'm also interested in WiFi support on Pico W. What's the current state of play?

@ThreeEights
Copy link
Collaborator

@JohnConnett - I have a PIO SPI driver that works on everything except the Pico W, for some reason I'm trying to debug, and a pull request is pending for the CYW43xxx WiFi driver. We're trying to pull it all together.

@PatrickE94
Copy link

@JohnConnett I have just put together some glue for the cyw driver and the PIO SPI. It looks like it should work, given that @ThreeEights gets three wire SPI to work. But I haven't tested anything since I have no communication...

I have an old branch where I've mashed in the official pico sdk driver which works, but it's not very neat.

I've been pretty busy with life recently, but I might just take a slow evening to see if I can support @ThreeEights. Let me know if there's anything you'd like me to take a peek at. I have access to Salae logic analysers and some other fine equipment at work.

@JohnConnett
Copy link

I've been pretty busy with life recently, but I might just take a slow evening to see if I can support @ThreeEights. Let me know if there's anything you'd like me to take a peek at. I have access to Salae logic analysers and some other fine equipment at work.

I currently have a single Pico W (no headers), with a Pico WH and Pi Debug Probe on order.

The plan is to use a Pico W with a PicoADC16 and Photo Transistor Light Sensors to monitor the state of LEDs on an underfloor heating controller and report them using MQTT to OpenEnergyMonitor. The LEDs indicate if the electrothermal actuators and circulation pump are energized.

We will probably use MicroPython initially. I was interested in Zephyr as a possible alternative.

Thanks for the comments. I might be interested in exploring Zephyr on Pico W for other things when WiFi is available.

@wasfan
Copy link

wasfan commented Dec 12, 2023

any evolving of Zephyr driver for the CYW43439 chip? I can't wait for btstack to support bluetooth le audio.
I try to port driver from pico sdk. pio spi > cyw43 driver > hci.

@DaAwesomeP
Copy link

Something to potentially add to the list: PIO-based Ethernet MAC
Example: https://github.com/holysnippet/pico_eth

@DaAwesomeP
Copy link

The "binary info" feature was I think completed through here: #54464 (can be checked off).

@Manu3l0us Manu3l0us mentioned this issue Oct 14, 2024
Closed
@vulpes2
Copy link
Contributor

vulpes2 commented Dec 29, 2024

Would be great if @soburi can update this list to reflect the recently merged SPI support for the AIROC WiFi driver and the RP2350 support.

@soburi
Copy link
Member Author

soburi commented Jan 7, 2025

@vulpes2
Done. Thanks for the notification.

@flyfish30
Copy link

flyfish30 commented Feb 20, 2025 •
edited
Loading

The cyw43439 wifi module on the pico 2 w still doesn't works fine. It is failed to set country code to cyw43439. When country code is WHD_COUNTRY_UNITED_STATES, the set IOVAR command failed with timeout. When country code is WHD_COUNTRY_UNITED_STATES_REV4, the set IOVAR command failed with return status -2. I also try set country code with WHD_COUNTRY_WORLD_WIDE_XX and WHD_COUNTRY_WORLD_WIDE_XX_REV17, the set IOVAR command also failed with timeout or return status -2.
I had checked the buffer of set IOVAR command, it is same as buffer of the set IOVAR command in pico-sdk.
Please fix this issue.@soburi

@soburi
Copy link
Member Author

soburi commented Mar 8, 2025

@flyfish30

The cyw43439 wifi module on the pico 2 w still doesn't works fine. It is failed to set country code to cyw43439. When country code is WHD_COUNTRY_UNITED_STATES, the set IOVAR command failed with timeout. When country code is WHD_COUNTRY_UNITED_STATES_REV4, the set IOVAR command failed with return status -2. I also try set country code with WHD_COUNTRY_WORLD_WIDE_XX and WHD_COUNTRY_WORLD_WIDE_XX_REV17, the set IOVAR command also failed with timeout or return status -2. I had checked the buffer of set IOVAR command, it is same as buffer of the set IOVAR command in pico-sdk. Please fix this issue.@soburi

At this time, Zephyr has not provided any support for Pico2W.
It is best to create an issue to request a new feature.
If you have already worked a port of pico2w,
you can also create a PR and discuss it through review.

@soburi soburi self-assigned this Mar 8, 2025
@flyfish30
Copy link

Hi, @soburi

I have already worked a port of pico 2 w by myself. I will create a PR to zephyr project. And by use third-party wifi driver of cyw43 from beechwoods-software, I get the wifi support in pico 2 w, it work well.
I saw a statement from beechwoods-software saying that the Infineon official WHD Wi-Fi driver integrated in the new code of Zephyr 4.0 is already available. Why can't it work properly on the Pico 2 W board?

@soburi
Copy link
Member Author

soburi commented Mar 18, 2025

@flyfish30

Simply put, just because it works on Pico1W doesn't mean it will work on Pico2W. Unless someone investigates, we won't know why.
Someone has to do that work.

@keks
Copy link

keks commented Mar 19, 2025 •
edited
Loading

Just asking because neither the docs nor this issue explicitly mention this: There is Wifi support for the Pico W (Version 1) but not BLE, right? What would be needed to make that work?

Edit: Looks like in theory there are BLE drivers for that chip: https://docs.zephyrproject.org/latest/build/dts/api/bindings/bluetooth/infineon%2Ccyw43xxx-bt-hci.html#dtbinding-infineon-cyw43xxx-bt-hci9

@rt-2pm2
Copy link

rt-2pm2 commented Mar 22, 2025 •
edited
Loading

Just asking because neither the docs nor this issue explicitly mention this: There is Wifi support for the Pico W (Version 1) but not BLE, right? What would be needed to make that work?

Edit: Looks like in theory there are BLE drivers for that chip: https://docs.zephyrproject.org/latest/build/dts/api/bindings/bluetooth/infineon%2Ccyw43xxx-bt-hci.html#dtbinding-infineon-cyw43xxx-bt-hci9

At least from the zephyr pico documentation page, the bluetooth is not mentioned. @keks You are right, there is a driver for the cyw43xx-bt, but from that page it looks like it is on UART, whilst that chip on the RPi seems to be on a different bus.

I am also interested to know more about enabling the bluetooth on the pico.

@soburi
Copy link
Member Author

soburi commented Mar 23, 2025

@keks @rt-2pm2

I haven't heard of anyone working on it yet.

It might be a lot of work, as it will require some changes to the bus, just like @ThreeEights did.
Of course, collaborators are welcome.

@rt-2pm2
Copy link

rt-2pm2 commented Mar 23, 2025

@soburi

Thanks very much for your reply. I don't consider myself an expert, so I guess I will have fun reading datasheet and documentation, but, from a first glance, I am concerned about the connections. For this reason, please, correct me if I get something wrong, I don't want to mislead anyone here ;-).

The RPi Pico datasheet , page 4, reports about it:

The wireless interface is connected via SPI to the RP2040

Looking at the CW43439 datasheet v3.0 (I don't understand why the link to the v5.0 on the Infineon site is broken...) it seems that that device has different buses for the two subsystems. The WLAN communicates via SPI and the Bluetooth is via UART.

If the RPi Pico has only the SPI connection with the CW43439, how to manage the Bluetooth? Would this problem be addressed with the "some changes to the bus" you were referring to?
I will look at the commits made by @ThreeEights to figure it out.

Best

@vulpes2
Copy link
Contributor

vulpes2 commented Mar 23, 2025

There has been some confusion about Bluetooth on the Pico W so I'll attempt to provide some details on the hardware and explain what's required to make Bluetooth support (the controller is dual mode) happen.

On this board the only available HCI transport is SPI, and the same SPI bus is already used by the AIROC WiFi driver. UART on the cypress chip is not connected to the micro and you cannot use it. This HCI over SPI transport is completely undocumented in the datasheet, and from what I can tell the RPi Pico W (and the Pico 2 W) are the only boards that use it. The packet format is pretty standard as far as I can tell.

To add Bluetooth support someone needs to come up with a way to multiplex the SPI bus and make it usable for both the WiFi and HCI driver simultaneously. There is currently no mechanism in Zephyr to facilitate that so a new shim driver is likely required. pico-sdk has such a driver and parts of it is within pico-sdk (BSD-3-Clause license), the other part (cyw43-driver) is proprietary source-available software so porting portions of it is not possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@soburi soburi

@yonsch yonsch

Labels
Enhancement Changes/Updates/Additions to existing features Meta A collection of features, enhancements or bugs platform: Raspberry Pi Pico Raspberry Pi Pico (RPi Pico)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests