> 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.
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'.
"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."
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.
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.
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.
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.
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.
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)
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.
If I understand it correctly, it uses the closed-source library libcyw43 from MicroPyton to communicate with the hardware chip.
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:
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.
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.
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.
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):
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.
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.
>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...
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."
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.
> 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.
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.
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.
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.
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)!
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.
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.
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.
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.
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.
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.
> 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
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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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
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.
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".
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.
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.
>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.)
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.
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.
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 ;^)
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.
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.
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.
> 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 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.
> 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.
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.
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.
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.
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)
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…
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?
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.
203 comments
[ 1.8 ms ] story [ 239 ms ] threadWhy 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.
That right there is one of those cheap screens, right?
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):
https://yo3iiu.ro/blog/?p=1301
https://www.merriam-webster.com/dictionary/eventuate
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.
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)
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.
[1] https://www.commanderx16.com/
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
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
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 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.
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...
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.
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.
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.
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.
https://micropython.org/download/rp2-pico-w/
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...
The whole thing xperience od unpaired devices broadcasting as a WiFi AP and having to join your phone to that SSID is clunky.
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.
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?
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...
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.