MDK streaking STL

// ================================================ ====================================
// Title:
// MDK streaking STL
// Author:
// Norains
// Date:
// Wednesday 16-December-2009
// Environment:
// MDK 4.0.2
// ================================================ ====================================
Both MDK and STL are well-known. The former full name is realview microcontroller Development Kit, which is a tool for software development in the hands of embedded engineers; while STL is the standard template library, translated as the C ++ standard library, it is a favorite of C ++ prawns. The so-called "streaking" only allows the CPU to run STL programs without relying on operating system interfaces.

 

In everyone's impression, just like a simple embedded CPU, it is nothing more than Assembly; a more user-friendly point is the C language; A more embarrassing point is nothing more than the C ++ of advanced features. STL? How to Use STL in Embedded MDK? Is this possible?

Here we will not discuss the rejection issues such as the significance of using STL to write embedded CPU programs, but simply discuss how to make the embedded CPU run properly the STL program.

 

This article assumes that all of my friends are familiar with the MDK compiling environment. In fact, it doesn't matter if you are not familiar with it. At least, you should know how to create a project. :)

 

Let's create a project first. It seems that the kernel of arm cortex m3 is very popular recently. Let's choose the CPU of this core. It doesn't matter if there is no actual development board, because I don't actually have it, but we can use the simulator that comes with MDK. This simulator is sufficient for our testing code. Of course, you can also select another type for this CPU, which has little impact on the discussion below.
　　
Let's take a look at the simplest STL example in the world:

　　# Include <vector> <br/> int main () <br/> {<br/> STD: vector <int> vtbuf; <br/> vtbuf. push_back (1); <br/>}< br/> 　　
If nothing happens, the code will be compiled smoothly. If the file fails, check whether the file suffix is CPP.
　　
Now let's run this program.
　　
However, it is a pity that it is dumpfounded. The debugger will stay here:
　　
　　
At this time, we didn't even call the main function, and the system broke down.
　　
It is actually very easy to solve this problem, because the C library function will call some special CPU-related functions to facilitate the transplantation of MDK in different CPUs during compilation. The software breakpoint occurs here because these functions only have declarations and no function body implementation. Therefore, a call to the C library immediately fails.
　　
Knowing the cause makes it very easy to solve the problem.
　　
Create another file named retarget. c ending with. C. Enter the following content in the file:
　　# Include <stdio. h> <br/> # include <rt_misc.h> <br/> # pragma import (_ use_no_semihosting_swi) <br/> extern int sendchar (INT ch);/* in serial. C */<br/> struct _ file {int handle;/* Add whatever you need here */}; <br/> file _ stdout; <br/> file _ stdin; <br/> file _ stderr; <br/> int fputc (int ch, file * f) <br/>{< br/> return (sendchar (CH )); <br/>}< br/> <br/> int fgetc (File * FP) <br/>{< br/> return (0 ); <br/>}< br/> <br/> int fclose (File * f) <br/>{< br/> return 0; <br/>}< br/> <br/> int ferror (File * F) <br/>{< br/>/* Your Implementation of ferror */<br/> return EOF; <br/>}< br/> int fseek (File * FP, long NPOs, int nmode) <br/>{< br/> return (0 ); <br/>}< br/> <br/> int fflush (File * pstream) <br/>{< br/> return (0 ); <br/>}< br/> <br/> void _ ttywrch (INT ch) <br/>{< br/> sendchar (CH ); <br/>}< br/> <br/> void _ sys_exit (INT return_code) <br/>{< br/> label: <br/> goto label;/* endless loop */<br/>}< br/>
　
Create a serial. c file with the following content:
　　# Define Cr 0x0d <br/>/* <br/> * superclass to initialize the UART. <br/> */<br/> extern void $ super $ __rt_entry (void); <br/> void $ sub $ __rt_entry (void) <br/>{< br/> $ super $ __rt_entry (); <br/>}< br/> <br/>/* <br/> * Implementation of putchar (also used by printf function to output data) <br/> */<br/> int sendchar (INT ch) <br/> {/* write character to serial port */<br/> return 1; <br/>}< br/> <br/> int getkey (void) <br/> {/* read character from serial port */<br/> return 1; <br/>}< br/>
　　

Whether the functions of these two files are normal is not important for the discussion in this article. What's important is that we add these two files and define the results of the program running after the corresponding function implementation.
　　
By the way, these two files are mainly used to bridge the printf and hardware in the C library. They are completely different on different platforms. In other words, your code in these two files determines the output destination of printf, whether it is output to the serial port or the file. You have the final say about everything.
　　
Well, after talking so much, let's run and see:
　　
　　
Okay, everything works normally. the breakpoint has already entered the main function, which means that our STL can run normally!