News just in from the folks at Raspberry Pi: the newest version of their Pico has WiFi and is called, obviously, the Pico W. We were going to get our hands on a sample unit and kick its tires, but it’s stuck in customs. Boo! So until it shows up, here’s what we can glean from the press releases and documentation.
The Pico is, of course, the Raspberry Pi microcontroller dev board based on their RP2040 microcontroller. This in turn has two Cortex M0+ cores and a good chunk of onboard RAM, which has made it a popular target for MicroPython. They had some extra real estate on the PCB, so they’ve added an Infineon CYW43439 WiFi chip, and voila: Pico W.
As of now, the WiFi is supported in both the C SDK and the pre-baked MicroPython image. It looks trivially easy to get it working, and it’s based on the time-tested lwIP stack, a classic in the embedded world. The CYW43439 is also Bluetooth capable, but there’s no firmware support for that yet, but we wouldn’t be surprised if it showed up soon.
The price? $6 for the whole shooting match. You can view this two ways: a small $2 premium over the old Pico, or a price increase of 50%. How you see things probably depends on your order quantity. Either way, it’s firmly in the ESP32 module price range, so you’ve got some comparison shopping to do if your project needs a microcontroller and WiFi. And in these days of silicon shortages, it’s nice to have a couple of options.
I’ve just ordered one!
Me too :)
I’ve just received one!
I’m actually just now fixing the bitrot on the Fuzix port to the Pico. I wonder how hard it would be to add networking support for the Pico-W?
Fuzix actually runs its own networking stack in userspace based on uIP, so I’d need a frame interface with the W’s networking chip (which is actually an ARM M3-based device with lots of RAM and ROM, which is considerably more powerful than the RP2040 itself!). Running lwIP itself in the Fuzix kernel may be an option but right now Fuzix has to run from RAM as the flash XIP stuff gets on very badly with filesystem writes to the flash, and lwIP looks like it’d use 70-odd-kB of space, which isn’t trivial.
It’d be nice to be able to push the entire networking stack into the network processor, which is certainly capable of it, but I don’t think the 200kB-ish firmware blob is open source.
(Incidentally, I’ll note that there’s a lawyerbomb in the cyw43 driver: the license only allows non-commercial use _except_ that the Raspberry Pi Foundation seem to have negotiated a better license if you’re using it on RP2040 hardware. Use with care. https://github.com/georgerobotics/cyw43-driver/tree/195dfcc10bb6f379e3dea45147590db2203d3c7b)
Yeah, that is a strange license indeed. I wonder if someone could cleanroom re-implement it? (IANAL)
There are firmware blobs, it’s not clear if this license covers the blobs as well, but most likely it will. So even if you cleanroom implement the code, you still have the blobs to reverse engineer and re-implement cleanroom. Which most likely will be a huge amount of effort.
Unless the firmware blobs are heavily customized, they’re under a semi-similar license to that library: “You can use this product only for the licensed hardware”.
I don’t consider that license quite as egregious for a firmware blob, since you can’t run it on anything else anyway… Obviously no blob would be ideal, but that does not exist for any WLAN chipset I’m aware of.
Not sure what the “lawyerbomb” is, the licensing situation still seems simple enough:
The driver is free for non-commercial use, so for any commercial use you contact the author (George Robotics, as in Damien George, the Micropython guy) and negotiate a licence (hardly unusual). Parts of the software are freely available as source – this seems to be the bits you run on your board to talk to the networking chip, which you otherwise treat as a black box. The rest of the s/w is provided as binary blobs. If you want the source to them, try negotiating a licence: it isn’t Open Source, just as a lot of s/w isn’t OSS.
That is all straightforward enough, not terribly unusual. If you are making a commercial widget then licensing some s/w you’d like to use is normal enough.
The R’Pi Foundation have had a chat with George Robotics and negotiated a licence so that anyone can use the software with the Foundation’s devices, in any capacity. This *is* a bit unusual, but then other device manufacturers will negotiate a licence so that they can let their customers use the devices without the all the customers having to all go and negotiate with the author or other rights holders individually (for example, a MPEG encoder chip coming with a pre-arranged licence to use the MPEG IP). The unusual bit is that the Foundation has licensed for you the IP to run on what is to them third-party hardware, just so long as you are connecting the CYW43439 to an RP2040 – i.e. you can make your own commercial RP2040 board with WiFi and keep it compatible with the Foundation’s new Pico board, the same way that plenty of non-Foundation RP2040 boards have already been released, with h/w USPs such as LiPo charging, that are compatible with the original Pico board.
Of course, IANAL etc etc but the licensing text is pretty short and easy to read.
“commercial use” is much fuzzier and broader than your analysis suggests.
Hooray! An ESP8266 (sort of).
While most of them will be used like an ESP____, the RP2040 does have some pretty unique tricks (low price-point for two cores, and more importantly the PIO). Also, its SDK is very pleasant to use if you’re more into C/C++ than micropython.
Half the exciting things to do with an ESP8266 or 32 got a bit crimped because of the shortage of i/o pins in general. So just having a lot more to play with should open more possibilities up, regardless of their extra tricks.
They have fully mapable I/O, right? I don’t typically find myself needing a ton of I/O in my projects, but that flexibility would give me what I need. I’ve been meaning to make an ESP32-C3 project for a while.
I’ve been sticking with EPS-8266 M1s for a while since they’re so cheap, but have been considering getting a few ESP-32s (expensive) for more elaborate IoT projects, but I also wanted to try to Pico which is cheap but so powerful with such interesting features.
Pico with wi-fi makes that decision for me, if I can get a Pico W cheaper than an ESP-32 clone.
The Pico SDK is _so_ much nicer to use than the ESPs, too. It’s not just documented, it’s well documented; and the SDK itself is basically a collection of type-safe functions which wrap hardware registers. There is some more complex stuff, like decent stdio, a USB stack etc, but unlike the ESP’s huge and clunky OS, on the Pico if you don’t want it you don’t have to pay for it.
I’m running down my stock of ESP8266 and migrating to ESP32. SpriteTM told me ESP8266 is dead at the last Supercon in 2019, which I believed. In practice, the dual cores make CPU-intensive tasks far more reliable while also doing network intensive tasks. I haven’t tried a single-core ESP32 or RISC-V though.
The RP2040 plus WiFi chip is interesting. However, Espressif will sell you a swimming pool of modules today while the Pi Cow is limited for now. I’m more interested in the RP2040 as a bare chip than the wireless dev board, though will definitely pick some up and see if they’re a good default option for my swiss army knife project brain bin.
Note that ‘esp8266 is dead’ needs to be placed in context: we’ll still produce it for the coming while and the SDK still will see releases, but most of the effort is going into ESP-IDF.
Oh interesting! Bad timing for me, as I recently discovered my octoprint Raspberry Pi 3 has apparently had its wifi die, and USB wifi adapters that work well with Linux are around $30…
I’ve never had any problems with the cheap random USB wifi modules on the Pi (before wifi was even a thing there). Here’s one that for a few dollars that will probably work:
https://m.aliexpress.com/item/1005003112521288.html
Can confirm that every Realtek USB adapter I’ve tried has worked. If you’d rather get one faster and are willing to pay a few more bucks and deal with the devil^H^H^H^H^HBezos, here’s one that should work fine on any modern Linux distro and platform: https://www.amazon.com/Plugable-Wireless-802-11n-Network-RTL8188EUS/dp/B00H28H8DU/
Oh interesting, I’ve got an RTL8188FU (yes no kidding) which definitely doesn’t work (easily/well) on Linux. I’ve remembered that I got a cheap wifi AC (dual band) USB adapter though and it works well everywhere, so I tried ordering another for $5.50
I’ve had a variety of RealTek adapters that didn’t work because the overarching driver was blacklisted by default.
Thought about ordering one, but of course on every reseller I tried the shipping cost significantly more than the Pico itself.
Obviously shipping charges exist, but are we talking about the same crap that seemed to apply to all Pi products, $15 shipping upcharge however you ordered it? Like free shipping over $50 but with a Pi in the cart it’s +$15 anyway, order a “half shoebox worth” of other bits that would normally travel in a $15 package and add a Pi and it’s $30, that kind of crap?
It’s shipping and “handling” ;)
So every time they open the storage vat they blow off $10 worth of nitrogen and use up a $5 paper bunny suit?
So as far as I can tell, resellers don’t get much if any discount on Raspberry Pi products and the official retailers appear to have a pretty strict “do not sell at anything other than our recommended price” agreement. It’s slipped a few times that e.g. Adafruit makes no profit on Pico sales, so it’s nice if you put some other product in your order, not just rpi products. And e.g. most discount codes exclude Raspberry Pi stuff for this reason too, etc. So in some ways they very well might be a loss leader.
I bought a LEGO set with a “Grab it Now!” (or something like that) promotion on Banggood.
But then they added S&H which made the final price twice higher than Walmart.
There was no option to cancel the order at that point.
B^(
Couldn’t they add Bluetooth? Isn’t it the same radio? It’s just a different stack. Easy, it’s only sw, says the hw guy.
It has got Bluetooth!
Sorry, not been implemented yet!
Yet being the key word.
I’ve dug into the datasheet just a little. And from what I am finding, the Bluetooth portion uses a different host interface that is not connected on the Pico W?
The WiFi uses SPI to talk to the host, I.E. Pico.
But Bluetooth uses a separate UART interface that is not connected?
But feel free to dig through the datasheet and correct me.
https://www.infineon.com/dgdl/Infineon-CYW43439KUBGT-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c7ddc01d7017ddd033d78594d
Not the same radio. Two different PHYs sharing the same antenna; you need FFT and channel estimate interpolation accelerators for the OFDM in WLAN, and a different kind of LO synth for BT.
Yep, I’m an SDR guy, and of course “it’s just different stack”, but unless you can install a core i7 and a matching battery in your wireless frontend, you want accelerators and specialized hardware to implement parts of the phy.
(I’m talking about the “interesting part”, the actual wireless stacks in the CYW43439; not implementing the interface to the BT stack is either a bit of an indication of a rush, where the BT demo for the RP2040 fell of the end of the wagon, or serious problems with that BT functionality (but the same stack has very likely been around in the BCM4325 from 2009, so it’s probably well-tested, see https://twitter.com/dEnergy_dTime/status/1542447730349555712 ), or a licensing problem. None of these three reasons would surprise me, at all.)
I mean, if you search the CYW part number it does say Bluetooth support, so somebody has software that made it work at least once. But presumably it’s not reliable enough or otherwise suitable for rpi trading/foundation yet
As all this does is adding a network coprocessor to the RP2040, what is stopping one from just adding an ESP8211? That at least can come with FOSS firmware. And if the humble C64 can SLIP and leave enough memory for programs then so should the RP2040 be able to.
Yes… but did you forget the sh*t storm when the Pi folks had the audacity to release a microcontroller -without- builtin wifi? They won’t make that “mistake” ever again ;)
Would be interesting to see an RP2040 board implement an ESP-14 (not sure if you can still purchase them)
https://hackaday.com/2017/02/13/hacking-on-the-weirdest-esp-module/
The only benefit to getting a supported more official product is the work is done for you, with a little caveat that it might also be much cheaper for you, as ordering quantity ‘small’ of the co-processor might well be impossible, or impossibly expensive…
Which is why wifi enabled dev boards that are otherwise basically just the same as the Pico have already been made by others.
I suspect at this point the “recommended for new design” coprocessor would be esp32-c3 or esp32 original, but yeah, while it’s more open source, I’m pretty sure it’s not blob free.
There are a few RP2040 dev boards out there with ESP32 co processors:
https://www.tindie.com/products/lilygo/lilygo-t-picoc3-esp32-c3-rp2040-wireless-wifi/
The block diagram shows the CYW43439 part has an ARM Cortex-M3 in WLAN subsystem and a Cortex-M4 in the Bluetooth subsystem. I don’t know about the clock rates, gpio, and memory, etc., but both these processors are nominally more capable than the Cortex-M0.
And they probably won’t work very well if there is random user code loaded onto them, affecting timing etc.
Also stuff that is exposed to users has to be properly documented and supported, which is just a money sink without any hope of payback. Good documentation is really really expensive esp. when there are patents because the lawyers have to check every word.
Presumably they’re not very accessible or well-provisioned with io since they’re basically intended as single purpose processors, but yeah, having more power in your WiFi adapter than your micro is not that uncommon. Even going back to the early Arduino WiFi boards that basically had a tiny openwrt router as their adapter, thru to Adafruit airlift stuff with a samd51 and esp32 (though maybe that’s a closer match)
Any unpopulated external antenna pads?
Not for a proper socket, but someone already put an external antenna on one, with the obvious compliance issues going with it.
https://forums.raspberrypi.com/viewtopic.php?t=336764&start=50#p2015954
None in stock at my “local” Micro Center.
Keep looking. Seems shipping in the US can start only on July 5. Maybe they’re keeping it out of the web pages on purpose because of that.
I found two, the Pico WH and the Pico Wifi (or Pico W) at my local Micro Center, which is in Brooklyn NY, they might be at the one in Queens or in Yonkers, or even LI, but I prefer the Brooklyn one. Why? How far away from NYC are you?
Has someone checked dormant / deep sleep power consumption?
Worth looking at Pimoroni’s YouTube channel. Their ‘Pico W aboard’ range of adaptors are using programmable RTCs to power down the PicoW, and then wake it up at a programmed interval (or trigger), to let them run wireless weather stations, wildlife cameras etc. on AA batteries for months.
have blob?
have blob
Is one forced to keep the Micro Python?
I like Python, but (IMMHO) not on my micro controller.
You can use C, C++ and assembly https://github.com/raspberrypi/pico-sdk
The bluetooth pins of the wireless module are all marked as NC on the schematic in the datasheet so I doubt we’ll be seeing firmware support any time soon…
That’s assuming those pins are for necessary functionality, as opposed to optional functionality.
When BT is implemented it’ll use the SPI bus. So just a software updated needed for BT support.
https://www.infineon.com/dgdl/Infineon-CYW43439KUBGT-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c7ddc01d7017ddd033d78594d
According to the datasheet, Bluetooth uses the separate UART pins from WiFi, which is connected via SPI to the Pico.
The UART pins are not connected, so Bluetooth may not work until the board is updated.
But please have a look. I could be wrong and am hoping someone will prove it!
sorry, this is NOT OPEN HARDWARE
betteri is orange crab
to many blobs
The only thing not open in it is the blob required to boot it up. Everything else is open, so much so that you can buy just the 2040 and build your own boards. The entire SDK is open source too, ready for your use on Github.
So it’s not like it’s 99% evil.
Other than System76, how many other open hardware PC/laptops/SBC are in the market? Especially for that price?
Pico W is not an SBC to begin with, so there’s tons of comparable boards with comparable MCU’s on them that are open source.
Is the SDK for the Cypress Wifi+BT module used here FOSS?