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

231–240 of 270 posts

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

#231

Post by rleigh »

ahepp wrote: post #223
rleigh wrote: post #207

Earlier quoted context omitted.

No, the consistency of the timing is terrible on Linux. Seriously, stick a scope or logic analyser on e.g. an I2C line and look at the timing consistency. Even on specialised kernels for realtime use, you can have variable timing delays between each transaction on the bus. And this is all in-kernel stuff that's inconsistent--it looks like it's getting pre-empted during a single I2C_RDWR transaction between receipt of…

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…

My profiling was on an NXP i.MX8 MPU, which is a A-profile quad core SOC very similar to an RPi. I think it was with a PREEMPT_RT kernel, but I can't guarantee that, but I was fairly shocked at the lack of consistency in I2C timing when doing fairly trivial tasks (e.g. a readout of an EEPROM in a single I2C_RDWR request). You wouldn't see this when doing the equivalent on an M-profile MCU with a bare metal application or an RTOS.

What is acceptable does of course depend upon the requirements of your application, and for many applications Linux is perfectly acceptable. However, for stricter requirements Linux can be a completely inappropriate choice, as can A-profile cores. They are not designed or intended for this type of use.

Profiling this stuff is a really interesting challenge, particularly statistical analysis of all of the collected data to compare different systems or scenarios. I've seen some really interesting behaviours on Linux when it comes to the worst-case timings, and they can occasionally be shockingly bad.

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

#233

Post by bsder »

voakbasda wrote: post #123
gaudat wrote: post #63

Earlier quoted context omitted.

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.

Amazon did not create FreeRTOS; they simply took over maintenance a few years back. I didn’t know that happened until I fact-checked your comment, but it is enough to make me never want to use it ever again. And that makes me very sad.

FreeRTOS is now MIT licensed, and the primary developer is actually getting paid to work on FreeRTOS.

This can only improve FreeRTOS and the embedded ecosystem in general.

And, if Amazon becomes a problem, people can fork and bail.

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

#234

Post by mixedCase »

steve_adams_86 wrote: post #59
gaudat wrote: post #42

Earlier quoted context omitted.

Shhhh stop spilling our secret to the software people... The semiconductor shortage is bad enough already... That said though, programming embedded devices like Arduino and ESP32 needs a completely different style of thinking than with high level languages or web stuff. Things like MicroPython reduces the friction just a bit to make it easy enough to get on board.

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…

Using Rust and esp-idf you can simply call the standard library threading facilities if you want to do concurrency, and it's all handled in the background by FreeRTOS for you.

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

#235

Post by tharkun__ »

charcircuit wrote: post #163
rolenthedeep wrote: post #156

Earlier quoted context omitted.

Honestly, working with all the restrictions of an embedded system like this is something that all programmers should experience at some point. Being forced to actually consider how you're using resources teaches you a lot about how to write efficient code. Or at least if gives you a better understanding of what the machine is actually doing with your code.

Not all embedded systems are that limited. Check the specs of some of the latest flagship phones.

You chose to ignore the like this your parent mentioned ;)

And I agree. All programmers should at some point work on a super slow, super limited AVR or something like that. Something where you have to make hard decisions either because you don't have enough RAM, not enough CPU power, not enough storage, not enough I/O pins etc.

Even non flagship phones are more powerful than the boxes running Windows Embedded 20 years ago.

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

#236

Post by bsder »

retrocryptid wrote: post #4

I know that you didn't ask, but my $0.02 is that yes, RasPi's are unreliable. If you use one for as an unattended remote server, it will do you well to include a hardware watchdog that power cycles the device after it hangs. But modern NUCs seem to take MINUTES to boot the BIOS. I had been using various BeagleBones and found them more reliable than RasPi's and faster to boot than the NUCs in the office. But depending…

People haven't been able to get an RPi for years, and yet they still won't switch to those nice Beaglebone Blacks running standard Debian in stock over there.

Shrug. At this point I see RPis as a litmus test.

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

#237

Post by lll-o-lll »

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

Earlier quoted context omitted.

You can read pins (well one) with sub-microsecond latency using the Fast Interrupt Request, but I have not tried this myself. I think a PI would be more than capable of matching most microcontrollers just due to its very fast clock speed. Add multiple cores with the PI4 and you get a crazy amount of compute between each pulse as well. There are a bunch of clocks that run plenty fast to enable high resolution timing a…

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?

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

#238

Post by jjk166 »

The value of the RPi is its versatility. It's not the optimal tool for any task, but I can be confident it will work well enough for an extremely wide range of projects. Some projects you might know exactly what you need at the start, but most times you don't, and when you prematurely optimize you often find yourself bending over backwards to make the wrong thing work.

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

#239

Post by rolenthedeep »

tharkun__ wrote: post #235
charcircuit wrote: post #163

Earlier quoted context omitted.

Not all embedded systems are that limited. Check the specs of some of the latest flagship phones.

You chose to ignore the like this your parent mentioned ;) And I agree. All programmers should at some point work on a super slow, super limited AVR or something like that. Something where you have to make hard decisions either because you don't have enough RAM, not enough CPU power, not enough storage, not enough I/O pins etc. Even non flagship phones are more powerful than the boxes running Windows Embedded 20 year…

I once ran a project on an Attiny. That bad boy has 1KiB of flash and 128 Bytes of RAM at an unthinkable 4/8MHz.

I can't begin to tell you how incredibly annoying it was, but it taught me a lot. I know a lot of people who would be completely dumbfounded at 128B of memory. That's only four int32!

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

#240

Post by dale_glass »

ahepp wrote: post #223
rleigh wrote: post #207

Earlier quoted context omitted.

No, the consistency of the timing is terrible on Linux. Seriously, stick a scope or logic analyser on e.g. an I2C line and look at the timing consistency. Even on specialised kernels for realtime use, you can have variable timing delays between each transaction on the bus. And this is all in-kernel stuff that's inconsistent--it looks like it's getting pre-empted during a single I2C_RDWR transaction between receipt of…

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 else running, so those risks don't exist. Eg, a 3D printer controls a MOSFET to enable/disable the heaters. The system can overheat and actually catch on fire if something makes the software get bogged down badly enough. On a Linux system there's a whole bunch of stuff that can go wrong, most of which is completely outside the software you actually wanted to run.

Post reply on HN