Differences Between ARM-Linux Development and MCU Development

Regarding the development of ARM-Linux programs, it is mainly divided into three categories: application development, driver development, and system kernel development. Different types of software development have their own characteristics. Today, let’s take a look at the differences between ARM-Linux development and MCU development, as well as the basic development environment for ARM-Linux.

1. Differences Between ARM-Linux Application Development and MCU Development

First, it should be noted that there are mainly two ways to develop applications for ARM: one is to develop applications directly on the ARM chip without using an operating system, also known as bare-metal programming. This development method is mainly applied to some low-end ARM chips, and the development process is very similar to that of microcontrollers, which will not be elaborated on here. The other method is to run an operating system on the ARM chip, requiring the writing of corresponding driver programs for hardware operations, and application development is based on the operating system. This method of embedded application development has significant differences from microcontroller development. The main differences between ARM-Linux application development and microcontroller development are as follows:

(1) Different hardware devices for application development

Microcontroller: Development board, emulator (debugger), USB cable;

ARM-Linux: Development board, network cable, serial cable, SD card;

For ARM-Linux development, typically there is no hardware debugger, especially during application development, where hardware debuggers are rarely used. Program debugging is mainly done through the serial port; however, it should be noted that there are hardware emulators for ARM chips, but they are usually used for bare-metal development.

(2) Different methods for program downloading

Microcontroller: Download via emulator (debugger) or serial port;

ARM-Linux: Download via serial port, tftp network download, or directly read/write SD, MMC cards, etc., to achieve program download;

This is directly related to the hardware devices in the development environment. Due to the absence of a hardware emulator, ARM-Linux development typically does not use emulator downloads; while this may seem inconvenient, it actually provides more downloading options for ARM-Linux application development.

(3) Different hardware resources of the chips

Microcontroller: Usually a complete computer system, including on-chip RAM, on-chip FLASH, and various peripherals such as UART, I2C, AD, DA;

ARM: Usually has only the CPU, requiring external circuits to provide RAM for normal operation, and external circuits to provide FLASH, SD card, etc., for storage system images, implementing various peripheral functions through external circuits. Due to ARM chips’ strong processing capabilities, various complex functions can be achieved through external circuits, far exceeding those of microcontrollers.

(4) Different storage locations for firmware

Microcontroller: Usually has on-chip flash memory, and firmware programs are typically stored in this area. If the firmware is large, external flash needs to be designed for firmware storage.

ARM-Linux: Due to the lack of on-chip flash and the need to run an operating system, the entire system image is usually large, thus the operating system image and applications for ARM-Linux development are typically stored on external MMC, SD cards, or using SATA devices, etc.

(5) Different boot methods

Microcontroller: Its structure is simple, with internal integrated flash, and usually, the chip manufacturer adds fixed jump instructions at power-on to jump directly to the program entry (usually in flash); the developed application program is compiled and directly downloaded to the corresponding address space using a dedicated downloading tool; thus, when the system is powered on, it directly runs to the corresponding program entry, achieving system startup.

ARM-Linux: Due to the use of ARM chips, which have high execution efficiency and powerful functions, and relatively rich peripherals, it is a powerful computer system that requires running an operating system. Therefore, its startup method is significantly different from that of microcontrollers, but is basically the same as that of home computers. Its startup generally includes BIOS, bootloader, kernel startup, application startup, and other stages;

(a) Startup BIOS: BIOS is the corresponding startup information set by the device manufacturer (chip or circuit board manufacturer). After the device is powered on, it reads the corresponding hardware device information, performs hardware device initialization, and then jumps to the location of the bootloader (a fixed position set by BIOS). (According to personal understanding, the startup of BIOS is similar to that of microcontrollers, requiring the use of corresponding hardware debuggers to write firmware stored in a certain flash space. When the device is powered on, it reads the instructions in the flash space to start the BIOS program.)

(b) Bootloader startup: This part belongs to the embedded Linux software development section, where the bootloader program can be customized by modifying the code. The bootloader is usually downloaded by directly reading/writing to the SD card. That is, a customized bootloader is written, compiled to generate a bootloader image file, and then downloaded to the MBR area of the SD card (usually the first sector of the storage area) using a tool (dedicated or general). At this time, it is necessary to set in the BIOS or through the hardware circuit of the circuit board to select the bootloader loading location; if the BIOS is set to boot from the SD card, then after the BIOS initialization is completed, it will jump to the location of the SD card to execute the bootloader, thus achieving bootloader startup.

The main function of the bootloader is to initialize necessary hardware devices, create some information needed by the kernel, and pass this information to the kernel through related mechanisms, thus bringing the system’s software and hardware environment to a suitable state, ultimately calling the operating system kernel, effectively serving to boot and load the kernel.

(c) Kernel startup: After the bootloader completes its initialization and related tasks, it will call the kernel startup program. This enters the actual startup of the operating system-related content, including the startup of the corresponding hardware configuration, task management, resource management, and other kernel programs.

(d) Application startup: After the operating system kernel starts, it can begin to start the required applications to complete the actual business operations.

2. Basic Development Environment for ARM-Linux