Embedded System Development

If you are new to embedded development, there may be too many available bootloader, distribution, file systems, and guis. However, these rich options are actually a gift that allows you to adjust the development or user environment to fully meet your needs. An overview of Linux embedded development will help you understand all these options.
Linux is developing steadily in the field of embedded development. Because Linux uses GPL (see references later in this article ), therefore, anyone who is interested in customizing Linux to PDA, handheld computers, or wearable devices can download their kernels and applications from the Internet for free and start porting or development. Many Linux improvements cater to the embedded/real-time market. These include RTLinux (Real-Time Linux), uClinux (Linux for non-MMU devices), and montavista Linux (Linux distribution for ARM, MIPS, and PPC), arm-Linux (Linux on ARM) and other Linux systems (see references to link to these terms and other products mentioned in this article .)

Embedded Linux development involves three levels: Boot Loader, Linux kernel, and graphical user interface (or GUI ). In this article, we will focus on some basic concepts related to these three layers, and gain an in-depth understanding of how the boot loader, kernel, and file systems interact; it will also look at part of the many options available for file systems, guis, and boot loaders.

Bootstrap loader
The bootstrap loader is usually the first piece of code executed on any hardware. In conventional systems such as desktops, boot loaders are usually loaded into Master Boot Record (MBR, or load the first sector of the disk where Linux resides. In general, the BIOS transfers control to the boot loader on a desktop or other system. This raises an interesting question: who loads the Boot Loader (in most cases) on an embedded device without a BIOS?

There are two common technologies to solve this problem: specialized software and tiny boot code ).

Private software can directly interact with Flash devices on a remote system and install the boot loader in a given location of flash. Flash devices are special chips that function like storage devices and can persistently store information-that is, they do not erase content during reboot.

This software uses the JTAG port on the target (embedded devices are usually called Targets in Embedded Development). It is an interface used to execute commands from external input (usually from host machines. Jflash-Linux is a popular tool for writing flash memory directly. It supports a large number of Flash chips; it is on the host machine (generally i386 machine-In this article we call an i386 machine as the host) and use the parallel port to access the target flash memory chip through the JTAG interface. Of course, this means that the target needs a parallel interface to enable it to communicate with the host. Jflash-Linux can be used in both Linux and Windows versions. You can run the following command on the command line to start it:

Jflash-Linux <bootloader>

Some types of embedded devices have tiny Boot Code-according to several bytes of instructions-it will initialize some DRAM settings and enable a serial (or USB, or Ethernet) on the target) the port communicates with the Host Program. Then, the host program or loader can use this connection to send the bootstrap loader to the target and write it into flash memory.

After installing it and giving it control, the bootstrap loader performs the following functions:

CPU initialization speed
Initializes the memory, including enabling the memory library and initializing the memory configuration registers.
Initialize the serial port (if any)
Enable command/data cache
Set Stack pointer
Set the parameter area and construct the parameter structure and tag (this is an important step because the kernel uses the bootstrap parameter to identify the root device, page size, memory size, and more)
Perform post (power-on self-check) to identify the existing device and report any problems
Support pending/restoring power management
Jump to the start of the kernel

The typical memory layout of a system with boot loader, parameter structure, kernel, and file system may be as follows:

Listing 1. Typical memory layout/* Top of memory */

Bootloader
Parameter Area
Kernel
Filesystem

/* End of memory */

Some popular and free Linux boot loaders on embedded devices include blob, Redboot, and bootldr (see references for links ). All these boot loaders are used in Linux based on ARM devices, and jflash-Linux tools are required for installation.

Once the boot loader is installed in the target flash memory, it will execute all the initialization work we mentioned above. Then, it is ready to receive the kernel and file system from the host. Once the kernel is loaded, the boot loader transfers the control to the kernel.

Set tool chains
Set the toolchain to create a Build Environment on the host machine for compiling the kernel and applications that will run on the target-this is because the target hardware may not have a host-compatible binary execution level.

A tool chain consists of a set of components used to compile, compile, and link the kernel and applications. These components include:

Binutils-a set of utilities used to operate binary files. They include utilities such as AR, As, objdump, and objcopy.
Gcc-gnu c compiler.
Glibc-all user applications are linked to the C library. Avoid using any c-library function kernel and other applications to compile without this library.

Build a tool chain to establish a cross-compiler environment. The local compiler compiles commands of the same processor as the local machine. The cross compiler runs on a certain processor, but can compile the commands of another processor. Setting the cross-compiler toolchain with repeated headers is not a simple task: it includes downloading source code, patching, configuration, compilation, setting header files, installation, and many other operations. In addition, such a thorough construction process has a huge demand for memory and hard disks. If there is not enough memory and hard disk space, many problems will pop up during the build phase due to problems such as relevance, configuration or header file settings.

Therefore, obtaining pre-compiled binary files from the Internet is a good thing (but it is not good that most of them are currently limited to ARM-based systems, but will change sooner or later ). Some popular pre-compiled tool chains include those from Compaq (familiar Linux), lart (lart Linux), and embedian (based on Debian but not related to it) tool chain-all these tool chains are used for ARM-based platforms.

Kernel settings
The Linux community is actively adding feature components and support for new hardware, correcting errors in the kernel, and making regular improvements in a timely manner. This results in a stable new release of the Linux tree every six months (or less than six months. Different maintainers maintain different kernel trees and patches for specific architectures. When you select a kernel for a project, you need to evaluate the stability of the latest release, whether it meets project requirements and hardware platforms, the degree of comfort from a programming perspective, and other uncertain aspects. It is also important to find all the patches that need to be applied to the basic kernel to adjust the kernel for a specific architecture.

Kernel Layout
The kernel layout is divided into the architecture-specific part and the architecture-independent part. In the kernel, the architecture-specific part is first executed. Hardware registers are configured, memory ing is configured, architecture-specific Initialization is executed, and control is transferred to the architecture-independent part of the kernel. The rest of the system is initialized during this second phase. The directory ARCH/Under the kernel tree is composed of different sub-directories, each sub-directory is used for a different architecture (MIPs, arm, i386, iSCSI, PPC, etc ). Each of these subdirectories contains the kernel/and mm/subdirectories, they contain system-specific code to perform operations such as initializing memory, setting IRQ, enabling cache, and setting kernel page tables. Once the kernel is loaded and controlled, these functions are called first, and the rest of the system is initialized.

Based on available system resources and boot loader functions, the kernel can be compiled into vmlinux, image, or zimage. The main difference between vmlinux and zimage is that vmlinux is an actual (uncompressed) executable file, zimage, however, is a self-decompressed compressed file that contains more or less the same information-it is only limited by the boot time of 640 kb for processing (usually forced by Intel. For all these authoritative interpretations, see the Linux magazine article "Kernel configuration: dealing with the unexpected" (see references ).

Kernel link and Mount
Once the kernel is compiled for the target system, it is loaded into the target flash memory by using the boot loader ), the kernel is loaded into the memory of the target system (in DRAM or flash memory ). The boot loader communicates with the host by using a serial, USB, or Ethernet port to transmit the kernel to the target flash memory or dram. After the kernel is fully loaded into the target, the boot loader will pass control to the address where the kernel is loaded.

The kernel executable file consists of many object files linked together. Object files have many sections, such as text, Data, init data, and bass. These object files are all linked and loaded by a file called a linker script. The function of this linker script is to map the sections of the input object file to the output file. In other words, it links all input object files to a single executable file, load the sections of the executable file to the specified address. Vmlinux. LDS is the kernel linker script that exists in the arch/<target>/directory. It is responsible for linking each section of the kernel and loading them to a specific offset in the memory. The typical vmlinux. LDS looks like this:

Listing 2. Typical vmlinux. LDS file output_arch (<arch>)/* <arch> supported des architecture type */
Entry (stext)/* stext is the kernel entry point */
Sections/* Sections command describes the Layout
Of the output file */
{
. = Textaddr;/* textaddr is LMA for the kernel */
. Init: {/* init code and Data */
_ Stext =.;/* first section is stext followed
By _ init data section */
_ Init_begin = .;
* (. Text. init)
_ Init_end = .;
}
. Text: {/* Real Text Segment follows _ init_data Section */
_ Text = .;
* (. Text)
_ Etext =.;/* end of text section */
}
. Data :{
_ DATA =.;/* Data section comes after text section */
* (. Data)
_ Edata = .;
}/* Data section ends here */
. BSS: {/* BSS section follows symbol table section */
_ Bss_start = .;
* (. BSS)
_ End =.;/* BSS section ends here */
}
}

LMA is the address of the mounted module. It indicates the address in the target virtual memory of the kernel to be loaded. Textaddr is the virtual starting address of the kernel, and its value is specified in makefile under ARCH/<target>. This address must match the address used by the boot loader.

Once the boot loader copies the kernel to flash memory or dram, the kernel is relocated to textaddr-which is usually in dram. Then, the pilot loader transfers the control to this address so that the inner nuclear energy starts to execute.

Parameter transfer and kernel boot
Stext is the kernel entry point, which means that the code in this section will be executed first during kernel boot. It is usually written in an assembly language and usually under the arch/<target>/kernel directory. This Code sets the kernel page Directory, creates the identity kernel ing, identifies the architecture and processor, and executes the branch start_kernel (initialize the main routine of the system ).

Start_kernel calls setup_arch as the first step of execution, in which the system structure-specific settings are completed. This includes initializing hardware registers, identifying the number of DRAM and flash memory available in the root device and system, specifying the number of available pages in the system, and the size of the file system. All this information is transmitted from the boot loader to the kernel in the form of parameters.

There are two methods to pass parameters from the boot loader to the kernel: parameter_structure and the tag list. In both methods, the parameter structure is not supported because it imposes a limit: specify that in memory, each parameter must be located at a specific offset in param_struct. The latest kernel expected parameters are passed as the tag List format and converted to the marked format. Param_struct is defined in include/ASM/setup. h. Some of its important fields are:

Listing 3. Sample parameter structure struct param_struct {
Unsigned long page_size;/* 0: size of the page */
Unsigned long nr_pages;/* 4: Number of pages in the system */
Unsigned long ramdisk/* 8: ramdisk size */
Unsigned long rootdev;/* 16: number representing the root device */
Unsigned long initrd_start;/* 64: Starting address of initial ramdisk */
/* This can be either in Flash/DRAM */
Unsigned long initrd_size;/* 68: size of initial ramdisk */
}

Note: These numbers indicate the offset in the parameter structure of the defined field. This means that if the boot loader places the parameter structure in the address 0xc0000100, then the rootdev parameter will be placed in 0xc0000100 + 16, initrd_start will be placed in 0xc0000100 + 64, and so on-otherwise, the kernel will encounter difficulties in interpreting correct parameters.

As mentioned above, because there are some constraints for passing parameters from the boot loader to the kernel, most 2.4.x series kernel expect parameters to be passed in the marked List format. In the marked list, each tag consists of the tag_header that identifies the passed parameter and its subsequent parameter values. The general format marked in the tag list can be as follows:

Listing 4. Sample tag format. The kernel identifies each tag using the <atag_tagname> header. # Define <atag_tagname> <some magic number>

Struct <tag_tagname> {
U32 <tag_param>;
U32 <tag_param>;
};

/* Example tag for passing memory information */

# Define atag_mem 0x54410002/* Magic Number */

Struct tag_mem32 {
U32 size;/* size of memory */
U32 start;/* Physical start address of memory */
};

Setup_arch also needs to perform memory ing on the flash repository, system registers, and other specific devices. Once the system structure-specific settings are completed, the control will return to the start_kernel function for initializing the rest of the system. These additional initialization tasks include:

Set traps
Initialization interruption
Initialization Timer
Initialize the Console
Call mem_init to calculate the number of pages in various regions and high memory areas.
Initialize the slab distributor and create slab cache for VFS and buffer cache.
Create various file systems, such as proc, ext2, and jffs2
Create kernel_thread, which runs the init command in the file system and displays the Lign prompt. If no INIT program exists in/bin,/sbin, or/etc, the kernel runs the shell in/bin of the file system.

Device Driver
Embedded systems usually have many devices used to interact with users, such as touch screen, keypad, roller wheel, sensor, ra232 interface, and LCD. In addition to these devices, there are many other dedicated devices, including flash, USB, and GSM. The kernel controls these devices through their own device drivers, including GUI user applications that also access these drivers. This section focuses on the device drivers of important devices that are usually used in almost every embedded environment.

Frame Buffer driver
This is one of the most important drivers, because this driver enables the system to display content on the screen. The frame buffer driver usually has three layers. The underlying layer is the basic console driver Drivers/Char/console. C, which provides some of the common interfaces of the text console. By using the console driver function, we can print text to the screen-But graphics or animations are not available (this requires the video mode function, which usually appears on the middle layer, that is, drivers/Video/fbcon. c ). The second-level driver provides a common interface for plotting in video mode.

The frame buffer is the memory on the video card. You need to map the memory to the user space so that the image and text can be written to this memory segment: Then This information will be reflected on the screen. Frame Buffer increases the drawing speed and overall performance. This is also an eye-catching topic DRIVER: The top layer is a hardware-specific driver, it must support different hardware aspects of the video card, such as enable/disable the video card controller, support for depth and mode, and color palette. All three layers depend on each other to implement the correct video function. The devices related to the frame buffer are/dev/fb0 (primary device number 29, secondary device number 0 ).

Enter the device driver
Touchpad is one of the most basic user interaction devices for embedded devices-keypad, sensor, and scroll wheel are also included in many different devices for different purposes.

The main function of the touchpad device is to report the user's touch at any time and identify the coordinates of the touch. This is usually implemented by generating an interrupt every time a touch occurs.

Then, the role of the device driver is to query the touch screen controller whenever there is an interruption and request the Controller to send the coordinates of the touch. Once the driver receives the coordinates, it sends signals about touch and any available data to the user application and sends the data to the application (if possible ). The user application then processes the data according to its needs.

Almost all input devices-including keypad-work in a similar way.

Flash MTD driver
MTD devices are devices such as flash chips, small flash cards, and memory sticks. They are increasingly used in embedded devices.

The MTD driver is a new type of driver specially developed for the embedded environment in Linux. Compared with conventional block device drivers, MTD drivers are designed for flash-based devices, therefore, they usually have better support, better management, and better interface for sector-based erasure and read/write operations. MTD driver interfaces in Linux are divided into two types: User Module and hardware module.

User Module
These modules provide interfaces directly used from the user space: original character access, original block access, FTL (flash conversion layer, flash transition layer-a file system used on flash memory) and JFS (that is, the log file system, journaled File System-provides the file system directly on flash memory instead of simulating Block devices ). The current version of JFS for flash memory is jffs2 (which will be described later in this article ).

Hardware module
These modules provide physical access to memory devices, but do not directly use them. Use the above user modules to access them. These modules provide actual routines for read, erase, and write operations on flash memory.

MTD driver settings
To access a specific flash device and place the file system on it, you need to compile the MTD subsystem into the kernel. This includes selecting the appropriate MTD hardware and user module. Currently, the MTD subsystem supports a large number of Flash devices-and more drivers are being added for different flash chips.

There are two popular user modules that enable access to flash memory: mtd_char and mtd_block.

Mtd_char provides access to the original characters in the flash memory, while mtd_block designs the flash memory as a general block device (such as an IDE disk) that can create a file system on it ). Devices associated with mtd_char are/dev/mtd0, mtd1, mtd2 (and so on), while devices associated with mtd_block are/dev/mtdblock0 and mtdblock1 (and so on ). Because mtd_block devices provide simulation like Block devices, it is generally better to create file systems like FTL and jffs2 Based on the simulation.

To perform this operation, you may need to create a partition table to split the flash device into the boot loader, kernel, and file system sections. The sample partition table may contain the following information:

Listing 5. Simple flash device partition struct mtd_partition sample_partition = {
{
/* First partition */
Name: bootloader,/* bootloader Section */
Size: 0x00010000,/* size */
Offset: 0,/* offset from start of flash-location 0x0 */
Mask_flags: mtd_writeable/* This partition is not writable */
},
{/* Second partition */
Name: kernel,/* kernel Section */
Size: 0x00100000,/* size */
Offset: mtdpart_ofs_append,/* append after bootloader Section */
Mask_flags: mtd_writeable/* This partition is not writable */
},
{/* Third partition */
Name: jffs2,/* jffs2 filesystem */
Size: mtdpart_siz_full,/* occupy rest of Flash */
Offset: mtdpart_ofs_append/* append after kernel Section */
}
}

The preceding Partition Table uses the mtd_block interface to partition flash devices. The device nodes in these partitions are:

User device node major number minor number

Bootloader/dev/mtdblock0 31 0
Kernel/dev/mtdblock1 31 1
Filesystem/dev/mtdblock2 31 2

In this example, the boot loader must set the node related to the root device (/dev/mtdblock2) and you can find the correct parameter of the file system address (flash_base_address + 0x04000000 in this example) in flash memory and pass it to the kernel. After partitioning, the flash device is ready to mount or mount the file system.

In Linux, the main objective of the MTD subsystem is to provide common interfaces between the hardware driver and the upper layer of the system or between user modules. Hardware drivers do not need to know the methods used by user modules such as jffs2 and FTL. All they really need to provide is a set of simple routines that perform read, write, and erase operations on the underlying flash system.

File System of embedded devices
The system needs a method for storing and retrieving information in a structured format, which requires the participation of the file system. Ramdisk (see references) is a mechanism for creating and mounting a file system by using the computer's ram as a device. It is usually used for diskless systems (including micro-embedded devices, of course, it only contains flash chips used as permanent storage media ).

You can select a file system type based on reliability, robustness, and/or enhanced features. The next section describes several available options and their advantages and disadvantages.

Version 2 extended File System (ext2fs)
Ext2fs is the de facto standard file system for Linux and has replaced its predecessor-extended File System (or extfs ). The maximum file size supported by extfs is 2 GB, and the maximum file name size supported is 255 characters-and it does not support index nodes (including data modification time tags ). Ext2fs is better; its advantages are:

Ext2fs supports up to 4 TB of memory.
The ext2fs file name can contain a maximum of 1012 characters.
When creating a file system, the administrator can select the logical block size (typically 1024, 2048, and 4096 bytes ).
Ext2fs implements a fast symbolic link: you do not need to allocate data blocks for this purpose, and store the target name directly in the inode table. This improves performance, especially in terms of speed.

Because of the stability, reliability, and robustness of the ext2 file system, ext2 file systems are used in almost all Linux-based systems, including desktops, servers, workstations, and even some embedded devices. However, when using ext2fs in embedded devices, it has some disadvantages:

Ext2fs is designed for Block devices like ide devices. The logical block size of these devices is a multiple of 512 bytes and 1 K bytes. This is not suitable for flash devices with different slice sizes.
The ext2 file system does not provide good management of sector-based erasure/write operations. In ext2fs, to erase a single byte in a single sector, the entire sector must be copied to ram, erased, and overwritten. This is not a particularly good method considering the limited lifetime of Flash devices (which can be erased about 100,000 times) that cannot be used afterwards.
In the case of a power failure, ext2fs does not prevent the crash.
The ext2 file system does not support loss balancing, thus shortening the slice/flash life. (Wear/tear balancing ensures that different areas of the address range are used in turn for write and/or erase operations to prolong the life of Flash devices .)
Ext2fs has no perfect sector management, which makes it very difficult to design a block driver.

For these reasons, MTD/jffs2 combination is a better choice in an embedded environment than ext2fs.

Mount ext2fs with ramdisk
By using the ramdisk concept, you can create and mount an ext2 File System (and any file system used for this purpose) on an embedded device ).

Listing 6. Create a simple ramdisk mke2fs-vm0/dev/Ram 4096 Based on ext2fs
Mount-T ext2/dev/RAM/mnt
CD/mnt
CP/bin,/sbin,/etc,/dev... files in mnt
CD ../
Umount/mnt
Dd If =/dev/Ram BS = 1 k count = 4096 of = ext2ramdisk

Mke2fs is a utility used to create an ext2 File System on any device-It creates Super blocks, index nodes, and index node tables.

In the above usage,/dev/Ram is the device on which 4096 ext2 file systems are built. Then, mount the device (/dev/Ram) to a temporary directory named/mnt and copy all necessary files. Once these files are copied, the file system will be uninstalled and the contents of the device (/dev/Ram) will be dumped to an ext2ramdisk, it is the required ramdisk (ext2 File System ).

In the above Order, a 4 MB ramdisk is created and filled with the necessary file utility.

Important directories to be included in ramdisk are:

/Bin-stores most binary files such as init, busybox, shell, and file management utility.
/Dev-contains all the device nodes used in the device
/Etc-contains all configuration files of the system
/Lib-contains all necessary libraries, such as libc and libdl

Log FLASH file system, Version 2 (jffs2)
Axis Communications in Sweden developed the initial jffs, which was improved by David Woodhouse of Red Hat. The second version, jffs2, appears as the actual file system of the original flash chip used for micro-embedded devices. The jffs2 file system is log structured, which means that it is basically a long column node. Each node contains part of information about the file, which may be the file name or data. Compared with ext2fs, jffs2 is increasingly popular in diskless embedded devices due to the following advantages:

Jffs2 performs flash erasure/Write/read operations on the sector level, which is better than the ext2 file system.
Jffs2 provides better crash/power loss security protection than ext2fs. When a small amount of data needs to be changed, the ext2 File System copies the entire sector to the memory (Dram), merges new data in the memory, and writes it back to the entire sector. This means that in order to change a single word, a READ/Erase/Write routine must be executed for the entire sector (64 KB)-This is very inefficient. If luck is poor, a power failure or other accident occurs when data is being merged in DRAM, the entire data set will be lost because the flash sector will be erased after the data is read into dram. Jffs2 attaches files instead of overwriting the entire sector, and features crash/power-down security protection.
This may be the most important point: jffs2 is specially created for embedded devices like flash memory chips, so its entire design provides better flash memory management.

Because this article mainly describes the use of flash memory devices, jffs2 has few disadvantages in the embedded environment:

When the file system is full or near full, jffs2 will greatly slow down the running speed. This is because of garbage collection issues (for more information, see references ).

Create a jffs2 File System
In Linux, run the mkfs. jffs2 command to create a jffs2 File System (basically ramdisk of jffs2 ).

Listing 7. Create a jffs2 File System mkdir jffsfile
CD jffsfile

/* Copy all the/bin,/etc,/usr/bin,/sbin/binaries and/dev entries
That are needed for the filesystem here */

/* Type the following command under jffsfile directory to create the jffs2 image */

./Mkfs. jffs2-E 0x40000-p-o ../jffs. Image

The typical usage of mkfs. jffs2 is shown above. -E option determines the size of the erased sector (usually 64 KB) of the flash memory ). The-P option is used to fill the remaining space of the image with zero padding. -O option is used to output files, usually jffs2 file system image-in this example, jffs. image. Once a jffs2 file system is created, it is mounted to an appropriate location in the flash memory (The Boot Loader informs the kernel to find the address of the file system) so that it can be mounted to the inner nuclear energy.

Tmpfs
When Linux runs on an embedded device, the device becomes a fully functional unit. Many daemon processes run in the background and generate many log messages. In addition, all kernel logging mechanisms, such as Syslogd, dmesg, and klogd, generate many messages in the/var and/tmp directories. Since these processes generate a large amount of data, it is not advisable to allow all these write operations to occur in flash memory. Since these messages do not require persistent storage during reboot, the solution to this problem is to use tmpfs.

Tmpfs is a memory-based file system. It is mainly used to reduce unnecessary flash write operations on the system. Because tmpfs resides in Ram, write/read/erase operations occur in Ram rather than flash. Therefore, log messages are written to ram instead of flash memory and will not be retained during reboot. Tmpfs also uses disk swap space for storage, and uses the virtual memory (VM) subsystem when requesting pages for file storage.

Tmpfs has the following advantages:

Dynamic file system size-the file system size can be scaled based on the number of copied, created, or deleted files or directories. This makes it ideal to use memory.
Speed-since tmpfs resides in Ram, reading and writing are almost instantaneous. Even if files are stored in the form of exchanges, I/O operations are still very fast.

One disadvantage of tmpfs is that all data is lost when the system is rebooted. Therefore, important data cannot be stored on tmpfs.

Install tmpfs
Most other file systems, such as ext2fs and jffs2, reside on the underlying block device, while tmpfs is directly located on the VM. Therefore, it is very easy to install the tmpfs File System:

Listing 8. Install tmpfs/* entries in/etc/rc. d/rc. sysinit for creating/using tmpfs */

# Mount-T tmpfs/var-O size = 512 K
# Mkdir-P/var/tmp
# Mkdir-P/var/log
# Ln-S/var/tmp

The above command will create tmpfs on/Var and limit the maximum size of tmpfs to 512 K. At the same time, the tmp/and log/directories become part of tmpfs to store log messages in Ram.

If you want to add an item of tmpfs to/etc/fstab, it may look like this:

Tmpfs/var tmpfs size = 32 M 0 0

This will mount a new tmpfs File System on/var.

Gui options
From the user's point of view, the graphical user interface (GUI) is one of the most important aspects of the system: the user interacts with the system through the GUI. Therefore, the GUI should be easy to use and highly reliable. However, it also needs to be memory-aware so that it can be executed seamlessly on memory-limited and micro-embedded devices. Therefore, it should be lightweight and can be quickly loaded.

Another important aspect to consider involves license issues. Some GUI distributions have licenses that allow free use, even in some commercial products. Other licenses require royalty if you want to merge the GUI into your project.

Finally, most developers may choose xfree86, because xfree86 provides them with a familiar environment to use their favorite tools. However, the newer guis on the market, such as century software's Microwindows (nano-x) and trolltech's QT/embedded, are fiercely competitive with X in the embedded Linux arena, this is mainly because they occupy a small amount of resources, execute quickly, and have support for custom window components.

Let's take a look at each of these options.

Xfree86 4.x( x11r6.4 supported with frame buffer)
Xfree86 project, Inc. is a company that produces xfree86. This product is an X Window System that can be repeatedly distributed and open source for free. X Window System (X11) provides resources for applications to display images. It is the most common window system on UNIX and Unix-like machines. It is small but effective. It runs on a large number of hardware and is transparent to the network and well documented. X11 provides powerful functions for window management, event processing, synchronization, and communication between clients-and most developers are familiar with its APIs. It has built-in support for the kernel frame buffer and occupies a very small amount of resources-this is very helpful for devices with relatively small memory. The X Server supports VGA and non-VGA graphics cards. It supports color depth 1, 2, 4, 8, 16, and 32, and provides built-in rendering support. The latest release version is xfree86 4.1.0.

Its advantages include:

The use of Frame Buffer Architecture improves performance.
The occupied resources are relatively small-the size is within the range of 600 KB to 700 KB, which makes it easy to run on small devices.
Excellent support: There are many documents available online and many mailing lists dedicated to xfree86 development.
X api is very suitable for expansion.

Its Disadvantages include:

It has poor performance than the recent embedded GUI tools.
In addition, xfree86 seems to require more memory than the latest development in the GUI, such as nano-X or QT/Embedded-designed specifically for Embedded environments.

Microwindows
Microwindows is an open-source project of century software and is designed for Micro Devices with small display units. It has many functional components for Modern Graphic Windows environments. Like X, there are multiple platforms that support Microsoft Windows.

The Microwindows architecture is client/server-based and hierarchical. The bottom layer is the screen and the input device driver (about the keyboard or mouse) to interact with the actual hardware. In the middle layer, the portable graphics engine supports line drawing, area filling, polygon, cropping, and color models.

At the top layer, Microwindows supports two types of Apis: Win32/wince API implementation, known as Microwindows. The other API is very similar to gdk, which is called Nano-X. Nano-X is used in Linux. It is an API like x used for applications that consume less resources.

Microwindows supports the palletized display of 1, 2, 4, and 8 BPP (number of digits per pixel), as well as true color display of 8, 16, 24, and 32 BPP. Microwindows also supports faster frame buffers. The nano-X Server occupies approximately 100 kb to 150 kb of resources.

The average size of the original nano-x application is 30 K to 60 K. Because nano-X is designed for low-end devices with memory restrictions, it does not support many functions as X does, so it cannot be used as a replacement for Micro X (xfree86 4.1.

You can run flnx on Microsoft Windows. It is a version of the fltk (fast light Toolkit) application development environment for nano-X instead of X. This article describes fltk.

The advantages of nano-x include:

Unlike xlib, nano-X is still running on each client. This means that once a client request packet is sent, the server waits until it provides services to another client, until the entire package arrives. This makes the server code very simple, and the running speed is still very fast.
Occupies a small amount of resources

Disadvantages of nano-x include:

The network components have not been properly adjusted (especially network transparency ).
There are not many ready-made applications available.
Compared with X, although nano-X is currently under accelerated development, there are still not so many documentation instructions and there is no good support, but this situation will change.

Fltk API on Microwindows
Fltk is a simple but flexible GUI toolbox that has gained more and more attention in the Linux world. It is especially suitable for environments with few resources. It provides most of the window components you want to obtain from the GUI toolbox, such as buttons, dialog boxes, text boxes, and excellent "value assignment" Selections (the window component used to input values ). It also includes slide, scroll bars, dial, and other components.

The Linux version of fltk for the Microwindows GUI engine is called flnx. Flnx consists of two components: fl_widget and fluid. Fl_widget consists of all basic window component APIs. Fluid (fast light User Interface Designer (fluid) is a graphic editor used to generate fltk source code. In general, flnx is an excellent UI builder that can be used to create applications for Embedded environments.

Fl_widget occupies approximately 40 K to 48 k resources, while fluid (including each window component) occupies approximately 380 K. These very small resource usage make fl_widget and fluid very popular in the embedded development world.

Advantages include:

Anyone who is used to developing Gui-based applications in a better environment like Windows can easily adapt to the fltk environment.
Its documentation includes a very complete and well-written manual.
It uses lgpl for distribution, so developers can flexibly issue licenses for their applications.
Fltk is a C ++ Library (Perl and Python binding are also available ). The choice of object-oriented models is a good choice, because most modern GUI environments are object-oriented, which also makes it easier to transplant written applications to similar APIs.
The century software environment provides several useful tools, such as screentop and viewml browsers.

Its disadvantage is:

Common fltk can work with X and Windows APIs, but flnx cannot. Its incompatibility with X hinders its use in many projects.

QT/embedded
QT/Embedded is a new graphic user interface system developed by trolltech for Embedded Linux. Trolltech initially created Qt as a cross-platform development tool for Linux desktops. It supports various Unix-specific systems and Microsoft Windows. KDE-one of the most popular Linux desktop environments is written using QT.

QT/Embedded is based on the original QT and has made many outstanding adjustments for Embedded environments. Qt embedded interacts directly with Linux I/O facilities through QT APIs. Those who are familiar with and have adapted to object-oriented programming will find it an ideal environment. Moreover, the object-oriented architecture makes code structured, reusable, and fast to run. Compared with other guis, qt gui is very fast and has no layering, making QT/embedded the most compact environment for running QT-based programs.

Trolltech also launched the QT palm machine environment (QT palmtop environment, also known as qpe ). Qpe provides a basic desktop window, and the environment provides an easy-to-use interface for development. Qpe includes a full set of personal information management (PIM) applications, Internet clients, utilities, and so on. However, to integrate QT/embedded or qpe into a product, you need to obtain a commercial license from trolltech. (The original QT version can be obtained based on GPL after version 2.2 .)

Its advantages include:

Object-oriented architecture facilitates faster execution
Occupies a small amount of resources, about 800 K
Pixel ing between anti-sawtooth text and mixed videos

Its disadvantage is:

QT/embedded and qpe can only be used when a commercial license is obtained.

Conclusion
Embedded Linux development is developing rapidly. You must learn and make choices from the various options of the boot loader and distribution to everything in the file system and GUI. But thanks to the freedom of choice and the very active Linux community, embedded development on Linux has reached a new realm, and it is never easier to adjust modules to suit your specifications. This has led to the emergence of many new handheld and micro-devices as open boxes, this is a good thing-the fact is that you don't have to become an expert to choose from these modules to adjust your device to meet your own requirements and needs.

We hope that this introductory introduction to the field of Embedded Linux will stimulate your desire to experiment, and you will enjoy the fun of playing with micro-devices to satisfy your interests. For further assistance in your project, refer to the "references" below to link to more in-depth information about the technology we have outlined here.