?? c-config9.html
字號(hào):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Configuration and Build </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-config.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-config8.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-tshell.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="86670">8.9 Creating Bootable Applications</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="86672"> </a>As you approach a final version of your application, you will probably want to add modules to the bootable system image, and include startup of your application with the system initialization routines. In this way, you can create a <i class="term">bootable application</i>, which is completely initialized and functional after booting, without requiring any interaction with the host-resident development tools.</p><dd><p class="Body"><a name="86673"> </a>Linking the application with VxWorks is really a two-step process. You must add an entry point to the application in <b class="file">usrConfig.c</b>, and you must modify the makefile to link the application statically with VxWorks.</p><dd><p class="Body"><a name="86677"> </a>To start your application during system initialization, add code to the <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> routine in <b class="library">usrConfig.c</b>. You can call application initialization routines, create additional I/O devices, spawn application tasks, and so on, just as you do from the Tornado shell during development. An example is provided in <b class="file">usrConfig.c</b>. This file includes and initializes a simple demo if the preprocessor constant <b class="symbol_UC">INCLUDE_DEMO</b> is defined in one of the configuration files. In that situation, <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> spawns <b class="routine"><i class="routine">usrDemo</i></b><b>( )</b> as a task as the last step in booting the system. You can simply insert the appropriate initialization of your application after the conditional code to start the demo. For example:</p></dl><dl class="margin"><dd><pre class="Code"><b><a name="86678">/* spawn demo if selected */ #if defined(INCLUDE_DEMO) taskSpawn ("demo", 20, 0, 2000, (FUNCPTR)usrDemo, 0,0,0,0,0,0,0,0,0,0); #endif taskSpawn ("myMod", 100, 0, 20000, (FUNCPTR)myModEntryPt, 0,0,0,0,0,0,0,0,0,0);</a></b></pre></dl><dl class="margin"><dd><p class="Body"><a name="86679"> </a>To include your application modules in the bootable system image, add the names of the application object modules (with the <b class="file">.o</b> suffix) to <b class="symbol_UC">MACH_EXTRA</b> in <b class="file">Makefile</b>. For example, to link the module <b class="file">myMod.o</b>, add a line like the following:</p><dl class="margin"><dd><pre class="Code2"><b><a name="86681">MACH_EXTRA = myMod.o ...</a></b></pre></dl><dd><p class="Body"><a name="86682"> </a>Building the system image with the application linked in is the final part of this step. In the target directory, execute the following command:</p><dl class="margin"><dd><pre class="Code2"><b><a name="86683"></b><tt class="output">% </tt><b>make vxWorks</a></b></pre></dl><dd><p class="Body"><a name="86685"> </a>Application size is usually an important consideration in building bootable applications. Generally, VxWorks boot ROM code is copied to a start address in RAM above the constant <b class="symbol_UC">RAM_HIGH_ADRS</b>, and the ROM in turn copies the downloaded system image starting at <b class="symbol_UC">RAM_LOW_ADRS</b>. The values of these constants are architecture dependent, but in any case the system image must not exceed the space between the two. Otherwise the system image overwrites the boot ROM code while downloading, thus killing the booting process. </p><dd><p class="Body"><a name="86688"> </a>To help avoid this, the last command executed when you make a new VxWorks image is <b class="command">vxsize</b>, which shows the size of the new executable image and how much space (if any) is left in the area below the space used for ROM code:</p><dl class="margin"><dd><pre class="Code2"><b><a name="86690"></b><tt class="output">vxsize 386 -v 00100000 00020000 vxWorks vxWorks: 612328(t) + 69456(d) + 34736(b) = 716520 (235720 bytes left)</tt><b></a></b></pre></dl><dd><p class="Body"><a name="86691"> </a>If your new image is too large, <b class="command">vxsize</b> issues a warning. In this case, you can reprogram the boot ROMs to copy the ROM code to a sufficiently high memory address by increasing the value of <b class="symbol_UC">RAM_HIGH_ADRS</b> in <b class="file">config.h </b>and in your BSP's <b class="file">Makefile</b> (both values must agree). Then rebuild the boot ROMs by executing the following command:</p><dl class="margin"><dd><pre class="Code2"><b><a name="86692"></b><tt class="output">% </tt><b>make bootrom.hex</a></b></pre></dl><dd><p class="Body"><a name="86693"> </a>The binary image size of typical boot ROM code is 128KB or less. This small size is achieved through compression; see <a href="c-config9.html#86745"><i class="title">Boot ROM Compression</i></a>. The compressed boot image begins execution with a single uncompressed routine, which uncompresses the remaining boot code to RAM. To avoid uncompressing and thus initialize the system a bit faster, you can build a larger, uncompressed boot ROM image by specifying the <b class="command">make</b> target <b class="file">bootrom_uncmp.hex</b>. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="86700">8.9.1 Creating a Standalone VxWorks System with a Built-in Symbol Table</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="86702"> </a>It is sometimes necessary to create a VxWorks system that includes a copy of its own symbol table. However, it is confusing to work with the host-resident Tornado tools when there is a target-resident symbol table, because the host-resident tools use a separate symbol table on the host. Thus, it is advisable to include the target-resident versions of the development tools (especially the shell) in this configuration, until you are ready to build a finished application that requires no interaction with the target. </p><dd><p class="Body"><a name="86703"> </a>The procedure for building such a system is somewhat different from the procedure described above. No change is necessary to <b class="library">usrConfig.c</b>. A different <b class="command">make</b> target, <b class="file">vxWorks.st</b>, specifies the standalone form of VxWorks:</p><dl class="margin"><dd><pre class="Code2"><b><a name="86705"></b><tt class="output">% </tt><b>make vxWorks.st</a></b></pre></dl>?? 快捷鍵說(shuō)明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -