Configuring and setting up the VSB and VIP is known as platform development.
Command-line Editing and Object-Module Loader
Learning Objectives
After this section you will be able to:
- Use the VI editor
- Describe and implement the object-module loader
The kernel shell makes use of command line editors, this is a quick guide on their functionality.
Command Line Editing
The kernel shell supports the VI editor as its primary editor and emacs as a secondary editor. While working in the shell, it will store commands in a history list with a maximum length of 20 commands. The shell supports command-line completion.
Navigating in VI
To start working with the VI editor, you need to press ESC to enter line-editing mode. Here is a list of those commands.
- k - Backwards through history buffer
- j - Forwards through history buffer
- h - Move cursor to the left
- l - Move cursor to the right
- a - Append after cursor
- A - Append at end of line
- i - Insert before cursor
- I - Insert at beginning of line
- rc - Replace current character with character c
- x - Delete current character
- dd - Delete entire line
- nG - Go to history line /string Search for string
Command-Line Completion
Mentioned before, the shell supports command autocompletion. To perform this, use the following commands:
- CTRL+D - To list symbols
- CTRL+D, TAB - To list and autocomplete symbols or file names
Emacs mode
To enable emacs use the following command:
shConfig "LINE_EDIT_MODE=emacs"
As a note, emacs can do a lot more than the Vi editor but has much more overhead. This is why VI is the primary by default.
Command History Limit
Lastly you can modify the command line history with the h() function. This can increases the default of 20 all the way to 500 if you use h 500, for example.
That covers the text editors that VxWorks uses. Next you will be learning about the object module loader.
Object-Module Loader
The object-module loader interacts with the kernel to load or unload code at runtime. This is useful during project development because it lets you unload, recompile, and then reload the object-modules that are being developed.
The alternative is to link the development code to a VIP. In this case, every time you want recompile that code you will have to rebuild the VIP and reboot the target.
To use an object module loader, first configure your VIP to include the component: INCLUDE_LOADER.
The loader must have access to the symbol table, as the object-module relies on information from it.
After the project has been configured you have access to two new functions. The first is ld() which lets you load C interpreter commands and unld() which unloads C interpreter commands.
The object-module loader lets you dynamically expand VxWorks. When code is loaded onto the OS, it makes no distinction between the original image and the new module loaded in.
Lastly the object-module loader allows for the handling of memory allocation. This happens on a per-load basis and for modules that are downloaded.
This has two applications. First, to dynamically allocate memory for downloaded code and free that memory when an unload is called. Second, the caller can specify the addresses of memory that have already been allocated. This allows you to have more control over the layout of the code in memory.
- Do not unload an object-module while its tasks are still running, this may result in unexpected ways.
