Platform Abstraction Layer
The PAL, or Platform Abstraction Layer, enables the STRIDE Runtime to be platform-independent by providing a consistent interface for the STRIDE Runtime regardless of the operating system or data transport used. This interface layer is necessary given the broad variety of operating systems and data transports that exist within embedded systems today.
PAL Concepts
This section describes the basic concepts of the PAL and the system services it must provide.
Function Registration
Typically, the STRIDE Runtime calls PAL functions; however, there are some functions in the STRIDE Runtime that need to be called by the PAL. To eliminate PAL dependencies on the STRIDE Runtime, these functions are accessed through a function registration process initiated by the STRIDE Runtime at startup. You write the registration routine called by the Runtime. This registration routine passes in the address of the STRIDE Runtime function to be registered as the input parameter, and stores the address of the STRIDE Runtime function in your own function variable, which is actually a pointer to a function. You can then call the registered function using your function pointer variable.
The registered STRIDE Runtime functions allow you to complete such tasks as delivering a received I-block to the Runtime, checking the number of I-blocks the Runtime has ready to send out, or signalling the Runtime that your transport is ready for the next I-block. It is not necessary for the PAL to know the details of these Runtime functions.
Event Notification
Unique information is required by an operating system to notify a thread of a pending event. This information can be a simple index into a table, an address to a thread control block, the address of a semaphore or one of a number of other implementations. Although each implementation may be different, a unique notifier is necessary for each thread. The STRIDE Runtime calls this unique information a Notification Identifier (NID). A thread uses a NID when waiting for a STRIDE event, and the STRIDE Runtime uses the same NID to notify the thread of a pending STRIDE event.
An additional piece of information included with the notify routine is a box ID, which is the ID of the mailbox where the message is delivered.
Critical Data Protection
The STRIDE Runtime needs to protect critical data structures from multiple, simultaneous accesses. The specific method of protection is not dictated to the PAL. The PAL requires that when one thread calls a STRIDE function which in turn calls palProtect(), and another thread calls a STRIDE function which also calls palProtect(); the second thread is preempted until the first thread’s STRIDE function calls palUnprotect(). Once palUnprotect() is called, the second thread can be rescheduled and continue. In addition, the STRIDE Runtime guarantees that calls to palProtect() will not be nested.
Timer Administration
The STRIDE Runtime requires that at least one timer be available. When a timer is created, a callback is registered so that the STRIDE Runtime can be notified of timer expirations. A user parameter, provided when the timer is created, is passed to the callback when it gets called. If several timers share a callback routine, this user parameter can be used to identify which timer expired. The STRIDE Runtime can also stop, start and delete timers.
Because the STRIDE Runtime also has the need to timestamp trace log data, a routine that returns the system time, PalGetTime(), is also part of the PAL. This routine is not associated with timers.
Memory Allocation
The STRIDE Runtime dynamically allocates memory for messages and trace log storage. The Runtime uses palMemAlloc() and palMemFree() to allocate memory dynamically and then return it to the system.
Transport Services
The PAL transport routines are needed to transfer I-blocks (STRIDE data packets) into and out of the STRIDE Runtime on your target platform. These routines handle the buffering and transferring of data to and from your transport mechanism. The PAL also contains registration routines that allow for STRIDE Runtime routines to be called by the PAL.
The palOut() routine enables the STRIDE Runtime to transfer I-blocks to your transport. The STRIDE Runtime calls the palOut() routine whenever it needs to send out an Iblock. Your transport calls the routine registered with the palOutRdyReg() routine when the transport is ready for the next I-block to be transmitted. The STRIDE Runtime will not call the palOut() routine until you call the registered function. In this way, you can control the flow of transmitted I-blocks.
When a complete I-block has been received by your transport, the routine registered with the palInReg() routine should be calle to put the received I-block into the STRIDE Runtime.
In some cases it is useful to know when the transmit path is not being requested. Your transport mechanism can check the number of I-blocks the STRIDE Runtime has ready for transmission by calling the routine registered with the palOutPndReg() routine.
Host Services
The PAL also provides a way for the STRIDE Runtime to support your transport protocol on the desktop. A Windows® DLL linked to the STRIDE Panel enables these host services. The DLL allows your data to be received and transmitted using your transport
PAL Organization
This section explains the two categories of PAL services that support the STRIDE Runtime, as well as the files used to implement these services on your target.
PAL Services
The PAL services include the following:
- Operating System (OS) Services
- Input/Output (IO) Services
PAL Operating System Services
The PAL Operating System (OS) Services are the routines that enable the STRIDE Runtime to work with the operating system on your target platform. In order to write your PAL OS services you must have detailed knowledge of how your operating system handles thread synchronization, timers, critical sections, dynamic memory, and notification. The PAL OS services make the features of your operating system available to the STRIDE Runtime. All of the functions described here must be fully implemented in your PAL.
| Function Name | Description |
|---|---|
| Synchronization | |
| palCreateNID | Create a Notification Identifier (NID) |
| palDeleteNID | Delete a Notification Identifier (NID) |
| palCreateRFCProxyNID | Create the RFC Proxy Notification Identifier (NID) |
| palDeleteRFCProxyNID | Delete the RFC Proxy Notification Identifier (NID) |
| palWait | Wait for an event |
| palNotify | Signal a thread that an event is pending |
| Timers | |
| palTimerCreate | Create a timer |
| palTimerDelete | Delete a timer |
| palTimerStart | Start a timer |
| palTimerStop | Stop a timer |
| palGetTime | Return system time (e.g., tick count) |
| Critical Section | |
| palProtect | Begin critical section |
| palUnprotect | End critical section |
| Memory | |
| palMemAlloc | Allocate a block of dynamic memory |
| palMemFree | Free a block of dynamic memory |
PAL Input/Output Services
The PAL Input/Output (IO) Services are the routines that enable the STRIDE Runtime to work with different data transport mechanisms. These routines enable your transport to send and receive data between the host and the target.
The IO services have also been defined to allow the target platform to control how memory is managed and the rate of data exchange. See Appendix A beginning on page 121 for definitions of the header file functions
| Function Name | Description |
|---|---|
| Transmit | |
| PalOutPndReg | Query the current output queue of the Runtime |
| PalOutRdyReg | Identify the transport as ready to receive data |
| PalOut | Send data to the host platform |
| Receive | |
| PalInReg | Data extracted from the transport and identified for the STRIDE Runtime |
Integrating the PAL
See Integrating the Platform Abstract Layer (PAL) for details.
To create a Transport Protocol for the Host↔Target connection, see Integrating the Platform Abstract Layer.