Changes between Version 7 and Version 8 of Guidelines/VxWorks

Timestamp:

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

Author:

Peter Brockamp

Comment:

typo

Guidelines/VxWorks

@@ -62 +62 @@
 * 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.
-  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.
+  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.
-  4. I use environment variables to announce the local directories for Boost and other libraries I 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).
+  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.