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.
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).
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.)
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...
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.
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.
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.
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.
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.
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]
>>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.
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.
>>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.
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.
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.
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?
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.
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.
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...)
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).
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.
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.
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