What are the tools and environmental requirements required to develop an embedded system?
ARM processors are popular worldwide, and 32-bit RISC embedded processors have become the mainstream of embedded applications and designs. Compared with 8-bit single-chip microcomputers that are widely used in China, 32-bit embedded CPUs have great advantages. It brings rich hardware functions and additional performance to embedded designs, making the entire embedded system upgrade only through software. Upgrade can be achieved.
The 64K software limitation that 8-bit processors usually suffer from is no longer there. Designers can almost choose a multi-tasking operating system, and design the application software to be complicated and huge, truly reflecting the design idea of "hardware and software". At present, there are many engineers familiar with the development of 8-bit processors in China, the development tools and means are also abundant, and the prices are low. The development of 32-bit processors differs significantly from the development of 8-bit processors.
First, the real-time multitasking operating system (RTOS) introduced 32-bit embedded systems. Because the 32-bit CPU is rich in resources, the instruction set is relatively large, and the system software is relatively complex, it is usually necessary to choose the corresponding RTOS when scheduling the various tasks in the application software. Software design engineers need to learn the new RTOS technology and master the design and debugging methods of the underlying software, system software and application software. This is a new challenge for developers. Of course, the introduction of RTOS will also bring the benefits of modularization and portability of software to embedded developers, and prepare for software engineering management.
Second, the hardware interface for debugging has changed. When developing an 8-bit processor, an in-circuit simulator (ICE) is usually used. The ICE uses a socket or a corresponding fixture to replace the CPU for simulation and development work. For a 32-bit embedded processor, because of its too high clock frequency (50MHZ to 400MHZ or more) and complex packaging (such as BGA), ICE is difficult to do the job of development tools. CPU manufacturers use the boundary scan interface (JTAG port) to provide debugging information for developers to develop. The JTAG port is usually a 14Pin or 20Pin socket. The JTAG debugger (or JTAG emulator) can simplify the design of the product because it can directly obtain debugging information from the CPU, which makes the price lower than ICE.
Third, the way the system is developed has changed. For an 8-bit system development, the designer only needs to follow the processes of hardware design and debugging, software (assembly or C language) programming, positioning guidance, software debugging, and system debugging. Application software development is usually Behind the hardware, and application software packages are not universal.
This is different for a 32-bit embedded system. While designing and developing the hardware, a real-time multitasking operating system environment is required, and software engineers can simultaneously develop and debug application software packages. At the end of hardware debugging, BSP (Board Support Package) design and debugging should be performed. After the BSP debugging is passed, the joint debugging of the system software and the application software can be performed. The development of application software can usually be done separately. After changing the CPU or hardware platform, the application software package is universal (based on the same RTOS).
So, what tools and environments are needed to develop a 32-bit embedded system? First you need to choose a suitable multitasking operating system. At present, there are many commercial RTOS, such as Linux, Nucleus, WinCE, VxWorkx and so on. Users can choose the appropriate one according to the technical and commercial requirements of the system. In addition, you must choose the appropriate compilation tool and debugging environment. Determine which compiler to use based on the RTOS and programming language you choose (C or C ++). For ARM series CPUs, the more common ones are ARM's SDT and ADS, and free GNU.
Many manufacturers provide the compiler (Compiler), linker (Linker), locator (Locater), simulator (Simulator) and monitor debugger (Monitor Debugger) as a whole to the user. This is often called an Integrated Development Environment (IDE). Choosing an IDE will bring a lot of convenience to debugging.
Furthermore, it is necessary to choose a suitable JTAG emulator. One end of the JTAG emulator is connected to the target board through a JTAG connection cable, and the other end is connected to the host's debugging environment. There are usually three ways to connect to the host. One is parallel port, one is USB port, and the other is network port. These three methods are different in terms of code download speed, connection convenience, and debugging resource sharing. Users can choose according to the actual situation such as funding, technical solution requirements, and host environment. In addition, the main frequency of JTAG is also an important technical indicator that affects the speed of the JTAG emulator. The faster the JTAG emulator, the higher the JTAG frequency.
Similar to the ICE development method, the JTAG emulator also provides a logic trace function to ensure the smooth execution of hardware debugging and software-hardware joint tuning. This feature requires additional cost, so it is recommended to purchase it only for complex system-level development projects.
A good JTAG emulator should also support task-level debugging. In addition to its rich debugging functions and a good debugging interface, its debugging environment should also be able to "know" various RTOS types. In this way, users can directly perform various tasks when debugging software based on RTOS. If the JTAG emulator cannot support task debugging, it will cause a lot of inconvenience to the software development engineer and affect the development progress. There are unique technical difficulties in the development of 32-bit embedded systems, so developers must be fully psychologically prepared and make corresponding countermeasures.
After the development and debugging of BSP is completed, the real-time operating system (RTOS) must be transplanted. The most important one is the development and debugging of BSP. In the entire embedded system, application software completes various application functions by calling the system software. The system software completes the handshake connection with the hardware device through the BSP. Therefore, the performance of the BSP will affect the reliability of the entire system.
Because the development environment provided by operating system (RTOS) vendors is established based on the normal work of the BSP, users can only "see" the entire system hardware resources after the BSP works normally. Therefore, before this, users debug the BSP almost in the "blind". BSP development and debugging sometimes takes one to two months or even longer.
There don't seem to be many solutions. The first is to improve the level of engineers, and strengthen the learning in terms of the mastery of the CPU, the familiarity of the target board hardware and peripheral drive equipment, an in-depth understanding of the operating mechanism of the operating system (RTOS), and the resource allocation of the system; Or other tools.
The parallel development of application software is becoming shorter and shorter due to the increasingly fast market requirements. This inevitably requires that software development can be performed at the same time as hardware development. On the one hand, users can develop part of the software on a standard evaluation board, and then perform system-level debugging and development after the actual target board hardware and BSP are completed. On the other hand, users can use the virtual environment provided by real-time operating system (RTOS) vendors for software development and debugging, and the software to be developed and debugged has almost no restrictions. After the actual hardware platform is completed, you only need to recompile and connect, and then you can download and run it on the target. Note that when using RTOS, increase the tool environment.
If you want to know more, our website has product specifications for the embedded system， you can go to ALLICDATA ELECTRONICS LIMITED to get more information