0
\$\begingroup\$

Context:
I essentially don't have a strong electrical engineering background. My knowledge consists in playing around with Arduino based microcontrollers or Raspberry Pis or equivalent SoCs.


Question:
What is the reason why a company would choose to design self made electronics with programmable microcontrollers instead of having a central SoC which runs an ordinary operating system, e.g. Linux, to handle all sensor inputs and processing. The target processing rate of sensor data (say 180 kB per time step) is 100-1000 Hz.


My idea behind this is the following:
A Raspberry Pi costs ~30$ and can handle all kinds of software, while a programmable microcontroller is essentially bound to compiled code in some self-written semi-compatible C/C++ language. Thus the development and maintenance cost for a SoC is way better. The processing frequency (max 1 kHz) makes me doubt that sophisticated hardware is needed here. Let's assume the processing steps are not too complicated. Assume that the CPU cost is not the main factor of the product cost. Size is neither a problem (A Raspberry Pi would easily fit). What are the bottlenecks of running a SoC in such a setup and thus prefer some self made boards with programmable microcontrollers (or even FPGAs)?


EDIT:
Assume the final product will be sold at 10k-100k$.

\$\endgroup\$
6
  • \$\begingroup\$ I think you could just say microcontroller to differentiate if from a SoC. Saying programmable microcontrollers sounds weird. They all should be programmable. Do you mean by that a "one-time programmable microcontroller"? \$\endgroup\$
    – jDAQ
    Feb 5 at 20:41
  • \$\begingroup\$ Often, cost. MCUs start at 50c or less (and that's 1-off). Handling 180kB may require one costing $2 or more. If that'll do the job, why pay $30? \$\endgroup\$ Feb 5 at 20:44
  • \$\begingroup\$ SoC running Linux could be great for general purpose non-realtime computing or UI. A dedicated MCU not running Linux is better suited for real-time work. Anything running Linux could need custom drivers. The custom drivers may need to be GPL and you may not want to reveal how your custom peripheral works. The RPi boots with a proprietary binary firmware blob, which may also have legal licencing or distribution issues in a commercial product. There are a lot of issues that are not technical but legal or political/policy issues when you are making a product for you or making it to your customer. \$\endgroup\$
    – Justme
    Feb 5 at 20:48
  • \$\begingroup\$ @jDAQ: I don't know the correct terminology. By microcontroller I mean anything that cannot run a standard operating system with standard (easy) software development procedure for development, test and maintenance. \$\endgroup\$
    – image357
    Feb 5 at 20:49
  • \$\begingroup\$ @BrianDrummond: Because the main cost factor for the product is in human resources. Thus keeping things standardized for development, testing and maintenance will outweigh hardware cost. \$\endgroup\$
    – image357
    Feb 5 at 20:53
5
\$\begingroup\$

The short answer is: Overhead.

Yes, an SoC running an OS has more resources and can do more. The tradeoff is that the hardware and software then become significantly more complicated than a dedicated microcontroller running custom firmware because they have more overhead.

Hardware overhead means a more complicated board design which may require:

  • More board space (more expensive and may not fit product form factor)
  • More support components (more expensive)
  • More PCB layers (more expensive)
  • Higher quality PCB manufacturing processes (more expensive)
  • More time spent debugging due to more failure points (more expensive and can cause schedule slips, and may still result in buggy hardware shipped to customers)

Software overhead means that there is more code and a deeper software stack (e.g., a Raspberry Pi has boot firmware, a kernel, hardware drivers, system daemons, and your user applications), potentially spread across multiple hardware components (e.g., the WiFi/Bluetooth and USB/Ethernet driver chips on RPi run their own firmware, whether or not you intend to use those features). More software always means a higher risk of bugs, which can cause operational failures, poor and/or unbounded performance, and compromised security. For small-scale and hobby deployment, these tradeoffs can be acceptable. For mass-produced products made by even a moderately reputable company, it’s a no-go; there are simply too many variables that are not in the manufacturer’s control.

Even if you are using an off-the-shelf SoC board, like a Raspberry Pi, which spares you many of the hardware development and production costs above, you are risking failure in the field by using a (relatively) bloated software stack.

An additional factor is how much control the manufacturer wants to have over their product and supply chain: If you’re basing your entire hardware and software design around a massive monolithic block from a third-party vendor, you are tying your fate to that vendor. Supply disruptions, cost increases, vendor hw/sw bugs, and deprecation are all risk factors.

\$\endgroup\$
3
  • \$\begingroup\$ +1 for the nice answer. Maybe you can also mention real time operation and deterministic behavior. \$\endgroup\$
    – Tagli
    Feb 5 at 21:50
  • \$\begingroup\$ Thanks for your answer! I assume that interface development for peripheral hardware like WiFi/Bluetooth/USB/Ethernet is at least as error prone for microcontrollers as for SoC? Even more so if there is no "lean" build environment (custom microcontroller toolchain/simulation vs. standardized PC operating system). So is it really the case that there is more software overhead for SoCs if you would use e.g. modern devops toolchains? Will the additional hardware cost for SoC really play a mayor role in the mentioned product prize range (10k-100k$)? Can you give some estimates (order of magnitudes)? \$\endgroup\$
    – image357
    Feb 5 at 22:40
  • \$\begingroup\$ When running a full Linux stack, don't forget about security vulnerabilities. There is so much crap out there running embedded linux that's riddled with all sorts of holes due to some combination of manufacturers not providing updated firmware and end-users not installing said updated firmware. Not to mention bug-ridden firmware and terrible default logins. Ever heard of the mirai botnet before, for example? Personally, I would not design a full linux stack into anything at all unless there was a specific design reason for it. \$\endgroup\$ Feb 10 at 9:28
1
\$\begingroup\$

If you can implement something on a microcontroller, then that something will take much less power for the same task, typically, than if you'd use a fully fledged Linux-running (or similar) SoC, enabling much longer battery life.

There is several reasons for that, fewer transistors to switch being the easiest one. The lack of DRAM significantly helps, too.

Most helpful is that it takes microcontrollers very short time periods to basically turn everything but the activated peripherals off and stop consuming measurable power in the core altogether. Waking back up typically takes microseconds. Compare that to the wakeup time of a RPi! (That's kind of an unfair comparison, the raspberry pi foundation chose SoCs specifically badly suited for embedded applications; other SoCs are orders of magnitude faster at waking up/going to sleep and use much less power, but still, compared to microcontrollers, have so much more hardware to initialize that it really makes things much slower/more complex)

The added complexity comes at a software complexity price: while the toolchains for microcontrollers are mostly but not as standardized (thanks to arm, it's a de facto standard that there's a GCC targeting your MCU, or something relatively similar) but differ in hardware abstraction libraries, SoCs require you to use a Linux kernel, very often with pretty low-quality vendor drivers. These drivers really often are so bad that you can't use all the power saving features of the OS you're running, or they do busy waiting in a couple of places, or... If you want to see really bad Linux kernel modules, I recommend you look through cheap SoC-based devices with multimedia peripherals like set-top boxes, smart TVs....

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.