Hacker News Reader

Comment by mikepurvis | Hacker News Reader

I think Arduino really struggles to justify its own existence in a world where RPi exists. Like, sure, there are lots of legitimate applications for microcontrollers where you need realtime or interrupts or signal generating timers or instant boot or ultra low power, but few of the common use cases (or libraries) for Arduino really corner any of that— most of it that I've seen is stuff that would make way more sense as a Python script running on a tiny Linux computer than as a microcontroller firmware.

View on HN

Eh, if you're doing anything in the background on an RPi, timing intensive operations like I2C or SPI get really buggy. Years ago, I had to add a retry function to basic, 3-byte I2C transactions on an RPi, because even something as simple as that was still getting bumped pretty often. These days, I'm more likely to just use a microcontroller for all of those operations, and then use an FTDI cable to let the micocontroller report its results up to the RPi. That's always been easier than setting up something like DMA on an RPi.

Granted, I write microcontroller firmware for a living these days, but I still use RPis and Arduinos for proof-of-concept work because of the simplicity of the toolchains.

I thought Linux had better support for realtime workloads these days? I mean, yes, I would still prefer a dedicated micro, but if you need a Real Computer in the mix it might be possible to get better results out of it.

I mean, yes and no. But it also gets into "who is it for?" and while you can do things better, eventually you reach a point where its easier to just do it the right way.

I mean to say, at the point where the I2C library user has to seriously think about patching their kernel, the strengths of the RPi as an out-of-the-box embedded computer are pretty much negated. If you have to do actual embedded engineering things, then the RPi becomes just another SoC dev board.

Probably, but if you think about the final 20% of the workload in optimizing, I think it's safe to say one will be immensely more grueling than the other just by the nature of it.

Not to say that your original comment didn't have merit; the beauty of hobby projects is that you can completely skip the last 20%.

I disagree. There are numerous advantages to using microcontrollers and one of them is not having a full operating system.

A full OS brings a whole lot of software complexity and places greater demands on the processor, which means greater power draw, greater hardware expense (because you need a beefier system just to run the OS) and reduced reliability.

There is certainly a role for systems like a R-Pi that have a complete OS on them, but there is also a real place for lighter systems.

> greater hardware expense (because you need a beefier system just to run the OS) and reduced reliability.

Unlikely. The marginal cost is so low that a "beefier" but standard processor that's widely used is likely to be cheaper than a lower-powered but less-popular processor. And using a standard system that everyone else does is more likely to have the bugs ironed out.

I don't like it, but realistically unless you really need low power it's cheaper and simpler to get an extremely standard off-the-shelf RPi like system and slap whatever on it. The savings you can shave off by going smaller just aren't worth the effort.

It entirely depends on the project. For about 2/3rds of the ones that I do, I don't really need much grunt. A 50 cent microcontroller can do the job as well (sometimes better) as a full R-Pi, but at a fraction of the cost ("cost" including power usage, size, etc.). I frequently see projects using a hefty system like an R-Pi that could have been done equally well with a tiny microcontroller.

And having a full OS running means that more code is running. More code means more potential points of failure.

Of course, if your project is something that needs a larger processor or more advanced software, then what you say can be very true.

Also, if your skillset is more in line with programming larger systems than smaller ones, the development time will be shorter for you by going with a full OS.

IMO, Linux is unusually complicated to configure for unattended use cases, despite being a server OS. Arduino just goes into user code shortly after powerup, a la AUTOEXEC.BAT, no systemd-jumpscared shenanigans. There's just too much of those.

There ought to be something in between Wiring and Linux. The problem is that the good minimal real-time operating systems are not free. QNX, VXworks, etc. are all expensive.

ESP32-based boards come with FreeRTOS built in.

Zephyr fits the description IMO.

FreeRTOS exists, and it's pretty good.

Yes if you set it up correctly, but it's very easy to set it up wrong, especially once a networking or usb stack is in the mix.

This is true for all platforms, including no OS at all, RTOSes, Linux, DOS, Windows, etc.

Fair, but there are ready-to-go Linux configurations for RPi that assume you'll do "normal" things like talk to USB devices and the network.

Additionally, Linux has available a multitude of very rich in-band debugging and logging capabilities that help you understand and mitigate common problems— whereas a bad interrupt or peripheral configuration on some microcontroller could have you banging your head again a GDB frontend or shelling out thousands for a tool like Tracealyzer to tell you what on earth is going on with it.

That sounds like a good usecase for micropython. In any event, I disagree; microcontrollers are easier to use than having to admin an entire GNU/Linux box just to twiddle some pins.

Reply on news.ycombinator.com