SDK update for Raspberry Pi Pico W unlocks Bluetooth support | Hacker News Reader

SDK update for Raspberry Pi Pico W unlocks Bluetooth support

github.com

159 points_Microft57 comments

I love RP2040 (especially how circuit designer and firmware dev friendly it is) and even tried building my own MCU with it[1]

However I don't quite see the Bluetooth use case - RP2040 is not really a low power chip, making it pretty hard to use for a battery-powered IoT application. You'd need a pretty giant battery pack to make it last a long time.

Nordic's nrf52 is an order of magnitude better for a typical "sleep-burst transmit-sleep" cycle, and can be suspended to <5uA current. Pico W is $6, Seeed has a $10 nrf52 MCU, or you could get a "just hook up USB and power" bare module for $5-6.

[1] https://twitter.com/levpopov/status/1623376630378008576

nit: MCU is Micro Controller Unit, so for example rp2040 itself. What you mean is "board".

Completely right on the power consumption though. The NRF52 is also quite good at limiting power consumption while it's running and automatically disabling peripherals while not used (you typically do that with disabling clocks on other chips). It also has the sanest hardware registers I've seen (looks like they were actually designed with software in mind).

Yes, thanks for the correction! In DIY keyboard community a microcontroller breakout board is often referred to as MCU which makes things confusing.

One use case would be a little desktop robot for an educational setting. The motors of a robot use orders of magnitude more power than the CPU so it needs big batteries anyway.

I can also imagine applications where the device has wall power but you want to connect to it with a phone. Like a piece of wall art you want to be able to turn on and off remotely.

There are a lot of IOT applications that do rely on battery power. Regardless, this is nice for people whose MCU/embedded experience is limited to pre-existing firmwares and the Arduino ecosystem.

There's also a fully open source Bluetooth stack for the Nordic chips (Apache nimBLE) compared to the non-commercial use only but with some vague and possibly not yet available exception for the RP2040 license of the BTstack used here. (This seems to have been enabled by the radio hardware being fully documented, which is very unusual for Bluetooth chips.)

I've got a bunch of ESP32's piggy-backing on USB chargers around the house doing BLE and wifi stuff. The things they're talking to are battery powered, but I want them plugged in to the mains. I could easily see myself using the Pico W in that job.

RPi is too expensive to be an end-point IoT device too. But it is perfect to serve as a hub/base station. And this is where BT could be actually of use, for communication with cheaper end-point devices, for example.

It's possible to use the RP2040 in a low power way if you're specifically code it to do so, no? It should be able to consume as little as 1.3mA in sleep state, so if you had an application with a loop that did something like read a sensor and send out a bluetooth or wifi signal, then sleep for 15 minutes, I think a few AAA batteries could power it for months, no? https://raspberrypi.stackexchange.com/questions/124951/raspb...

The pico is an amazing little board. Im using it with micro-python and HID library to simulate subtle mouse movements every 120 seconds to prevent RDP session to remote server from closing due to lack of activity. Now with bluetooth support, I can just hopefully toggle it on or off or disable. Instead of removing the usb cable from the notebook.

bluetooth mouse jiggler sounds like a potentially revolutionary concept

> I can just hopefully toggle it on or off or disable

I used an accelerometer. Just a funny UI idea, flip it upright to jiggle the mouse.

I used a different board of course, although you could add an generic accelerometer to a Pico W pretty easily.

Here is the Bluetooth Mouse HID sample demo from the Bluetooth stack which the Pico W is using, Bluekitchen:

https://github.com/bluekitchen/btstack/tree/master/example/h...

Perfect. This might be what I'm looking for to get started. thank you!

You can't use autohotkey?

Thanks, TIL: https://en.m.wikipedia.org/wiki/AutoHotkey

I'm not impressed by it. It's got 264 kilobytes of RAM. That's so low, that you can't run Linux or BSD on it. I guess you'd need some DOS-like OS for it.

This chip sells for $8.45 which is ridiculously high for what it offers[1].

The price of $0.80 per chip non-W is impressively low however, I'll admit. [2] But once you throw shipping and other costs in, how much will it actually cost?

The Pi Zero 2 W at $15 is far far better than this chip. [3]

[1] https://www.pishop.ca/product/raspberry-pi-pico-w/

[2] https://www.raspberrypi.com/news/raspberry-pi-direct-buy-rp2...

[3] https://www.microcenter.com/product/486575/raspberry-pi-zero...

This is apples and oranges. Microcontrollers aren't meant to be SBCs.

>>That's so low, that you can't run Linux or BSD on it. I guess you'd need some DOS-like OS for it.

Absolutely no offence, but I think you are absolutely, 100% missing the point of microcontrollers, like by a nautical mile. It's the kind of chip that you'd have inside a humidifier and it controls the fan turning on or off depending on the read from the humidity sensor. It absolutely doesn't need to run a full OS, and in fact it would be a detriment to it and its abilities.

I have several Pico Ws around the house acting as sensor boards and I wouldn't replace them with Zero Ws even if they were free - it's just a worse board for that kind of job.

Did you pay circa $8.45 for each of your Pico Ws?

My problem is the price point. At that price point, you can get a full power chip. The Pico W should be selling for $0.90 so, if it were to be good value.

I paid £5.90 each.

>>At that price point, you can get a full power chip.

You see, this is the problem right here - you got it in your head that this isn't a "full power chip", whatever that even means. It's as "full power" as any microcontroller that has ever existed.

Once again ,it isn't meant to run an OS. The price is more than justified by the rich development environment with plenty of support(both official and community driven) as well as good connectivity options implemented directly on the board. The closest thing I can think of is a cheap ESP8266 board like a D6 Mini, but cheap chinese clones of that sell for £4 on ebay, barely any cheaper than the Pico W - an official D6 board is about £12, so not only it costs more - it actually offers less functionality and power.

If you know what this chip is for and what it's competing against, you'd see that in fact the value here is outstanding.

By "full power", I mean that it's at least capable of running Linux.

Even like 64 MiB of RAM is probably sufficient to qualify as "full power".

"Full power" means you can use heavy language & heavy tools without worrying too much.

You're not forced into the "embedded"[1] ecosystem of tools/languages/libraries.

[1] Which typically are heavily limited variants of the full versions.

But one doesn’t (or shouldn’t) want “full power”, an OS and drivers, etc for simple things. You want simplicity, lower power consumption, small size, instant power-on, and a single deterministic thread. Imagine if your hairdryer, or toaster took 30s to boot before using just because someone preferred to program it using JavaScript instead of C.

It’s not about being forced into the embedded ecosystem, embedded is the right choice for the job in many cases. In fact it’s common to see hobbyists struggle trying to make a full featured raspberry pi work for simple use cases that are more well-suited to an arduino.

While we don't yet have a Unix for Pico - correct me if I'm wrong - we have this - https://news.ycombinator.com/item?id=34446251 - a small RetroBSD clone for an ARM, a Cortex-M0 one.

DOS-like OS is also possible... RetroBSD creator is apparently looking into it: https://vak.dreamwidth.org/982612.html

You can get usb cables with built in button... Or just wire a button to the pico.

https://www.amazon.com/Switch-Extension-Upgraded-Strips-Syst...

These USB cables with a switch won't work - since they only seem to allow power. But you're right - a button will do the job.

For those looking to find this specifically, it's about 79% of the way to the bottom with sub-heading:

> Bluetooth Support for Pico W (BETA) The support is currently available as a beta. More details will be forthcoming with the actual release. In the meantime, there are examples in pico-examples.

> The Bluetooth API is provided by BTstack

From https://github.com/bluekitchen/btstack

| BTstack is free for non-commercial use. However, for commercial use, tell us a bit about your project to get a quote.

I was so excited until I read that. I’m working on an IoT device that I hope to sell and was going to build it around an RPi; I would love to switch from nano to pico but need better Bluetooth.

So go ahead and use Bluetooth on the Pico? Selling your IoT device is explicitly supported, you just have to get a license.

Yes, but at what cost per unit?

See my other comment above, this will be allowed on RP2040.

The motto of Bluetooth is "It's going to work great ...next year!". I've had so many challenges working with it in my past projects (even writing my own firmware) that I now try to avoid it and go directly to wifi.

Will you be able to source enough rpi modules? I guess your plan isn't just "buy them off the (online) shelves" because it's nigh-impossible to get more than a couple that way these days.

That's only true for the computer boards. The Pico never had supply issues. And apparently, computer boards will also be back in stock starting from Q2.

(edited, did a bit of research after complaining)

"It will be licensed by us for more permissive use on RP2040 (like cyw43-driver)"

Seen on https://github.com/raspberrypi/pico-sdk/issues/1164

What does that mean, though? Wouldn't they need an open source license for everything in BTStack except non-RP2040 drivers? There's a daemon, there's a "libusb", etc. This sounds like it'd require open sourcing practically all of BTStack, not just one driver?

There's really not that much. "libusb" is just the port of BTStack to the libusb API.

I'm just curious about the backstory; did the RPi foundation pay BTStack to be ok with this sudden open sourcing?

It sounds like it won't be open source. It'll be redistributable, but legally only usable on Raspberry Pis. Just like cyw43-driver.

Okay, so the minimal pessimistic interpretation of "more permissive". Bummer.

I'm excited about seeing BT LE support come to this.

I’m happy to see a built-in I2C responder library, even if it is an incorporation of the most popular community one. I’m working on a board with a bare RP2040 as a responder and currently my firmware is in MicroPython, which at best has a polling, third-party responder library. I’ve already decided to now move the firmware to the C SDK and this seems like good timing.

This is great. I've been using the Pico W as an automation tool and been controlling over a network connection. Controlling it through a BT keyboard would be much more reliable, I thing.

I don't understand why they didn't use something like an esp for the wireless. That seems to be more open. Is it a cost thing. Or is the esp equally closed but has a front end that isn't?

The wireless chip they used is a cypress chip but the design was by Broadcom, who sold it to Cypress (now owned by Infinion). A lot of the Pi team are ex-Broadcom and probably have a good working relationship with the team that make that chip. That will give them good confidence that any issues can be sorted out because they can get the attention of the right people. It's related to the chips which they use on the original Pi line

RF in general is pretty closed. Last I heard the ESP low level drivers for wifi and BT were closed source (but that was a few years back). There is a lot of resistance to opening RF, partly to please incumbents but partly because of concerns that completely open RF would cause a radio spectrum "tragedy of the commons" - BT and wifi protocols need each tranceiver to behave in order to share the spectrum, if people could easily tweak it, people could easily take the spectrum at the expense of their neighbours. (for example, see https://fsfe.org/activities/radiodirective/radiodirective.en...)

Having worked with creating drivers for Qualcomm (but not worked at Qcom) I can't stress enough how important is to have connections with people who are familiar with the hardware or have access to documentation.

Yes, between Broadcom and Arm, Raspberry Pi is very much a product of the Cambridge (UK) microcosm.

That tragedy of commons thing is why any consumer product where you could modify the radio transmitter firmware would loose its FCC certification, making it illegal to sell in the US.

That almost ended the sale of openwrt (or other open firmware) compatible wifi routers in the US. The compromise that was reached was that radio firmware would be signed blobs that would not be user modifiable, but that everything else could be modifiable while retaining the FCC certification.

I sure wish we could teach no tricks to the very capable RF hardware in many things. But things like the FCC and NDA's from IP vendors make that hard.

> That tragedy of commons thing is why any consumer product where you could modify the radio transmitter firmware would loose its FCC certification, making it illegal to sell in the US.

This is not true. FCC equipment approvals have both a frequency range and power level. What the FCC tried to clarify is that devices should not be able to be "easily modified" to operate outside of these approved parameters, which has always been true since way before radios had anything that could be considered software or firmware. For example, it would be against the rules to sell a radio certified for 1W power output that had a 5W power amplifier inside that could be enabled by removing a screw or something.

Firmware modification, in general, is not against FCC rules. For example, new firmware that lowered maximum power would be permissible (or firmware changes that did not affect the emissions of the device at all).

Here is the specific document from the FCC: https://s3.documentcloud.org/documents/2339685/fcc-software-...

Exactly, the firmware of the radio part cannot be freely modifiable. The manufacturer can release updatea for it.

Having the radio firmware separate ensures that openwrt style formwares stay in the "cannot affect emissions of the device"-realm.

Surely the pi foundation is big enough now to be able to get through the front door of any chip maker.

I'd like to see them using that clout to get (more) open hardware.

Protecting against tragedy of the commons through obscurity? Seems misguided. You could make the same claims about software, or SDR. And it isn't As if the Pico is high powered...

If you have ESP (most of them anyways) you don't really need the RP2040 anymore - you can run all your code on the ESP. Also there are all that geopolitical concerns about Chinese networking gear coming with more than you asked for.

And I am still waiting for the WiFi support in the Rust rp-rs crates

For Embassy-Rs there is this: https://github.com/embassy-rs/cyw43

I've tested it myself and it works great. Plus async Rust on embedded is nice.

I'm still waiting for the AP mode :(

That’s a big W for the Pico W. If you know what I mean. :smirk:

Reply on news.ycombinator.com