A hilarious example - to deal with the poor reliability of the RPi, you might think to use its watchdog timer to reset the device if it locks up. But guess what? The WDT in the crappy Broadcom chip on the RPi doesn't work! It's supposed to be there, and it's exposed to the kernel, but it doesn't actually do anything.
Seriously, why the hacker community even touches the RPi is beyond me. It is a ridiculously closed product.
In fact I'd bet most of them would be scared off by the several thousand pages of documentation an SoC like that usually would have.
1) glue shit together
or
2) read several thousand pages of documentation
who is going to choose the latter?
This is a market that's being poorly served (maybe it's not big enough to justify investment in developing non-shitty products for them?) but blaming the users seems distasteful.
Is that any different from all that stack overflow copypasta you find all over source code, where the paster clearly had no idea how that code worked? And I’m talking about people who are being paid to ship code.
shudder. It’s a wonder anything functions at all these days.
Not to pick on anyone, but I recently installed a stock storybook setup. Out of curiosity I did a count of all the node_modules (top level + nested). There were >2000 packages installed.
Now I know that if I follow the rules of a textbook professional (one that takes security seriously), then I'm obliged to audit all 2000 packages. But between you and the rest of the gazing internet, I don't do this. That's my dirty little secret. I don't give a shit. Gluing orphaned half-assed npm packages together and pretending everything is okay is my job.
The ironic part is how many hours we are murdering worrying about TypeScript or unit tests or integration tests and trying very very very hard not to notice that landfill we have placed under our massive rug.
There are too many technologies and not enough time to master them. Every time I dive into a popular node package I become more and more worried for the human race. We get things fundamentally wrong and it lives like that. For decades. And people come along and just obliviously use it like that and don't question it. Take something simple, like JWT. Or nonces. Or what people believe and implement around random numbers and how random numbers work (or, often, don't work). Bad information becomes bad code that sits around for a lifetime.
I started on ARMv5 back in the days of Sheevaplug/Dreamplug. At least that had JTAG, even if the cable did cost $70.
I have tried:
* Espressobin: While Marvell's hardware is pretty good, they've had trouble with the v7 board, resulting in the small community being somewhat bifurcated. I still don't think it runs a mainline kernel properly. At least the PCIe slot is standards-compliant. u-boot+ATF will always be a 2018 (?) Marvell fork, no one's ever going to update that.
* Firefly RK3399. Lol. https://lkml.org/lkml/2020/4/6/320. Although, if you can get ARM Trusted Firmware working it's a reasonably competent board.
* Vocore2. Support is reasonably helpful but insists that I use GCC 3.4.2 to compile the bootloader. Remember to back up the wifi calibration data - you can't ever get it back if you erase it. You will need to break out the magnet wire if you want to unbrick it. Shame, it's a nice little MIPS board.
* Anything Libreboard - use this, they've put a stunning amount of work in to get things upstreamed.
When I want to just work on something not on a PC, I keep coming back to the Pi. The Pi 4 is competent with an SSD attached over USB 3, and the Pi 0W is great for very simple tasks that need Linux. I wish it were better, I wish Broadcom was more open, but the Pi has the biggest community I've seen in any "hobbyist" ARM space.
Seriously, it's easy to crap on this stuff when you're willing to recommend boards that cost "just 20 dollars more", or have one-hundrenth the community because most of the end users are embedded engineers or the anything-but-a-pi sub crowd.
To me it just shows a lack of ability to consider requirements in evaluation. Even something as simple as the fact the rPI form factor has been fairly consistent for a while is a huge boon to people just trying to start with this stuff.
I could give my mom a rPI and a $20 starter kit and she could probably get to the point of a working PC.
I wouldn't dream of that with anything else. The fact it's Broadcom based is a little unfortunate but that ship has sailed and the ecosystem around it now trounces any benefit of alternatives for the actual people using them. Not embedded engineers who say it's crap because they wouldn't make a custom product based on that SoC.
-
This is like when people point out that for half the price of an Arduino Uno you can get an STM32 board that will run circles around a dinky ATmega328.
It's not about the power or "objective goodness", even the header layout of the Uno lets beginners use an insane wealth of peripherals designed for it
There is an Arduino port to STM32 (Blue Pill in particular), for those whose idea of embedded programming involves a bunch of delay() statements scattered around the library code, making sure no other peripherals can be used while you’re polling for the next UART char..
There's a million and one peripherals designed for that specific combination that don't work seamlessly with other boards (even within the "official" Arduino family)
I mean your complaint about the quality of the library code, it's perfectly fine that the code sucks if it lets people do 1 million and one things they couldn't otherwise.
Do you really think someone programming an Arduino for controlling their cosplay LEDs cares if the library they used is poorly written? As long as it works it works.
They were never going to read the datasheet for an MCU and start figuring out bit masks for pin initialization, so it's literally a case of something is better than nothing, and there's no reason to gatekeep the environment that lets them use embedded systems
(A few employers ago, they were the only source for ethernet PHYs for a carrier-grade network product we were building where we supplied our own MAC)
Commercial embedded stuff is better but not without warts. A former colleague of mine sent me a rant a couple of weeks about one which I won’t name, but the board vendor couldn’t even get a Linux kernel to boot reliably on it when it was shipping to customers.
Engineers and power users tend to forget that the Raspberry Pi wasn't designed for them.
The target market for the Raspberry Pi doesn't care about reading the SoC datasheet or connecting the latest NVMe drive that costs several times more than the SBC. They just want a cheap, simple board that lets them start learning and tinkering with ample resources available on the internet. The $35 Raspberry Pi excels in this regard.
Please do! It would be very good to know that your vendor is doing that.
For example the Honeycomb LX2K at https://www.solid-run.com/nxp-lx2160a-family/honeycomb-works... or the NVIDIA Jetsons at https://developer.nvidia.com/embedded-computing.
Those options have the advantage of using SoMs so that you can customise the boards for a higher-volume run too.
The regular RPi on that point isn't exactly ideal, but depending on the use might be quite _okay_.
It was around 3 years ago. I haven't touched any ARM board ever since. We specifically used OrangePi zero. The armbian at the time had thermal management problems to the point the boards would straight up fry to a brick. I remember there was an update that fixed the thermal problem but it would corrupt the SD card once in about five reboots. And it really didn't solve the thermal problems. They'd get hot enough to be unresponsive. So the clever decision by management was to add a fully self designed avr based board to periodically poll the device on one of the GPIO pins and somehow reboot the OrangePi if it didn't respond. So reboots were common and SD cards only lasted 1 month tops.
If anyone knows of an alternative that's in the $100 (US) price range, runs linux, and will make my life easier, I'm grateful for suggestions.
Oh, and it needs to play nicely with a USB-to-ZWave dongle and one of the major open-source home-automation packages that can do lighting controls.
EDIT: I forgot to mention that I want it to reside in a closet that has very little ventilation. So I'd be leery of deploying a cheap used x86 system, even if the price way right.
EDIT2: Holy crap I'm being high-maintenance here. I should just do a damn Google search like everyone else.
The power system doesn't suck like the RPi series. The chips are all well-documented with the possible exception of graphics. It has eMMC so you don't have the microSD idiocies if you don't want them.
And if you need genuine real time, it has two RISC cores (4 on the AI) that operate in actual real time as opposed to Linux kinda/sorta/when-it-works/maybe real time.
"But the RPi is cheeeeeeaaaper!" <grumble>
Bullshit. The beaglebone can be permanently damaged (not just filesystem corruption!) BY BEING UNPLUGGED: https://elinux.org/Beagleboard:BeagleBoneBlack#Improper_Powe...
Never had crap like that happen to a raspberry pi.
Uh, yeah. A failure mode so rare that they can't isolate it.
RPi--the system that overdraws every USB interface on the planet and requires special power supplies. RPi--the system that couldn't even get USB-C right. RPi--the system that shuts down when you fire off a flashbulb (not their fault--but still a power failure). RPi--the compact system that needs a heatsink or it shuts down.
RPi has lots of things going for it. The power system is NOT one of them.
(If you want to pick on Beaglebone power systems, pick on the PocketBeagle. It has some truly stupid failure modes.)
My main frustration with them is that there's a ton of outdated documentation around how some of the software stack works. It's changed quite a bit over the last 5 years and you can easily go down pointless rabbit holes.
The Beaglebone series really does lots of I/Os well.
Worry about a better product for your next build.
Also, like the sibling said, just do it. If every option is ARM, there shouldn't really be much of a difference if you swap the underlying system.
Couple years ago I bought a pile of barebones ex-Datto Alto, NUC-style, AMD GX-415GA systems on eBay for sub-$5/ea and I reach for one of those for pretty much anything that doesn't Actually Need an RPi. RAM runs $5-$10 for 4GB, $20 for a 2.5" SATA SSD. They boot much faster than a Pi, idle around 7w, and run fine in my "network closet" that gets over 100F in summer.
Those exact systems aren't plentiful on eBay any more but there are tons of NUC-alikes, actual NUCs, and Thin Clients in the $40-$75 range with low-TDP CPUs of comparable performance.
Pi 4 as home server value proposition gets bad fast for me at least once cases, power supplies, storage etc factored in.
I've got more than a thousand of the previous unit in production. just ramping up on APU units. yes they are higher power than a Pi, but still very low. easy to develop for (amd64). tons of Ethernet ports. easy to use reliable storage. USB3, SATA, mpcie ports, SIM slots. openly available schematics
Not a lot not to like!
You could consider the more expensive Jetson Nano if you need a powerful GPU or if you just want to try something different. People tend to assume it's faster, but the Raspberry Pi 4 CPU actually beats it in most cases ( https://syonyk.blogspot.com/2019/11/battle-of-boards-jetson-... )
Client bought too many to change.
I know of a museum with a huge Pi deployment and they don't have issues like that at all.
It's not like they overheat and lock up in 4 hours, it's more like randomly in a day or two. But since they're just monitoring stuff every couple min, it probably felt safer to reboot all the time.
Not sure exactly about the decision process that went there, I just did part of the software running on them. But they definitely weren't stable long term.
So your pihole doesn't heat as much as the pi in that kiosk even given the same room temperature. And then, the temps inside an outdoor box in the sun can go way up too.