The most common idea on 'new age' embedded devices - IoT Devices is using an Arm Cortex (Mostly M Series) processor as Central Unit and some Sensors and Peripherals for acquiring data and metrics (Correct me if i am wrong please).

I was wondering, if and how much efficient is, in a more complex embedded device, the idea of using more SoCs for different purposes, (for example, for a device which is logging 3 different cases, for each case using a different SoC developed for this specific case) and finally all the processed data sent to Cortex and from there to a hub or to a mobile device.

Is this a feasible 'Architecture' ? If not, what You would propose to a similar Use Case.


closed as too broad by Elliot Alderson, Chris Stratton, pipe, Lundin, Scott Seidman Mar 14 at 14:31

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ the whole point of a SoC, System on Chip is to reduce the amount of different chips you need. Congratulations, you just re-invented microcontrollers. But: yes, pretty much any more complicated device has a central processor where all strings run together. It's not necessarily the one with the communication link. Your laptop is an embedded device, if you will: sensors are cascaded on buses that in the end connect to your Intel or AMD CPU, but one one of these buses, also the Wifi chipset resides, which gets the communication job. \$\endgroup\$ – Marcus Müller Mar 14 at 10:19
  • \$\begingroup\$ @MarcusMüller So probably there will be used a SoC for WiFi, a SoC for BLE, a SoC for sensors etc. Also by all strings run together what do you mean? \$\endgroup\$ – Ioan Kats Mar 14 at 10:40
  • 2
    \$\begingroup\$ no, the literal meaning of SoC is System on Chip, ie. if a chip is single-purpose, it's not a SoC. \$\endgroup\$ – Marcus Müller Mar 14 at 11:00
  • \$\begingroup\$ You might be interested in iot.stackexchange.com - but this question is rather too broad for there too. \$\endgroup\$ – Sean Houlihane Mar 14 at 15:00

When I designed a very precise (0.05625 degree precision) 2 axis tilt sensor using an electrolytic sensor (MEMS had long term drift issues I could not live with) I used a dedicated microcontroller for the sensor due to the very precise timing requirements.

The application processor was a STM32F series part, but had all sorts of interesting interrupts and processing going on and therefore could not guarantee the timing precision I needed.

Apart from that, the internal ADC was never going to cut it (I needed a minimum of 16 bit precision (true 16 bits ENOB, not something usually available in microcontrollers) so I used a dedicated (and somewhat expensive) ADC. The support circuitry was also high precision and I needed a microcontroller as I was doing 64 point decimating FIRs on the averaged data from the ADC.

There were interrupts going on, but the specifics of the architecture guaranteed they could never overlap (nested interrupts were impossible) and the timing of events was guaranteed.

The results were passed up to the application processor using DMA.

This was driven by the requirements of the design. If there are tight requirements, it is perfectly possible to need to have a dedicated chip to handle some of it.


More parts = More costs

Each additional part on a board costs something, consumes more space, and requires more design effort to place and route it. It also requires separate programming. So, all other things being equal, designers will try to use as few parts as possible.

Given a general-purpose processor, it ought to be usable for any type of processing.

Standalone solutions

However, some things are both hard to implement and hard to combine with other things due to realtime requirements. Wireless technologies are the usual answer here. So quite often the wireless parts will be a separate SoC.

Power domains

A major reason for having separate processors is the ability to turn some of them off while leaving a controller to turn them back on when required.

  • \$\begingroup\$ Hello and thank you! So a good practice would be every sensor module to be a SoC, so the main processor could turn them on and off for better power consumption ? \$\endgroup\$ – Ioan Kats Mar 14 at 12:41
  • \$\begingroup\$ "Sensor" and "SoC" are usually understood to be different things? A sensor might be a temperature sensor or a microphone or a capsense touch sensor. Not usually containing a processor. Whereas a SoC is a processor+support components+some peripherals on a chip; like a microcontroller, but the term SoC usually implies more processing power. \$\endgroup\$ – pjc50 Mar 14 at 12:44
  • \$\begingroup\$ So in case you take an ECG (too many data points for 20 sec), you need a SoC to process that data and after the proccess send that data to the CPU or to another SoC for wireless transmittion lets say. But in case of Temperature which is a simple mathematical computation you could just pass the raw data to the CPU and process that data there. Did i get that right? \$\endgroup\$ – Ioan Kats Mar 14 at 12:49
  • \$\begingroup\$ Something like that. It's difficult to generalise, because there's always tradeoffs possible. \$\endgroup\$ – pjc50 Mar 14 at 13:00
  • \$\begingroup\$ Thank you for your time. Nice to discuss with You! :) \$\endgroup\$ – Ioan Kats Mar 14 at 13:08

The general answer to this is that the requirements drive the architecture of the system. Specialised components are, generally, more expensive and require interfaces, which increase the integration complexity and therefore cost and time to market. However, your requirements might dictate that you need the performance of the dedicated component. To take a consumer computing example, most people just use the internet and office tasks and so they don't need an expensive GPU, the in built graphics driver on the processor (SoC) is fine. In this way, the motherboard doesn't need the expansion slots, high power supplies, size of case etc.

For your IoT case, if you're just polling a sensor every 100 ms and then sending it out over a BLE link every 5 minutes, you'd chose a SoC that has a low speed ADC and a built-in RF module. The vendor will likely provide example code, so you can be up and running in a day or two. Then, when you need millions of samples per second, but can process that down into something that only needs a small bandwidth, you might be able to use the original SoC and a dedicated ADC IC. Then you decide, actually you need a higher bandwidth output, you move to a dedicated ethernet controller. Each time you add you a new component, you increase the complexity and hence cost by any measure (time, money, size, errors...). So, your concept is valid but always think if it's necessary by whatever metric is valuable to you.

At this point, the system is has 3 different ICs and interfaces, but then you discover that many FPGAs are able to handle this in a single chip, and you move to that instead!

  • \$\begingroup\$ Thank you for your time answering that. So lets say we have a gadget which is measuring Heart Rate(HR), ECG and Temperature. Also the processor could be an Arm Cortex M3. Of course we are not going to reinvent the wheel. We are going to use an ECG IC from one vendor, HR IC from another vendor, an RF module, a temperature sensor and as main CPU the Cortex ?. Or just build everything on a FPGA ? \$\endgroup\$ – Ioan Kats Mar 14 at 11:50
  • 1
    \$\begingroup\$ Ok, so your ECG/HR/temperature monitors aren't SoCs - they're dedicated sensors and they are not going to be available built into what would be considered an SoC and cannot be realised on an FPGA. They probably have standard interfaces (eg I2C, SPI), and M-class SoCs will have dedicated hardware to handle this. The processor and RF module are available as a SoC, eg. Nordic nRF series are an M0+ and BLE module (and other peripherals). My guess is that your sampling rate doesn't need to be that high, so you should be ok with a "simple" Cortex-M based SoC. \$\endgroup\$ – awjlogan Mar 14 at 12:24
  • \$\begingroup\$ Take a look at BMD101 - NeuroSky for example. It is an ECG SoC. In that case, you transfer the data between SoC and Cortex with UART ? Is this a good practise? I mean in the case that is not a Dedicated sensor. \$\endgroup\$ – Ioan Kats Mar 14 at 12:39
  • \$\begingroup\$ The BMD101 is a sensor, not an SoC, it just generates data which you need to read. I couldn't find a datasheet for it, but it's unlikely to be UART (typically this is used between boards), more likely I2C or SPI. It would connect to your Cortex-M SoC, which would then process and pass the data to the outside world. \$\endgroup\$ – awjlogan Mar 14 at 12:54
  • \$\begingroup\$ I said SoC because it is referred as one on the datasheet. Datasheet \$\endgroup\$ – Ioan Kats Mar 14 at 13:07

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