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:
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."
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.
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.
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.
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):
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.
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.
>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.
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.
>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.)
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.
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.
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.
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.
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'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.
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.
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).
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.
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)!
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.
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.
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.
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.
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.
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.
>"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...
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...
> 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.
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)
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
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".
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.
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.
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.
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).
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.
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
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.
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.
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?
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.
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.
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 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.
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
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.
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.