First Impressions with the Raspberry Pi Zero 2 W(blog.alexellis.io)
blog.alexellis.io
First Impressions with the Raspberry Pi Zero 2 W
https://blog.alexellis.io/raspberry-pi-zero-2/
80 comments
My dream device for clustering is dual core 1Ghz+, 1GB ddr4 (ddr3 in a pinch) and wired Gb ethernet. In bulk (where bulk ~ 100) price $5-10. Some of the allwinner and rockchip based pi clones get close but price is a lot more.
You can hit this now with the CM4 modules,
For qty 1 @ $30 you get 2GB and 4 cores, you could put 2 more ethernet ports on the PCIe port for a total of 3. That gets you into the same-ish performance regime.
I am all for aggregates of low end compute, but I think something with more processing power and more PCIe lanes would scale better.
https://www.digikey.com/en/products/detail/raspberry-pi/SC02...
For qty 1 @ $30 you get 2GB and 4 cores, you could put 2 more ethernet ports on the PCIe port for a total of 3. That gets you into the same-ish performance regime.
I am all for aggregates of low end compute, but I think something with more processing power and more PCIe lanes would scale better.
https://www.digikey.com/en/products/detail/raspberry-pi/SC02...
Availability is a Real Issue, tho. 16-week leadtime on that URL.
16 weeks will come sooner than you realize. For other parts I need, I am seeing 40-60 week lead times.
You don’t ask for much ;)
Just a question on pi clustering in general. Is there an advantage vs buying a single more powerful computer, or a few powerful machines instead of a dozen+ pis?
The big difference is number of cores you have to work with, and to a lesser extent the amount of RAM. For say 800€ you can get probably a 4 core CPU, maybe 8. I guess 8GB RAM? Or you can get 10 raspberry pi 4s for a total of 40 cores and 40GB RAM.
What makes more sense for you will depend on your workload and scaling requirements.
What makes more sense for you will depend on your workload and scaling requirements.
Nope, you build a RPI cluster for the sake of it.
Isn't this more of question on redundancy, ie: "two is one and one is none"? RPi's aren't technically best known for general purpose usage.
[deleted]
Thanks for your RPi content Alex. Even though I'm not really active in the space, I still enjoy reading/watching about what's going on.
Does anyone else have feelings about “there’s too many tiers of Pi” yet?
I’m not sure if I feel that but it’s on my mind.
I’m not sure if I feel that but it’s on my mind.
Not really, but that's because I largely dismiss the early Pis altogether. They sit in the awkward space where they're larger and faster than a microcontroller but practically speaking require an OS that wastes a lot of the available resources; for running Linux applications, they feel way underpowered. Pi 3 seemed powerful enough to be interesting and I did a small project with it, but Pi 4 pushes it to where I'm actually starting to like the platform (though I'm still anxious for a Pi 5).
Now with the Zero 2 W, there are three tiers: the Pi 4 for SBCs, Zero 2 W for providing connectivity for things that don't really look like computers as such (but still need Linux for whatever reason?), and then the Pico for microcontroller projects. The difference in capabilities between each tier is large; they cover a wide spectrum of use cases. You can't complain that there are too many tiers.
It's good to know that you can fall back to the older Pis if you have very specific/niche needs that they fulfill better than the new ones, but you'll know it when you need them, and having these extra choices doesn't hurt.
If you don't have very specific requirements, just pick the most appropriate of the three new ones. Easy.
I guess I'm also disregarding the compute module, because I haven't seen particularly compelling reason to look at it. Again I guess if you have very specific needs and can design a carrier board for it, have a go at it. Otherwise, ignore.
Now with the Zero 2 W, there are three tiers: the Pi 4 for SBCs, Zero 2 W for providing connectivity for things that don't really look like computers as such (but still need Linux for whatever reason?), and then the Pico for microcontroller projects. The difference in capabilities between each tier is large; they cover a wide spectrum of use cases. You can't complain that there are too many tiers.
It's good to know that you can fall back to the older Pis if you have very specific/niche needs that they fulfill better than the new ones, but you'll know it when you need them, and having these extra choices doesn't hurt.
If you don't have very specific requirements, just pick the most appropriate of the three new ones. Easy.
I guess I'm also disregarding the compute module, because I haven't seen particularly compelling reason to look at it. Again I guess if you have very specific needs and can design a carrier board for it, have a go at it. Otherwise, ignore.
> They sit in the awkward space where they're larger and faster than a microcontroller but practically speaking require an OS that wastes a lot of the available resources; for running Linux applications, they feel way underpowered.
The Raspberry Pi isn't competing with a microcontroller. They're on opposite ends of the computing spectrum. If an application can be quickly developed and run on a microcontroller, using a full embedded Linux system would be overkill.
As for Linux work: The Raspberry Pi 4 is plenty fast for most embedded applications. If you're trying to use it as a desktop replacement it's going to feel sluggish relative to an actual desktop, especially if you're only using an SD card instead of a USB3 SSD. However, it's generally not a problem for most non-desktop use cases.
Compiling large projects is the only place where a Pi 4 starts to feel limited, but cross-compilation is available with plenty of guides online.
If you have a situation that requires more power than a Pi 4, you should probably be using a real desktop or VM anyway. These are embedded systems that start at $35, not something competing with a $500 NUC or a $2000 laptop.
The Raspberry Pi isn't competing with a microcontroller. They're on opposite ends of the computing spectrum. If an application can be quickly developed and run on a microcontroller, using a full embedded Linux system would be overkill.
As for Linux work: The Raspberry Pi 4 is plenty fast for most embedded applications. If you're trying to use it as a desktop replacement it's going to feel sluggish relative to an actual desktop, especially if you're only using an SD card instead of a USB3 SSD. However, it's generally not a problem for most non-desktop use cases.
Compiling large projects is the only place where a Pi 4 starts to feel limited, but cross-compilation is available with plenty of guides online.
If you have a situation that requires more power than a Pi 4, you should probably be using a real desktop or VM anyway. These are embedded systems that start at $35, not something competing with a $500 NUC or a $2000 laptop.
> The Raspberry Pi isn't competing with a microcontroller. They're on opposite ends of the computing spectrum.
The spectrum is wider than that, but if you're comparing Pi and MCUs, today you have 32 bit multi-core ARM microcontrollers that run at hundreds of MHz and make a 486 look wimpy. And for a microprocessor, the first gen Pi is pretty darn wimpy (wikipedia compares it to a 300MHz Pentium II). Yet the performance difference between a first gen Pi and a Pi 4 is absolutely massive.
That's what I mean by the awkward space. Yes it's still faster than a high end microcontroller, but if I need an application running on modern Linux, chances are I don't want to deploy it on Pentium II class hardware except in very niche circumstances. So it's neither a microcontroller, nor is it a decent microprocessor for modern OS. It's about right in the middle of the spectrum where it kinda sucks for any application that can be implemented on a microcontroller and sucks for anything that needs a "real computer".
I need to point out that I actually work as an embedded software developer in this space where we have high end microcontrollers running a custom RTOS and applications that offer largely the same functionality and interfaces that we also implement using low end Linux-capable ARM solutions; what you can implement on a microcontroller is a heck of a lot, but Linux capable chips have gotten cheap and using them sometimes saves development effort on the driver & application stack. There's plenty of overlap, they're totally not opposite ends of the spectrum.
The spectrum is wider than that, but if you're comparing Pi and MCUs, today you have 32 bit multi-core ARM microcontrollers that run at hundreds of MHz and make a 486 look wimpy. And for a microprocessor, the first gen Pi is pretty darn wimpy (wikipedia compares it to a 300MHz Pentium II). Yet the performance difference between a first gen Pi and a Pi 4 is absolutely massive.
That's what I mean by the awkward space. Yes it's still faster than a high end microcontroller, but if I need an application running on modern Linux, chances are I don't want to deploy it on Pentium II class hardware except in very niche circumstances. So it's neither a microcontroller, nor is it a decent microprocessor for modern OS. It's about right in the middle of the spectrum where it kinda sucks for any application that can be implemented on a microcontroller and sucks for anything that needs a "real computer".
I need to point out that I actually work as an embedded software developer in this space where we have high end microcontrollers running a custom RTOS and applications that offer largely the same functionality and interfaces that we also implement using low end Linux-capable ARM solutions; what you can implement on a microcontroller is a heck of a lot, but Linux capable chips have gotten cheap and using them sometimes saves development effort on the driver & application stack. There's plenty of overlap, they're totally not opposite ends of the spectrum.
> very niche circumstances
Which happens to be exactly where the pi excels. I'm currently writing an application to record my homebrew information and also capture basic sensor data. A PC + arduino/sensor platform would be overkill and an ESP8266/ESP32 would slow me down.
Pi 2B running PHP? Perfect.
Which happens to be exactly where the pi excels. I'm currently writing an application to record my homebrew information and also capture basic sensor data. A PC + arduino/sensor platform would be overkill and an ESP8266/ESP32 would slow me down.
Pi 2B running PHP? Perfect.
In end-user space, Pi has a bunch of good niches:
* There's an application that runs on Linux already and you want a cheap way of running it in a small space -- like a shairport-sync audio client feeding a local music system, or a web-connected clock/calendar/tasklist/notification.
* Very low cost, replaceable desktop for a kiosk, a classroom, whatever where it will run either simple office applications or be mostly a web terminal. (If you just want low cost, a used laptop might be a better value -- but if you need to be able to repeat and/or replace it, a Pi is better).
* Friendly target for someone who doesn't really understand embedded systems and will be tinkering for a long time.
* There's an application that runs on Linux already and you want a cheap way of running it in a small space -- like a shairport-sync audio client feeding a local music system, or a web-connected clock/calendar/tasklist/notification.
* Very low cost, replaceable desktop for a kiosk, a classroom, whatever where it will run either simple office applications or be mostly a web terminal. (If you just want low cost, a used laptop might be a better value -- but if you need to be able to repeat and/or replace it, a Pi is better).
* Friendly target for someone who doesn't really understand embedded systems and will be tinkering for a long time.
The first product I ever shipped with a Pi was a controller that needed a nice UI and some data storage. For a one-off, the $35 cost for a Pi2 probably saved at least $1,000 in dev cost than if I were to throw a microcontroller at the problem.
There are some game servers implemented using RPi, specially in open source games.
> for running Linux applications, they feel way underpowered
I think that's because the Raspberry Pi's might be best used as tiny consumer servers, not desktop (or embedded) computers. They seem perfect for running things that require an OS and a moderate amount of processing power - say, DNS, Syncthing, audio streaming, ssh tunnel point, a VPN, a small personal (static) website, or a NAS that doesn't have particularly high performance requirements.
So, Linux "applications" but not in the sense of Firefox, or other interactive GUI programs.
(this ignores the lower barrier to entry that they have than actual microcontrollers, which is a different kind of use-case)
I think that's because the Raspberry Pi's might be best used as tiny consumer servers, not desktop (or embedded) computers. They seem perfect for running things that require an OS and a moderate amount of processing power - say, DNS, Syncthing, audio streaming, ssh tunnel point, a VPN, a small personal (static) website, or a NAS that doesn't have particularly high performance requirements.
So, Linux "applications" but not in the sense of Firefox, or other interactive GUI programs.
(this ignores the lower barrier to entry that they have than actual microcontrollers, which is a different kind of use-case)
Yep. I use them in headless robotics applications and they always seem fast. And then I have an 8GB unit as a media server at home and it feels sloooowwwww. Loading a video in chrome takes forever but they’re really good at running my Python robotics stack in docker!
A pi2b lives under my desk and runs a discord bot, pihole and database. Now that I've learnt docker im tempted to go back and containerize everything on it
In the always-on space where it is rather energy inefficient to run normal hardware.
I think the later Pi 3 models are still fine; they're a little slower (CPU and IO), but they're cheaper than the 4 while still running 64-bit ARM and being reasonable capable. I would agree that unless you have existing stuff to replace in place the Pi 1 and 2 are irrelevant today:)
This is the first time I'm hearing of the Pico. Is there any reason to use it, instead of the ESP32 or ESP8266 boards, or one of the many Arduino compatible uC's?
The competitors seem to be much more common than the Raspberry Pico (i.e. it is much easier to find expansion boards, examples etc. for them). They seem to cost roughly the same too, and the ESPs even include WiFi and in the case of the ESP32 even Bluetooth, which makes interfacing with them so much easier.
I'm kinda surprised they released that. The RPi was awesome because it was the first mass-produced SBC (making it both affordable and well documented/supported). There are many competitors, but none so universal and common. With microcontrollers, I don't see any unique selling point, nothing that could get them to that position.
The competitors seem to be much more common than the Raspberry Pico (i.e. it is much easier to find expansion boards, examples etc. for them). They seem to cost roughly the same too, and the ESPs even include WiFi and in the case of the ESP32 even Bluetooth, which makes interfacing with them so much easier.
I'm kinda surprised they released that. The RPi was awesome because it was the first mass-produced SBC (making it both affordable and well documented/supported). There are many competitors, but none so universal and common. With microcontrollers, I don't see any unique selling point, nothing that could get them to that position.
I don't see any real killer (technical) feature. But I think that's always been the case for the Raspberry products: you could always get the same (and often better) features in other boards (though this may be less true as of the Pi4 which actually was and still is very competitive in the SBC market).
The Raspberry Pi was developed for teaching, as a low cost board that's easy to work with and that has good community support. It wasn't intended to be the most advanced board for your projects, and you could always find something cheaper if you really wanted and didn't mind the hassle..
The Pico is very similar. You get it for less than 5 eur from official distributors in Europe, you plug it in and it shows up as a USB mass storage device onto which you drop your program and off you go. I can see it being a very popular way to get started with microcontrollers, and just like Arduino, that popularity is not a function of features.
I'm curious to see where they take it though. It's their first in-house chip afaik, and the board is rather bare. I wouldn't be surprised if they release variants with more features.
The Raspberry Pi was developed for teaching, as a low cost board that's easy to work with and that has good community support. It wasn't intended to be the most advanced board for your projects, and you could always find something cheaper if you really wanted and didn't mind the hassle..
The Pico is very similar. You get it for less than 5 eur from official distributors in Europe, you plug it in and it shows up as a USB mass storage device onto which you drop your program and off you go. I can see it being a very popular way to get started with microcontrollers, and just like Arduino, that popularity is not a function of features.
I'm curious to see where they take it though. It's their first in-house chip afaik, and the board is rather bare. I wouldn't be surprised if they release variants with more features.
Good documentation and the killer feature is the PIO. (Programmable I/O unit)
> but practically speaking require an OS that wastes a lot of the available resources
They don't actually require that, but that's what we usually end up doing. That's a choice though, and there are alternatives, they're just a lot of work.
They don't actually require that, but that's what we usually end up doing. That's a choice though, and there are alternatives, they're just a lot of work.
Yes, I think there are too many. Everyone tends to go for the latest and greatest. The Pi is heading towards becoming a PC replacement, but I'm not sure what advantage that is.
Instead of have faster computers, I want a faster OS. Or preferably very little in the way of an OS. Something like a DOS, perhaps. Something where you could write blazingly-fast software because the kernel is straightforward. And I want a real-time kernel.
I'm vaguely aware that there's some stuff out there, like RTEMS and a real-time Linux, but I suspect it's all a pain to set up.
I've played around with writing my own "kernel" - but it's more in the style of a "unikernel" - which is a pretty good approach.
The real problem occurs when you want to use the USB. A USB stack is not easy to implement. I also had the SD card working, but I haven't been able to get it working lately.
I would like to see Pis flourish as a way of implementing Operating Systems, but the hardware is too complex.
Maybe some kind of Pico/Pi hybrid might be feasible. That might sound an insane suggestion, but Ebon has mentioned in the past that a combo of a Pi with a microcontroller is a good one. Why not take this idea to its logical conclusion and put both on the same board?
Instead of have faster computers, I want a faster OS. Or preferably very little in the way of an OS. Something like a DOS, perhaps. Something where you could write blazingly-fast software because the kernel is straightforward. And I want a real-time kernel.
I'm vaguely aware that there's some stuff out there, like RTEMS and a real-time Linux, but I suspect it's all a pain to set up.
I've played around with writing my own "kernel" - but it's more in the style of a "unikernel" - which is a pretty good approach.
The real problem occurs when you want to use the USB. A USB stack is not easy to implement. I also had the SD card working, but I haven't been able to get it working lately.
I would like to see Pis flourish as a way of implementing Operating Systems, but the hardware is too complex.
Maybe some kind of Pico/Pi hybrid might be feasible. That might sound an insane suggestion, but Ebon has mentioned in the past that a combo of a Pi with a microcontroller is a good one. Why not take this idea to its logical conclusion and put both on the same board?
STM32MP1 is a good example of your hybrid idea - it combines a Cortex A7 Linux application-side stack with an STM32 Cortex-M4 based microcontroller on the same SoC.
This is very useful for running hard realtime tasks on the microcontroller and "control" / GUI / application-stack intensive tasks on the Linux side, as you suggest.
With that said, all this does for toy OS development is makes it more complicated.
I think what you are looking for for your use cases might really be just an RTOS on a microcontroller with some provided driver blocks. Take a look at ESP32 as well :)
This is very useful for running hard realtime tasks on the microcontroller and "control" / GUI / application-stack intensive tasks on the Linux side, as you suggest.
With that said, all this does for toy OS development is makes it more complicated.
I think what you are looking for for your use cases might really be just an RTOS on a microcontroller with some provided driver blocks. Take a look at ESP32 as well :)
Thanks for posting that!
On the table next to me I have a system that's comprised of a SOM running Linux for a UI and an STM32 for real-time control. They talk over a serial port. I didn't realize that ST had combined the two. That's definitely useful information!
On the table next to me I have a system that's comprised of a SOM running Linux for a UI and an STM32 for real-time control. They talk over a serial port. I didn't realize that ST had combined the two. That's definitely useful information!
Is there anything fundamental in pi hardware that prevents putting a real time OS on it? (I'm not a hardware engineer)
How do you define "real-time"?
The Broadcom CPUs in the RPis have unpredictable pauses to let the GPU refresh the RAM (really). That makes them unsuitable for hard real-time applications where you must service an interrupt within a certain time, or emit a signal on a strict deadline, etc.
They're just fine for soft real-time applications where some jitter is acceptable, but what counts as "soft" real-time versus "not-at-all" real-time is the subject of some debate.
The Broadcom CPUs in the RPis have unpredictable pauses to let the GPU refresh the RAM (really). That makes them unsuitable for hard real-time applications where you must service an interrupt within a certain time, or emit a signal on a strict deadline, etc.
They're just fine for soft real-time applications where some jitter is acceptable, but what counts as "soft" real-time versus "not-at-all" real-time is the subject of some debate.
Not at all. It's just that writing drivers and supporting all the peripherals is a massive undertaking (even Linux is often way behind on support -- chips that came out years ago might have poor or no support for some peripherals and the only support you find is in some vendor fork of an ancient android kernel).
There's also the fact that compared to PCs, ARM boards are kinda special snowflakes. DOS could boot and run on thousands of different machines ("IBM PC compatible") from different manufacturers, in part thanks to BIOS abstracting out some of the core peripherals, in part thanks to (de-facto) standard peripherals. Your custom ARM OS? Well, it won't boot on the next board. UEFI is sort of changing that, but really it pushes the problem to the bootloader (until they start implementing UEFI in firmware).
In a way, I actually prefer not having to rely on BIOS or UEFI, because that protects me from stupid implementations and allows me to customize things. And on the other hand, if you want high performance drivers for modern peripherals, you probably don't want to rely on a firmware abstraction for it (but it'd still be nice to be able to boot and get a shell & some basic I/O going even without hardware specific drivers). But that means you do need drivers in your OS, and as long as chips keep changing as often as they do, it's a never-ending battle to stay on top of driver support.
PCs also gave you a nice escape hatch in that you'd plug in your peripherals to a slot and you could choose parts that you have drivers for. That's not really the case for laptops of course, and ARM SoCs integrate most of the peripherals so if you get a new chip, you get new everything.
There's also the fact that compared to PCs, ARM boards are kinda special snowflakes. DOS could boot and run on thousands of different machines ("IBM PC compatible") from different manufacturers, in part thanks to BIOS abstracting out some of the core peripherals, in part thanks to (de-facto) standard peripherals. Your custom ARM OS? Well, it won't boot on the next board. UEFI is sort of changing that, but really it pushes the problem to the bootloader (until they start implementing UEFI in firmware).
In a way, I actually prefer not having to rely on BIOS or UEFI, because that protects me from stupid implementations and allows me to customize things. And on the other hand, if you want high performance drivers for modern peripherals, you probably don't want to rely on a firmware abstraction for it (but it'd still be nice to be able to boot and get a shell & some basic I/O going even without hardware specific drivers). But that means you do need drivers in your OS, and as long as chips keep changing as often as they do, it's a never-ending battle to stay on top of driver support.
PCs also gave you a nice escape hatch in that you'd plug in your peripherals to a slot and you could choose parts that you have drivers for. That's not really the case for laptops of course, and ARM SoCs integrate most of the peripherals so if you get a new chip, you get new everything.
The different options are definitely appreciated.
The default choice should be the base model Raspberry Pi 4. The other options (compute module, Zero, higher RAM versions) are for specialized needs. Even if you’re using the Zero or Compute Module you probably want the normal Raspberry Pi 4 around for development.
The default choice should be the base model Raspberry Pi 4. The other options (compute module, Zero, higher RAM versions) are for specialized needs. Even if you’re using the Zero or Compute Module you probably want the normal Raspberry Pi 4 around for development.
Same. If you're shopping for a ras-pi, I think you're already in the market of people that are ok researching many models to find one that matches your use case best.
It's different from, say, apple having 10 different types of mac books each for slightly different use cases.
It's different from, say, apple having 10 different types of mac books each for slightly different use cases.
What baffles me is the rather bad availability of older versions.
I'd have guessed that there's somewhere a warehouse full of Pi Zero Ws, but I can't buy one right now in Germany. There's a shop in Switzerland, but I'd have to pay import taxes and whatnot to get hold of that.
So, let's try a Model 3 B+ then... Same as before: Official vendors are almost all sold out, one has some but it's 15 to 20 Euro above the recommended price...
Something's broken in the reselling system if you ask me.
I'd have guessed that there's somewhere a warehouse full of Pi Zero Ws, but I can't buy one right now in Germany. There's a shop in Switzerland, but I'd have to pay import taxes and whatnot to get hold of that.
So, let's try a Model 3 B+ then... Same as before: Official vendors are almost all sold out, one has some but it's 15 to 20 Euro above the recommended price...
Something's broken in the reselling system if you ask me.
It says on the official Raspberry Pi website:
Are you discontinuing Zero and Zero W?
No. We seldom discontinue products, even where they have been superseded by more modern product at the same price point. Zero 2 W is $5 more expensive than Zero W, and joins the Zero family as a third member.
Note that Zero and Zero W are currently experiencing supply constraints in the context of the global semiconductor shortage. We hope that this will be resolved in 2022.
Are you discontinuing Zero and Zero W?
No. We seldom discontinue products, even where they have been superseded by more modern product at the same price point. Zero 2 W is $5 more expensive than Zero W, and joins the Zero family as a third member.
Note that Zero and Zero W are currently experiencing supply constraints in the context of the global semiconductor shortage. We hope that this will be resolved in 2022.
In case you didn’t hear, there is a global supply chain crisis and a chip shortage.
> So, let's try a Model 3 B+ then... Same as before: Official vendors are almost all sold out, one has some but it's 15 to 20 Euro above the recommended price...
An econ student would probably tell you that this is the market adjusting (or trying to) against the official price not matching the supply/demand intersection, so they're only available at the "real" price that unofficial vendors provide. (Of course, it may be more complex than that simplistic reading, hence econ student :])
An econ student would probably tell you that this is the market adjusting (or trying to) against the official price not matching the supply/demand intersection, so they're only available at the "real" price that unofficial vendors provide. (Of course, it may be more complex than that simplistic reading, hence econ student :])
The PI is almost always sold off, since the first version. Availability has always been low.
What you are seeing is probably because the 3B+ is the most sold version, and replenishing anything is slightly harder right now.
What you are seeing is probably because the 3B+ is the most sold version, and replenishing anything is slightly harder right now.
if you don't mind a soldered-on header then berrybase seems to have plenty of Pi Zero WHs
I prefer the WH, unless you have serious space constraints, soldering your own is a little fiddly.
Not really: the pico is in the mcu space, compute module for industrial projects, pi4 as large sbc, and pi zero as small sbc. Seems like a good range. I think the least differentiated are the pi4 and pi zero but there's still a big difference when you think about applications (e.g. trying to stick a pi4 in a diy smart speaker or multiple VMs).
IMHO, the relevant ones are 3B+, 4B+ and zero. The zero comes on many forms, but if you are using it, their difference should be clear enough.
For random stuff you do once, if you need a powerful computer (weak-desktop-like) with great IO, you go with 4. If you need great IO on a weak normal computer, you go with the 3. If you need a powerful-desktop-like computer, you go with AMD64, and if you only need great IO and not much of a computer, an Arduino.
The zero goes on things that you will do many times or that have very specific constraints.
For random stuff you do once, if you need a powerful computer (weak-desktop-like) with great IO, you go with 4. If you need great IO on a weak normal computer, you go with the 3. If you need a powerful-desktop-like computer, you go with AMD64, and if you only need great IO and not much of a computer, an Arduino.
The zero goes on things that you will do many times or that have very specific constraints.
I don't know about too many tiers, but they've certainly run out of sensible naming ideas.
Who the hell signs off naming a product 'Zero 2' let alone the 'Zero 2 W' ?
Who the hell signs off naming a product 'Zero 2' let alone the 'Zero 2 W' ?
It's becoming like USB version names. If you're familiar with them from working with them all regularly, you can just remember what name means what. But for newcomers, it's a massive struggle. I feel that naming things in general imposes a lot of cognitive burden on people. Chrome version numbers are beautiful. Just incrementing integers, the way we numbered things as kids.
I wonder if the naming mess is intentional for marketing or an accident of not predicting the future well enough? They certainly seem to be trying to keep it simple and it's nowhere near the impossible muddle of, say, Intel and AMD CPUs or Nvidia GPUs yet.
I wonder if the naming mess is intentional for marketing or an accident of not predicting the future well enough? They certainly seem to be trying to keep it simple and it's nowhere near the impossible muddle of, say, Intel and AMD CPUs or Nvidia GPUs yet.
I wouldn't say so. RPi doesn't discontinue products, but it doesn't really make sense to buy most older models.
In practice there are 4 RPi's: the Zero (5$ is hard to beat), the Zero 2 W (small, cheap, with WiFi) and the 4 Model B.
Then there is the Pico, but it is a microcontroller, a completely different product, and the CM4, for large scale deployments.
In practice there are 4 RPi's: the Zero (5$ is hard to beat), the Zero 2 W (small, cheap, with WiFi) and the 4 Model B.
Then there is the Pico, but it is a microcontroller, a completely different product, and the CM4, for large scale deployments.
I also like the 3 A+ for an inbetween Zero 2 W and 3/4. Don't need a USB OTG adapter you'd need for a Zero, and not as big as the 4.
The idea of using it as a self-hosted Github Actions runner spoke to me. I wouldn't have thought of that. Thank you!
Personally, I'd prefer to get a standard Raspberry Pi 4 model for any server-like duties. Get the 8GB RAM model and it's easy to run a lot of virtual machines on it for all of your different mini-server needs on a single device.
Managing a lot of different little Pis for different server-like things is fun for experimenting with clustering and multi-server management tools, but it gets old fast if you really just want several different VMs or containers.
VMWare ESXi is even available for the Raspberry Pi now: https://www.servethehome.com/getting-started-with-vmware-esx...
Managing a lot of different little Pis for different server-like things is fun for experimenting with clustering and multi-server management tools, but it gets old fast if you really just want several different VMs or containers.
VMWare ESXi is even available for the Raspberry Pi now: https://www.servethehome.com/getting-started-with-vmware-esx...
>VMWare ESXi is even available for the Raspberry Pi now
Wow, thanks, I'll definitely be checking that out
Wow, thanks, I'll definitely be checking that out
Don't blame me. The idea came from Martin Woodward (from GitHub) and I was surprised how I had it up and running, executing builds in a few minutes.
What kinds of things would you run with yours? Maybe you could use a GitHub action to trigger IoT lights on and off.
What kinds of things would you run with yours? Maybe you could use a GitHub action to trigger IoT lights on and off.
I use Github Actions mostly for automatically publishing my website when I change its content. But I haven't fully set up my build pipeline to my liking. And getting logs and stuff when the pipeline goes sideways isn't very easy right now with Github Actions. If I hosted my own running, at least I could poke around my build environment to see why it failed until I have it running reliably enough to let the cloud handle it.
That's a long-winded way to say: debugging.
That's a long-winded way to say: debugging.
Raspian still relies on inferior wifi management. You have to replace with network-manager to get it to connect to Enterprise wifi. Is there any specific reason why it's not the default?
Probably because SystemD network management is harder to use on a headless install. With a Raspberry Pi you just need to edit a couple of lines in the boot.conf to have it connect to WiFi on boot.
You can deploy one without ever plugging in a keyboard or monitor.
You can deploy one without ever plugging in a keyboard or monitor.
How do you edit boot.conf without a keyboard or monitor?
Mount the sd card elsewhere, the boot partition is FAT formatted and can be edited on most OSes.
you pre-configure the boot.conf and other settings on the same system you use to write the raspbian image onto the microSD card, before you put it in the pi. if you get the config right you should be able to boot a pi headless and ssh to it over your 802.11n/ac/ax network immediately after the first time it powers up.
This question is so apt that it gave me a chuckle. I've done it before, but I had to think about that one for a second. You have to edit the file while the SD card is plugged into a separate computer.
it's on a FAT partition, you can edit it by plugging the sd card into something else
Well that's stock on both Debian and Ubuntu still, right? It's more of a question why they haven't replaced it either.
Been a while since I've used Debian but I'm sure Debian is already using NetworkManager. This means the Raspberry OS has actually removed NetworkManager from its Debian base and put in something else. I agree with the OP this shouldn't happen. For my Raspberry Pi, I ended up switching out the Raspberry Pi OS' default networking manager thingy in preference for NetworkManager so I could share wireless networking configuration among my devices. It also helps with troubleshooting as well since I can just use the same commands I use on other Linux machines even those running other distros.
It’s not.
How are people dealing with subpar SD card storage option which is guaranteed to fail if there are ANY consistent writes?
Why don't they add M.2 port?, it would instantly make Pi lot more reliable.
Why don't they add M.2 port?, it would instantly make Pi lot more reliable.
I've switched to only buying SD cards from AAA+ platinum-rated photography websites (B&H, Adorama), they seem to be the only reliable places to buy non-counterfit SD cards these days. I've never had an issue with an SD card since I made this shopping change. Shipping and price are about 10% higher, but guaranteed quality product is worth it.
If you buy your SD cards from Amazon or Ebay you can't guarantee quality for these products.
If you buy your SD cards from Amazon or Ebay you can't guarantee quality for these products.
What SD brands do you usually buy? Are the Sandisk Extreme range any good?
Sandisk, Lexar, Prograde. Depends on the application.
My raspberry pi doesn't do many disk operations so the speed isn't critical and 90 MB/s is plenty. My digital camera, on the other hand, has dual SD card slots, and can record uncompressed(!) 10 bit 4k video @ 60fps but needs 2 x 400 MB/s continuous write, which is... a pretty specific need. And cost accordingly.
My raspberry pi doesn't do many disk operations so the speed isn't critical and 90 MB/s is plenty. My digital camera, on the other hand, has dual SD card slots, and can record uncompressed(!) 10 bit 4k video @ 60fps but needs 2 x 400 MB/s continuous write, which is... a pretty specific need. And cost accordingly.
I find Samsung much more reliable than Sandisk in my pis
Sandisk makes high endurance microSDXC cards, e.g. SDSQQNR-064G-GN6IA, which are inexpensive. Beyond that, they also make industrial SLC microSDXC cards with very specific longevity guarantees, e.g. SDSDQED-064G-XI, but those are rather expensive.
M.2 is possible on the compute module, but there's iirc only a single PCIe lane on the pi... so it's not as speedy as desktop and also you'd need a PCIe switch to get M.2 storage and networking/USB which just increases costs further and in the zero's case, probably not possible with board space.
pi3/4 can boot straight from USB.
In my case.. I have a couple of old gen1/1.2 Pis, no boot straight from USB, but an SD card with only the FAT32 /boot partition that's got the read lock on card set, and boot config set for a USB stick in the side of it. They're still slow, but not gonna brick the SD card.
pi3/4 can boot straight from USB.
In my case.. I have a couple of old gen1/1.2 Pis, no boot straight from USB, but an SD card with only the FAT32 /boot partition that's got the read lock on card set, and boot config set for a USB stick in the side of it. They're still slow, but not gonna brick the SD card.
Am using (high quality) USB for my pi storage now. Recent firmware can boot directly, though before that I was using the sd card as boot partition only, having everything else on USB. Depending on the application, network boot (i.e. completely diskless) might also be an option - probably the most reliable one, but needs wired ethernet so not possible on the Zero.
Three options:
1. Use an "endurance" SD card, these are usually advertised for dashcam use.
2. Boot from a USB device instead of SD, now natively supported.
3. Boot from LAN, also natively supported.
1. Use an "endurance" SD card, these are usually advertised for dashcam use.
2. Boot from a USB device instead of SD, now natively supported.
3. Boot from LAN, also natively supported.
Nice article, well written. I like Alex's approach and I like that I have found all the information I wanted to know about this new shiny board :) Keep up the good work alexellisuk :)
I wonder if this faster CPU will cause the stenogotchi project consider de-prioritizing performance optimization of their code.
Will existing HATs for pi zero work for this one? I'm wondering about the ANAVI Infrared pHAT
Interesting, dint know faasd
Are you running Zeros now or other models? What would you run on an RPi Zero 2?