First, I would like to thank all the members here who don't get annoyed when someone asks a very general or basic question. I really appreciate that about this community, because I don't find this kind of attitude everywhere.

Now coming to my actual question. When we write C code for a microcontroller, we normally have a main() function with a superloop inside it, where different things are handled one after another. So, I was thinking that I could consider this as one task that the CPU keeps executing.

Then we move to OS-style programming, where we can have multiple tasks and a scheduler decides which task should run and when, like in Linux. So my understanding is that multiple tasks are somewhat like having multiple loops, with each loop handling a different task.

So should I think about the application in terms of dependent and independent activities? For example, I have read in some places that when we have independent things that need to be done, it can make sense to create separate tasks for them. On the other hand, if some activities depend heavily on each other, they may be better handled within the same task.

I have also seen some places that when one main loop starts doing many different things and becomes difficult to manage, we can separate those activities into different tasks to make the application easier to organize and maintain.

So is this a reasonable way to think about why we create multiple tasks? Or are there other important reasons or criteria for deciding when something should become a separate task?

 

You are attempting to pigeonhole all situations into one generalized solution. Instead, each application needs to be analyzed based on its unique requirements.

Some applications can run on a single main loop. Some can run entirely in low power sleep mode and entirely on interrupts. Others might use round-robin threads.

One thing to be aware of with interdependent processes, is the deadly embrace. Two or more processes are waiting to proceed based on the outcome of a dependent process. It is the grid lock in computers. Every process grinds to a halt and the application locks up. Only a power-on reset gets you out of it.

 

Instead, each application needs to be analyzed based on its unique requirements.

So my first intention was simply to understand what advantage we get from creating multiple tasks in an OS-based application. I don't currently have a real-world application that I can give as a reference, so if you have an example application that would help explain, please share it.

When I say "independent" and "dependent" tasks, this is what I mean.

For example, suppose I have an application where a device can be controlled by two different events, and those two events do not depend on each other. Either event can happen at any time, and whenever one occurs, the device needs to react. In such an application, I was thinking that it might make sense to have two separate tasks handling those activities.

For a different application, suppose I have a sensor that detects an object, and only after the sensor detects the object do I update a counter on a display. Here the display update depends on the sensor event. So in this case, I was thinking that these activities might be better handled together rather than as two completely independent tasks.

So this is what I currently mean when I use the terms "independent" and "dependent" activities. so I would appreciate an example or correction if my understanding is wrong.

 

An important criteria that dictates the design of the application is the response and delay times involved in each process. Are event times occurring in the time frame of picoseconds or milliseconds?

A digital oscilloscope is an example of a real application.
Analog data must be recorded at giga-Hz rates. Screen updates occur in milliseconds. The user interacts with buttons, control knobs, and a touch screen.

How many times have you clicked on a button or cursor on a PC and had to wait for an unreasonably length of time for a response?

 

A digital oscilloscope is an example of a real application.

Thank you for giving a reference example, the "digital oscilloscope." I am not an expert, but I think we can discuss this example further. I will share my understanding based on what I have read and learned so far. I may be wrong in some places, so please correct me if needed.

I think digital oscilloscope can be designed in different ways, at least four possible approaches are a normal bare-metal application with a main function and superloop, an RTOS such as FreeRTOS, Linux, or a combination of Linux and FreeRTOS.

So I know that an RTOS is not necessarily required to build a digital oscilloscope. It can also be built using a normal bare-metal approach. Obviously, an RTOS must provide some advantages over the normal superloop approach, but we don't need to go into those details yet.

Then we have Linux. Since a digital oscilloscope has real-time requirements and some operations need predictable response times, I would not consider general-purpose Linux the best choice for the time-critical parts, because traditional Linux is designed as a general-purpose OS rather than as a hard real-time system. I would also leave the Linux + FreeRTOS combination aside for now because I want to keep the discussion focused.

So for our discussion, we are left with two approaches: building the oscilloscope without an RTOS using a normal main loop, or using an RTOS.

I would choose the RTOS approach for our discussion because my original question was specifically about OS-based coding, and I want to understand why we create one task versus multiple tasks and what advantage that gives us.

If you agree with this way of narrowing down the example, then we can continue from here.

And just to be clear, I know we are not actually trying to design a digital oscilloscope here. I am only using it as a reference application so that I can better understand the concept we are discussing.

 

After reading a little more about this in detail, I think OS is a large software program, with many source files, header files, folders, and other components organized together. The kernel itself is one part of the overall OS, and it also contains many files and folders. Since Linux runs on desktop computers, and Linux can also run on embedded systems

I have two questions about how this works in practice.

First, when Linux runs on an embedded system, is it basically the same complete Linux OS that runs on a desktop, or is the Linux customized, configured, and built specifically for the embedded system? My current understanding is that it is customized/configured for the specific embedded hardware.

Second, do we directly download the Linux kernel source code and then write our application code on top of it to run on the embedded system and control the specific hardware? This is also what I currently believe, but I am not completely sure if this is the correct way to understand it.

 

There are many OS and many versions of Linux. There are OS specifically targeted to embedded systems and not PC.
Do not assume that one OS will fit all embedded applications. You need to define the requirements of the application before looking for a platform and OS. Consider that a rPi can be a viable platform for many embedded systems if you need the functionality that it offers. Other times it can be overkill.

Is an OS necessary? An OS might be required when the application tasks are complex and writing your own drivers is out of the question. Keep in mind that an OS tends to be large and needs a lot of computer resources, speed and memory. For a simple application, the OS can be a hindrance and counter productive.

Bottom line: Define the needs of the application first before going looking for a platform and OS.

 

Bottom line: Define the needs of the application first before going looking for a platform and OS.

I don't have enough knowledge yet to give you a specific real-world application as a reference, but let me present a generic scenario

Suppose I build my own customized development board using an ARM Cortex-series microcontroller or processor with enough resources to run Linux. My board has Ethernet, Wi-Fi, Bluetooth, a display, keyboard, and mouse connected to it. Now suppose I want to use this board for some specific application. If I try to write a normal program from scratch to handle every one of these interfaces, I imagine it would be quite difficult because I would have to develop and manage the required drivers and software for each interface myself.

Instead, if I port Linux to my customized board, I would mainly need to configure/customize Linux and provide the necessary hardware support so that Linux can run on my board. Then I could use the existing Linux drivers and OS functionality rather than developing everything from scratch.

So, as I understand it, this would be one of the major advantages of using an OS like Linux compared with writing the entire software stack from scratch

Do you agree or disagree with me ?

 

I don't have enough knowledge yet to give you a specific real-world application as a reference, but let me present a generic scenario

Suppose I build my own customized development board using an ARM Cortex-series microcontroller or processor with enough resources to run Linux. My board has Ethernet, Wi-Fi, Bluetooth, a display, keyboard, and mouse connected to it. Now suppose I want to use this board for some specific application. If I try to write a normal program from scratch to handle every one of these interfaces, I imagine it would be quite difficult because I would have to develop and manage the required drivers and software for each interface myself.

Instead, if I port Linux to my customized board, I would mainly need to configure/customize Linux and provide the necessary hardware support so that Linux can run on my board. Then I could use the existing Linux drivers and OS functionality rather than developing everything from scratch.

So, as I understand it, this would be one of the major advantages of using an OS like Linux compared with writing the entire software stack from scratch

Do you agree or disagree with me ?

Taking a free open-source Linux and porting it to a platform may or may not be a substantial task depending on:

1. Your familiarity with Linux operations
2. Your familiarity with the ARM Cortex architecture

The usual solution to this problem is divide and conquer. In my experience the familiarity with the platform needs to come first and the familiarity with Linux needs to come second. That said your first experiment should be a bare metal (no OS) attempt, that implements multitasking with a fixed (predefined) number of tasks. Then you progress to multitasking with dynamic task creation and deletion. At that point you will have the experience to add Linux to the mix.

Depending on you particular circumstances, your mileage may differ.

 

Taking a free open-source Linux and porting it to a platform may or may not be a substantial task depending on:

1. Your familiarity with Linux operations
2. Your familiarity with the ARM Cortex architecture

The usual solution to this problem is divide and conquer. In my experience the familiarity with the platform needs to come first and the familiarity with Linux needs to come second. That said your first experiment should be a bare metal (no OS) attempt, that implements multitasking with a fixed (predefined) number of tasks. Then you progress to multitasking with dynamic task creation and deletion. At that point you will have the experience to add Linux to the mix.

Depending on you particular circumstances, your mileage may differ.

Yes, I agree with you. For now, I am only trying to understand Linux at a higher level, so I don't want to go too deeply into the normal bare-metal process right now. My main objective is to understand Linux and how it is used in an embedded system.

So let me take my previous custom-board example a little further.

I am trying to understand what a "customized Linux distribution" actually means. Suppose my custom board has a temperature sensor, and I want to send the sensor data to a cloud server over Ethernet or Wi-Fi.

In that case, I would need the Linux features and drivers required for Ethernet and Wi-Fi. But I may not need other features such as keyboard, mouse, or display support.

So my understanding is that I can configure Linux so that the features and drivers I actually need are included in my customized Linux image, while unnecessary components are left out. This would give me a smaller and more suitable Linux system for my particular embedded hardware and application.

From what I have read, tools such as Yocto and Buildroot can be used to create this kind of customized Linux image.

I haven't actually tried this process yet, so I don't want to claim that I fully understand it. I would obviously like to try it myself and verify my understanding. But at a high level, this is how I currently understand the process of creating a customized Linux image for an embedded system.

 

Have a look at OpenSTLinux.

 

Have a look at OpenSTLinux.

As I understand it, different manufacturers such as Raspberry Pi, NXP, and ST may provide their own Linux-based software or distributions for their platforms.

And if we don't need the complete set of Linux features for a particular embedded application, we can customize the Linux system and include only the features and drivers we actually need. Tools such as Yocto and Buildroot can be used to build this customized Linux image

What do you think ?

 

Yes, I agree with you. For now, I am only trying to understand Linux at a higher level, so I don't want to go too deeply into the normal bare-metal process right now. My main objective is to understand Linux and how it is used in an embedded system.

So let me take my previous custom-board example a little further.

I am trying to understand what a "customized Linux distribution" actually means. Suppose my custom board has a temperature sensor, and I want to send the sensor data to a cloud server over Ethernet or Wi-Fi.

In that case, I would need the Linux features and drivers required for Ethernet and Wi-Fi. But I may not need other features such as keyboard, mouse, or display support.

So my understanding is that I can configure Linux so that the features and drivers I actually need are included in my customized Linux image, while unnecessary components are left out. This would give me a smaller and more suitable Linux system for my particular embedded hardware and application.

From what I have read, tools such as Yocto and Buildroot can be used to create this kind of customized Linux image.

I haven't actually tried this process yet, so I don't want to claim that I fully understand it. I would obviously like to try it myself and verify my understanding. But at a high level, this is how I currently understand the process of creating a customized Linux image for an embedded system.

It is tempting to design embedded systems with minimum interactive capability. I am here to tell you that built in debugging support is absolutely essential. You want to be able to probe and dump to a screen all kinds of internal data and structures. Extracting this information from a locked down embedded system is more than unusually difficult. This port is usually a UART and the connector can be made less than obvious. The production techs will love this feature for testing the finished unit before they go out the door.

I'm not here to tell you how to go about things, but merely to express an opinion that might save you some heartburn in the future.

 

An oscilloscope is your window into the operation of hardware and is absolutely the essential tool to have as a hw/sw developer. It would be very difficult to debug hardware problems without an oscilloscope.

Similarly, a debugger is your window into the operation of an MCU. Having a capable debugger is essential in order to resolve software problems. STM IDE provides essential debugging capabilties via ST-Link. In addition to using ST-Link, a simple text output via a TXD port can provide very useful diagnostics information in real-time. (Some IDEs provide console interface but I rarely take advantage of that feature.)

 

I usually just use a terminal emulator like PuTTY, TeraTerm, or Procomm to keep things general and compatible even though they may be long in the tooth.

 

I use a black box hw terminal (RXD only) built around MSP430G2553 and an LCD1602 display module, battery powered. It is simple and stand-alone.

 

I don't currently have any plan to create a Linux-based application because I don't have a specific requirement for one. My focus right now is on understanding the fundamentals of Linux. As I understand it, we can create an application that runs on top of the Linux operating system, and that complete Linux-based system runs on the embedded processor. In other words, we have the Linux OS and our application, and both are part of the software running on the embedded device.

I actually had two questions in mind. The first was when and why we need to create more than one thread or task. The second was what exactly it means to create a customized Linux image. I gone through quite a few documents and links on these topics, and I shared my understanding using example scenarios as references.

What I was looking for from others was simply an opinion on whether my understanding is correct or not. if you disagree, I would like to understand exactly where my understanding is wrong and why. I am not trying to design a specific Linux-based product here. I am mainly trying to discuss these fundamentals and correct my understanding through other people's experience and opinions.

 

The picture of having only a single thread or task is wildly off the mark. Linux itself consists of a large number of tasks. You may be about to bite off way more than you can chew. Take a step back, a deep breath, and rethink how you want to approach this problem. For example:

1. Start with familiarity with the ARM-Cortex processor.
2. Study each of the embedded peripheral devices.
3. Switch to your embedded Linux and enumerate the separate tasks involved in managing those peripheral devices.
4. Add your application into the mix and answer the question of how many tasks are required.
5. Now determine if the chosen hardware has the resources required to meet your requirements.

That should keep your fingers to the grindstone for a while.