北有孤酒tskParams.arg0 = 1;
tskParams.arg1 = 2;
tskParams.priority = 15;
tskParams.stack = null;
tskParams.stackSize = 1024;
var task0 = Task.create('&task0Fxn', tskParams);
SPRUEX3K—December 2011About SYS/BIOS 17Submit Documentation Feedback 9f752a73f46527d3240ce0a5
How are SYS/BIOS and XDCtools Related?
1.3.3XDCtools Modules and Runtime APIs
XDCtools contains several modules that provide basic system services your SYS/BIOS application will need to operate successfully. Most of these modules are located in the xdc.runtime package in XDCtools. By default, all SYS/BIOS applications automatically add the xdc.runtime package during build time.
The functionality provided by XDCtools for use in your C code and configuration file can be roughly
pided into four categories. The modules listed in the following table are in the xdc.runtime package, unless otherwise noted.
Table 1–1. XDCtools Modules Using in C Code and Configuration
Category
Modules Description System Services System Basic low-level "system" services. For example, character output,
printf-like output, and exit handling. See Section 8.3. Proxies that
plug into this module include xdc.runtime.SysMin and
xdc.runtime.SysStd. See Section D.4.
Startup Allows functions defined by different modules to be run before
main(). See Section 3.1.
Defaults Sets event logging, assertion checking, and memory use options for
all modules for which you do not explicitly set a value. See Section
6.7.1 and Section 8.7.1.1.
Main Sets event logging and assertion checking options that apply to your
application code.
Program Sets options for runtime memory sizes, program build options, and
memory sections and segments. This module is used as the "root"
for the configuration object model. This module is in the xdc.cfg
package. See Section 3.3.1 and Section 6.3.2.
Memory Management Memory Creates/frees memory heaps statically or dynamically. SeeSection
6.7.3.
Diagnostics Log and Loggers Allows events to be logged and then passes those events to a Log
handler. Proxies that plug into this module include
xdc.runtime.LoggerBuf and xdc.runtime.LoggerSys. See Section
8.2.1 and Section 3.5.4.
Error Allows raising, checking, and handling errors defined by any
modules. See Section 8.3.
Diags Allows diagnostics to be enabled/disabled at either configuration- or
runtime on a per-module basis. See Section 8.7.1.
Timestamp and Providers Provides time-stamping APIs that forward calls to a platform-specific
time stamper (or one provided by CCS). See Section 5.4,
Text Provides string management services to minimize the string data
required on the target. See Section D.2.5.
Synchronization Gate Protects against concurrent access to critical data structures. See
Section 4.3.
Sync
Provides basic synchronization between threads using wait() and signal() functions. See Section 9.5.
18About SYS/BIOS SPRUEX3K—December 2011Submit Documentation Feedback SYS/BIOS Packages
9f752a73f46527d3240ce0a5
1.4SYS/BIOS Packages
SYS/BIOS provides the following packages:
Table 1–2. Packages and Modules Provided by SYS/BIOS
1.5Using C++ with SYS/BIOS
SYS/BIOS applications can be written in C or C++. An understanding of several issues regarding C++ and SYS/BIOS can help to make C++ application development proceed smoothly. These issues concern memory management, name mangling, calling class methods from configured properties, and special considerations for class constructors and destructors.
SYS/BIOS provides an example that is written in C++. The example code is in the bigtime.cpp file in the packages\ti\sysbios\examples\generic\bigtime directory of the SYS/BIOS installation.
1.5.1Memory Management
The functions new and delete are the C++ operators for dynamic memory allocation and deallocation. For TI targets, these operators use malloc() and free(). SYS/BIOS provides reentrant versions of malloc() and free() that internally use the xdc.runtime.Memory module and (by default) the
ti.sysbios.heaps.HeapMem module.
Package
Description ti.sysbios.benchmarks
Contains specifications for benchmark tests. Provides no modules, APIs, or configuration. See Appendix B .ti.sysbios.family.*
Contains specifications for target/device-specific functions. See Section 7.5.ti.sysbios.gates Contains several implementations of the IGateProvider interface for use in various
situations. These include GateHwi, GateSwi, GateTask, GateMutex, and GateMu-
texPri. See Section 4.3.
ti.sysbios.hal Contains Hwi, Timer, and Cache modules. See Section 7.2, Section 7.3, and
Section 7.4.
ti.sysbios.heaps Provides several implementations of the XDCtools IHeap interface. These include
HeapBuf (fixed-size buffers), HeapMem (variable-sized buffers), and HeapMultiBuf
(multiple fixed-size buffers). See Chapter 6.
ti.sysbios.interfaces Contains interfaces for modules to be implemented, for example, on a device or
platform basis.
ti.sysbios.io Contains modules for performing input/output actions and interacting with peripheral
drivers. Chapter 9.
ti.sysbios.knl Contains modules for the SYS/BIOS kernel, including Swi, Task, Idle, and Clock.
See Chapter 3 and Chapter 5. Also contains modules related to inter-process
communication: Event, Mailbox, and Semaphore. See Chapter 4.
ti.sysbios.utils
Contains the Load module, which provides global CPU load as well as thread-specific load. See Section 8.2.
SPRUEX3K—December 2011About SYS/BIOS 19Submit Documentation Feedback 9f752a73f46527d3240ce0a5
Using C++ with SYS/BIOS
1.5.2Name Mangling
The C++ compiler implements function overloading, operator overloading, and type-safe linking by
encoding a function's signature in its link-level name. The process of encoding the signature into the linkname is referred to as name mangling.
Name mangling could potentially interfere with a SYS/BIOS application since you use function names within the configuration to refer to functions declared in your C++ source files. To prevent name mangling and thus to make your functions recognizable within the configuration, it is necessary to declare your functions in an extern C block as shown in the following code fragment from the bigtime.cpp example:This extern C block allows you to refer to the functions within the configuration file. For example, if you have a Task object that should run clockTask() every time the Task runs, you could configure a Task as follows:
Notice that in the configuration example above, the arg0 parameter of the Task is set to
$externPtr("cl3"). The C++ code to create a global clock object for this argument is as follows:
Functions declared within the extern C block are not subject to name mangling. Since function
overloading is accomplished through name mangling, function overloading has limitations for functions that are called from the configuration. Only one version of an overloaded function can appear within the extern C block. The code in the following example would result in an error.
While you can use name overloading in your SYS/BIOS C++ applications, only one version of the
overloaded function can be called from the configuration./*
* Extern "C" block to prevent name mangling
* of functions called within the Configuration Tool
*/extern "C" {
/* Wrapper functions to call Clock::tick() */
void clockTask(Clock clock);
void clockPrd(Clock clock); void clockIdle(void);
} // end extern "C"
var task0Params = new Task.Params();
9f752a73f46527d3240ce0a5 = "task0";task0Params.arg0 = $externPtr("cl3");
Program.global.task0 = Task.create("&clockTask", task0Params);
/* Global clock objects */
Clock cl3(3); /* task clock */
extern “C” { // Example causes ERROR
Int addNums(Int x, Int y);
Int addNums(Int x, Int y, Int z); // error, only one version
// of addNums is allowed
}
20About SYS/BIOS SPRUEX3K—December 2011Submit Documentation Feedback Using C++ with SYS/BIOS
9f752a73f46527d3240ce0a5
Default parameters is a C++ feature that is not available for functions called from the configuration. C++ allows you to specify default values for formal parameters within the function declaration. However, a function called from the configuration must provide parameter values. If no values are specified, the actual parameter values are undefined.
1.5.3Calling Class Methods from the Configuration
Often, the function that you want to reference within the configuration is the member function of a class object. It is not possible to call these member functions directly from the configuration, but it is possible to accomplish the same action through wrapper functions. By writing a wrapper function which accepts a class instance as a parameter, you can invoke the class member function from within the wrapper.
A wrapper function for a class method is shown in the following code fragment from the bigtime.cpp
example:
Any additional parameters that the class method requires can be passed to the wrapper function.
1.5.4Class Constructors and Destructors
Any time that a C++ class object is instantiated, the class constructor executes. Likewise, any time that a class object is deleted, the class destructor is called. Therefore, when writing constructors and
destructors, you should consider the times at which the functions are expected to execute and tailor them accordingly. It is important to consider what type of thread will be running when the class constructor or destructor is invoked.
Various guidelines apply to which SYS/BIOS API functions can be called from different SYS/BIOS
