Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unpopular Opinion: Don’t Use a Raspberry Pi for That

set-inform.com

Post reply on HN
Print view View original

241–250 of 270 posts

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#241

Post by rleigh »

lll-o-lll wrote: post #237
rleigh wrote: post #229

Earlier quoted context omitted.

The high clock speed and multiple cores are great. It's definitely a beefy system. But this is completely orthogonal to timing accuracy and consistency. Speed does not make it more consistent. Tiny low power MCUs have much more accurate and consistent timing. Low latency can be a good thing, but it's also not related to consistency, particularly when you start looking at what the worst-case scenario can be.

So I am the opposite of an expert here, but I don’t follow. If I have control over the interrupts (which I do) and I have high precision timers (which I have), why can I not drive a gpio pin high for X microseconds accurately? What’s going to stuff it up?

As I mentioned in the previous reply, the CPU caches and the MMU to begin with. You're probably running your application from SDRAM and an SD card. The caches and page tables result in nondeterminism, because the timing depends upon existing cache state, and how long it takes to do a lookup in the page tables. And as soon as you have multiple cores, the cache coherency requirements can cause further subtle effects. This is why MCUs run from SRAM and internal FLASH with XIP, and use an MPU. It can give you cycle-accurate determinism.

The A-profile cores are for throughput and speed, not for accurate or consistent timing. However, you can disable both the cache and the MMU, if you want to, which will get you much closer to the behaviour of a typical M-profile core, modulo the use of SRAM and XIP. If you're running bare metal with your own interrupt handlers, you should get good results, excepting for the above caveats, but I don't think you'll be able to get as accurate and consistent results as you would be above to achieve with an MCU. But I would love to be proven wrong.

While most of my bare metal experience has been with ST and Nordic parts, I've recently started playing around with a Zynq 7000 FPGA which contains two A9 A-profile cores and GIC. It's a bit more specialised than the MPU since you need to define the AXI buses and peripherals in the FPGA fabric yourself, but it has the same type of interrupt controller and MMU. It will be interesting to profile it and see how comparable it is to the RPi in practice.

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#242

Post by petsfed »

quake wrote: post #126
t344344 wrote: post #110

Earlier quoted context omitted.

It does not get the job done. Last problem I had with Pi: my keyboard did not work for some reason. Guess what, Pi has shitty USB 1.1 implementation (USB 2.0 is different stack), on top of that it does not give enough power to connected devices. With normal computers I had similar problems in 2003!!! For serious use it is like Gentoo. You have to learn about its boot process, how it bootstraps from video memory.... O…

Your arguments are almost identical to the ones greybeard embedded devs have against the Arduino. Yeah, it's expensive, uses an outdated micro (at least the AVR-based Arduinos), but it's effective because of its popularity. Basically a flywheel effect. Doesn't have to be good or optimal, just has to be flexible and have a big community. I doubt anyone is using an off the shelf Pi with SD card for an actual safety cri…

I once encountered a hydroponic nutrient dosing system that was, no shit, a RPi 3+ with a custom HAT for the electrochemistry and actuation. These were sold to businesses running container farms and the like.

At the end of the day, it seemed like the manufacturer had the (good) idea to automate the dosing, but thought that all the standard industrial automation tactics (PLCs, ladder logic, HMIs, etc) were somehow overkill for the application.

Which meant that the end users had to write all the software to make it work with a standard industrial automation system anyway. It was super annoying.

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#243

Post by petsfed »

some_random wrote: post #27

I typically see two kinds of raspi hate, and only one of them is reasonable imo. The first is stuff like this article, where you can probably get something better than a raspi these days for about the same price (especially when you consider scalper pricing) or just run a docker image in a server you can make with an old computer. This is very good advice, especially now that getting a raspi at MSRP is borderline imp…

I mean, there is the trollduino

https://hackaday.io/project/176844-trollduino-v10

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#245

Post by thomasjb »

Steltek wrote: post #45
geocrasher wrote: post #11

If you don't need GPIO, then you don't need a RPi. They are useful, but an old laptop can do most things a Pi can do, and putting them to use keeps them out of the landfill longer.

I'm a bigger fan of Dell desktop that companies have put out to pasture after a refresh cycle. They're very expandable, have plenty of horsepower, and the idle power draw isn't that bad. The better thermal characteristics compared to a laptop usually lead to very long life as well. Related to a sibling comment, a decent UPS could power a Dell like that for a couple of hours if it's mostly idling.

Yes, I've got a Dell T3610 under the desk here now. My only beef is that it has weird Dell proprietary hardware, so I can't easily fit quieter fans to the PSU, or reuse the case with an ATX mobo

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#246

Post by retrocryptid »

outworlder wrote: post #203
retrocryptid wrote: post #103

Earlier quoted context omitted.

Happy that yours works well. Many problems don't show up until you hit larger numbers. We deployed over 1k RasPi's for a particular customer. We averaged about five reboots per day. On top of that I had to deal with the RasPi Organization's insistence that they were not an ODM. Though these were the RasPi B's and RasPi2 B+'s. I'm sure the reliability has gotten better over the years. I'm not a big TI fan, but everyth…

... what were they doing with 1k Pi's Please tell me they were using the GPIO pins for something.

Of course. GPIO is the simplest way to get a blinky light.

Seriously though, we used a GPIO pin to stroke the watchdog.

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#247

Post by retrocryptid »

olabyne wrote: post #134
retrocryptid wrote: post #103

Earlier quoted context omitted.

Happy that yours works well. Many problems don't show up until you hit larger numbers. We deployed over 1k RasPi's for a particular customer. We averaged about five reboots per day. On top of that I had to deal with the RasPi Organization's insistence that they were not an ODM. Though these were the RasPi B's and RasPi2 B+'s. I'm sure the reliability has gotten better over the years. I'm not a big TI fan, but everyth…

Raspi's are stable if you respect 2 things : - avoid writes to sd card too much (log2ram mitigates this, alpine in read-only solves this) - plenty of power (the recent 3 and 4 have huge sipkes of current draw !) Do you know the reason for your reboots ? Also before the 3+, the die have no RF shield. The B and 2 B+ are exposed if you don't use a metal case with a seperation from the PSU.

Yes. RasPis are stable except when they're not.

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#248

Post by ahepp »

dale_glass wrote: post #240
ahepp wrote: post #223

Earlier quoted context omitted.

The parent comment says > control a mechanism and reliably react on a deadline of a few ms I actually did measure this with an oscilloscope on embedded Linux (not a raspberry pi). A PPS signal was fed into Linux, and in response to the interrupt Linux sent a tune command to a radio. Tuning the radio itself had some unknown latency. End-to-end, including the unknown latency of tuning the radio, I never observed a late…

I was referring to that yes, even if Linux performs well in the ideal case, it's not necessarily reliable, and the possible problems are hard to compensate for. Eg, your process can randomly get stuck because something in the background is checking for updates and IO is being much slower than usual, or the system ran out of RAM and everything got bogged down by swap. On a microcontroller you just don't have anything…

I guess I feel like things are a bit tangled up here.

Sure, a single purpose MCU controlling a heater MOSFET has a lot fewer failure modes than a Linux device doing the same.

I don't dispute there are a lot fewer ways it's even possible for that system to misbehave.

The original comment was recommending ESP32s over Raspberry Pis for DIY projects like opening your curtains or flashing LEDs. The ESP IDF runs on FreeRTOS, so we're already moving away from the bulletproof single task MCU. People will almost certainly be adding some custom rolled HTTP webserver on top. They might be leaking memory all over the place, there are probably all kinds of interrupts they have no idea about firing off in the background. I wouldn't trust an ESP32 curtain-bot not to strangle me any more than I'd trust a Raspberry Pi based one.

Your example about running out of RAM seems just as relevant to MCUs. You can leak memory and crash an MCU. You can overload an MCU with tasks and degrade performance. You can use cgroups or ulimit to help prevent a bad process from bringing Linux down.

I agree that Linux is not going to be as reliable as going baremetal, and I'm not recommending you use it as a motor controller. But even the most reliable MCU can fail. An MCU can get hit by cosmic rays or ESD. People might spill water on the 3d printer or physically damage it. It's not even a binary "works right or dies" thing. I've voltage glitched MCUs to get them to skip instructions and get into an unanticipated state.

In any case, the best path to safety is to imagine that the computer might be taken over by Skynet and do everything in its power to kill you. Or worse, ruin your print. If safety is the goal it's probably best to achieve through requiring the computer system to take some positive action to keep the heater on. Or even better, a feedback safety mechanism like a thermal fuse.

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#249

Post by ahepp »

yamtaddle wrote: post #139
t344344 wrote: post #95

Earlier quoted context omitted.

I hate PI because its hardware is just junk. Cheap low end stuff designed for consumer electronics like TVs! Devops like to use Intel NIC, ECC memory only. But somehow Pi junk gets pass because it is "open-source" or what. Great, we will run this mission critical deployment from cheap SD CARD!!!!!

Sure, running off the SD card sucks, but "flash the card on another computer, boot straight to your installed OS" is the nicest OS installation experience I've ever had.

And it gives users an easy way to set up an SSH key and wifi configuration as well

Re: Unpopular Opinion: Don’t Use a Raspberry Pi for That

#250

Post by steve_adams_86 »

gaudat wrote: post #63
steve_adams_86 wrote: post #59

Earlier quoted context omitted.

The thing that tripped me up the most was concurrent tasks. In languages like Go or JavaScript it’s pretty easy to figure out how to decrement a timer or wait until x time to perform a task without having the waiting period be blocking. On an arduino, you have a few options but none of them are likely to be familiar to high level software devs. It isn’t rocket science, but there are loads of little details like that…

RTOSes are developed to solve this exact problem of concurrency. Try Zephyr, ThreadX (from MS) or FreeRTOS (from Amazon) or whichever OS your microcontroller vendor supports. It will be eye opening, and you get to learn to write safe code in C with synchronization primitives just like our ancestors.

Ha, I'd never seen FreeRTOS – thanks! It looks awesome.
Post reply on HN