The C language for Embedded Linux is not very different from the C language for Linux Desktop, when you program software. But when it comes to device drivers for Embedded Linux programming there are significant changes. Although software development for Embedded Linux and Linux Desktop are similar in many aspects, there are still minor differences to consider.
Compiler for Embedded Linux
The compiler used will depend on the architecture of the SoC (System-on-a-chip) chosen. The most commonly used architectures for Embedded Linux is currently ARM, MIPS and PowerPC. It is also sometimes used the x86 intel. You need to compile or download a variant of gcc for the specific target. It's what we call cross-compiler or toolchain. Then we would have something to ARM as arm-linux-gcc. For MIPS, mips-linux-gcc. And so on.
The Debian GNU/Linux is a great distribution that offers free compilers for various platforms. There are compilers for architectures that uncompensated've never heard as SPARC, S390 and hppa. visit: http://www.emdebian.org/tools/crosstools.html.
In application level you can program in C language and many other languages like C++, Java, Perl, Python, Lua and others. There are many projects and libraries in Python for Embedded Linux.
Libraries for software development
A big problem in Embedded Linux programming is finding the development libraries for the platform you chose. If not there you need to cross-compile. And this is an even bigger problem when a library depends on another, and another, a process that seems to have no end. I went through it, is very bad, and you lose a lot of time!
Again Debian GNU/Linux can save you! It has a large availability of packets to multiple ports. In addition to developing libraries, it also has many applications. In particular for the ARM platform. So you could even run Debian within Android.
Programming of Device Drivers
On Linux there are three distinct layers of software in which it has different levels of access within the kernel. The lowest layer is the Platform drivers. The second is device drivers. The third and last is the application layer. The level of device drivers and platform drivers is only possible to program in C language.
The kernel space is where Linux runs its services, and where device drivers reside. The user space is a region of memory in which user processes run. The kernel space can be accessed by user processes only through the use of system calls.
From the point of view of layers, if we take as an example an EEPROM memory at24cxx accessed via I2C bus:
1° layer: I2C driver plataform (usually provided by the manufacturer)
2º layer: I2C device driver at24.c
3º layer: The software in user space to read and write the memory
The source code for a platform driver is architecture dependent and manufacturer. Thus, a platform I2C driver for Freescale i.MX processors does not work for AM335x processors from Texas Instruments and vice versa. On the other hand, the device driver at24.c runs on any platform that has a minimum functionality provided by the I2C Platform driver. I will explain this in more detail in another article.
Developing Device Drivers for Android
The development of device drivers for Android is in many cases similar programming device drivers for Linux. Because the lower layer of Android is Linux itself. However, Linux used on Android, does not correspond exactly to the official Linux. The Android kernel has, for example, a totally new, directed power management for portable devices whose power source is a battery. And other subsystems of the Linux kernel were rewritten and others were created from scratch.
The Android driver programming involves developing/porting drivers for peripherals chosen that already have support in the Android stack. Some of these devices are:
Cartão de memoria SD
LCD e Touch Screen