Raspberry Pi Pico W: your $6 IoT platform(raspberrypi.com)
raspberrypi.com
Raspberry Pi Pico W: your $6 IoT platform
https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/
203 comments
The Raspberry Pi Foundation's ultimate goal is to get access to computing, computer science, robotics and experimentation into the hands of children, especially those that can't afford a conventional PC. Their goal is not to advance free software or open source or any of that stuff. The GPU on Raspberry Pis (which is basically the master controller of the entire system) is a repurposed chip that was meant for cable TV set-top boxes and is very proprietary.
From the launch blog post, "The network stack is built around lwIP, and uses libcyw43 from Damien George (of MicroPython fame) to communicate with the wireless chip. By default, libcyw43 is licensed for non-commercial use, but Pico W users, and anyone else who builds their product around RP2040 and CYW43439, benefit from a free commercial-use license."
point of GP being availability of source, not freedom as in beer.
It's not remotely bizarre. Distros take on so much god damn work because of the quality of firmware, etc releases. It's a real nightmare. Go check the firmware commit log. Or try to figure out what version of the kernel, firmware, dtbs, eeprom, and more, are actually tested by the Foundation.
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.
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.
Man, thanks for doing all that work.
> Seems bizarre to me that rpi didn't just create a non-proprietary library.
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.
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.
The point is they could be using these very same chips, but with an open source driver.
Another point is that chip suppliers can pick their customers until supply issues resolve, which there's no sign of.
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.
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.
> they could be using these very same chips, but with an open source driver.
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.
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.
Raspberry Pi never put openness first.
Maybe a few factors at play here:
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.
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.
All true, but the radio chip [1] has two on-board ARM cores (an M3 for Wi-Fi and an M4 for BT) each with separate ROMs. So I would assume the library just interfaces with the chip and tells it what to do, not implement low-level radio protocols and so on. Weird that such a library is closed source, on the other hand. Annoying. :(
Edit: forgot to include the link to the radio chip.
[1]: https://www.infineon.com/cms/en/product/wireless-connectivit...
Edit: forgot to include the link to the radio chip.
[1]: https://www.infineon.com/cms/en/product/wireless-connectivit...
> not implement low-level radio protocols
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):
https://yo3iiu.ro/blog/?p=1301
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):
https://yo3iiu.ro/blog/?p=1301
Even if you don't write custom RF code, you still need to go through certification, so it does not really matter if user can or cannot write their own custom code. It may be just a bit more expensive to get it certified if you make a mistake.
That blog post is describing hardware-specific configuration tweaks. It's quite possible for firmware to check that these are regulation-compliant, and good quality hardware will typically do this.
Very useful - so does the wifi chip have faster ARM cores than the RP2040 microcontroller which has M0+ cores is what I'm wondering now.
The cores are faster/better, but the one public document I found [1] without logging in to Infineon does not specify how they are clocked. Weirdly, the document says that both Wi-Fi and Bluetooth have M3 cores, no M4 mentioned.
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-...
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-...
I found under the block diagram of https://www.infineon.com/cms/en/product/wireless-connectivit...
Does shows it does have an M4 as you stated, that is for the BT stack.
Does shows it does have an M4 as you stated, that is for the BT stack.
Likely, the computation needed for n almost certainly exceeds that needed for basic IoT logic.
Yes, and that's why ESP32 can be so cheap. They just run the WiFi stack on the same core, and they got very good know-how on the side of hardware<->RTOS interaction how to make it viable (very hard.)
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.
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.
rpi has never been about open source.
>...but it never eventuated
I think you're a couple of decades too early for the Babel Fish.
https://www.merriam-webster.com/dictionary/eventuate
https://www.merriam-webster.com/dictionary/eventuate
>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...
Another bit of interesting news that came across my feed this morning: ESPHome is working on supporting the Pico (and Pico W) in an upcoming release[1].
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-...
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-...
[deleted]
IBM PC for $4,000ish:
Intel 8088 @ 4.77 MHz with 256 KB of motherboard memory on some models
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?)
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?)
I mean, if you're just looking at compute-per-dollar then this is a rather bland entry. The Pi Zero came out in 2015 for $5 and has >1000x the memory, is much faster and is a real computer that runs linux and even multiplies floats. Even among MCUs this one is not that great, you can find STM32-based boards ("blue/black pill") for <$3.
Also the venerable ESP8266 packaged as ESP12f at about $3 in hobby quantities. Sure, it is slow, but includes wifi.
How do the stm mcus compare to the teensy? I think the latest teensy is much faster than prevision versions, hitting 600mhz.
The Teensy 4.x are based on a Cortex-M7 chip[1] from NXP. The STM32H7 line is also based on a Cortex-M7, though officially only up to 550MHz.
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...
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...
> The STM32H7 line is also based on a Cortex-M7, though officially only up to 550MHz.
Unofficially, CPU cores on the STM32H7 parts I've worked with are often stable well into the 700+ MHz range. Peripherals are another story.
Unofficially, CPU cores on the STM32H7 parts I've worked with are often stable well into the 700+ MHz range. Peripherals are another story.
Yes, teensy 4.x is much faster, probably about 10x, but is also ~10x more expensive.
>And how we waste said hardware with our bloated proglangs.
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.)
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.)
Great news, I played with the Pi Pico a few months ago: the idea was to make certain 3D printing products I produce not just dumb miniatures, but "alive", doing something. The Pi Pico price point and capabilities were perfect, but the lack of wireless capabilities AND the fact there is no display with a sane price point, made the project economically impossible.
I've been using the Pico to drive a screen successfully: https://slint-ui.com/blog/porting-slint-to-microcontrollers....
Sure, it can drive screens without issues. The problem is the cost of the screen. If I'm selling, right now, a plastic miniature for $20, if I can make it "smart" and selling it for $30 or $35, that's ok, but $50? Nope.
This one is $2: https://es.aliexpress.com/item/1005002438086706.html
How much screen do you want? Have a dig round on aliexpress, some of them are dirt cheap if you want a small TFT, and some are designed specifically for use from the pico.
you can get screens for under 10$
eg https://www.waveshare.com/pico-lcd-1.3.htm or https://www.waveshare.com/pico-lcd-0.96.htm
Warhammer scale miniatures?
The tiny OLED screens are often under a dollar and you can stuff them into basically anywhere, and run them off anything. Sure they're low resolution and monochomatic, but often it's all you need to bring something to life. The total BOM cost for showing some short animations on one is likely under $3.
I was just eyeing this product this product the other day: https://www.keebmonkey.com/products/megalodon-triple-knob-ma...
That right there is one of those cheap screens, right?
That right there is one of those cheap screens, right?
In my experience, the very cheap oled screens are usually quite a bit bigger than that. Closer to the size of a smaller smart watch (with much lower resolution of course)
That's one of them.
Not hadd that issue myself and quick check https://thepihut.com/pages/search-results?q=oled&page_num=3 shows few cheap options, sure bit more than the controller but equally, not bad and more so not the cheapest place either (though not the worst and more walk in highstreet ballpark fair price). Though your bangood and aliexpress's will have cheaper options and in volumes you start to see the price slide down nicely.
I'm surprised there's no 802.15.4/Thread support on a new IoT platform in 2022.
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.
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.
And the came the ESP32-C5 RISC-V IoT MCU which supports dual-band (!!) WiFi 6 (!), Bluetooth 5.0 LE…
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.
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.
[deleted]
What’s the power usage of this device? How long can it work connected to Wi-Fi on a small battery?
It would be awesome if it also supported zigbee and /or the new smart home standard “Matter”.
I don't have detailed data yet (thanks to a hospital stay when I was going to do power testing), but an informal test shows approximately 80 mA (@ 5.14v) under a WiFi / web page load test (from my review[1]).
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...
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...
Would you by any chance know of a similar board with Z-Wave or Zigbee?
One new model of the ESP32 does, though I don't think it's coming until later this year.
While a WiFi enabled Pico is incredible, I don't understand why they're still using Micro USB over USB-C in 2022. Is there any good reason for choosing one over the other?
Cost perhaps.
Probably under $0.05 difference - but when trying to hit $4 retail every cent matters.
A quick search on the supplier page I happen to have open right now puts the cheapest Micro B connector in stock at around $0.20 and the cheapest C at around $0.40 (both at factory MoQ). So the price difference still appears to be around x2.
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.
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.
Well, LCSC [0] has microB at around $0.02 [1] and USB-C (16 pin) at $0.05 [2]
[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...
[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...
I have a bunch of smaller, nicer Pico clones with USB-C ports. I expect the W to be cloned by Chinese manufacturers within the month.
I'm going to avoid RPI products where I can for right now. All the issues with availability have turned me off on them. Their attempts to get compute modules to businesses using them for products seems to have failed (or at least I have heard nothing from them). And this part in particular seems under specced compared to the competition.
> All the issues with availability have turned me off on them.
The Pico in particular has never had availability issues. Actually, it seems to have much better availability than most competing products.
The Pico in particular has never had availability issues. Actually, it seems to have much better availability than most competing products.
Yeah, the RP2040 has done quite well throughout the chip shortage. That's probably because it's too new to have commercial users (have you ever bought a product at a store that had a RP2040 in it?), but somewhat appreciated in a world where my go-to STM32 chips have an indefinite lead time.
As I understand, they are having much more trouble sourcing components for their Linux ARM machines than for their microcontroller hardware. Hence why they are launching so many Pico things this year - that's what they can get and sell.
What product do you recommend at a similar price point?
ESP32 products.
What's interesting with the ESP32 is that the Wifi stack on it consumes a huge amount of both memory and CPU... and it's faster and has more memory than the Pi Pico.
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.
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.
> 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.
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.
Let me know when they have a Zero 2 on sale in that store of yours, I'l take several.
The RP2040 is just over a dollar and there is nothing else of value on Pico so $4 retail is a bit low (typically you have 3-4x bill of material) but doable.
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
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
> So either they managed to make that more efficient somehow or you'll have exactly jack shit left after turning on wifi on it.
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 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 ESP32 wrover modules that come with 8M of PSRAM are pretty cost effective. 3-4$ in single part quantities is pretty good.
And I love that it has FreeRTOS built in. Makes multitasking so much easier.
The RP2040 has a PIO controller that can work independently and offload stuff off it’s cores. So performance can’t be compared directly.
Only PI SoC products have had availability issues, Pico microntrollers have been readily available in both individual pieces and in bulk.
So you’re dissing a new product because their former products aren’t readily available? That makes no sense.
It has more to do with the RPI people not communicating about their supply issues effectively and not being effective in working with customers to plan for them.
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.
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.
I'm curious of product support thread eg https://openthread.io/ and matter. As a further thought raspberry pi Pico w with thread might interfere with Wi-Fi networks. Consumer routers aren't built to handle large amounts of the Wi-Fi clients and IoT.
Why do you think it would interfere with WiFi? IoT devices are pretty widespread these days, and use minimal data. A single Youtube stream is going to use substantially more airtime than dozens of IoT devices.
It's not a new chip, it's the same RP2040 chip with a Cypress (now Infineon) CYW43439 WiFi controller. Which isn't available to buy in single quantities at costs $4.55 if you buy a reel of 5,000. So unfortunately it doesn't look like this will be able to compete with the ESP offerings for any sort of volume product.
> Like all modern Raspberry Pi boards, the radio circuitry is encapsulated in a metal shield can, reducing compliance costs for customers who want to integrate it into their own 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).
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).
$6? more like $60 coming to a scalper near you.
Unlike the SBCs that use BCM2711 or other larger chips, the Pico and Pico W are built on the RP2040, which has been in abundant supply for many months.
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.
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.
I just placed an order for a Pico W that, with tax and shipping, came out to around $15. Most places are capping the quantity to 1 for the moment.
You can get RP2040 based boards now for a handful of dollars. I've been working with a RP2040-zero (third party board) on an epaper side-project for the last few weeks.
They're a lot more plentiful than the mainstream Pi boards.
They're a lot more plentiful than the mainstream Pi boards.
The eternal question of people working on epaper projects: have the panels finally become reasonably priced?
I spent about $85 (AUD) on mine, it's a 5.83-inch tri-color (black/white/red), 648x480 display. For that much it came with the interface board so I could wire the display to my microcontroller easily enough.
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)
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)
Heh, it seems like affordable epaper and fusion energy are on the same plane of existence. Maybe one of them will become a reality in my lifetime.
The rp2040 isn't really in short supply, so no it probably is $6
Is Pico their attempt at breaking away from Broadcom?
I am still waiting some better IO connectors so I can connect an SSD to RPi.
I am still waiting some better IO connectors so I can connect an SSD to RPi.
I don't think so—the RP2040 has a couple very slow Cortex-M0 cores, and it's not anywhere near the capability of the BCM2711.
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.
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.
And if TSMC pushes them from 40nm to 28nm the M0+ cores and SRAM should scale to even higher clock rates without drawing too much power. While the RP2040 is "only" specified at up to 133MHz it has been reported stable at over twice that. From the scattered reports at least the AHB-lite bus matrix, SRAM and CPU cores are stable up to ~400MHz which more than compensates for the lower per clock throughput on anything but floating point heavy code.
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 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.
Uh some of us here in the "real" embedded world read the RP2040's specs (dual Cortex-M0+ cores clocked at 133 MHz, bare chip cost is $1) and go "uh there's a typo here, they put THREE digits in the clock speed hahaha".
Not really, but you get my point. For the kinds of devices the RP2040 competes with, it is not slow.
Not really, but you get my point. For the kinds of devices the RP2040 competes with, it is not slow.
The barrier to a PI SoC is the non CPU components - which are proprietary to companies like Broadcom. I’m sure that RPi could happily license an Arm core - indeed they have with the Pico - and the existence or otherwise of RISC-V cores is beside the point.
[deleted]
Why isn’t Bluetooth enabled? Bluetooth gives you a lot more flexibility in consumer provisioning of IoT devices (eg HomeKit, etc).
The whole thing xperience od unpaired devices broadcasting as a WiFi AP and having to join your phone to that SSID is clunky.
The whole thing xperience od unpaired devices broadcasting as a WiFi AP and having to join your phone to that SSID is clunky.
264kB of RAM? so you can't run linux on this, I guess?
Yes, this is for embedded devices like Arduino. You write firmware and load it into flash.
264K is plenty for many things you can do with that kind of device.
264K is plenty for many things you can do with that kind of device.
A bit low for Wifi stuff though isn't it? The ESP32 has 520KB and that's usually already somewhat limiting.
I don't know. I'm using the original Pico and not doing WiFi.
It's a microcontroller, not a single-board computer.
It's not meant to, but the Pico board comes with 8MiB of flash, so it is at least conceivable, even if not sensible, that someone gets Linux to run there (with a healthy dose of execute-in-place trickery).
But why? It (well, the Pico board at least) already runs Python ;^)
But why? It (well, the Pico board at least) already runs Python ;^)
The Pico comes with 2MB of flash rather than 8MB, but same idea, more or less. There are some 3rd party boards with 8MB. I suppose you could connect up an SD card via SPI for near-unlimited storage.
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...
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...
> We always believed that RP2040 was a great fit for commercial and industrial applications
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.
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.
Commercial and Industrial applications are one of the reasons they're so difficult to get your hands on at the moment - https://www.raspberrypi.com/for-industry/
Yes. I've seen at least one large HVAC controller (think the massive metal boxes on top of buildings) that ran on an RPi Compute module.
Yes. That is why they thinned things down with the compute module form factors.
https://www.raspberrypi.com/for-industry/
https://jfrog.com/connect/post/3-best-industrial-raspberry-p...
https://www.raspberrypi.com/for-industry/
https://jfrog.com/connect/post/3-best-industrial-raspberry-p...
Again you can’t buy it with $6 anywhere.
Sure you can, from the Pi Hut... where it's gonna be sold out in 24 hours and never go on sale again.
Right so far with sold out at pihut! Except still stock at https://shop.pimoroni.com/products/raspberry-pi-pico-w?varia...
Just bought it at my local pi reseller for exactly 7.2€ or 6 before vat
Awesome innovation and regardless of what is open and what is proprietary the key is that it is a platform enabling thousands of others, price point and accessibility is creating conditions for product market fit.
Actually, the MicroPython build for the Raspberry Pi Pico W has already been integrated into the CI pipeline:
https://micropython.org/download/rp2-pico-w/
https://micropython.org/download/rp2-pico-w/
[deleted]
>"Raspberry Pi Pico W is priced at $6, and brings 802.11n wireless networking to the Pico platform, while retaining complete pin compatibility with its older sibling."
A super-cheap WiFi Router -- could be made out of this...
A super-cheap WiFi Router -- could be made out of this...
Cheaper than $1? https://github.com/martin-ger/esp_wifi_repeater
Excellent link!
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!
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!
> Eagle-eyed readers of datasheets will notice that CYW43439 supports both Bluetooth Classic and Bluetooth Low-Energy: we have not enabled Bluetooth on Pico W at launch, but may do so in the future.
Why wait?
Why wait?
And delay the whole product launch until also the Bluetooth-stack has reached maturity?
My guess is either they're awaiting certification or the drivers aren't finished yet.
It's the latter—they didn't have time to finish up the software interface, but I've been told that's pretty much the next priority post-launch.
This is a bit of a pet peeve of mine, but arguably a lot of stuff in pico-playground or pico-extras is not finished and left as exercise for the reader. This is fine if you already know what you are doing but not so much when it's marketed as 'baby's first uC'.
> baby's first uC
Is it though? Seems to me the marketing, especially this announcement, pushes it for commercial users.
Is it though? Seems to me the marketing, especially this announcement, pushes it for commercial users.
From the 2021 press release:
"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...
"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...
> but arguably a lot of stuff in pico-playground or pico-extras is not finished
Arguably? They straight up say that the things in those repos are unfinished or otherwise not good enough for the SDK.
Arguably? They straight up say that the things in those repos are unfinished or otherwise not good enough for the SDK.
Yes, and the wording implies that as they mature they would be merged into the SDK. Yet 18 months after release there was nothing done save for some minor janitorial fixes. Not to mention the lack of any sort of documentation.
Pico does not have flash Protection/Lock.
This makes impossible to protect the firmware.
Almost every other uC has a feature to
disable reading of flash content.
Any comments on this?
How would you go about reading the flash (aside from doing so directly via QSPI)? The BOOTSEL mode is write-only from what I understand (and have observed).
You could always break into a program with the debugger (using the SWD interface), and load a program that reads data from the QSPI flash and dumps it to, say, a UART.
(I may be wrong here.)
Using Thonny IDE, I can just read
all Python scripts stored in QSPI Flash.
At least, I could not find how BOOTSEL will help here.
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?
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?
This is awesome.
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.
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.
How does this comparing to the ESP8266 families which is even cheaper, P2040 is taking the IoT space by storm.
[deleted]
I still can't understand why it took the Western world 8 years to produce an alternative to ESP8266.
I'm bored of Raspberry releasing endless minuscule and weak boards. I want a Raspberry Pi 5, like Pi 4 but with much more powerful CPU (so YouTube wouldn't be so slow - now the video plays OK but the UI is a pain) and IO (so I would be able to bit a multi-gigabit router+firewall+vpn on it).
Nevertheless, whatever they do is awesome anyway.
Nevertheless, whatever they do is awesome anyway.
It sounds like you don't want a raspberry pi?
Perhaps. I want something 100% compatible to Raspberry Pi (so it would support "hats" designed for the original Raspberry PI and also sun the original Raspberry PI OS, not the x86 clone) but way more powerful (for the reasons I mentioned - browsing the "modern" websites like YouTube without tears + networking). And no, mini-ITX won't fit in the place I need to put it.
Yeah, I find I am the opposite in that I don't want the Pi 4, think the Pi 3 is sort of the sweet spot for performance/price.
Pi Zero's have such wonky connectors....
Pi Zero's have such wonky connectors....
I wouldn't bank on a 5th edition Pi any time soon. The supply chain issues for the pi4 have meant stock shortages for months on end and it probably won't let up.
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
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
Yay, another useless 3.3 V microcontroller that needs a level shifter to do basically anything.
many i/o chips take 3.3V, especially for those with an I2C interface 3V3 ... 5V seems to be the norm. 5V only was 80s.
I just used a Pico in a project a couple weeks ago and didn't need to do any level shifting at all. I'm kinda shit at circuit design, though, so maybe I did something wrong lol
Many circuits take "3.3 - 5V" inputs, so a 3.3V driver will usually work... unless literally anything goes wrong.
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".
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".
Do you know of a chip that has 5V tolerance and ample GPIO? Needs to be ready to ship right now, and a $5 dev board would be nice.
The ESP32 has unofficial 5V tolerance on most pins so it can for example handle 5V serial with no problems (but can't output 5V of course), but my go-to is still the Arduino Nano for most things.
Yes, it wont interface directly with all the ECL circuits you keep in the basement.
That's not the primary mission of the Raspberry Pi Foundation, yes things change overtime but I think it would be a major mistake to make the Raspberry Pi into a product in a classical way ( even if a large chunk of their success is coming from "the market" )
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.
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.
> 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.
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.
With all those requirements, I don't think so.
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.
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.
What does power consumption look like? Is this useable for battery-powered applications?
I haven't done any measurements, but the non-W variety seems to last a pretty long time on a battery, even while powering a DAC and speaker at max gain.
if you can’t find it, there are Chinese “black pill” board with same or more amount of ram and optional flash storage.
It’s challenging to actually buy a Raspberry Pi these days unfortunately. All the official resellers are out of stock of all the other models and resellers have these on eBay for 3-4x the list price. Maybe this one will be in stock for longer…
The penalty for using linux & micropython in an embedded platform is enormous: power and performance with both will be inferior to a baremetal or RToS solution and C.
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).
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).
MicroPython is totally fine for initial prototyping or for slow embedded control.
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.
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 Pico doesn't run Linux. It does optionally run MicroPython or CircuitPython (I recently used the latter w/ a Pico for a friend's cosplay blaster pistol), but the C/C++ SDK is baremetal.
It seems to me that the Pico is what the pi should have been all along.
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.
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.
I'd say both of them missed the target by quite lot.
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.
[1] https://www.commanderx16.com/
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.
[1] https://www.commanderx16.com/
This is a really interesting comment with which I have a lot of sympathy but disagree in large part. I too yearn for an updated ‘home computer’ but with powerful modern hardware!
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.
https://geoffg.net/maximite.html
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.
https://geoffg.net/maximite.html
> But it doesn't really do much that you couldn't also do with a PC
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
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
I think this captures it. The key feature that differentiates the (non-pico) Pi from a desktop PC is the included GPIO header, and associated hardware buses. Price and size are also factors.
But you can drive display, there's libraries for driving a VGA monitor and add on boards. And you can also plug in a keyboard via usb
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
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
The pi is almost self contained.
The pico is a piece of e-waste without a proper computer to program it. So start wit the pi.
Could you go a little deeper into what you mean by this? What is a proper computer in this context? How standalone must an electronics device be to be valuable? Should all embedded devices be self-programmable?
I think they're just being snarky with the e-waste thing. The way you program a Pico is by plugging it into the USB port on another computer. Once programmed, it can run on battery power.
It's similar to Arduino boards. You can use Arduino or PlatformIO if you like, or alternately Micropython or CircuitPython.
It's similar to Arduino boards. You can use Arduino or PlatformIO if you like, or alternately Micropython or CircuitPython.
RPI Pico is irrelevant in my view.
Seriously checkout RISC-V equivalence (there are many, I like the ESP32-C3)
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.
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.
A microcontroller is a means to an end. When I need a CPU for an FPGA design, I will always use RISC-V because there's plenty of easy to integrate open source CPUs available. Similarly, when I need a hard microcontroller chip or board, I use whatever suits me best. And then I frankly don't care whether it's RISC-V or ARM. Why should I? I use what's available and has the right features.
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?
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?
Do you have any recommendations on how to learn about PIO? I’ve mostly been in the arduino world and got pretty comfortable with AVR features, now I’m writing micropython to control neopixels for a board called the Plasma2040 and instead of bitbanging the signal from a digital pin, it’s apparently generating the signal via PIO, but it’s all black magic to me.
This is a blog post of someone converting a conventional bit-banged method of driving a display to pure PIO. Maybe it helps getting an idea?
https://www.zephray.me/post/rpi_pico_driving_el/
https://www.zephray.me/post/rpi_pico_driving_el/
It is, at once, both over my head and very encouraging that someone who hasn’t used PIO before was able to achieve this, thanks for the link, I think if I compare this code to what the Plasma library is doing I might be able to tease out what’s happening.
Did you have a look at chapter 3 of the Raspberry Pi Pico C SDK already by the way? It's about PIO programming.
https://www.raspberrypi.com/documentation/microcontrollers/c...
https://www.raspberrypi.com/documentation/microcontrollers/c...
I did not notice they wrote a whole book on the SDK, this looks perfect, thanks again
The C SDK contains examples, the actual documentation is in the RP2040 docs. It's also chapter 3.
https://www.raspberrypi.com/documentation/microcontrollers/
https://www.raspberrypi.com/documentation/microcontrollers/
Chapter 3 of the RP2040 datasheet is all about PIO, but it may not be the best wy to learn: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
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....
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....
Hey I managed to miss that raspberrypi repo since I jumped straight into my neopixel project, many thanks
I don't know how you can say it's irrelevant. Multiple standards can exist concurrently. Not even because they deserve to, but because people like them and are comfortable with them even if they are or aren't a bit crappy.
Also the RP2040 is a great chip and it's super available and it's super cheap. And it runs Rust.
Also the RP2040 is a great chip and it's super available and it's super cheap. And it runs Rust.
Ditch arm, skip RPI, ignore STM-32, and scoff at TI, .. RISC-V is the future.
Can you point to any parts that are in full production and have a 5-7 year supply horizon?
Can you point to any parts that are in full production and have a 5-7 year supply horizon?
Since I like to build custom electronics using JLCPCB, I went on there and looked for RISC-V chips. I found the ESP32-C3 and a dozen or so Chinese chips that seemed to only have Chinese datasheets. It seems that things are still pretty immature in RISC-V adoption. I will be getting a ESP32-C3 dev board to tinker with at least.
The projects I work on need long time horizons and industrial or automotive environmental specs. RISC-V will be hardware cosplay (h/t n-gate!) until that time, as far as I can see it.
I just built a keyboard based on the RP2040 because it's cheap, capable, obtainable, and you can also write rust for it. The RP2040 is interesting though with its PIO peripheral.
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
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
Thanks for the recommendation on ESP32-C3. I've been wanting to work with a cheap RISC-V chip. Unfortunately the lead time on mouser is 9 weeks and it only offers 22 GPIO.
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.
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.
[deleted]
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.