4 ms·
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 microcontro
by mikepurvis 3y ago
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.
- numpad0 3y agoIMO, 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.
- Animats 3y agoThere 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.
- HeyLaughingBoy 3y agoESP32-based boards come with FreeRTOS built in.
- fest 3y agoZephyr fits the description IMO.
- cyberax 3y agoFreeRTOS exists, and it's pretty good.
- mikepurvis 3y agoYes 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.
- JohnFen 3y agoThis is true for all platforms, including no OS at all, RTOSes, Linux, DOS, Windows, etc.
- mikepurvis 3y agoFair, 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.
- yjftsjthsd-h 3y agoThat 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.
- petsfed 3y agoEh, 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.
- yjftsjthsd-h 3y agoI 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.
- petsfed 3y agoI 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.
- petsfed 3y agoI 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.
- joshish 3y agoProbably, 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%.
- JohnFen 3y agoI 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.
- lmm 3y ago> 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.
- JohnFen 3y agoIt 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.