Use ads1.2 for embedded software development (I)

Overview
Embedded applications are usually debugged and developed in a prototype environment, which is not exactly the same as the final product. Therefore, it is very important to consider the running status of applications in the final target hardware during system debugging.
This article aims to discuss how to transfer an embedded application in a development/debugging environment to a target system that ultimately runs independently, it also mentions some features of the arm ads1.2 Development Kit and their roles in this process.

When using ads to develop embedded programs, you must consider the following issues:
1. Use of hardware-related C language library functions;
2. Some C language library functions use resources in the debugging environment and redirect these resources to the hardware in the target system;
3. Memory ing of executable image files must be cropped Based on the memory distribution of the target hardware;
4. Before the main program is executed, the embedded application must initialize the system. A complete initialization includes the user's startup and Execution Code and the initialization process of the C library function in ads.

 

Figure 1 example of semihosting

Figure 2 C Language Library Function Structure

Figure 3 default memory ing

Figure 4 connector layout rules

Default Project Settings
At the beginning of an embedded application software development, ADS users may not fully understand some parameter indicators of the target hardware. For example, some details about peripherals, memory address distribution, and even the processor type may not be finalized yet. To develop software before all these details are ready, the ads tool has a set of default settings for program building and debugging. Understanding this set of default project settings is very helpful for understanding the final porting steps.

Ads1.2c function library
Semihosting
In the C language function library of ads, some ansic functions are provided by the debugging environment of the host. This mechanism is called semihosting. Semihosting is implemented through a set of software interrupt (SWI) commands. 1. When a semihosting Soft Interrupt is executed, the debugging system first identifies the SWI request, then suspends the running program, calls the semihosting service, and resumes the original program execution. Therefore, the tasks executed by the host are transparent to the program.

C Language Library Function Structure
In terms of concept, C language library functions can be divided into two parts: one is part of the ansic language specification itself, and the other is only supported by a specific ansic level, as shown in 2.
Some ansic functions are completed by calling driver-level functions in the host debugging environment. For example, the library function printf () of ADS outputs the output information to the console window of the debugger. This function is implemented by calling _ sys_write (), __sys_write () A semihosting Soft Interrupt service program that outputs the string to the host console is executed.

Default memory ing
If you do not specify the memory ing distribution of the image during program compilation, ADS will allocate a default memory ing map for the generated target code and data, as shown in figure 3.
The target impression is connected to the address 0x8000, and the storage and execution areas are all located in the space starting from this address. The RO (read-only) part is placed in front, followed by the RW (read/write) part, and the Zi (zero initialization) part.
Heap is followed on the Zi part, so the exact heap address can be determined only during connection.
The base address of the stack is provided by a semihosting operation when the application starts. The address value returned by this semihosting operation depends on the debugging environment:
Armulator returns the Setting Value in the configuration file peripherals. ami. The default value is 0x08000000.
Multi-ice returns the value of $ top_of_memory In the debugger. The default value is 0x00080000.

Connector layout rules
The connector allocates code and data in the memory system according to a set of rules, as shown in figure 4.
The image is first arranged in the order of RO-RW-ZI by attributes, and the code in the same attribute is prior to the data. The connector then sorts the input segments alphabetically by their names. The names of the input segments are the same as those in the assembly code (the area keyword is used in the assembly program ). In the input segment, the order of code and data placement from different objects is the same as the order of object Files specified in the connector command line.
We recommend that you do not simply rely on these rules when you need to flexibly allocate code and data placement. The following describes how to control the code and Data Layout in scatterloading.

Figure 5 default ads initialization process

Figure 6 function redirection in library C

Figure 7 scatter File Syntax

Figure 8 simple example of Distributed Loading

Start the application
Most embedded systems have an initialization process before entering the application main program, which completes the system startup and initialization functions. The default ads initialization process is shown in step 5.
In general, the initialization process can be divided into two parts:
_ Main is responsible for setting the running image memory ing;
_ Rt_entry initializes the library function.
_ Main completes code and data copying and clears the Zi data zone. This step makes sense only when the code and data areas are in different storage locations during storage and runtime. Next, _ main jumps into _ rt_entry to initialize the stack and heap. Finally, _ rt_entry jumps into the main () Entry of the application (). When the application is executed, _ rt_entry returns the control to the debugger.
The main () function has special significance in ads. When a program project contains main (), the connector connects the initialization code in _ main and _ rt_entry. Without the main () function, the initialization process will not be connected, as a result, some standard C library functions are invalid.

Cut C-database functions according to the target environment
By default, the C library function uses the semihotsting mechanism to implement the device-driven function. However, a real embedded system uses peripherals or hardware to run independently of the host environment.
C library function redirection
You can define your own C-language library functions. These new functions are automatically used by the connector during connection. This process is called the function of redirecting the C language library, as shown in figure 6.
For example, a user has an I/O device (such as UART ). The original library function fputc () Outputs characters to the debugger control window, but the user changes the output device to the UART port, so that all () the printf () Series Function outputs of the function are redirected to the UART port.
The following is an example of implementing fputc () redirection:
Extern void sendchar (char * Ch );
Int fputc (int ch, file * F)
{/* E. g. Write a character to an UART */
Char tempch = CH;
Sendchar (& tempch );
Return ch;
}
In this example, the input character is simply redirected to another function sendchar (). sendchar () is assumed to be another defined serial output function. Here, fputc () is like an abstraction layer between the target hardware and the Standard C library functions.

Disable semihosting in C language library functions
In an independent embedded application, the semihostingswi operation should not exist. Therefore, you must ensure that semihosting is not used in all the called library functions. To ensure this, a symbolic keyword _ use_no_semihosting can be introduced in the program:
In the C code, use # prgrama # pragmaimport <_ use_no_semihosting_swi> 〉
In the assembler, use import
Import_use_no_semihosting_swi
In this way, when a library function using the SWI mechanism is connected, the connector reports an error:
Error: symbol_semihosting_swi_guardmultiplydefined
To determine which function is used, enable the-verbose option during connection. In this way, the library function will have a tag of _ I _use_semihosting_swi when the result information is output.
Loadingmembersys_wxit.ofromc_a_un.1.
Definition: _ sys_exit
Reference: _ I _use_semihosting_swi
You must define these functions as your own execution content.
Note that the connector can only report the semihosting called in the library function, and no error is reported for the semihosting used in the User-Defined Function.

Memory ing customized based on target hardware
Scatlerloading)
In the actual embedded system, the default memory ing provided by ADS cannot meet the requirements. Your target hardware usually has multiple memory devices located in different locations, and these memory devices may have different configurations during program loading and running.
Scattertoading can specify different locations of a piece of code or data in the memory during loading and running through a text file. The scatterfile is specified by the-scatter switch in the command line. For example:
Armlink_scatterscat.scffilel.ofile2.0
In scatterfile, you can specify different storage region addresses for each code or data zone during loading and execution. The storage block of scatlertoading can be divided into two types:
Load area: The Storage Area of the application when the system starts or loads.
Execution zone: the memory zone for application execution and data access after the system starts. The system can have one or more execution blocks during real-time operation.
All the code and data in the image have a loading address and an operational address (the two may be the same or different, depending on the situation ). When the system starts, the _ main initialization code in the C function library performs the necessary copying and resetting operations to transfer the corresponding code and Data Segment of the application from the loading status to the execution status.
1. Scatter File Syntax
The scatter file is a simple text file that contains some simple syntax.
My_region 0x0000 0x1000
{
The context of Region
}
Each block is defined by a header title. The header contains at least the block name and start address, and the maximum length and other attribute options. The content of the block definition is included in a pair of curly braces that depend on specific system conditions.
A loading block must contain at least one execution block. In practice, multiple execution blocks are usually used.
An execution block must contain at least one code or data segment. These are usually from target files such as source files or library functions; the wildcard Number * matches the remaining part of the specified attribute item that is not defined in the file.
2. Simple decentralized loading example
In the example shown in figure 8, there is only one loading block, which contains all the code and data. The starting address is 0. The loaded block corresponds to two execution blocks. One contains all the RO code and data, and the execution address is the same as the loading address. The other starting address is 0x10000, which contains all RW and Zi data. In this way, when the system starts to start, it starts to run from the first execution block (the execution address is equal to the loading address). During the execution, some initialization code transfers part of the code in the loading block to another execution block.
The following is the scatter description file, which describes the above memory ing method.
Load_rom 0X4000
{
Exe_rom 0x0000 0X4000; rootregion
{
* <+ RO>; allcodeandconstantdata
}
Ram 0x10000 0x8000
{
* <+ RW, + Zi>; allnon-constantdata
}
}
3. place objects in scattered files
In most applications, all attributes are not put together in a simple way like metadata. users need to control the location of specific code and data segments. This can be achieved by defining a single target file in the scatter file, rather than simply relying on wildcards.
To override the standard connector layout rules, we can use the + first and + Last Distributed Loading commands. A typical example is to place the interrupt vector table at the beginning of the execution block:
Load_rom 0x0000 0X4000
{
Exec_rom 0x0000 0X4000
{
Vectors. O <vect, + first> 〉
* <+ RO> 〉
}
; More execregions...
}
In this scatter file, the vect field in vextors. O is saved to address 0x0000.
4. rootregion (root zone)
The root zone is an execution block, and its loading address is consistent with the execution address. Each scatter file must have at least one root zone. Distributed Loading has one restriction: the code and data (that is, the code and data that have been copied and cleared) of the execution block cannot be copied to another location. Therefore, the root zone must contain the following parts:
_ Main. O, including the code for copying code/data;
Connector output variables $ table and zisection $ table, including the address of the copied code/data.
Because the attributes of the preceding two parts are read-only, they are matched by the * <+ RO> wildcard syntax. If * <+ RO> is used in a non-root zone, you must explicitly specify another Ro region in the root zone.
The following is an example:
Load_rom 0x0000 0X4000
{
Exe_rom 0x0000 0X4000; rootregion
{
_ Main. O <+ RO>; copyingcode
* <Region $ tabl0e>; RO/rwaddressestocopy
* <Zisection $ table>; ziaddressestozero
}
Ram 0x10000 0x8000
{
* <+ RO>; allotherrosections
* <+ RW, + Zi>; allrwandzisections
}
}