Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Embedded Linux Applications

Status
Not open for further replies.

ranayehya

Junior Member level 3
Joined
Apr 13, 2018
Messages
26
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
203
Hello, All
I am trying to understand some concepts about Embedded Linux and Why engineers use it.
I read this article

www.eetimes.com/document.asp?doc_id=1277902

and I understand that applications that need server controlling and image processing

Is there the only applications for Embedded Linux or it is used in other applications?

Also why ARM cores are popular in Embedded Linux applications?

Also if there is a book to explain the programming process and interfacing with FPGA, I would be grateful
Thank you
 
Last edited by a moderator:

why ARM cores are popular in Embedded Linux applications?

Not all ARM cores, but the ones which meets some requirements in their instructions set; actually most of them.
 

Linux in embedded systems main appeal is time to market and ease of use. From a hardware stand point there is a decent amount of support in terms of kernel modules and device drivers. From a software perspective it has a large number of stuff such as filesystems and networking along with various packages that can be installed for ssh or cryptography.

This basically accelerates development. Linux is also a full operating system which supports multi-threading/processing. This can allow a decent amount of developmental comfort to be passed on. The Linux kernel supports a wide array of hardware but isolates this from the programmer to a large extent unless your doing serious kernel coding. Which for most of the time I am going to guess it will not be common outside of a few specific areas.

So far this sounds really awesome right. However the catch is mostly as seen in the linked article. Linux is not actually super low level, its an operating system. Linux is designed to work in environments which are not real time. What a lot of people have done is bought their way out with faster hardware, which lead to power consumption issues. This is part of the love of ARM to which is supposed to be pure magic.

You will find the weaker members of the embedded community are very opinionated and love three major groups. These members also tend to have little insight into what they are doing or what is proper for this context. These groups are Atmel, ARM, and Linux fanboys. You will generally hear them talk about the development support and debugging options. Most of this is for people that are not trained or accustom to this context/environment.

Linux is like high level programming for hardware. Which is why people generally attempt to classify this as low level. This of course fails. However areas of concern here are memory management and process/task management. Programmers that struggle with pointers will struggle with bare metal programming. Which is a major motivation for using Linux. Simply put there are many programmers that could not work in that area. Just like Java was created because people could not use pointers, unsigned, memory management, etc.

Now there is one area that really shocks me. Linux generally speaking is not known for security in IoT. The reason for this is not so much due to Linux itself but the large context of Linux and improper understand/application of it. Linux standardizes the security footprint and allows assumptions to be made for hackers. Along with a programmer doing stupid things can basically create a side channel for exploitation. The massive amount of reuse in Linux and the ecosystem can promote a culture of insecurity which can have huge ramifications under the premise of IoT.

Even more shocking is the whole notion of embedded Linux to begin with. Here the abuse is the notion of embedded which generally implies specialization, whereas Linux generally implies general purpose. Embedded systems as part of their specialization generally work under real time constraints. However Linux does not. RTOS is supposed to be used here. Granted the Linux kernel has a patch which can be applied to bridge the gap. However overall Linux has a lot of overhead due to the large general purpose support it carries. This can cut into the RTOS behavior. Granted Linux is modularized and kernel programming is available. However following that would be following bare metal which begs the question of why?

As for ARM itself. Look this mostly a feature of fad culture and ignorance mostly. Linux did recently trim down support, which makes some sense and is confusing at the same time. A lot of what surrounds ARM is BS. I generally look down on "engineers" that go over the top with singing ARMs praise. Personally I think they miss the point of the context and lack understand of hardware, architecture and ironically software. Everyone was so shocked when ARMs power yields against frequency fell off, but anyone familiar with hardware knew this would happen due to dynamic current.

I personally do not like ARM or embedded Linux too much. The reason is people are too likely to push pure software which is very inefficient or push something like Java or Python. Which we have already seen. ARM cores enable most of this. ARM cores also are rarely implemented in a Harvard configuration outside of the core itself. Granted many higher speed processor don't do this also. However options do exist for this, but rarely do. Again with hardware software co design and SoC based designs most of this should be changing.

This is kind of the issues with the whole PIC vs AVR war. Sure the AVR may be faster, however there are contexts for which this simply put does not matter. An engineer had better know this. Engineers should be the only ones in this space, as CS has shown complete disregard for basic theory and conceptual stuff learned in the second year of college. I view the promoting of embedded Linux as something a CS person would do rather than an engineer. CS as a field has entered a very strange position in the world. It believes it can do anything, but is bad at it. It also has moved away from more productive in devours. Engineering will have to sort that out later on. Of course I am referring to AI, which is not new at all.

Interfacing with an FPGA is a very open ended topic. FPGAs do not really have an interface so you can make it do whatever you want. If you have a Zynq you can use an internal interface to bridge between the ARM and some custom hardware perhaps via memory or AXI. Then there is external interfaces like SPI or PCI/PCI express. Driver development for something like Linux will depend on this interface and the platform you are using. For bare metal its a little more straight forward as you are basically working with an IO module.

Now I briefly mentioned that it was possible to use Linux for a custom module in a FPGA. However I also mentioned that Linux is poor for real time performance. Why would I say that then? Well the answer is it would depend on how the design handles this. For example the hardware does everything that is real time. The Linux part only handles say a configuration component which is TLS or a web server. That Linux part can be slowed out of real time, as the actual operation will happen concurrently in hardware without restriction. The same is not true with pure software. Granted you could use multiple software processes, but then you get into cache issues, memory bus problems, etc.

In summary ARM is loved for its support. Linux is loved for its support and cost reductions. Which mostly has to do with labor and time reductions. However proper design and support is usually compromised under this. Arrogance is extremely common.

There is now a light switch running cell phone grade hardware. Why cause it needed Java for some AI component. It runs off Android which is based in Linux. Welcome to 2019. Were inefficient is efficient. Were we need to do better to save the planet but screw it over doing this. The guy that made that will be declared smarter than me, yet I may know more about this than him. He may even have a PhD. After all this is so low level. So I would say these people are amateurs rather than engineers. You cannot really have this discussion with an amateur. (That is my foolishness.)
 
Last edited:

The reason for embedded Linux is the time to market. Try and design a video player in a bare metal platform and providing an API for the client to interface to it. I previously worked for a payment terminal company and previously everything was baremetal. When the requirements change to adopt more high level functionality, the time to develop in bare metal would take too long especially to meet the high level features and functionality. Providing access for a major client to add their own content would have been a pain if working on a bare metal platform. They would want access to certain components in the payment terminal. Customization with their own graphics and animation.

I guess it depends on your requirements, time to market and cost which are factored in the selection of hardware and software.
For example if you were creating a inference on the edge or ai on the edge device, would you implement in baremetal when considering time to market and cost. I definitely would not consider bare metal based on the device that are available and none of them would work in a baremetal device. If it is time to market and cost, I would rather use embedded Linux than writing something from scratch. If I have the time then I would potentially use a FPGA with an ARM core without embedded Linux. I have ported kerasify to the ARM core without any issue and was in the process of applying high level synthesis or arm intrinsics to accelerate the inference. The issue how does it compare with the Google coral in performance. The coral has a dedicated ASIC for tensor operations.

I am not dishing baremetal as I have used in a lot of different application varying from automotive, automatic doors, cop cars and ventilation and heating systems. The processors ranges from stm32 to a small pic. The selection of the processor was due to cost, time to market as usual. Stm32 due to the can bus peripheral and cost. Pic was mainly due to cost as the client required a certain pricing for his product.

In a previous life I have used FPGA for high speed data acquisition mainly 2GBSP ADC and DAC. Boards that were mainly used for electronic surveillance.

Like I said choice of components depends on application, requirements and cost as one the main factors in my work experince.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top