No they don't. I have a Dell Optiplex 3070 SFF (not even ultra small form factor, it is standard desktop sized) that idles at 8W. It has an i5-9500, 8GB memory, and a 128GB NVMe.
My Rpi Zero idles at 0.2W - it's nor in the same computing class as SFF/NUCs. I don't run a homelab in it; and I find it ideal for ambient, always on compute/networking/monitoring tasks
That's not totally true. I have a Dell Optiplex mini-PC version (and not that new) and it draws on average 10W, which is surely more than a RPi4 but not 10 times.
There are multiple uses for the Pi. The mini PC is good are being computer, which Pi really isn't good at. But the mini PC can't do the other uses.
For example, the mini PC doesn't run on PoE. It won't fit in enclosure and can't put it on pole outside. But that is what I'm planning to do with Pi for ADS-B receiver.
The mini PC doesn't have PPS support or ability to install GPS receiver. That is what I need for Stratum 1 time server.
A lot of things I want to do just need USB. The question is if one PC or multiple Pis is better. I like idea of Pi per task since are independent units.
You need to attach the GPS and its PPS pin (Pulse per second) to the gpio on the rpi. Gives you microsecond NTP, pretty cool if you need that. It can be used to sync network, radios and audio over long distances.
every person I know who has had problems with the Pis has had problems because they've cheaped out on either storage or power supply.
the official power supplies (and others with the same ratings) are only sufficient if you don't plug anything into the USB port, don't have any hardware drawing power from the GPIO, and don't utilize Bluetooth and wifi 100% of the time at full throughput or anything.
boot to a fast thumb drive, power the board via a 30W or more power supply, and get an onboard battery so in the rare event that the onboard power regulation can't keep up, a battery powered supply can deliver power through the GPIO pins.
Raspberry Pis are built down to a price point, not up to a quality level. they are extremely good per unit of money spent on them, but they are not perfect.
calling them "shit" shows a general lack of understanding, to me.
All solid advice, though I mostly prefer to use the Zero W-s, which need less power, and to boot off a decent sd card into the 'overlay filesystem'[1] which is RAM-only, so writing logfiles etc. doesn't wear out the sd card (I also use 'high endurance' sd cards intended for dashcams etc. which are a little slower but theoretically last longer). I have a couple of Pis that have been running for years this way, no probs.
they aren't industrial embedded computers, so comparing them to some $1500 hardened industrial embedded platform is not only unfair, it's not a comparison that's respectful of the other participants in the conversation. you're relying on people not knowing about embedded hardware so that it appears your comparison is fair.
The Raspberry Pi is not an embedded platform in the ways that you are using for comparison. The Raspberry Pi is an educational platform.
it is very hard to know if your raspberry pi issue is power related if you don't do what you can to make sure that power isn't an issue.
prior Pis didn't log when they had power issues, and current ones do, if they are able to.
on a Pi 2 A (I think) I had to hook up an oscilloscope to catch all the tiny power problems I was having, and only then realized what was happening. I was 100% sure I was delivering enough power. I was not. those symptoms were only visible without the scope as weird errors in the OS and running applications, and corrupted SD cards.
After my 3b+ died and the 4 was nowhere to be found, my enthusiasm kind of shifted towards something even crazier - Ryzen 7840 based machine for 5x the price.
Since these SBCs keep getting pricier and need active cooling while software is still far from ideal, it's not that big of a jump.
You might be able to run on a 5W supply, but my experience is that booting on a less than 15W supply is a recipe for corrupted SD cards and hard-to-trace bugs.
My biggest frustration with hobbyist boards is how little power the can source to e.g. the USB ports. Its super frustrating to need a powered USB hub to add e.g. a USB indicator light. The fact that you can power the RPi from the powered USB hub seems hacky, but maybe that was always the intent.
Try to run even a Pi 3 on 5W and let me know how it goes. You'll get undervolt warnings like crazy. Not sure if you looked at the article but these are the power adapters listed. These SBCs are not exactly low power anymore:
You'd need to limit the CPU operating points or offline most of the CPU cores to get lower max power consumption under load. 5W is too strict for Orange Pi 5 Plus.
And of course forget nvme if you want predictable low power consumption. nvme alone is 5-10W load. The board itself can run under 5W, but you'd have to carefully consider what peripherals you can use and how.
M600 idles around 5-8 watts. If you spank it hard it gets up to 12W. That has a 500Gb SATA SSD and 8Gb of RAM and ethernet.
Note that the M600 does not have any active cooling. The entire unit is a big heatsink. The thing will run as a headless network computer with just the power supply (a proper Lenovo SMPS brick) and an ethernet port connected.
power usage on a computer is not constant by any measure.
power usage spikes with CPU activity (among many other things) and if your power supply can't deliver the current that is required, voltage will drop, and things start failing, but only for 1ms or maybe even less. maybe even a single clock cycle in some cases.
if you can't keep the board powered fully for every clock cycle, then you are going to have problems, and that's true for any computer, not just the Pi.
If you are hobbling with a PI it's all about the community support, form factor, low power and the header pins. Hopefully if you are buying a Pi you already have a specific project in mind.
For example: I use a few zero 2 w's with shairport-sync to make Airplay stereos. I use the header pins to control a relay to turn on and off an audio amp. Pi 4+ would actually work a lot better for this especially when playing audio on multiple of these setups at once. A Lenovo mini pc wouldn't be as easy to hide.
I wouldn't go too far down the "community support" thing with the RPi foundation. Careful if you say anything negative, even in a constructive tone, in case Liz shuts your threads down. I had some problems with brownouts on the RPi 2 and posted a technical thread. It was deleted and my account terminated. There are various reports of this from community refugees who switched to other platforms.
I guess by community support is if you want to build something you'll find 100 tutorials on how to do it or it will even be part of the GitHub project. I never visit the official forums. These community mods are crazy with the little bit of power given. I had similar issues with arstechnica.com before it became an echo chamber.
ESP32s. So easy. As well supported as any RaspberryPi.
Proper real time on the metal. Interrupts. Native i2c, i2s, spi, serial with a cross-plane so you can re-route most pins around, depending on the board and a few minor caveats.
Any non-real-time operating system will eventually get a little bit buggy around timing intensive operations like I2C or (especially) SPI. Better to have your GPIO operations performed by a dedicated micro that only handles your serial traffic and whatever pin-twiddling operations you need to do. Ideally, your serial traffic is in a binary protocol like MODBUS-RTU, so your traffic parser is as fast as possible.
Bitbanging I2C or SPI is tedious but generally pretty achievable in a bare-metal application. But unless you're hacking your kernel to force that kind of timing fidelity, bit banging on an RPi running Debian is just impossible.
Sounds like this would be very annoying compared to a SBC. You have typically several SPI, UART, I2C, gpio interfaces on the pin header on usual ARM SBCs. Ready to use from Linux via standard API, using DMA, etc.
I once had a very simple I2C operation performed on an Orange Pi running project nerves. I had to add a try-again loop to the I2C operation, because the underlying OS kept disrupting the I2C timing. I2C is generally run between 100-400 KHz, so you'd think it wouldn't be an issue, but it definitely was. You can get around this by patching the kernel to carve out timing protection for those operations, but speaking as a firmware programmer, if I'm patching the kernel to avoid writing a simple arduino sketch, I've made some pretty deep mistakes.
100 khz is still very fast, with sub-millisecond I2C tranfers possible.
You'll have the same issue on any SBC running Linux. You'd need to carefully use realtime process scheduling, if you want more predictable timing on a general purpose OS for such stringent timing requirements.
What I see a lot of is people trying to cram all sorts of shit into a Pi and expecting everything to work properly. I actually wrote a fairly small event-driven kernel for AVR parts a few years ago called XOC "exec-or-communicate" which could do small real-time tasks easily (combinational logic, state machines, interrupt handling) and delegated complicated ones to a host machine over virtual serial port. It was used for a metering system I developed. The AVR side could withstand a complete host failure and reboot.
> GPIO Zero supports a number of different pin implementations (low-level pin libraries which deal with the GPIO pins directly). By default, the RPi.GPIO library is used (assuming it is installed on your system), but you can optionally specify one to use. For more information, see the API - Pins documentation page.
> One of the pin libraries supported, pigpio, provides the ability to control GPIO pins remotely over the network, which means you can use GPIO Zero to control devices connected to a Raspberry Pi on the network. You can do this from another Raspberry Pi, or even from a PC.
Presumably, e.g. TLS to secure that control channel is your responsibility.
> TTL serial refers to single-ended serial communication using raw transistor voltage levels: "low" for 0 and "high" for 1. [31] UART over TTL serial is a common debug interface for embedded devices.
I've been using one for my media centre for many years, only swapping it out for newer versions for the performance upgrades. No issues here, and things like CEC are plug'n'play.
If you want a dependable computer, stay away from pseudo-embedded hardware.