They're all shit. Get a Lenovo mini PC off eBay and stick Debian on it. I replaced my shitty Pi with a Lenovo M600.
If you want a dependable computer, stay away from pseudo-embedded hardware.
If you want a dependable computer, stay away from pseudo-embedded hardware.
Schrodinger's power consumption.
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.
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.
1: https://www.raspberrypi.com/documentation/computers/configur...
And you basically outlined it: they are bad quality and we have all these power problems and here's the insane list of workarounds.
Incidentally I ran mine of an Agilent E3614A which was worth 30x the price of the Pi.
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's just a (respectable( power supply. I'm assuming OP just wanted to say that power quality was not the 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.
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.
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.
Yet note that a good power source doesn't mean that these SBCs will suddenly draw 15W sustained.
Average draw will be much lower than any of these NUC-like devices.
e.g. my VisionFive 2 is below 4w.
After trying three I gave up.
5V/5A (USB-C) 5V/4A (USB-C) 5V/5A (USB-C)
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 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.
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.
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.
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.
Found this:
"Ryanteck RTk.GPIO (PC GPIO Interface)" https://uk.pi-supply.com/products/ryanteck-rtk-gpio-pc-gpio-...
gpiozero > Remote GPIO: https://gpiozero.readthedocs.io/en/stable/remote_gpio.html :
> 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.
Parallel ports > Pinouts: https://en.wikipedia.org/wiki/Parallel_port#Pinouts
"The parallel port" (2023) https://news.ycombinator.com/item?id=34585216
Serial port: https://en.wikipedia.org/wiki/Serial_port
UART: Universal asynchronous receiver-transmitter:
Serial TTL: https://en.wikipedia.org/wiki/Transistor%E2%80%93transistor_... :
> 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.
"Possible to use a 9 Pin Serial port as "GPIO" using ioctl()?" https://stackoverflow.com/questions/27789099/possible-to-use...
D-subminiature > Typical applications > Communications ports: https://en.wikipedia.org/wiki/D-subminiature#Communications_...
Crosstalk: https://en.wikipedia.org/wiki/Crosstalk
"Can you hotwire this computer to transmit a tone through the radio?" https://www.getyarn.io/yarn-clip/aac07d77-c6d6-4da7-bdd3-b93... https://en.wikipedia.org/wiki/Air-gap_malware
The power considerations are pretty negligible from a cost per year perspective.
I really only use mine for pseudo IOT applications where space is a factor, like for OctPi and a Shairplay receiver.