Raspberry Pi Pico W: your $6 IoT platform
raspberrypi.com
raspberrypi.com
The library is closed source, I think, because it uses propriety Cypress code.
Cypress apparently since released source code and the author had considered releasing an open source version of the library but it never eventuated. See this discussion from 2019:
https://github.com/micropython/micropython/pull/4669#discuss...
Seems bizarre to me that rpi didn't just create a non-proprietary library.
Wireless/RF drivers tend to be closed source for what I understand gets down to bad code can cause RF no noes. Hopefully somebody more knowlegable will chip in upon that though it is common (sadly) for your mobile driver to be some closed blob.
They may also be working on such a library and still need a lot of work, which could be why BT/BTE is not enabled as is though mooted at a later date.
Might also be that the community is large and momentomous enough that the hope is that they will produce the goods in open source spirit. Certainly the whole graphics driver stack upon the RPi's seems to be going down both those last two paths in it's open source flavour.
Edit: forgot to include the link to the radio chip.
[1]: https://www.infineon.com/cms/en/product/wireless-connectivit...
The chapter on Wi-Fi says this:
10.1 WLAN CPU and Memory Subsystem
The CYW43439 includes an integrated ARM Cortex-M3 processor with internal RAM and ROM. [...] On-chip memory for the CPU includes 512 KB SRAM and 640 KB ROM
And for Bluetooth it has this:
8. Microprocessor and Memory Unit for Bluetooth
The Bluetooth microprocessor core is based on the ARM Cortex-M3 32-bit RISC processor with embedded ICE-RT debug and JTAG interface units. It runs software from the link control (LC) layer up to the host controller interface (HCI). The ARM core is paired with a memory unit that contains 576 KB of ROM for program storage and boot ROM, and 160 KB of RAM for data scratch-pad and patch RAM code.
Strange and confusing.
Edit: quote markup, added mising section number for BT.
[1]: https://www.infineon.com/dgdl/Infineon-CYW43439-Single-Chip-...
Does shows it does have an M4 as you stated, that is for the BT stack.
Imho, non-wireless-intergrated MCUs will go extinct in IoT very soon.
They also have the best mixed signal out of every other scrawny IoT startup who uses off-the-shelf IP.
You don't have to re-implement protocols to commit FCC (or pick your local reg agency) no-no's. See e.g. discussion by this HAM radio operator on his blog (doing legal things, but you can easily do this for non-legal things):
>...but it never eventuated
>Other British grammarians, and even some Americans, agreed that it was horrible. Eventuate is less controversial these days, though its use is still regarded by the occasional critic as pompous, ponderous, and unnecessary...
There is a chip shortage on, so having a volume supply wifi chips is a miracle.
Not having to pay a licensing cost is also rather a good deal.
As with all things here, perfect is the enemy of good.
Should chip suppliers view open-source drivers as undermining their competitive advantage? I don't think so, but they tend to, and this isn't a great time for RasPi to get on their bad side.
It's also not their mission, although that's been pointed out enough. Call it a battle for another day.
You are not understanding the issues. If it was an option, the Rpi foundation would have taken it. Shipping closed drivers, to an opensource project is a ball ache, and leads to lovely people claiming that the foundation is there to stifle this and under mine that.
Its far more dull than that.
Its either a compliance thing (opensource drivers might need re-certifying the wifi) Contractual: its a seller's market and in order to get the best value, the foundation had to use the drivers provided.
Doing some work for (distro), I've spent an enormous amount of time building automated, hdmi-captured, media-less-netboot testing platform and you wouldn't believe the number of bugs I hit or slight behavior changes I saw as various firmware updates landed. Usbboot (nee rpiboot) is not really great or well written. Oh I forgot by/wifi firmware is in two more repos, with no instructions on usage, and they keep renaming files breaking my work.
So, yeah, I'm not remotely even 1% surprised by this.
I played around with the in-progress branch for the Pico and it already works fine[2]. Having ESPHome support the Pico W would make it very easy to integrate it into my Home Assistant setup like I do with various ESP8266 devices currently.
[1] https://twitter.com/esphome_/status/1542402677539078144
[2] https://www.jeffgeerling.com/blog/2022/esphome-on-raspberry-...
Raspberry Pi Pico W for $5ish: two Arm Cortex-M0+ cores @ 133MHz with 264kB of on-chip SRAM
Nearly 25 times the computing power (per core! So really 50 something times the computing power total) for 800 times less the price.
Absolutely staggering how much our computing hardware capabilities have progressed!
(And how we waste said hardware with our bloated proglangs. Anyone have book recommendations for RTL design patterns, design thinking?)
In fairness, the BASIC interpreter on the IBM PC was no paragon of efficiency either. And Microsoft's C compiler was something like $600. (In 1981 money when I was earning around $27K as an engineer.)
I haven't studied the capabilities much, the biggest difference I could see was that the 550MHz version of the H7 only comes with 0.5MB SRAM vs 1MB SRAM for NXP one, while the H7 with 1MB SRAM only goes to 480MHz. However the STM32 parts comes with flash memory included (up to 2MB), while the NXP one has none. To me it seems the STM32H730VB[2] is one of the closer matches if you favor speed, while the STM32750VB[3] if you favor SRAM, but it depends heavily on the metric used for comparison.
[1]: https://www.nxp.com/part/MIMXRT1062DVL6A#/
[2]: https://www.st.com/en/microcontrollers-microprocessors/stm32...
[3]: https://www.st.com/en/microcontrollers-microprocessors/stm32...
Unofficially, CPU cores on the STM32H7 parts I've worked with are often stable well into the 700+ MHz range. Peripherals are another story.
That right there is one of those cheap screens, right?
Also the power consumption makes this mostly useless for battery operation. Overall I'm still not impressed by the 2040. I'll stick with the NRF52840.
As much as I like the Pico, it seems that Espressif is (finally) upping its game.
Dual band is highly relevant especially in hight density areas with crowded 2.4 GHz bands.
At idle, while connected to WiFi, it's under 10 mA, but I haven't had time to do any detailed testing, so take those numbers with a grain of salt.
[1] https://www.jeffgeerling.com/blog/2022/raspberry-pi-pico-w-b...
A few years ago when I was working on a project, the factor was in low two digits. It was a no-brainer to choose micro B over C.
[0] https://lcsc.com/products/USB-Connectors_369.html [1] https://lcsc.com/product-detail/USB-Connectors_XKB-Connectiv... [2] https://lcsc.com/product-detail/USB-Connectors_G-Switch-GT-U...
So either they managed to make that more efficient somehow or you'll have exactly jack shit left after turning on wifi on it. Still, the ESP32 is not exactly cheap, but I have a feeling this $7 cost is the usual fantasy they advertise, then sell them for twice the price everywhere.
The current pico is sold at the stated price + taxes here in Sweden, so I don't see why the W wouldn't also be. And it seems unlike that Sweden would be special in that regard.
OTOH Zero is $5 only because it's effectively subsidized at various points in retail chain.
Pico W must be cutting it close at $6.
Edit: typo
The wifi stack doesn't run on the rp2040, the cypress module has its own cpus(2!) and ram to handle it. The lwIP stack runs on the pico but its resources requirements are essentially negligible.
So the rp2040 cores and memory are fully available unless you need TLS, which I'm sure will Absolutely steal both resources.
The Pico in particular has never had availability issues. Actually, it seems to have much better availability than most competing products.
While that doesn't currently affect the Pico, maybe it will in the future. So its probably just better to sidestep the whole thing and not use their products.
Does anyone familiar with CE/FTC compliance know how much easier this makes things? I have a project that uses an ESP32 and the lack of clarity around the infamous "CE+CE != CE" is rather annoying. I'm guessing the RPi is the same (i.e. if I put it in a case and want to sell it I still need to get testing done).
They're a lot more plentiful than the mainstream Pi boards.
I think that's reasonable cost-wise for my purposes (I'm making a status display to go inside my white-build gaming 'rig' to look shiny). Red takes about 12 seconds to refresh, AFAICT I should be able to get sub-1s black updates. You can get 7-color versions for about the same price but the refresh on those is very slow.
As ever it depends what you want to do - If you want a 2-inch tri-color display, in a format where you can attach SPI wires easily, you might get away with $20 AUD. You can find small greyscale eink displays very cheap (sub-$1) like this - https://www.aliexpress.com/item/1005003555154992.html
But you'll need to find some sort of interface from the ribbon cable to whatever wires you need.
If you want full-color, fast-update e-ink/epaper, that's just filtering into the market AFAICT, and it's much more pricey. I can find a 31.5 inch full-color epaper display for about $2200(US)!
(There's a video of it in action here - https://www.youtube.com/watch?v=bPnJh4QcjDY)
Right now there is stock on a number of reseller sites, and though they might sell through for the first few weeks as enthusiasts bundle up a bunch of orders, I would bet it will be easy to get them at MSRP (maybe with expensive shipping of course) in the next few months at the latest.
The Pico was sold out for a month or two initially, but there's a ton of stock right now—heck, you can buy the RP2040 by the thousands on reels from any distributor.
Though they still had 4k+ units of the non-wifi version (Pico Pi)
I am still waiting some better IO connectors so I can connect an SSD to RPi.
I'd imagine if Raspberry Pi were to try their hand at their own SoC chip, it would be someday in the future when RISC-V designs have matured enough to make a suitable successor.
Otherwise, making a chip as complex as a modern SoC requires a lot of resources a smaller company like Raspberry Pi just doesn't have at their disposal.
Not really, but you get my point. For the kinds of devices the RP2040 competes with, it is not slow.
The RP2040 isn't perfect, but it's a good starting point for more capable/specialised chips e.g. variants with high speed USB, 100Mb/s MAC, just scaled up (four M0+ cores, 8way interleaved memory banks, additional PIO and DMA engines, dual QSPI).
Just upgrading to a good dual QSPI peripheral would make the chip more versatile allowing users to choose between different external memory configuration like SPI flash and PSRAM or higher combined flash read bandwidth.
The whole thing xperience od unpaired devices broadcasting as a WiFi AP and having to join your phone to that SSID is clunky.
264K is plenty for many things you can do with that kind of device.
But why? It (well, the Pico board at least) already runs Python ;^)
This might be of interest:
https://blog.adafruit.com/2022/03/10/linux-written-in-python...
It's a clickbait title, it's actually more of a busybox-like thing giving a linux-like shell from what I can tell. I haven't looked into it.
FUZIX, which I think is based on Doug Braun's even earlier UZI (Unix Z80 Implementation), might also be of interest:
https://www.raspberrypi.com/news/how-to-get-started-with-fuz...
I always believed the Raspberries, Arduinos, etc weren't suitable for large-scale industrial applications.
Do they really use Raspberry Pis in commercial/industrial products?
Please forgive my ignorance, I have zero experience in the embedded systems industry.
https://www.raspberrypi.com/for-industry/
https://jfrog.com/connect/post/3-best-industrial-raspberry-p...
A super-cheap WiFi Router -- could be made out of this...
Here you've got the idea of using a ESP8266 or ESP8285 microcontroller (basically a chip, an ASIC -- which contains CPU, enough onboard scratch RAM, WiFi circuitry, and GPIO -- to be used for the Ethernet interface, apparently implemented by a separate ASIC and/or attached module/electronic circuit) -- to implment a WiFi Router and/or Access Point...
And for very little money no less!
If we look at this set of ideas in the broadest most abstract way possible, we have an ASIC (in this case a Microcontroller) -- or set of ASICs (if we count the Ethernet chip as separate) which cost very little money to implement a WiFi Router/Access Point -- on...
This leads me to the following question:
What is the cheapest, absolute cheapest ASIC that is available today that would implement all of the features necessary to create a WiFi Router/Access Point -- with direct support for (one or possibly several) wired Ethernet ports -- included?
And maybe another question:
Would that thing be an ASIC, or would it be a board + Ethernet Ports based on that ASIC? (It may cost someone more money to purchase the additional components once you have that ASIC than the cost of purchasing a pre-manufactured board with all of them on it...)
Let's suppose that the use case would be: You want to sell hardware devices with basic Router/Access-Point capabilities to customers, but you want to pay as little as you can for the parts...
So what combination of those parts -- gets you the cheapest, yet most fully-functional WiFi Router/Access Point?
Someone going down this path might need to even take into consideration costs arising from cases and power supplies -- because that's what end-users/consumers would expect as part of their purchase...
Anyway, Excellent link!
Why wait?
Is it though? Seems to me the marketing, especially this announcement, pushes it for commercial users.
"To help you get the most of your Pico, why not grab a copy of Get Started with MicroPython on Raspberry Pi Pico by Gareth Halfacree and our very own Ben Everard. It’s ideal for beginners who are new (or new-ish) to making with microcontrollers."
https://cdn.shopify.com/s/files/1/2280/2293/products/068-069...
Arguably? They straight up say that the things in those repos are unfinished or otherwise not good enough for the SDK.
QSPI Flash is external to RP2040. I was expecting some form of facility to encrypt XIP flash content and RP2040 could decrypt and execute (instead of execute only)
Or, Any idea if Rpi would add this feature?
The PICO has great software documentation and seems easy to program. I did not use it till now as it had no networking features at all.
Now this comes along, and the Pico can form a great Edge device.
Nevertheless, whatever they do is awesome anyway.
Pi Zero's have such wonky connectors....
I'm guessing the Pico is a much simpler thing to make and in high quantities, so much easier to churn out to meet the demand
They will usually work as far down as 3V, for that matter. These are analog systems, and there's a big difference between "works" and "works reliably, for months and years".
In current market conditions what you want would cost at the very least $100 and would require active cooling some of the workloads. The question is: would you buy it in those conditions? Most people don't and worse than that, the Raspberry folks would "lose focus in their mission" and the "product" would be just another one in a sea of clones.
Is there a clone which can browse modern heavyweight web (like YouTube) without tears, runs the original Raspberry Pi OS (not the x86 clone), has the same (or bigger) set of GPIO pins and supports Raspberry PI hats? More IO would also be great to have. I don't mind if it costs some hundreds dollars. I'd love to have passive cooling though. And it has to be approximately the same size, MiniITX won't fit.
The problem with the "clones" is they are more or less the same but have one or two components as their strong point, one has a beefier CPU, the other has more IO, one has an "AI engine", etc but when it comes to smooth performance for the "normal" end-user, ie. run a bunch of tabs with "modern" sites in a smooth way every time you'll need to enter x86 territory. Then this whole affordable SBC tinker thing doesn't make sense because these are 2 different worlds.
I know because I've been obsessing for a sub ~$70 SBC that supports a bunch of SATA disks ( natively, no USB trickery ) for a decade.
Up until Apple's M1, desktop ARM was always an "almost there" experience at best and most were a terrible experience. ( Software is a big part in this too )
In the next few year I think things will change for the better.
As an embedded developer, you are far better off learning how to use the BSPs for the major embedded semi vendors, such as NXP, STMicro, and Renesas. No one is going to ship a battery powered IoT product that runs linux (and make money).
Here's a good example of a project of mine where I used MicroPython: https://twitter.com/tom_verbeure/status/1536127568931217408.
I needed a way to quickly drive a bunch LEDs but I didn't want to dive into C yet. Too about 20min to install MicroPython on the RP2040 (no clue why you're bringing up Linux) and get my LEDs going. Perfect!
In a later phase, I'll convert to C, once MicroPython runs out of steam.
For a lot of slow control projects, that will never be necessary.
The pi was designed to get kids into computers. The pi is now powerful enough that you can use it as a pc almost. The Pico forces you to engage with it in a different way. Plus the pio and other hardware stuff opens up possibilities for hardware stuff.
It's similar to Arduino boards. You can use Arduino or PlatformIO if you like, or alternately Micropython or CircuitPython.
The original idea for the Pi was to be a modern BBC Micro. But the Pi turned out to be just a regular PC. A little cheaper, less powerful and ARM. But it doesn't really do much that you couldn't also do with a PC. It doesn't have the magic of turning it on and ending up on a BASIC prompt. It doesn't bring you closer to the hardware. It has all the complexities of a PC.
Meanwhile the Pico is just a regular old MCU. It doesn't have anything that you would associate with a home computer, no keyboard, no way to connect a display, no swappable storage, can't be it's own development platform, etc. It's not something you'd ever want to have as your first computer. You need a real computer to even get any use out of it.
A project like the CommanderX16[1] feels a lot closer to the original goal. As it's just a home computer build modern components.
Firstly, I don’t think the PI’s can be seen to have failed. I’m not close to their use in schools but I do think that for hardware to be useful on this context if needs to engage with the modern computing world and that includes all the ‘messiness’ of Linux etc.
Secondly, I think the Pi Pico W - which can drive a display using one of the cores (see link) - has the potential to be the basis of a system close to what you describe.
https://picockpit.com/raspberry-pi/raspberry-pi-pico-video-o...
I wasn’t aware of the Commander x16 which looks interesting but I was a bit disappointed to see the 6502 based CPU. In the 2020s I think we need to be using a modern architecture and that means Arm or RISC-V.
Finally, the Colour Maximite is also close to the sort of thing you’re talking about.
the big thing you are missing is that PI can be used for electronics and robotics- it has GPIO, SPI and I2C accessible from python, javascript, etc.
this was unheard of previously - if you buy a normal PC or even an industrial SBC, even when the pins are exposed they are often 1.8 volts, which is impossible to work with for a hobbyist. The binsings are usually some unusable C header file.
all the people who could plug in Kinect and make a robot that navigates a 3d environment would be stuck without a pi
It runs python which I suppose is the modern basic, I believe there's a maximite (picomite) Project for running basic on it though. With SD card and screen support
So you can get all this up and running, or you can do it yourself.
Commanderx16 is aiming more for the retro computer crowd. I don't think the pi foundation ever aimed for that.
I think you may be misinterpreting the BBC reference. The BBC was introduced as a computer to teach people about computers, it was widely used in schools etc. That's what the pi was trying to do. There is also the straight to basic element in there too. I don't think they were ever aiming to remake the BBC though
Linux on RISC-V is real, china is using & standardizing on it. Ditch arm, skip RPI, ignore STM-32, and scoff at TI, .. RISC-V is the future.
While you're at it - skip micropython, skip the OS Linux - use RUST and target RISC-V directly.
The cost of RISC-V is cheap and will only continue to plummet, nothing in the IOT space is going to compete with RISC-V except absurdly expensive niche proprietary solutions that were engineered before the blackhole-esque super-nova gravity hole that is RISC-V which is happening right now in the IOT space. I'm not even sure those will survive, ..
The RISC-V options are only going to continue to increase. I say this because China is using RISC-V for most of it's future everything, it's basically the national chip and there are literally tens of thousands of developers & engineers coming out of school into this ecosystem every single day.
Do not use micropython, avoid all these runtime debugging headaches. Yeah, it might take you a few months or even years to learn RUST, but the concurrency, the power saving, the deterministic behaviors - oh joy! The headaches you will save, the extra rest at night and reduced stress will increase your lifespan.
Qemu RISC-V for emulation + testing and you'll save yourself a ton of time only deploying and supporting code that works. Full simulated environments, you can test in parallel in the cloud, few platforms can do that! RISC-V + RUST it's a joy.
Fewer crashes in the field-- and let me tell ya! .. when you're doing anything IOT that is the only thing that matters - never having a crash in the field, that's better than chocolate cake.
Can you point to any parts that are in full production and have a 5-7 year supply horizon?
Do you know of any RISC-V chips which have something like that? Generally curious too about which RISC-V chips are as widely available as the RP2040
Also the RP2040 is a great chip and it's super available and it's super cheap. And it runs Rust.
There's nothing irrelevant about an RPI Pico: it has more RAM than most, it has excellent documentation and example code, it has PIOs that are incredibly versatile, it's available everywhere, and it's dirt cheap.
For quick prototyping I use MicroPython, otherwise I use C. Why should I have to learn Rust for something simple?
https://www.raspberrypi.com/documentation/microcontrollers/c...
I find the Pico SDK examples useful to learn, but it requires that you already have a good understanding of the instructions and the protocol that it implements. Here's the I2C PIO program, for example: https://github.com/raspberrypi/pico-examples/blob/master/pio....
In contrast the RP2040 is readily available, has 30 GPIO, and the Pico dev board is only $4. I'm not building an IoT device for my next project so I consider the die space dedicated to those features wasted.
I recognize this post is about IoT but I just wanted to say I don't think the RP2040 or Pico are irrelevant. The platform has it's benefits. In my case, relying more on the SOC and not having to increase BOM.