Benefits of using Embedded Linux in real world projects

[matrixofdynamism]

By using embedded linux we can get benefits like open source drivers for peripherals like printer, usb memory stick e.t.c. and get capability to access file system and communicate on network using things like TCP/IP and UDP.

Could you give me a few examples of why you chose embedded linux and what the project did using it for ideas of how it is used in real world projects?

[shapirus]

Let's define "embedded Linux" first.

[ppTRN]

Do you mean something like a Raspberry pi?

[Foxxz]

Feel like this is a question on your undergrad homework.

But... You can do things like use higher level programming languages such as python to write complex programs using less and more simplified code.

[ppTRN]

Feel like this is a question on your undergrad homework.

Now that you said it i cannot unsee it   

[shapirus]

Unless we have more detailed description, the answer is: embedded linux, typically understood as an OS with a reduced set of userspace software and a linux kernel compiled with a required minimum set of features, is used for narrow-purpose hardware with a limited computing power and memory size. This is the opposite of general-purpose desktop or server linux distributions which are not feature-limited to be able to run a wide range of software on a wide range of desktop (laptop) and server hardware.

Embedded or not, it's the same linux kernel in every case (sometimes with custom patches), the only difference being compile-time configuration, plus a certain set of software which, combined with the kernel, comprise an operating system.

[nctnico]

Unless we have more detailed description, the answer is: embedded linux, typically understood as an OS with a reduced set of userspace software and a linux kernel compiled with a required minimum set of features, is used for narrow-purpose hardware with a limited computing power and memory size. This is the opposite of general-purpose desktop or server linux distributions which are not feature-limited to be able to run a wide range of software on a wide range of desktop (laptop) and server hardware.

Actually that is no longer true either. Only someone who loves lots of pain would go down the road of Buildroot / Yocto / Openembedded nowadays. Modern day equipment running Linux uses a regular Linux distribution like Debian or Ubuntu. Makes it much easier to keep up with security updates as well.

Feel like this is a question on your undergrad homework.

Indeed. I was thinking it is ChatGPT asking questions but noticed the OP has registered in 2011 already.

But... You can do things like use higher level programming languages such as python to write complex programs using less and more simplified code.

You can use Python on microcontrollers as well so that is hardly an advantage of having Linux.

[shapirus]

Actually that is no longer true either. Only someone who loves pain would go down the road of Buildroot / Yocto / Openembedded nowadays. Modern day equipment running Linux uses a regular Linux distribution like Debian or Ubuntu. Makes it much easier to keep up with security updates as well.

Even so, that distribution may need to be significantly tuned to fit in a small amount of memory, have certain compile-time kernel options enabled or modified, support certain methods of bootloading etc.
Take Armbian for example: it looks and feels just like a regular debian-based distro, yet it is quite a big project in terms of development and maintenance effort. It can be an example of a modern day embedded linux distro.

The lower the computing power, the more specialized (or exotic, if you want) the CPU, the lower the RAM and disk (flash or whatever) size, the more effort goes into making a standard linux distribution suitable for running on the given hardware.

[shapirus]

Indeed. I was thinking it is ChatGPT asking questions but noticed the OP has registered in 2011 already.

Lol I also had to go into the profile and check latest posts.

Captchas of the future will ask us to tell which of the two texts was produced by human and which by an AI instead of finding all traffic lights in the picture.

[JohanH]

By using embedded linux we can get benefits like open source drivers

Could you give me a few examples of why you chose embedded linux

The first sentence answers the question.

Then you can ask, embedded Linux compared to what? Windows? A full Linux distro?

It depends entirely on your application. If you can use x86 hardware, there is no problem running a full Linux distro, which makes your life a bit easier. If it's ARM or some obscure platform, use what the hardware vendor recommends, usually some form of customized distribution. I see both being used. I also see Windows disappear from a lot of specialized applications in the industry. It's replaced by Linux and there are new things invented that weren't possible before.

[matrixofdynamism]

The question is embedded linux vs bare metal.

I am trying to find out if I should spend my hobby time learning about this. My background is FPGAs, RTL and testbench design using VHDL.

[barshatriplee]

The first advantage that comes to my mind is reduction of cost and size. Let's say, you wanna do an automation project, or maybe a machine learning project. Decades ago, you had to use a dedicated computer for each of such projects. But now you can just use an embedded linux board like the Raspberry Pi, Orange Pi or Beaglebone black etc. Not only your cost is reduced, your projects are being more compact. Many IoT projects like the following are done by Raspberry Pi.

https://www.theengineeringprojects.com/2022/11/iot-based-web-controlled-home-automation-using-raspberry-pi-4.html

[zilp]

I think I'd approach this differently. Forget about "embedded linux" vs. "bare metal", and instead approach it as "being competent at levels above bare-metal code".

Boadly speaking, there isn't anything all that special about embedded linux vs. any other linux. I mean, it's not like there are two linux kernels, one for embedded use and one for non-embedded use. While there sure are aspects to learn that are more important to one application vs. another, and you might end up using differently configured kernels or even different userpace implementations for various embedded use cases, the general userspace API and userspace software you can run on a linux kernel are the same between all the various uses of a linux kernel, subject to hardware limitations, obviously.

As such, I'd think that it is ultimately somewhat arbitrary whether you use "embedded linux" on a processor that directly interfaces your hardware or whether you use "server linux" on a processor that interfaces with a separate processor that runs "bare metal code" to talk to hadware, and which option you'd choose would probably primarily depend on economic considerations.

The reason for using linux is its huge set of features, and the gigantic amount of existing software that can be executed on it, with all of it coming with source code and without licence fees, and the permision to modify it for your needs.

So, if all you want to do is to blink an LED, linux obviously doesn't help you anything with that, but rather just adds a ton of complexity and hardware requirements, so ... don't do that.

On the other hand, if you need to add remote access to your project, and a complex local user interface that needs significant data collection and analysis capabilities ... you could try building all of that from scratch, of course, but then, if you just use linux with SSH, an X server with a GTK/QT application written in Perl/Python/Ruby/go/whatever, you have 90% of what's needed already implemented in very high quality, reliability and security, and you are writing your high-level application code in a language that's probably significantly more productive to write in, especially so with all the available libraries, than if you tried to do the same in C or something, so it's probably a good idea to use linux for that.

But then, again, technically, it doesn't really matter whether you have that software running on a "server" next to your machine or whatever, or on an "embedded board" mounted inside the machine - as far as how you'd implement that software it doesn't make much of a difference.

So, really, the question is whether you want to have competence in writing higher-level software, (inter-)networking, i.e., stuff that's somewhere between impossible and extremely high effort to do on bare metal--and if you do, then linux and the surrounding ecosystem certainly is a good platform for that. Whether you end up putting the software on an embedded processor on on a desktop PC next to the product or on a virtual machine on the customer's network, or on some server in a data center somewhere is kinda secondary ...

[betocool]

I've been working on a Linux-FPGA embedded platform for pretty much the whole last year.

Let's just say I stuck with a De10-Nano board and used Buildroot to get things started. It is a steep learning curve, and yet very satisfying when you can:
- Blink your LED from and FPGA
- Blink your LED from the ARM processors
- Use the ARM processor to tell the FPGA what to do

Best option is to try and find an existing project with your platform (buildroot has an off-the-shelf configuration for DE10-Nano), I believe Yocto is used for Xilinx dev kits. I tried Yocto for about two weeks and got nowhere... Also, do all your development (FPGA + ARM) on a real Linux box, compiling a small Linux kernel for ARM takes about 1 hour on Buildroot and about 4 on Yocto.

Worth the effort? I thought it was a pain at the beginning, and I'm still learning, but yeah, being able to write a Python 3.10 script that talks to the FPGA fabric is awesome. Definitively worth doing if you're interested and patient.

Hope it helps.

Cheers,

Alberto

[nctnico]

Actually that is no longer true either. Only someone who loves pain would go down the road of Buildroot / Yocto / Openembedded nowadays. Modern day equipment running Linux uses a regular Linux distribution like Debian or Ubuntu. Makes it much easier to keep up with security updates as well.

Even so, that distribution may need to be significantly tuned to fit in a small amount of memory, have certain compile-time kernel options enabled or modified, support certain methods of bootloading etc.
Take Armbian for example: it looks and feels just like a regular debian-based distro, yet it is quite a big project in terms of development and maintenance effort. It can be an example of a modern day embedded linux distro.

Define small memory nowadays. An Emmc several GBytes in size costs a few dollars. Same for ram. You need to sell a huge number of devices (>100k) to make it worthwhile to use buildroot / Yocto. This has been true for at least a decade already. Tuning an existing distro is not that hard. Ubuntu has a minimalistic install for example. For Debian there are scripts available (from module suppliers) that create a minimal install to which you can add additional packages if you want.

[agehall]

Four words: Path of least resistance.

If you need a full fledged OS, use Linux (or some other OS supported by your platform). If you don’t need it, there are probably simpler solutions.

It all comes back to understanding your needs, requirements, skills and previous experiences. For hobby projects it is also a matter of how much new stuff you want to learn.

Some things are just easier to do in a high-level system like Linux while other things are probably easier to do in a bare-metal environment or FreeRTOS.

[shapirus]

Define small memory nowadays.

I'd say 512MB or less. A lot of SBCs fall into this category.
RAM, of course. For storage, once there is an SD card slot, it's a non-issue.

[nctnico]

Define small memory nowadays.

I'd say 512MB or less. A lot of SBCs fall into this category.
RAM, of course. For storage, once there is an SD card slot, it's a non-issue.

512MB of memory is more than enough to run a regular Linux distribution from which you select the packages you really need. Buildroot / Yocto don't help much where is comes to RAM usage, only flash storage might be reduced a little bit. In my experience you will want to use regular libc and regular system utilities because the low storage footprint versions do have compatibility issues that can eat up a lot of development time quickly.

[tunk]

The minimum requirements of linux based openwrt is 128MB of RAM and 16MB of flash.

[matrixofdynamism]

I would be gateful if you could give examples of some projects that can be qualify as embedded system and used linux to achieve their primary task. That would be sufficient as answer to this project.

By the way Yocto could be used with Xilinx but this company has created their own PetaLinux that uses Yocto under the hood.

[nctnico]

My most recent Linux based embedded system is a HMI for a piece of mechanics related test equipment. Touchscreen, logging and remote control over a network (both through VNC over SSH or SCPI over a tcp/ip socket) made the choice for Linux an easy one.

[matrixofdynamism]

@nctnico, touch screen means creating GUI and having ability to process the touch inputs. How was this handled? Qt with C++ or something else?

[nctnico]

@nctnico, touch screen means creating GUI and having ability to process the touch inputs. How was this handled? Qt with C++ or something else?

Wxwidgets and C++ but it is pretty much the same compared to using Qt. I standarised on WxWidgets a long time ago when Qt wasn't free for commercial purposes.

[peter-h]

What sort of hardware (CPU etc) would run linux and be suitable for a production run of 10-20 years?

That's always been the huge problem with building a product which is basically a PC. I've seen so many... you have to redesign every few years, or less.

If this wasn't the case, nobody would use freertos, lwip, mbedtls, building http/https servers, etc. Just build a "PC" in a box.

[nctnico]

What sort of hardware (CPU etc) would run linux and be suitable for a production run of 10-20 years?

NXP's iMX series is a good (and about the only) choice where it comes to versability and long production runs. Some parts are guaranteed to be available for 15 years. However, you want to go for a full-custom design. Don't use modules as you don't have control over the changes and you end up having to modify the software to make it compatible with new module versions.

[DrGeoff]

If you want real-time performance (eg rate-monotonic tasks) then you are better off using a RTOS. Linux is not a RTOS.
Many applications don't require precise realtime performance so Linux work fine out of the box.

[peter-h]

NXP's iMX series is a good (and about the only) choice where it comes to versability and long production runs

That is probably why few people do this for industrial stuff. Actually the old Intel 186 was around for many years for this sort of thing, running some sort of embedded windows.

But every box I have seen running linux was crap in performance. Draytek went from their own OS to linux and even just logging into the config page takes many seconds. I have a 4G ethernet modem right here which also runs linux and is incredibly slow. Putting linux in a box seems to be the standard chinese way of doing stuff (easy to rip off another design, and bring out a product in weeks or a month or two) and it produces very slow products.

[shapirus]

Putting linux in a box seems to be the standard chinese way of doing stuff (easy to rip off another design, and bring out a product in weeks or a month or two) and it produces very slow products.

There is nothing inherently slow in Linux, so it must be a result of poor configuration of the userspace programs.

[nctnico]

If you want real-time performance (eg rate-monotonic tasks) then you are better off using a RTOS. Linux is not a RTOS.
Many applications don't require precise realtime performance so Linux work fine out of the box.

For that purpose many modern day SoCs have an extra ARM microcontroller (typically Cortex-Mx where x is a number) inside that can do tasks that require sub 1ms timing. Still, Linux has quite a few realtime tasks in order to make things work and you can get quite far with using Linux for realtime stuff as well. It all depends on how many processes you run and their priorities. Remember that on an embedded Linux system you have far better control over what runs when compared to a desktop PC / server.

Putting linux in a box seems to be the standard chinese way of doing stuff (easy to rip off another design, and bring out a product in weeks or a month or two) and it produces very slow products.

There is nothing inherently slow in Linux, so it must be a result of poor configuration of the userspace programs.

In my experience slowness on such systems is mainly caused by using a slow/crappy flash storage medium that makes loading/starting applications slow.

[zilp]

> However, you want to go for a full-custom design. Don't use modules as you don't have control over the changes and you end up having to modify the software to make it compatible with new module versions.

Well, either that, or split the design into one long-term "core hardware" that does all the low-level hardware interfacing and one "control plane" processor that runs linux and interfaces the "core hardware" through a standard interface like ethernet or even just RS232, so it's trivial to swap it out for essentially any other processor that has an ethernet interface or two and that can run linux.

After all, one of the big advantages of linux is that it comes with a ton of drivers that get abstracted to a common API, so if you write software that uses an AF_PACKET socket to interface your low-level hardware via ethernet, say, you can just swap out the CPU for a different architecture, the NIC for a different chipset (or SoC MAC or whatever), recompile, and things just work without any need to touch your software.

Also, Olimex sells a buch of boards intended for industrial use with long-term support, some based on iMX, but also others.

[nctnico]

That won't help because you typically want to customise the bootloader and kernel to match the hardware. And then you have to do extensive regression testing. I've been down the module road a couple of times and it sucked every time. It is most certainly not a simple as you think. The best way is to keep the hardware as identical as you can over the lifetime of a product.

[zilp]

> That won't help because you typically want to customise the bootloader and kernel to match the hardware.

Hu? Match what hardware, when there is no hardware integrated with the "control plane board", other than what's mounted on the board itself and presumably supported by the bootloader/device tree that comes with the board? I mean, the whole point of that sort of setup is to make that part as un-specialized as possible, ideally to the point where you could just hook up a laptop instead or something!?

[nctnico]

> That won't help because you typically want to customise the bootloader and kernel to match the hardware.

Hu? Match what hardware, when there is no hardware integrated with the "control plane board", other than what's mounted on the board itself and presumably supported by the bootloader/device tree that comes with the board? I mean, the whole point of that sort of setup is to make that part as un-specialized as possible, ideally to the point where you could just hook up a laptop instead or something!?

That goes out of the window if you need a specific form factor, thermal management, interfaces (*), or other special requirements like a centered boot logo, etc. One particular project I designed/developed has a setup you outline for safety reasons but still both the embedded Linux and controller board are full custom to meet the form factor requirements. Also keep in mind that a module relies on making contact reliably with a carrier board. Reliability of interconnects is not a given and are best to be avoided where possible.

* Try to find an exact replacement for a module with a different SoC for example. You'll see that this is near impossible due to technology progressing and new interfaces replace the older ones. For example: try to replace a module with a Sata interface with a modern day module.

[zilp]

> That goes out of the window if you need a specific form factor, thermal management, interfaces (*), or other special requirements like a centered boot logo, etc.

Well, yeah, obviously you design to avoid all of that?!

Like, you leave enough space that you could easily fit in any reasonable future SBC, probably don't mount the board directly, don't do a tight thermal design, avoid specialized or likely to be deprecated interfaces, ... and forget about a boot logo? ;-)

> Also keep in mind that a module relies on making contact reliably with a carrier board. Reliability of interconnects is not a given and are best to be avoided where possible.

Well, yeah, depends on the application, of course, but obviously you don't want to use unreliable connectors ...

> You'll see that this is near impossible due to technology progressing and new interfaces replace the older ones. For example: try to replace a module with a Sata interface with a modern day module.

Well, yeah, there is a reason why I mentioned ethernet and RS232 ;-)

As for storage, I guess I would consider that part of the "SBC assembly"? I mean, all of this obviously depends on the application, there obviously are many applications that really aren't a good fit for this approach, but it's an option to consider that can considerably reduce design effort where the limitations of the approach don't matter much.

[peter-h]

it's trivial to swap it out for essentially any other processor that has an ethernet interface or two and that can run linux.

Ah, yes, very easy

Like so much, it depends on whether you are just working for someone (bread on the table = bread on the table) or it's your own company

The best way is to keep the hardware as identical as you can over the lifetime of a product.

Exactly, and hard to do this if you need many megabytes of RAM when a more normal embedded version might not need any external RAM.

[nctnico]

Industrial grade DDR memory tends to stick around for a long time. I designed a product around a TI Omap processor + DDR memory little over a decade ago which is still in production and it is not a problem to buy the memory today.

[nctnico]

As for storage, I guess I would consider that part of the "SBC assembly"? I mean, all of this obviously depends on the application, there obviously are many applications that really aren't a good fit for this approach, but it's an option to consider that can considerably reduce design effort where the limitations of the approach don't matter much.

You have to keep in mind that if you have 2 seperate systems, you'll need to have a very clear seperation of functionalities. If that is even possible! In the project where I used this approach a lot of time was spend on defining the commands between the HMI and controller board. And then there is dealing with error conditions and recovery. The safety requirements from the customer made this seperate setup a good choice. However, it is not a good choice when the only goal is to be able to swap SBCs later on. Dealing with the mechanical side alone (mounting brackets, thermal, power) makes this an economically unwise decission. Better use components that have long availability from the start and design a solution that fits without too much fuss.

[matrixofdynamism]

For multicore ARM processors, is the approach that one core runs Linux while the other core runs bare metal code or RTOS so we can get best of both worlds in a single system?

[SiliconWizard]

For multicore ARM processors, is the approach that one core runs Linux while the other core runs bare metal code or RTOS so we can get best of both worlds in a single system?

Depends on what the "other core" is. If it's some Cortex-Mxx, sure.
But if it's the same kind of core, a Cortex-Axx, good luck writing "bare metal" code for it. While it can be done, it's usually not supported by anything official and is often a major PITA, riddled with potential pitfalls.

[matrixofdynamism]

We can't write bare metal code for A series ARM? Why would that be? I did not know that.

[nctnico]

We can't write bare metal code for A series ARM? Why would that be? I did not know that.

Ofcourse you can. You could use u-boot as a starting point for example.

There are also domain specific RTOS for SoCs. And you can go even further using virtualisation. The iMX8 -for example- allows to run virtual machines so you can have a couple of cores running safety critical engine management while the other cores are handling the instrument cluster / entertainment / navigation system of a car.

[SiliconWizard]

We can't write bare metal code for A series ARM? Why would that be? I did not know that.

Who said that?
I said it was usually a major PITA in practice. Please have a go and come back with your results. We're just exchanging words here, reality takes a bit more time.

On top of what I mentioned, if you have a multi-core Cortex-A and want to run Linux on it, you'll have to configure and build the kernel in order for it not to grab all cores but leave one alone that you can use with your bare metal code, that's an additional burden also riddled with pitfalls. The bootloader will also be fun to write/configure.

Sure going with VMs is probably "easier" to work around the above, although that's now something else to configure and set up.

[Nominal Animal]

Putting linux in a box seems to be the standard chinese way of doing stuff (easy to rip off another design, and bring out a product in weeks or a month or two) and it produces very slow products.

There is nothing inherently slow in Linux, so it must be a result of poor configuration of the userspace programs.

Most companies hire wild monkeys or hormone-crazed high-schoolers to do Linux systems integration, based on the end results.  Spit, bubblegum, and cargo cults.  "Unix philosophy?  That is so outdated, we live in the 2020s now."

Proper systems integration –– that is, taking a Linux kernel, configuring it, picking the userspace tools and services for the base OS, and the applications or services the appliance needs, and combining them all into a reliable, working system –– takes expertise; generalists who know what they are doing.
Unfortunately, very few organizations are willing to spend the time and resources to get an actual professional to do this.

[Simon]

For multicore ARM processors, is the approach that one core runs Linux while the other core runs bare metal code or RTOS so we can get best of both worlds in a single system?

You need a separate subsystem or you will always have a problem with managing the resources. What we did was use an M0+ micro controller on a board that did all of the electronic stuff that our RPI/Rock4 board just would not have as a SBC and then talk to the SBC over serial. So we had a tacho wheel going around, that was done in embedded.

[Thomas]

If you want real-time performance (eg rate-monotonic tasks) then you are better off using a RTOS. Linux is not a RTOS.
Many applications don't require precise realtime performance so Linux work fine out of the box.

For that purpose many modern day SoCs have an extra ARM microcontroller (typically Cortex-Mx where x is a number) inside that can do tasks that require sub 1ms timing. Still, Linux has quite a few realtime tasks in order to make things work and you can get quite far with using Linux for realtime stuff as well. It all depends on how many processes you run and their priorities. Remember that on an embedded Linux system you have far better control over what runs when compared to a desktop PC / server.

Putting linux in a box seems to be the standard chinese way of doing stuff (easy to rip off another design, and bring out a product in weeks or a month or two) and it produces very slow products.

There is nothing inherently slow in Linux, so it must be a result of poor configuration of the userspace programs.

In my experience slowness on such systems is mainly caused by using a slow/crappy flash storage medium that makes loading/starting applications slow.

I use pigpio in Python on a Raspberry Pi for measuring pulse width from a 433MHz radio module.
5us resolution, pretty impressive. I thought I had to use an external uC for this, but it works fine on the Pi itself.

https://abyz.me.uk/rpi/pigpio/

Remains to be seen how well it works when I pile on other things