ARM development steps

嵌入式十年

ARM development steps [Copy link]

Make a minimum system board: If you have never done ARM development, it is recommended that you do not be greedy and try to complete all the applications at the beginning, because the startup method of ARM is different from that of dsp or microcontroller, and often encounters various problems. Therefore, it is recommended to first build a small system board with only Flash, SRAM or SDRAM, CPU, JTAG, and reset signal, leaving room for expansion interface. If you can make the minimum system run normally, your task is half done. Fortunately, the peripheral interfaces of ARM are basically standard interfaces. If you have experience in wiring these hardware, it is a very easy thing for you. 2. Write the startup code. According to the hardware address, first write a small code that can be started, including the following parts: Initialize the port, shield the interrupt, copy the program to SRAM; complete the remapping of the code; configure the interrupt handle and connect it to the C language entry. Maybe you see that in some sample programs given to you, bootloaderwill have a lot of things, but don't be bothered by these complicated programs, because you are not making a development board, your task is to make a small program to make your application run. 3 Carefully study the information of the chip you are using. Although ARMis compatible in the kernel, each chip has its own characteristics, and these issues must be considered when writing programs. Especially girls, don't be dependent here, always want to modify other people's sample programs, but the more you modify them, the more messy they become. 4． Look at more operating system programs. There are many open source programs for ARM applications. If you want to improve yourself, you should look at other people's programs. Linux, uc/os-II, etc. are all very good source codes. 5. If you are working on hardware, each manufacturer basically has a DEMO board schematic for the chip. Digest the schematic first. In this way, when you design in the future, you will have a clear idea of the allocation of resources. The DATSHEET of the device must be digested well. 6.If you are doing software, it is best to have some understanding of the mechanism of the operating system. Of course, this is a piece of cake for software engineers. But if you are a hardware engineer, it is a bit difficult. Q: Is it better to make a minimum system board with 2 layers or 4 layers? A: Only AT91 can use a two-layer board, and the others can use at least 4 layers; 44b0 can also use a two-layer board if the ground and power supply are well handled; Talking about four-layer boards and 33 ohm resistors: Choosing a four-layer board is not only a matter of power and ground. High-speed digital circuits have requirements for the impedance of the routing, and it is difficult to control the impedance of a two-layer board. 33 ohm resistors are usually added to the driver end, which also plays the role of impedance matching. When wiring, the data address line and the high-speed line that needs to be guaranteed should be laid out first. At high frequencies, the traces on the PCB board should be considered as transmission lines. Transmission lines have their characteristic impedance. Those who have studied transmission line theory know that when there is a sudden impedance change (mismatch) somewhere on the transmission line, the signal will be reflected, and the reflection will interfere with the original signal. In serious cases, it will affect the normal operation of the circuit. When using a four-layer board, the outer layer usually has signal lines, and the middle two layers are power and ground planes. This isolates the two signal layers. More importantly, the outer layer's lines and the planes they are close to form a transmission line called a microstrip, which has a relatively fixed impedance and can be calculated. This is more difficult to do for a two-layer board. The impedance of this transmission line is mainly related to the width of the line, the distance to the reference plane, the thickness of the copper cladding, and the characteristics of the dielectric material. There are many ready-made formulas and programs for calculation. A 33 ohm resistor is usually connected in series at one end of the driver (in fact, it is not necessarily 33 ohms. It can range from a few ohms to fifty or sixty ohms, depending on the specific situation of the circuit). Its function is to match the impedance of the trace after being connected in series with the output impedance of the transmitter, so that the signal reflected back (assuming that the impedance at the receiving end is not matched) will not be reflected back again (absorbed), so the signal at the receiving end will not be affected. The receiving end can also be matched, for example, by using resistors in parallel, but it is rarely used in digital systems because it is more troublesome, and in many cases, one send and multiple receive, such as the address bus, which is not as easy to do as the source end matching. The high frequency mentioned here does not necessarily mean a circuit with a very high clock frequency. Whether it is a high frequency depends not only on the frequency, but more importantly on the rise and fall time of the signal. Usually, the rise time (or fall time) can be used to estimate the frequency of the circuit. Generally, half of the reciprocal of the rise time is taken. For example, if the rise time is 1ns, then its reciprocal is 1000MHz, which means that when designing the circuit, it is necessary to consider the frequency band of 500MHz. Sometimes it is necessary to deliberately slow down the edge time. Many high-speed ICs have adjustable output slopes for their drivers. Building embedded Linux Linux has a complete set of tool chains, which makes it easy to build an embedded system development environment and a cross-running environment by yourself, and can overcome the barriers of simulation tools (ICE) in embedded system development. The complete openness of the kernel allows people to design and develop real hard real-time systems by themselves, and soft real-time systems can also be easily implemented in Linux. Powerful network support allows Linux to use its network protocol stack to develop it into an embedded TCP/IP network protocol stack. Linux provides the basic kernel for completing embedded functions and all the required user interfaces. It is multifaceted. It can handle embedded tasks and user interfaces. A small embedded Linux system only needs the following three basic elements: * Boot tool * Linux microkernel, which consists of memory management, process management and transaction processing * Initialization process If you want it to be able to do something and continue to keep it small, you have to add: * Hardware driver * One or more applications that provide the required functionality. To add more functionality, you might need the following: * A file system (perhaps in ROM or RAM) * TCP/IP network stack Below we will introduce the actual development of embedded Linux in four steps: streamlining the kernel, system startup, driver installation, and replacing X-Window with MicroWindows. The commonly used commands for constructing the streamlined kernel include: make config, dep, clean, mrproper, zImage, bzImage, modules, and modules_install. The command description is omitted. Now let me give you an example: I am using the 2.2.15 included with Mandrake. I did not modify any line of code, and only modified the configuration file to get these data. First, use make config to remove all the options that can be removed. Don't use floppy; don't use SMP and MTRR; don't use Networking and SCSI; remove all block devices and leave only the old IDE device; remove all character devices; remove all filesystem Remove all the options, leaving only minix; no sound support. Believe me, I have removed all the options. After doing this, I got a 188K kernel. Isn't it small enough? OK, one more trick, please replace -O3, -O2 in the following two files with -Os. ]./Makefile ./arch/i386/kernel/ Makefile This way, the whole kernel size was reduced from 9K to 179K. However, this kernel may not be able to fully play the functions of Linux, so I decided to add the network back. Add network support in General and recompile the kernel, and the kernel size became 189K. Adding a TCP/IP stack to the 10K kernel seems to be a good deal. It is useless to have a stack without a driver, so I added the RTL8139 driver commonly used in embedded boards, 195K. If you need a DOS file system, the size becomes 213K. If minix is replaced by ext2, the size grows to 222K. The memory required for Linux is about 600K to 800K. 1MB of memory may be enough to boot the system, but it is not very useful because it has difficulty loading the C library. 2MB of memory should be enough to do some work, but 4MB or more is needed to run a relatively complete system. This is because the Linux filesystem is quite large, about 230K, which accounts for 1/3 of the size of the kernel. Memory management takes up 80K, which is about the same as the sum of the rest of the kernel. The TCP/IP stack takes up 65K, and the drivers take up 120K. SysV IPC takes up 21K and can be removed if necessary. The kernel file should be about 10K smaller. If you want to reduce the kernel size, where should you move? The answer is obvious: the file system. Linux VFS simplifies the design of the file system, and buffer cache and directory cache increase the efficiency of the system. But these embedded systems are not very useful. If they can be removed, the kernel can be reduced by about 20K immediately. If you skip the entire VFS and write the file system directly as a driver, you should be able to reduce the size of 230K to about 50K. The entire kernel is reduced to about 100K. System startup The system's boot sequence and related files are still in the kernel source directory. See the following files: ./arch/$ARCH/boot/ bootsect.s ./arch/$ARCH/boot/setup.s ./init/main.c bootsect.S and setup.S This program is the first program of the Linux kernel, including Linux's own bootstrap program. But before explaining this program, we must first explain the general actions of an IBM PC when it is turned on (the startup here means "turning on the power of the PC")]. Generally, when a PC is powered on, it starts executing from the address FFFF:0000 in the memory (this address must be in the ROM BIOS, ROM The BIOS is usually in FEOOOh to FFFFFh), and the content here is a jump instruction, which jumps to another location in the ROM BIOS and starts to execute a series of actions. Immediately after the system test code, control will be transferred to the startup program (ROM bootstrap routine) in ROM. This program will read the zeroth track and zeroth sector on the disk into the memory. Where is it read into the memory? --The absolute position 07C0:0000 (that is, 07C00h) This is a feature of the IBM series PC. The boot sector of the Linux boot disk is the Linux bootsect program. Let's make a rough comparison between the well-known MS DOS and Linux boot parts. MS DOS has the boot sector on the disk responsible for loading IO.SYS into memory, and IO.SYS is responsible for loading the DOS kernel --MSDOS.SYS into memory. In Linux, the bootsect program located in the boot sector is responsible for loading setup and the Linux kernel into memory, and then passing control to setup. Driver In the Linux system, the set of entry points provided by the device driver is described to the system by a structure. The entry points provided by the device driver are registered with the system when the device driver is initialized so that the system can call them at the appropriate time. In Linux, register_chrdev is called to register a character device driver. In Linux, in addition to directly modifying the source code of the system kernel and adding the device driver to the kernel, the device driver can be used as a loadable module and dynamically loaded by the system administrator to make it part of the kernel. The loaded module can also be dynamically unloaded by the system administrator. In Linux, modules can be written in C and compiled into target files (without linking, as *.o file exists). To do this, you need to add the -c parameter to the gcc command line. After successfully registering the device driver with the system (after successfully calling register_chrdev), you can use the mknod command to map the device to a special file. When other programs use this device, they only need to operate on this special file. Replace X-Window with MicroWindows MicroWindows uses a layered design approach. It allows different layers to be changed to suit actual applications. At the bottom layer, drivers for the screen, mouse/touch screen, and keyboard are provided, allowing programs to access actual hardware devices and other user-defined devices. In the middle layer, there is a lightweight graphics engine that provides methods for drawing lines, filling areas, drawing polygons, clipping, and using color modes. At the top layer, different APIs are provided for graphics applications to use. These APIs may or may not provide desktop and window appearance. Currently, MicroWindows supports Windows Win32/WinCE GDI and Nano-X API. These APIs provide tight compatibility between Win32 and X window systems, making it easy to port other applications to MicroWindows. For technical advice, please add Q2537161284.

kkmugs

chicken soup