Changes between Version 8 and Version 9 of Guidelines/VxWorks

Timestamp:

Apr 29, 2013, 12:14:33 PM (9 years ago)

Author:

Peter Brockamp

Comment:

--

Guidelines/VxWorks

@@ -12 +12 @@
 === Operating modes
 
-We are talking here about the actual Version of VxWorks, for the timing being this is V6.9. Much older versions like the V5.x branch are being left aside as they are very outdated and the libraries that come bundled with it are partially not standard conformant, making it impossible to use boost. The current version of VxWorks can execute software in two modes. You can compile your project as a DKM (''D''ownlodable ''K''ernel ''M''odule, sort of a driver in Windows terms) or as a RTP (''R''eal ''T''ime ''P''rocess, sort of a normal program in Windows terms). For both modes different behaviour, available functionality and default values are present, keep that in mind for the next couple of minutes.[[BR]][[BR]]
+We are talking here about the actual Version of VxWorks, for the timing being this is V6.9. Much older versions like the V5.x branch are being left aside as they are very outdated and the libraries that come bundled with it are partially not standard conformant, making it impossible to use Boost. The current version of VxWorks can execute software in two modes. You can compile your project as a DKM (''D''ownlodable ''K''ernel ''M''odule, sort of a driver in Windows terms) or as a RTP (''R''eal ''T''ime ''P''rocess, sort of a normal program in Windows terms). For both modes different behaviour, available functionality and default values are present, keep that in mind for the next couple of minutes.[[BR]][[BR]]
 
 === POSIX-conformance
@@ -61 +61 @@
 * Other real time OSes (e. g. QNX) ''may'' be prone to the problem as well, depending on the defaults used. Consult your OS' documentation to gain clarity about this.
 * Here's another useful piece of information concerning VxWorks' POSIX-functionality in general:[[BR]] At the time a task calls it's first POSIX-function during runtime it is being transformed by VxWorks into a POSIX-thread. This transformation does include a call to {{{malloc()}}} to allocate the memory required for the housekeeping of POSIX-threads. In a high priority RTP this {{{malloc()}}} call may be highly undesirable, as its timing is more or less unpredictable (depending on what your actual heap looks like). You can circumvent this problem by calling the function {{{thread_self()}}} at a well defined point in the code of the task, e.g. shortly after the task spawns up. Thereby you are able to define the time when the task-transformation will take place and you could shift it to an uncritical point where a {{{malloc()}}} call is tolerable. So, if this could pose a problem for your code, remember to call {{{thread_self()}}} from the affected task at an early stage. Calling {{{thread_self()}}} to initiate the transformation is BTW an official recommendation by Wind River.
-* Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it. I'll save you the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the workbench build boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53.
+* Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it. I'll save you the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the workbench build Boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53.
   1. Create a Workbench project for your Boost directory and copy this content to a text file called {{{.wrproject}}}, replacing the file automatically generated by the workbench.
   2. Adapt to your personal needs.
-  3. Static linking boost to your project will be OK, though I haven't tested dynamic linking.
+  3. Static linking Boost to your project will be OK, though I haven't tested dynamic linking.
   4. I use environment variables to announce the local directories for Boost and other libraries I regularly use. These are called {{{BOOST_ROOT}}}, {{{BZIP2_ROOT}}}, {{{ZLIB_ROOT}}} etc. Create this system variables appropriately or use your own hardcoded paths (Change the include settings of your project).
   5. The file below is for the GCC compiler, as I don't use the diab-compiler, and for x86 as a platform. For other settings you are on your own.