Currently, I am planning to work on a system, in which we will be gathering the data from the multiple sensor for more than 15 parameters, based on the sensor value we will be controlling the actuators.

Some sensors have higher priority than others, and the output from the sensor values should be displayed in the color LCD screen in real time.

When we have less sensor data I am comfortable using ARM Cortex-M4 based controllers, STM32 controllers from STMicroelectronics are my favourites. Now, as we are planning to have a feedback control system and the real-time display of the value of the sensor, a real time operating system (RTOS) programming will be required. TouchGFX is a very good tool to display the value in the LCD display. I need your suggestion regarding which system should be selected for the above-mentioned project. (basic embedded, embedded with RTOS, embedded Linux, PLC, National Instruments controllers / LabVIEW etc, is there anything apart from what I have mentioned).

For a pneumatic based system, I have heard PLC based systems are very effective. Even Cortex-A based processors ( Linux based embedded systems) like Raspberry-Pi and Beaglebone can be used. If you could help in giving direction regarding which kind of system should be used for the above-mentioned application it would be great, and if there is any rule of thumb in selecting the one, please help with it.

I am curious about what kind of processors are used in standalone embedded devices such as ultrasonic machines and mechanical ventilators. How does an engineer program the touch screen, they must be using tools like QT?

If you have any knowledge regarding the industry-standard tool, please reply.


1 Answer 1


You first need to define what "real-time" means to you: a reaction with 100 ms (as would be sufficient for your data display-only thing)? 10 ms? 1ms? 100 µs? 10 µs? 1 µs?

How often do your sensors even give you data?

This will restrict your choice in CPU; but honestly, none of what you describe suggest you need any hard real-time contraints at all so far!

Then, you need to define how much computation needs to happen.

Together, this will define whether you'd want:

  • one MCU that's both fast enough to calculate all the computation you need and still has enough headroom to still allow for low latency real-time reaction to sensors?
  • A mixed approach, where a MCU takes care of the real-time low-latency tasks, and highly complex computation is done by an application processor?
  • Or even something like a digital hardware design on an FPGA to guarantee low reaction times, or to fulfill specific computational tasks that might be hard to do in software.

So, it mainly takes better requirements modelling to start with. From how I read your question, you haven't really written down what your latency requirements are – and what your processor actually needs to do, but you're already choosing components! That's a mistake that we've all done a couple of times, but really, the right approach here is: requirements first, hardware selection later.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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