It is writing driver in Linux for embedded systems complicated?

Hi,
I want to start writing drivers for Linux in embedded systems. All my friends warned me that is very complicated and tedious. Mostly they are programming in Java or c# (for X86 servers) and few are working on embedded system but in bare metal hardware in C (as I, but only short time). I have concept on HW part of working system (IRQ, timers, DMA, different buses, etc.) and worked for years in C and understand skeleton concept of creating drivers in Linux. So question which I want ask it is really so difficult if you compare it to other programming (create applications, bare metal embedded programming, etc.) and which part is most challenging (going over device documentation, integration into Linux, optimalisation, etc.). Thx

You say you have experience working close to hardware so there's your answer. Which is it's exactly THAT level of complexity. A DRIVER is how the OS talks to hardware.

Thank for you point of view . What is puzzling me is that even people programming embedded processors as bare metal considering writing Linux drivers complicated and I have no doubt that have a way to deal with HW complexity. If there are different thoughts please point them out.

People working on embedded processors typically program in a non-OS or a traditional RTOS environment.

They do write code in C as well as assembler, some may use C++, but typically most programming is at the lowest level.

I think it's mainly the fact that they're uncomfortable or unfamiliar with the higher level OSes like Windows, Linux, and iOS.

The highest most embedded developers go are the commercial RTOSes like pSos, OSE, FreeRTOS, VxWorks, stuff like those. Linux's programming models are both similar, as well as different. And although Linux is pretty good embedded, I never claim it to be real-time. For those requiring true real-time behaviors, they go either no-OS or one of the free/commercial RTOSes.

Originally Posted by pepo007 So question which I want ask it is really so difficult if you compare it to other programming (create applications, bare metal embedded programming, etc.) and which part is most challenging (going over device documentation, integration into Linux, optimalisation, etc.).

Linux (like any well-written operating system) has a high degree of modularity and abstraction. From what I've seen in some embedded projects (i.e. not mine), the concepts of modularity and abstraction are often considered optional or simply absent.

Linux is one of the few embedded OSes that use virtual memory and executes its kernel in a protected CPU mode. That is a big step up in complexity over a bare-metal environment. Device drivers are one of the few areas in the kernel that may have to deal with both virtual and physical memory addresses.

Processors for embedded Linux are typically RISC, and are often ARM, rather than x86. If you have only programmed for x86, then you will have to learn the restrictions of word alignment. Even if you program for Linux on x86, you need to learn about memory word alignment, since Linux is processor/architecture agnostic.

The Linux kernel requires adherence to its C coding style. Personally I learned C in order to do Unix kernel programming, so it's not an issue for me. But from reading code samples on the web and seeing how typical people are resistant to changing their own coding style, the Linux kernel code style can be difficult to use for some. Hint: posting your Linux driver code that does not conform to the kernel style
in a public forum brands you as a kernel newbie or clueless.

Regards

Originally Posted by blue_z Linux (like any well-written operating system) has a high degree of modularity and abstraction. From what I've seen in some embedded projects (i.e. not mine), the concepts of modularity and abstraction are often considered optional or simply absent. Linux is one of the few embedded OSes that use virtual memory and executes its kernel in a protected CPU mode. That is a big step up in complexity over a bare-metal environment. Device drivers are one of the few areas in the kernel that may have to deal with both virtual and physical memory addresses. Processors for embedded Linux are typically RISC, and are often ARM, rather than x86. If you have only programmed for x86, then you will have to learn the restrictions of word alignment. Even if you program for Linux on x86, you need to learn about memory word alignment, since Linux is processor/architecture agnostic. The Linux kernel requires adherence to its C coding style. Personally I learned C in order to do Unix kernel programming, so it's not an issue for me. But from reading code samples on the web and seeing how typical people are resistant to changing their own coding style, the Linux kernel code style can be difficult to use for some. Hint: posting your Linux driver code that does not conform to the kernel style in a public forum brands you as a kernel newbie.

Hi...

That's quite a first post. Welcome to the forum

Regards...