NAME

intro ­ introduction to Section 1: System Calls

DESCRIPTION

This section describes the system calls and C language interface to the following system components:

The calls for each component are arranged alphabetically in separate subsections. Each subsection begins with an intro page that contains an alphabetical listing of the calls for that particular component.

A comprehensive list containing all of the system calls described in this section, with page numbers, is provided on pages 1-3 through 1-6.

See the section, ``About This Manual" for a description of the notation conventions and general headings used in reference pages.

NAME

intro - Introduction to pSOS+ System Calls

DESCRIPTION

The first part of Section 1 contains descriptions of the following pSOS+ system calls:

as_catch as_return as_send
de_close de_cntl de_init
de_open de_read de_write
errno_addr ev_asend ev_receive
ev_send k_fatal k_terminate
m_ext2int m_int2ext pt_create
pt_delete pt_getbuf pt_ident
pt_retbuf pt_sgetbuf q_asend
q_aurgent q_avsend q_avurgent
q_broadcast q_create q_delete
q_ident q_receive q_send
q_urgent q_vbroadcast q_vcreate
q_vdelete q_vident q_vreceive
q_vsend q_vurgent rn_create
rn_delete rn_getseg rn_ident
rn_retseg sm_av sm_create
sm_delete sm_ident sm_p
sm_v t_create t_delete
t_getreg t_ident t_mode
t_restart t_resume t_setpri
t_setreg t_start t_suspend
tm_cancel tm_evafter tm_evevery
tm_evwhen tm_get tm_set
tm_tick tm_wkafter tm_wkwhen

NAME

as_catch - Specify an asynchronous signal routine (ASR)

SYNTAX

#include <psos.h>
unsigned long as_catch(
        void (* start_addr) (), /* ASR address */
       unsigned long mode      /* ASR attributes */
    )

DESCRIPTION

This system call allows a task to specify an Asynchronous Signal Routine (ASR) to handle asynchronous signals. as_catch() supplies the starting address of the task's ASR, and its initial execution mode. If the input ASR address is zero, then the caller is deemed to have an invalid ASR, and any signals sent to it will be rejected.

A task's ASR gains control much like an ISR. If a task has pending signals (sent via as_send()), then the next time the task is dispatched to run, it will be forced to first execute the task's specified ASR. A task executes its ASR according to the mode supplied by the as_catch() call (e.g. Supervisor mode, Non-preemptible etc.). Upon entry to the ASR, all pending signals - including all those received since the last ASR invocation - are passed as an argument to the ASR. In addition, a stack frame is built to facilitate the return from the ASR.

The start_addr argument specifies the address of the ASR.

The mode argument specifies the ASR's primary attributes, and is formed by OR-ing the following symbolic constants (one from each pair), which are defined in <psos.h>.

T_PREEMPT
ASR is preemptible.
T_NOPREEMPT ASR
T_NOTSLICE
ASR cannot be time-sliced.
T_TSLICE
ASR can be time-sliced.
T_ASR
ASR nesting enabled.
T_NOASR ASR
nesting disabled.

One of the symbolic constants T_ISR and T_NOISR (defined in <psos.h>) must be ORed with the symbolic constants used to specify the ASR's interrupt mask level.

If the T_NOASR attribute is set, the ASR is prevented from being re-entered as a result of another as_send() call made to that task. If the T_ASR attribute is enabled, then the ASR should be programmed to be re-entrant.

RETURN VALUE

This system call always returns 0.

ERROR CODES

This system call returns no errors.

NOTES

  1. as_catch() replaces any previous ASR for the calling task. Therefore, a task can have only one ASR at any time.
  2. An invalid ASR (i.e. start_addr = 0) should not be confused with the ASR attributes T_ASR or T_NOASR in a task's mode specifier. If a task's ASR is invalid, then as_send() calls directed to it will be rejected and returned with an error; whereas, the T_NOASR attribute simply defers the ASR's execution, with any intervening signals sent to it left pending.
  3. A normal task would call as_catch() only once, and usually as part of its initialization sequence. Before the first as_catch() call, a task is initialized by the pSOS+ kernel to have an invalid ASR.
  4. Prior to an as_return() call, CPU registers do not have to be restored by the ASR. They are saved by the pSOS+ kernel prior to the ASR and restored within as_return(). The ASR can, therefore, be written in high-level languages like C. An ASR must exit using the as_return() system call.

MULTIPROCESSOR CONSIDERATIONS

None, since the actions performed by as_catch() are entirely confined to the local node, although asynchronous signals may be sent from remote nodes.

CALLABLE FROM ISR No

SEE ALSO as_send, as_return

NAME

as_return - Return from an asynchronous signal routine (ASR)

SYNTAX

DESCRIPTION

This system call must be used by a task's ASR to exit, and return to the original flow of execution of the task. The purpose of this call is to allow the pSOS+ kernel to restore the task to its state before the ASR.

Prior to an as_return() call, CPU registers do not have to be restored by the ASR. They are saved by the pSOS+ kernel prior to an ASR and restored within the as_return() call. An ASR can, therefore, be written in high-level languages like C.

RETURN VALUE

If successful, this system call never returns. An error code is generated on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x3E ERR_NOTINASR Illegal, not called from an ASR.

NOTES

  1. This call is analogous to the i_return() call, which allows an Interrupt Service Routine (ISR) to return to the interrupted flow of execution properly.
  2. as_return() cannot be called except from an ASR.
  3. This call restores the task's original execution mode.

MULTIPROCESSOR CONSIDERATIONS

None, since its actions are confined entirely to the local node.

CALLABLE FROM ISR Not callable from ISR or task

SEE ALSO as_catch, as_send

NAME

as_send - Send asynchronous signals to a task

SYNTAX

DESCRIPTION

This system call sends asynchronous signals to a task. The purpose of these signals is to force a task to break from its normal flow of execution and execute its Asynchronous Signal Routine (ASR).

Asynchronous signals are like software interrupts, with ASRs taking on the role of ISRs. Unlike interrupts, which are serviced almost immediately, an asynchronous signal does not immediately affect the state of the task. An as_send() call is serviced only when the task is next dispatched to run (and that depends on the state of the task and its priority).

Each task has 32 signals. They are encoded bit-wise in a single long word. Bits 31 through 16 are reserved for internal system use, and bits 15 through 0 are available for user-specific purposes.

Like events, signals are neither queued nor counted. For example, if three identical signals are sent to a task before its ASR has a chance to execute, the three signals have the same effect as one.

The argument tid specifies the task to receive the signals. The argument signals contains the bit-encoded signals.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Task has already been deleted.
0x06 ERR_OBJID tid incorrect, validity check failed.
0x3F ERR_NOASR Task has no valid ASR.

NOTES

  1. When an ASR starts execution, all pending asynchronous signals (since its last invocation) are passed to it as an argument.
  2. as_send() does not trigger the ASR handler if the signals is 0.

MULTIPROCESSOR CONSIDERATIONS

If tid identifies a global task that resides on another processor node, the pSOS+ kernel internally makes an RSC to that remote node to send the asynchronous signal to the task.

CALLABLE FROM ISR

SEE ALSO as_catch

NAME

de_close - Close an I/O device

SYNTAX

DESCRIPTION

The de_close() call invokes the device close routine of a pSOS+ device driver specified by the dev argument. The functionality of the device close routine is device-specific. For example, an RS-232 device driver close-routine may signal a modem to hang up to signify the end of the connection.

The de_close() call, when used in conjunction with de_open(), can also be used to implement mutual exclusion. In this case, de_close() can be used to signal the end of a critical region for the device operation.

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver.

RETURN CODE

This call returns 0 on success, or an error code on failure. Besides the error codes listed below, other driver-specific errors may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number
0102 ERR_NODR No driver provided

SEE ALSO de_open

NAME

de_cntrl - Request special I/O device service

SYNTAX

#include <psos.h>
unsigned long de_cntrl(
                unsigned long dev,      /* major/minor device number */
                void *iopb,             /* I/O parameter block address */
                void *retval            /* return value */
                )

DESCRIPTION

The de_cntrl() call invokes the device control routine of a pSOS+ device driver specified by the dev argument. The functionality of a device control routine depends entirely on the device driver implementation. It can include anything that cannot be categorized under the other five I/O services. de_cntrl() for a device can be used to perform multiple input and output sub-functions. In such cases, extra parameters in the I/O parameter block can designate the sub-function.

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver.

RETURN CODE

This call returns 0 on success or an error code on failure. Beside the error codes listed below, other driver-specific errors may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number
0102 ERR_NODR No driver provided

NOTES

Examples of functions that are often performed by de_cntrl() include the following:

SEE ALSO de_read, de_write, de_open, de_close

NAME

de_init - Initialize an I/O device and its driver

SYNTAX

#include <psos.h>
unsigned long de_init(
            unsigned long dev,      /* major/minor device number */
            void *iopb,             /* I/O parameter block */
            void *retval,           /* return value */
            void **data_area        /* device data area */
            )

DESCRIPTION

The de_init() call invokes the device init routine of the pSOS+ device drive specified by the dev argument.

The drive init routine can perform one-time device initialization functions such as:

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver.

data_area is no longer used, but it remains to support compatibility with older drivers and/or pSOS+ application code.

RETURN CODE

This call returns 0 on success, or an error code on failure. Besides the error codes listed below, other driver-specific error may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number
0102 ERR_NODR No driver provided

NOTES

  1. The pSOS+ kernel does not automatically call de_init() during system initialization. The application must initialize each device, as required.
  2. Normally de_init() is called once from the ROOT task for each configured device driver. This call is normally made before other driver services are used.
  3. Although not used, the pSOS+ bindings store a value into the variable pointed to by data_area. Therefore, a dummy variable still must be allocated to prevent memory corruption.

SEE ALSO de_open

NAME

de_open - Open an I/O device

SYNTAX

#include <psos.h>
unsigned long de_open(
           unsigned long dev,      /* major/minor device number */
           void *iopb,             /* I/O parameter block address */
           void *retval            /* return value */
           )

DESCRIPTION

The de_open() call invokes the device open routine of a pSOS+ device driver specified by the dev argument.

The device open routine can be used to perform functions that need to be done before the I/O operations can be performed on the device. For example, an asynchronous serial device driver can reset communication parameters (such as baud rate, parity, and so on) to a known state for the channel being opened. Parameters are baud rate, parity, and so on.

A device driver can also assign specific duties to the open routine that are not directly related to data transfer or device operations. For example, a device driver can use de_open() to enforce exclusive use of the device during several read and/or write operations.

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver.

RETURN CODE

This call returns 0 on success, or an error code on failure. Besides the error codes listed below, other driver-specific errors may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number
0102 ERR_NODR No driver provided

SEE ALSO de_close

NAME

de_read - Read data from an I/O device

SYNTAX

#include <psos.h>
unsigned long de_read(
            unsigned long dev,      /* major/minor device number */
            void *iopb,             /* I/O parameter block address */
            void *retval            /* return value */
            )

DESCRIPTION

The de_read() call is used to read data from a device. It invokes the device read routine of a pSOS+ device driver specified by the dev argument. This service normally requires additional parameters contained in the I/O parameter block, such as the address of a data area to hold the data and the number of data units to read.

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver. For example, it can hold the actual number of data units read.

RETURN CODE

This call returns 0 on success, or an error code on failure. Besides the error codes listed below, other driver-specific error may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number
0102 ERR_NODR No driver provided

NOTES

For many interrupt-driven devices, de_read() starts an I/O transaction and blocks the calling task. Most of the I/O transaction can actually be performed in the device's ISR. Upon completion of the transaction, the ISR unblocks the blocked task.

SEE ALSO de_write

NAME

de_write - Write to an I/O device

SYNTAX

#include <psos.h>
unsigned long de_write(
        unsigned long dev,      /* major/minor device number */
        void *iopb,             /* I/O parameter block address */
        void *retval             /* return value */
      )

DESCRIPTION

The de_write() call is used to write to a device. It invokes the device write routine of a pSOS+ device driver specified by the dev argument. This service normally requires the additional parameters contained in the I/O parameter block, such as the address of the user's output data and the number of data units to write.

The argument dev specifies the major and minor device numbers, which are stored in the upper and lower 16 bits, respectively. The argument iopb points to an I/O parameter block, the contents of which are driver-specific. The argument retval points to a variable that receives a driver-specific value returned by the driver (the actual number of data units written, for example).

RETURN CODE

This call returns 0 on success, or an error code on failure. Besides the error codes listed below, other driver-specific error may be returned.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0101 ERR_IODN Illegal device (major) number.
0102 ERR_NODR No driver provided.

NOTES

For many interrupt-driven devices, de_write() starts an I/O transaction and blocks the calling task. Most of the I/O transactions can actually be performed in the device's ISR. Upon completion of the transaction, the ISR unblocks the blocked task.

SEE ALSO de_read

NAME

errno_addr - Obtain address of the calling task's errno variable

SYNTAX

#include <psos.h>
unsigned long *errno_addr();

DESCRIPTION

This system call returns the address of the calling task's internal errno variable.

The pSOS+ kernel maintains an internal errno variable for every task. Whenever an error is detected by any pSOSystem component, the associated error code is stored into the running task's internal errno variable. The error code may then be retrieved by referencing the errno macro defined in the header file <psos.h> as follows:

#define errno (*(errno_addr())

Thus, a statement like the following expands to include a call to errno_addr().

if (errno == ERR_NOMGB)

RETURN VALUE

This system call returns the address of the errno variable of the calling task.

ERROR CODES

None

NOTES

  1. errno_addr() provides a unique errno value for each task while maintaining compatibility with industry standard library semantics. It should never be necessary to call errno_addr() directly from application code.
  2. All pSOSystem components set a task's internal errno variable. However, for the pSOS+ kernel and pHILE+ file system manager, which return error values via the function return value, use of the errno macro is superfluous.
  3. A successful system call does not clear the previous errno value. errno always contains the error code from the last unsuccessful call.

MULTIPROCESSOR CONSIDERATIONS

None

CALLABLE FROM ISR No

NAME

ev_asend - (pSOS+m kernel only) Asynchronously send events to a task

SYNTAX

#include <psos.h>
unsigned long ev_asend(
        unsigned long tid,      /* target task identifier */
        unsigned long events    /* bit-encoded events */
        )

DESCRIPTION

This system call asynchronously sends events to a task. It is identical to ev_send() except the call is made asynchronously. Refer to the description of ev_send() for further information.

The task ID of the target task is specified by the argument tid. The events to send are bit encoded in the argument events.

RETURN VALUE

When called in a system running the pSOS+m kernel, this call always returns 0. The pSOS+ kernel (the single processor version) returns ERR_SSFN.

ERROR CODES

Should the call fail, if present, the node's MC_ASYNCERR routine is invoked and the following error codes may be reported:

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Task has been deleted.
0x06 ERR_OBJID tid is incorrect, failed validity check.

If an MC_ASYNCERR routine is not provided, the pSOS+m kernel generates a fatal error.

NOTES

  1. This call is supported only by the pSOS+m kernel.
  2. The events sent to a non-waiting task, or those that do not match the events being waited for, are always left pending.
  3. If the tid input argument identifies a task residing on the local processor node, the calling task may be preempted as a result of this call.
  4. In a multiple-event wait situation, the ev_send() and ev_receive() pair of calls depend greatly on the temporal course of events. See Note 2 under ev_receive() for an example.
  5. The pSOS+m kernel does not prevent the use of bits reserved for system use. However, for future compatibility, these bits should not be used.

MULTIPROCESSOR CONSIDERATIONS

If the tid input argument identifies a global task residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to send the specified events to that task.

CALLABLE FROM ISR No, only a task can call ev_asend().

SEE ALSO ev_send, ev_receive

NAME

ev_receive - Wait for an event

SYNTAX

#include <psos.h>
unsigned long ev_receive(
       unsigned long events,    /* bit-encoded events */
       unsigned long flags,     /* event processing attributes */
       unsigned long timeout,   /* timeout delay */
       unsigned long *events_r          /* events received */
       )

DESCRIPTION

This service call allows a task to wait for an event condition. The event condition is a set of events and an ANY/ALL waiting condition qualifier. Each task can wait on 32 events, which are bit-encoded in a long word. An ALL condition occurs when all of the specified events are received. An ANY condition occurs when any of the specified events is received.

If the selected event condition is satisfied by events already pending, ev_receive() clears those events and returns. Otherwise, the caller either returns immediately with an error, waits until the requisite new events have been received, or waits until a timeout occurs (if requested).

If successful, ev_receive() returns the actual event captured by the call in the location pointed to by events_r.

The argument events specifies the set of events.

The flags argument is formed by OR-ing the following symbolic constants (one from each pair), which are defined in <psos.h>.

EV_NOWAIT
Causes ev_receive() to return if the event condition is unsatisfied.

EV_WAIT
Forces ev_receive() to block until the event condition is satisfied.

EV_ANY
Wait for ANY of the desired bits (OR qualifier).

EV_ALL
Wait for ALL the desired bits (AND qualifier).

If EV_NOWAIT is set, the timeout argument is ignored. If EV_WAIT is set, the timeout parameter specifies the timeout in units of clock ticks. When EV_WAIT is set, if the value of timeout is 0, ev_receive() waits forever.

A successful return with the EV_ALL attribute signifies that the events captured match the specified events. Similarly, a successful return with EV_ANY signifies that at least one specified event was captured.

An events argument equal to 0 is special. In this case, ev_receive() returns the pending events but leaves them pending. In this case, the other parameters are ignored.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x01 ERR_TIMEOUT Timed out; this error code is returned only if EV_WAIT was used and the timeout argument was non-zero.
0x3C ERR_NOEVS Selected events not pending; this error code is returned only if the EV_NOWAIT attribute was selected.

NOTES

  1. Events are not accumulated. No matter how many identical events are sent to the calling task before it calls ev_receive() for receiving the event, the result is the same as if one event were pending.
  2. The ev_receive() call captures only the events that the caller selects. It captures each selected event once. If a pending event does not match a selected event, the pending event remains pending. Also, if a pending event was sent after an earlier event was used to match a selected event, the pending event remains pending. Consider the following example sequence:
    1. Task P has pending events 1 and 2.
    2. With EV_ALL set, P calls ev_receive() for events 1, 3 and 8. Pending event 1
      is cleared.
    3. Task A sends events 1 and 8 to P.
    4. Event 1 is made pending. Event 8 is used to match the wanted event.
    5. Task B sends events 2, 3 and 5 to P. Event 2 has no effect because event 2 is already pending. Event 5 is unwanted and made pending. Event 3 is used to match a wanted event. The event condition is met, so P becomes ready to run.
    6. Events 1, 2 and 5 are left pending
    7. Events 1, 3 and 8 are returned in events_r.

  3. The ev_receive() call with the EV_NOWAIT attribute selected is a convenient way to reset all or selected pending events. For example, an ev_receive() for events 1 and 2 unconditionally resets events 1 and 2.

MULTIPROCESSOR CONSIDERATIONS

None. The actions performed by ev_receive() take place only on the local node (whether or not events come from other nodes).

CALLABLE FROM ISR No

SEE ALSO ev_send

NAME

ev_send - Send events to a task

SYNTAX

#include <psos.h>
unsigned long ev_send(
         unsigned long tid,      /* target task identifier */
         unsigned long events    /* bit-encoded events */
         )

DESCRIPTION

This system call sends events to a task. If the target task is not waiting for events, the newly sent events are simply made pending. If the task is waiting for events, and the wait condition is fully satisfied as a result of the new events, then the task is unblocked and readied for execution. Otherwise, the task continues to wait. In either case, any of the events sent that do not match those waited on are always left pending.

Each task has 32 events, which are encoded bit-wise in a single long word. Bits 31 through 16 are for internal system use, and bits 15 through 0 are for user-specific purposes. ev_send() can send up to 32 different events at one time.

Events are neither queued nor counted. For example, if three identical events are sent to a task before it issues a wait for that event, the three events have the same effect as one event.

The task identifier of the target task is specified by the argument tid. The events to send are bit-encoded in the argument events.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Task has been deleted.
0x06 ERR_OBJID tid is incorrect, failed validity check.
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. The events sent to a non-waiting task, or those that do not match the events being waited for, are always simply left pending.
  2. If the caller is a task, it may be preempted as a result of this call.
  3. In a multiple-event wait situation, the ev_send() and ev_receive() pair of calls are highly dependent on the temporal course of events. See Note 2 under ev_receive() for an example.
  4. The pSOS+ kernel does not prevent the use of bits reserved for system use. However, for future compatibility, these bits should not be used.

MULTIPROCESSOR CONSIDERATIONS

If the tid input argument identifies a global task residing on another processor node, then the pSOS+ kernel internally makes an RSC to that remote node to send the input events to that task.

CALLABLE FROM ISR

SEE ALSO ev_receive

NAME

k_fatal - Abort and enter fatal error handling mode

SYNTAX

#include <psos.h>
void k_fatal(
     unsigned long err_code, /* user's error code */
     unsigned long flags     /* fatal condition attributes */
     )

DESCRIPTION

This system call allows the user application to pass control to the user-defined fatal error handler in the event of a nonrecoverable failure. k_fatal() forces a nonrecoverable shutdown of the pSOS+ environment and never returns to the caller.

The argument err_code specifies a user-defined failure code that is passed to the fatal error handler. The failure code must be at least 0x10000.

The flags argument is ignored in the single-processor version of the pSOS+ kernel. See Multiprocessor Considerations for a complete description of this parameter. In a multiprocessor system, the flags argument is used to determine if the local node should be shutdown or a system-wide shutdown should occur. flags is formed by selecting one of the following symbolic constants, which are defined in <psos.h>.

K_GLOBAL
k_fatal() invocation causes global system shutdown.
K_LOCAL

If the value of flags is K_GLOBAL, a global shutdown packet is sent to the master, which then sends a shutdown packet to every other node in the system.

RETURN VALUE

This call never returns to the caller.

NOTES

  1. The shutdown procedure is a procedure whereby pSOS+ attempts to halt execution in the most orderly manner possible. The pSOS+ kernel first examines the pSOS+ Configuration Table entry kc_fatal. If this entry is nonzero, the pSOS+ kernel jumps to this address. If kc_fatal is zero, and the pROBE+ System Debug/Analyzer is present, then the pSOS+ kernel simply passes control to the System Failure entry of the pROBE+ debugger. Refer to the pROBE+ User's Manual for a description of the pROBE+ debugger behavior in this case. Finally, if the pROBE+ debugger is absent, the pSOS+ kernel internally executes an illegal instruction to cause a deliberate illegal instruction exception. This will hopefully pass control to a ROM monitor or other low-level debug tool.
  2. k_fatal() is not the only mechanism by which control is passed to the fatal error handler. It may also receive control following an internal pSOS+ fatal error or, in multiprocessor systems, a shutdown packet from the master node.

MULTIPROCESSOR CONSIDERATIONS

In a multiprocessor system, k_fatal() can be used to implement a system-wide abort or shutdown. In this case, K_GLOBAL should be set. This causes a global shutdown packet to go to the master node, which sends a shutdown packet to every node in the system.

CALLABLE FROM ISR No

NAME

k_terminate - (pSOS+m kernel only) Terminate a node other than the master node

SYNTAX

unsigned long k_terminate (
              unsigned long node,     /* Node to terminate */
              unsigned long fcode,    /* failure code */
              unsigned long flags     /* unused */
              )

DESCRIPTION

This system call allows the user application to shutdown a node that it believes has failed or is operating incorrectly. k_terminate() causes the specified node to receive a shutdown packet and all other nodes to receive notification of the specified node's failure.

node specifies the node number of the node to shutdown. It cannot be the master node. err_code specifies a user-defined failure code. It must be at least 0x10000. flags is unused.

RETURN VALUE

This system returns 0 on success or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x04 ERR_NODENO Node number out of range
0x67 ERR_MASTER Cannot terminate master node

NOTES

  1. k_terminate() may be used to terminate the node from which it is called. In most cases the results are the same as a k_fatal() call. However, it is implemented differently. Whereas k_fatal() will immediately enter the fatal error handler, k_terminate() causes a packet to be sent to the master node, which then sends a shutdown packet to the calling node. If the calling node cannot communicate with the master, then the KI presumably will call k_fatal() anyway. It is preferable to use k_fatal() when the failed node is known to be the local node.
  2. A k_fatal() call made with the K_GLOBAL flag set should be used to shutdown the entire system including the master node.

CALLABLE FROM ISR Callable from ISR, callouts and tasks.

SEE ALSO k_fatal

NAME

m_ext2int - Convert an external address to an internal address

SYNTAX

#include <psos.h>
unsigned long m_ext2int(
        void *ext_addr, /* external reference */
        void **int_addr /* local reference */
        )

DESCRIPTION

This system call converts an external address into an internal address corresponding to the calling node. A typical use for this conversion is by a node that has received an address from another node that resides in a dual-ported memory zone.

m_ext2int() is relevant only to systems with multiple processors connected by dual-ported memory on a memory bus. Other users can disregard this call.

The argument ext_addr specifies the external address. The resultant internal address is returned in the location pointed to by int_addr. If the external address is within a dual-ported zone whose p-port is tied to the calling node, then the internal address will be different. In all other cases, the internal and external addresses will be the same.

RETURN VALUE

This system call always returns 0.

NOTES

  1. The pSOSystem System Concepts manual contains descriptions of internal and external addresses and dual-ported memory considerations.
  2. Be careful about structures that straddle the boundary of a dual-port zone, since the address range for the structure may contain a discontinuity.

MULTIPROCESSOR CONSIDERATIONS

None. Although m_ext2int() is primarily used in multiprocessor systems, its action is restricted to the local node.

CALLABLE FROM ISR Callable from ISRs, KIs, callouts and tasks.

SEE ALSO m_int2ext

NAME

m_int2ext - Convert an internal address to an external address

SYNTAX

unsigned long m_int2ext(
         void *int_addr, /* local reference */
         void **ext_addr /* external reference */
         )

DESCRIPTION

When a node on a multiprocessor system passes an address that resides within a dual-ported zone, it first must convert the address by calling m_int2ext(). This call applies to systems with multiple processors that are connected by dual-ported memory on a memory bus.

The argument int_addr specifies the internal address. The resultant external address is returned in the location pointed to by ext_addr.

If the internal address is within a dual-ported zone whose p-port is tied to the calling node, the external address is different. In all other cases, the internal and external addresses are the same.

RETURN VALUE

This call always returns 0.

NOTES

Be careful about structures that straddle the boundary of a dual-port zone because the structure's address range could contain a discontinuity.

MULTIPROCESSOR CONSIDERATIONS

None. Although used in multiprocessor systems, m_int2ext() executes on the local node.

CALLABLE FROM Callable from ISRs, KIs, callouts and tasks.

SEE ALSO m_ext2int

NAME

pt_create - Create a memory partition of fixed-size buffers

SYNTAX

#include <psos.h>
unsigned long pt_create(
         char name[4],           /* partition name */
         void *paddr,            /* partition physical addr. */
         void *laddr,            /* partition logical address */
         unsigned long length,   /* partition length in bytes */
         unsigned long bsize,    /* buffer size in bytes */
         unsigned long flags,    /* buffer attributes */
         unsigned long *ptid,    /* partition identifier */
         unsigned long *nbuf     /* number of buffers created */
         )

DESCRIPTION

This service call allows a task to create a new memory partition, from which fixed-sized memory buffers may be allocated for use by the application. The pSOS+ kernel takes a portion from the top of this region to use as its Partition Control Block.

The argument name specifies the user-assigned name for the new partition. The physical memory address of the partition is defined by paddr. The logical address of the partition generated after MMU-translation is defined by laddr; it is ignored on non-MMU systems. The total partition length, in bytes, is defined by length. The size of the buffers are defined by bsize, and must be a power of 2, and equal to or greater than 4.

The flags argument is formed by OR-ing the following symbolic constants (one from each pair), which are defined in <psos.h>.

PT_GLOBAL
Partition becomes globally addressable to other nodes.

PT_LOCAL
Restricts partition addressability to the local node.

PT_DEL
Allow deletion with outstanding buffers.

PT_NODEL
Prohibit deletion with outstanding buffers.

The partition ID of the named partition is returned in the variable pointed to by ptid. The number of actual buffers in the partition is returned in the variable pointed to by nbuf.

RETURN VALUE

This call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x08 ERR_OBJTFULL Node's object table full.
0x28 ERR_PTADDR Starting address not on long word boundary.
0x29 ERR_BUFSIZE Buffer size not power of 2, or less than 4 bytes.
0x2A ERR_TINYPT Length too small to hold the partition control information.

NOTES

  1. The pSOS+ kernel treats a partition name as a 32-bit integer, but the partition name is passed to the kernel as a four-byte character array when the application calls the kernel.
  2. The pSOS+ kernel does not check for duplicate partition names. If duplicate names exist, a pt_ident() call can return the ptid of any partition with the duplicate name.
  3. If the PT_DEL attribute is set, the pt_delete() call can delete the partition even though one or more buffers are allocated. If PT_NODEL is set, the pSOS+ kernel requires that all the buffers be freed before it deletes the partition.
  4. The single-processor version of the pSOS+ kernel ignores PT_GLOBAL.

MULTIPROCESSOR CONSIDERATIONS

  1. The PT_GLOBAL attribute should be set only if the partition must be made known to other processor nodes in a multiprocessor configuration. If set, the partition's name and ptid are sent to the master node for entry in its Global Object Table.
  2. If the PT_GLOBAL attribute is set and the number of global objects currently exported by the node equals the Multiprocessor Configuration Table entry mc_nglbobjs, then the partition is not created and ERR_OBJTFULL is returned.

CALLABLE FROM ISR No

SEE ALSO pt_ident, pt_getbuf

NAME

pt_delete - Delete a memory partition

SYNTAX

#include <psos.h>
unsigned long pt_delete (
              unsigned long ptid      /* partition identifier */
              )

DESCRIPTION

This system call deletes the memory partition with the specified ptid. Unless the PT_DEL attribute was specified when the partition was created, pt_delete() will return an error if any buffers allocated from the partition have not been returned.

The calling task does not have to be the creator (parent) of the partition to be deleted. However, a partition must be deleted from the node on which it was created.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Partition has been deleted.
0x06 ERR_OBJID ptid is incorrect, failed validity check.
0x2B ERR_BUFINUSE Cannot delete; one or more buffers still in use.
0x53 ERR_ILLRSC Partition not created from this node.

NOTES

Once created, a partition is generally used by multiple tasks for data buffers, which may be passed around between tasks, or even between nodes. There is rarely a reason for deleting a partition, even when it is no longer used, except to allow reuse of memory occupied by the partition.

MULTIPROCESSOR CONSIDERATIONS

If ptid identifies a global partition, pt_delete will notify the master node so that the partition may be removed from its Global Object Table. Thus, deletion of a global partition always causes activity on the master node.

CALLABLE FROM ISR No

SEE ALSO pt_create

NAME

pt_getbuf - Get a buffer from a partition

SYNTAX

#include <psos.h>
unsigned long pt_getbuf(
         unsigned long ptid,     /* partition identifier */
         void **bufaddr  /* starting address of buffer */
         )

DESCRIPTION

This system call gets a buffer from a partition. If the partition is empty, then an error will be returned.

The argument ptid specifies the partition identifier. The starting address of the allocated buffer is returned in the variable pointed to by bufaddr.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Partition has been deleted.
0x06 ERR_OBJID ptid is incorrect, failed validity check.
0x2C ERR_NOBUF Cannot allocate; partition out of free buffers.
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. Buffers always start on long word boundaries.
  2. It is not possible to wait for a buffer. pt_getbuf() unconditionally returns.

MULTIPROCESSOR CONSIDERATIONS

If the input ptid identifies a global partition residing on another processor node, then the pSOS+ kernel will internally make an RSC to that remote node to allocate the buffer.

CALLABLE FROM ISR

SEE ALSO pt_retbuf

NAME

pt_ident - Obtain the identifier of the named partition

SYNTAX

unsigned long pt_ident(
         char name[4],           /* partition name */
         unsigned long node,     /* node selector */
         unsigned long *ptid     /* partition identifier */
         )

DESCRIPTION

This system call allows the calling task to obtain the partition ID of a memory partition it only knows by name. This partition ID may then be used in all other operations relating to the memory partition.

Most system calls, except pt_create() and pt_ident(), reference a partition by its partition ID. pt_create() returns the partition ID to the partition creator. For other tasks, one way to obtain the partition ID is to use pt_ident().

The argument name specifies the name of a partition whose ID is returned in the variable pointed to by ptid. The argument node is a node selector. In a single node system, this argument must be 0. For multiprocessor systems, see Multiprocessor Considerations.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x04 ERR_NODENO Node specifier out of range.
0x09 ERR_OBJNF Named partition not found.

NOTES

  1. The pSOS+ kernel treats a partition name as a 32-bit integer, but the partition name is passed to the kernel as a four-byte character array when the application calls the kernel.
  2. The pSOS+ kernel does not check for duplicate partition names. If duplicate partition names exist, a pt_ident() call can return the ID of any partition with the duplicate name.

MULTIPROCESSOR CONSIDERATIONS

  1. pt_ident() converts a partition's name to its ptid using a search order determined by the node input parameter, which is described in pSOSystem System Concepts. Because partitions created and exported by different nodes may not have unique names, the result of this binding may depend on the order in which the object tables are searched.
  2. If the master node's Global Object Table must be searched, then the pSOS+m kernel makes an RSC to the master node.

CALLABLE FROM ISR No

SEE ALSO pt_create

NAME

pt_retbuf - Return a buffer to the partition from which it came

SYNTAX

#include <psos.h>
unsigned long pt_retbuf(
         unsigned long ptid,     /* partition identifier */
         void *bufaddr           /* starting address of the buffer */
         )

DESCRIPTION

This system call returns a buffer to the partition from which it was allocated. Since the pSOS+ kernel does not keep track of buffer ownership, it is possible for one task to get a buffer, and another task to return it.

The argument ptid specifies the partition ID of the buffer to return. The argument bufaddr specifies the buffer's address.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Partition has been deleted.
0x06 ERR_OBJID ptid is incorrect; failed validity check.
0x2D ERR_BUFADDR Incorrect buffer starting address.
0x2F ERR_BUFFREE Buffer is already unallocated.
0x65 ERR_STALEID Object's node has failed.

MULTIPROCESSOR CONSIDERATIONS

If the input ptid identifies a global partition residing on another processor node, then the pSOS+ kernel will internally make an RSC to that remote node to return the buffer.

CALLABLE FROM ISR

SEE ALSO pt_getbuf

NAME

pt_sgetbuf - Return a buffer with its physical and logical addresses

SYNTAX

#include <psos.h>
unsigned long pt_sgetbuf(
              unsigned long ptid,     /* partition identifier */
              void  **paddr,          /* physical address */
              void  **laddr           /* logical address */
              )

DESCRIPTION

This system call gets a buffer from a partition. If the partition is empty, then an error will be returned.

On MMU-based systems, both physical and logical addresses are returned to simplify transfer of buffers between Supervisor and User mode programs. In non-MMU systems, the logical address is the same as the physical address, this call functions the same as the pt_getbuf() call.

This service is available in the non-MMU versions of the pSOS+ kernel for the sole purpose of allowing software designed for MMU-based systems to run, unmodified, on systems without MMU.

The argument ptid specifies the buffer's partition ID. The physical and logical addresses of the buffer are returned in the variables pointed to by paddr and laddr respectively.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Partition has been deleted.
0x06 ERR_OBJID ptid is incorrect, failed validity check.
0x2C ERR_NOBUF Cannot allocate; partition out of free buffers.
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. Buffers always start on long word boundaries.
  2. It is not possible to wait for a buffer. pt_sgetbuf() unconditionally returns.

MULTIPROCESSOR CONSIDERATIONS

If the input argument ptid identifies a global partition on another processor node, the pSOS+ kernel internally makes an RSC to that remote node to allocate the buffer.

CALLABLE FROM ISR No

SEE ALSO pt_retbuf, pt_getbuf

NAME

q_asend - (pSOS+m kernel only) Asynchronously post a message to a message queue

SYNTAX

#include <psos.h>
unsigned long q_asend(
              unsigned long qid,              /* queue identifier */
              unsigned long msg_buf[4]        /* message buffer */
              )

DESCRIPTION

This system call functions the same as q_send() except that it executes asynchronously. Refer to the description of q_send() for further information. For a detailed description of asynchronous services, refer to the pSOSystem Systems Concept manual.

The argument qid specifies the queue ID of the target queue. The message to send is contained in the argument msg_buf.

RETURN VALUE

When called in a system running the pSOS+m kernel this call always returns 0. The pSOS+ kernel (the single processor version) returns ERR_SSFN.

ERROR CODES

Should the call fail, if present, the node's MC_ASYNCERR routine is invoked and the following error codes may be reported:

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x34 ERR_NOMGB Out of system message buffers.
0x35 ERR_QFULL Message queue at length limit.
0x3A ERR_VARQ Queue is variable length
0x65 ERR_STALEID Object's node has failed.

If an MC_ASYNCERR routine is not provided, the pSOS+m kernel generates a fatal error.

NOTES

  1. This call is supported only by the pSOS+m kernel.
  2. The calling task can be preempted as a result of this call.
  3. q_asend() asynchronously sends a message to an ordinary message queue. Use q_avsend() to asynchronously send a message to a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If a task awakened by this call does not reside on the local node, then the pSOS+m kernel will internally pass the message to the task's node of residence, whose pSOS+m kernel will ready the task and give it the relayed message. Thus, a q_asend() call, whether it is on the local or a remote queue, may cause pSOS+m activities on another processor node.

CALLABLE FROM ISR No, only a task can call q_asend().

SEE ALSO q_send, q_vsend, q_avsend, q_aurgent, q_receive

NAME

q_aurgent - (pSOS+m kernel only) Asynchronously post a message at the head of a queue's message queue

SYNTAX

#include <psos.h>
unsigned long q_aurgent(
              unsigned long qid,              /* queue identifier */
              unsigned long msg_buf[4]        /* message buffer */
              )

DESCRIPTION

This system call functions the same as the q_urgent() call except that it executes asynchronously. Refer to the description of q_urgent() for further information.

The argument qid specifies the queue ID of the target queue. The message to send is contained in the argument msg_buf.

RETURN VALUE

When called in a system running the pSOS+m kernel, this call always returns 0. The pSOS+ kernel (the single processor version) returns ERR_SSFN.

ERROR CODES

Should the call fail, if present, the node's MC_ASYNCERR routine is invoked and the following error codes may be reported:

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x34 ERR_NOMGB Out of system message buffers.
0x35 ERR_QFULL Message queue at length limit.
0x3A ERR_VARQ Queue is variable length.
0x65 ERR_STALEID Object's node has failed.

If an MC_ASYNCERR routine is not provided, the pSOS+m kernel generates a fatal error.

NOTES

  1. This call is supported only by the pSOS+m kernel.
  2. The calling task can be preempted as a result of this call.
  3. q_aurgent() asynchronously sends an urgent message to an ordinary message queue. Use q_avurgent() to asynchronously send an urgent message to a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If a task awakened by this call does not reside on the local node, then the pSOS+m kernel will internally pass the message to the task's node of residence, whose pSOS+m kernel will ready the task and give it the relayed message. Thus, a q_aurgent() call, whether it is on the local or a remote queue, may cause pSOS+m activities on another processor node.

CALLABLE FROM ISR No, only a task can call q_aurgent().

SEE ALSO q_urgent, q_vurgent, q_avurgent, q_asend, q_receive

NAME

q_avsend - (pSOS+m kernel only) Asynchronously post a variable length message to a message queue

SYNTAX

 #include <psos.h>
 unsigned long q_avsend(
         unsigned long qid,      /* queue identifier */
         void *msg_buf,          /* message buffer */
         unsigned long msg_len,  /* length of message */
         )

DESCRIPTION

This system call functions the same as the q_vsend() call except that it executes asynchronously. Refer to the description of q_vsend() for further information.

The argument qid specifies the queue ID of the target queue. The message to send is contained in the argument msg_buf. msg_len specifies the length of the message. It must not exceed the queue's maximum message length.

RETURN VALUE

When called in a system running the pSOS+m kernel, this call always returns 0. The pSOS+ kernel (the single processor version) returns ERR_SSFN.

ERROR CODES

Should the call fail, if present, the node's MC_ASYNCERR routine is invoked and the following error codes may be reported:

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x31 ERR_MSGSIZ Message too large
0x35 ERR_QFULL Message queue at length limit.
0x3B ERR_NOTVARQ Queue is not variable length
0x65 ERR_STALEID Object's node has failed.

If an MC_ASYNCERR routine is not provided, the pSOS+m kernel generates a fatal error.

NOTES

  1. This call is supported only by the pSOS+m kernel.
  2. The calling task can be preempted as a result of this call.
  3. The pSOS+m kernel must copy the message into a queue buffer or the receiving task's buffer. Longer messages take longer to copy. User's should account for the copy time in their design.
  4. q_avsend() asynchronously sends a message to a variable length message queue. Use q_asend() to asynchronously send a message to an ordinary message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If a task awakened by this call does not reside on the local node, the local kernel will internally pass the message to the task's node of residence, whose pSOS+m kernel will ready the task and give it the relayed message. Thus, a q_avsend() call, whether it is on the local or a remote queue, may cause pSOS+m activities on another processor node.

CALLABLE FROM ISR No, only a task can call q_avsend().

SEE ALSO q_vsend, q_send, q_asend, q_urgent, q_vreceive

NAME

q_avurgent - (pSOS+m kernel only) Post a variable length message at the head of a message queue

SYNTAX

#include <psos.h>
unsigned long q_avurgent(
         unsigned long qid,      /* queue identifier */
         void *msg_buf,          /* message buffer */
         unsigned long msg_len,  /* length of message */
         )

DESCRIPTION

This system call functions the same as q_vurgent except that q_avurgent executes asynchronously. Refer to the description of q_vurgent for further information. For a more detailed description of asynchronous services, refer to the pSOSystem System Concepts manual.

The argument qid identifies the queue. The argument msg_buf defines the message to send. The argument msg_len specifies the length of the message.

RETURN VALUE

When called in system running pSOS+m, this call always returns 0. The pSOS+m kernel (the single processor version) returns ERR_SSFN.

ERROR CODES

The following error codes may be reported if a q_avurgent() call fails and the node's MC_ASYNCERR routine (if present) is invoked:

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x31 ERR_MSGSIZ Message too large
0x35 ERR_QFULL Message queue at length limit.
0x3B ERR_NOTVARQ Queue is not variable length
0x65 ERR_STALEID Object's node has failed.

If an MC_ASYNCERR routine is not present, the pSOS+m kernel generates a fatal error.

NOTES

  1. This call is supported only by the pSOS+m kernel.
  2. The calling task can be preempted as a result of this call.
  3. The pSOS+m kernel must copy the message into a queue buffer or the receiving task's buffer. Longer messages take longer to copy. User's should account for the copy time in their design.
  4. q_avsend() asynchronously sends a message to a variable length message queue. Use q_asend() to asynchronously send a message to an ordinary message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If a task awakened by this call does not reside on the local node, the local kernel internally passes the message to the task's node of residence, whose pSOS+m kernel readies the task and gives it the relayed message. Thus, a q_avurgent() call, whether it is on the local or a remote queue, can cause pSOS+m activity on another processor node.

CALLABLE FROM ISR No, only a task can call q_avurgent().

SEE ALSO q_urgent, q_vurgent, q_vreceive, q_vsend

NAME

q_broadcast - Broadcast identical messages to a message queue

SYNTAX

#include <psos.h>
unsigned long q_broadcast(
              unsigned long qid,           /* queue identifier */
              unsigned long msg_buf[4],    /* msg. of 4 long words */
              unsigned long *count         /* # tasks receiving msg. */
              )

DESCRIPTION

This system call allows the caller to wake up all tasks that might be waiting at an ordinary message queue. If the task queue is empty, this call does nothing. If one or more tasks are waiting at the queue, q_broadcast() gives a copy of the input message to each such task and makes it ready to run. After a q_broadcast() call, no tasks will be waiting to receive a message from the specified queue.

The argument qid specifies the queue ID of the target queue. The argument msg_buf contains the message to send. The number of tasks readied by the broadcast is returned in the location pointed to by count.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid is incorrect, failed validity check.
0x3A ERR_VARQ Queue is variable length
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. q_broadcast() is particularly useful in situations where a single event (e.g. an interrupt) must wake up more than one task. In such cases, q_broadcast() is clearly more efficient than multiple q_send() calls.
  2. If the caller is a task, it may be preempted as a result of this call.
  3. q_broadcast() may be intermixed with q_send() and q_urgent() calls to the same queue.
  4. q_broadcast() sends messages to an ordinary message queue. Use q_vbroadcast() to send messages to a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, then the pSOS+m kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If tasks awakened by this call do not reside on the local node, then the pSOS+m kernel will internally pass the message to each task's node of residence, whose pSOS+m kernel will ready the task and give it the relayed message. Thus, a q_broadcast() call, whether it is on the local or a remote queue, may cause pSOS+m activities on one or more other processor nodes.

CALLABLE FROM ISR

SEE ALSO q_send, q_receive, q_vbroadcast

NAME

q_create - Create a message queue

SYNTAX

#include <psos.h>
unsigned long q_create(
         char name[4],           /* queue name */
         unsigned long count,    /* queue size */
         unsigned long flags,    /* queue attributes */
         unsigned long *qid      /* queue identifier */
         )

DESCRIPTION

This system call creates an ordinary message queue by allocating and initializing a Queue Control Block (QCB) according to the specifications supplied with the call.

Like all objects, a queue has a user-assigned name, and a pSOS-assigned queue ID returned by q_create(). Several flag bits specify the characteristics of the message queue. Tasks can wait for messages either by task priority or strictly FIFO, and a limit can be optionally set on the maximum number of messages that can be simultaneously posted at the queue.

The argument name specifies the user-assigned name of the new message queue. The flags argument is formed by OR-ing the following symbolic constants (one from each pair), which are defined in <psos.h>.

Q_GLOBAL
Queue is globally addressable by other nodes.

Q_LOCAL
Restricts queue addressability to local node.

Q_PRIOR
Tasks queued by priority.

Q_FIFO
Tasks queued by FIFO.

Q_LIMIT
Limit message queue size to count.

Q_NOLIMIT
No limit on message queue size.

Q_PRIBUF
Allocate private buffers for message storage.

Q_SYSBUF
Use system buffers for message storage.

If Q_LIMIT is set, then the count argument specifies the maximum number of messages that can be simultaneously posted at the queue. If Q_PRIBUF is also set, then the argument count also specifies the number of buffers set aside from the system-wide pool of message buffers for the private use of this queue. If Q_NOLIMIT is set, count is ignored. The queue ID of the named queue is returned in the variable pointed to by qid.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x08 ERR_OBJTFULL Node's object table full.
0x33 ERR_NOQCB Cannot allocate QCB; exceeds node's maximum number of active queues.
0x34 ERR_NOMGB Cannot allocate private buffers; too few available.

NOTES

  1. The pSOS+ kernel treats a queue name as a 32-bit integer, but the queue name is passed to the kernel as a four-byte character array when the application calls the kernel.
  2. The pSOS+ kernel does not check for duplicate queue names. If duplicate names exist, a q_ident() call can return the qid of any queue with the duplicate name.
  3. The maximum number of queues that can be simultaneously active is defined by the kc_nqueue entry in the pSOS+ Configuration Table.The count argument is ignored if the Q_NOLIMIT attribute is specified.
  4. A queue created with Q_NOLIMIT specified is slightly more efficient.
  5. Q_LIMIT and a count equal 0 is a legitimate setting. This combination has the interesting property that a q_send() will succeed only if there is already a task waiting; otherwise, q_send() will fail.
  6. Q_LIMIT set with Q_PRIBUF guarantees that enough buffers will be available for messages to be posted at this queue. If Q_LIMIT is not set, then Q_PRIBUF is ignored.
  7. If a queue is created without private buffers, then messages posted to it will be stored in buffers from the system-wide pool on the node where the queue resides. The size of this pool is defined by the kc_nmsgbuf entry in the node's pSOS+ Configuration Table.
  8. The Q_GLOBAL attribute is ignored by the single-processor version of the pSOS+ kernel.
  9. q_create() creates an ordinary message queue. Use q_vcreate() to create a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. The Q_GLOBAL attribute should be set only if the queue must be made known to other processor nodes in a multiprocessor configuration. If set, the queue's name and qid are sent to the master node for entry in its Global Object Table.
  2. If the Q_GLOBAL attribute is set and the number of global objects currently exported by the node equals the Multiprocessor Configuration Table entry mc_nglbobj then the queue is not created and ERR_OBJTFULL is returned.

CALLABLE FROM ISR No, only a task can call q_create.

SEE ALSO q_ident, q_delete, q_vcreate

NAME

q_delete - Delete a message queue

SYNTAX

#include <psos.h>
unsigned long q_delete(
         unsigned long qid       /* queue identifier */
         )

DESCRIPTION

This system call deletes the ordinary message queue with the specified queue ID, and frees the QCB. q_delete() take cares of cleaning up the queue. If there are tasks waiting, they will be unblocked and given an error code. If some messages are queued there, the message buffers, along with any free private buffers are returned to the system-wide pool.

The calling task does not have to be the creator of the queue in order to be deleted. However, a queue must be deleted from the node on which it was created. The argument qid specifies the queue ID of the queue to delete.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid is incorrect; failed validity check.
0x38 ERR_TATQDEL Informative only; there were tasks waiting at the queue.
0x39 ERR_MATQDEL Informative only; there were messages pending in the queue.
0x3A ERR_VARQ Queue is variable length
0x53 ERR_ILLRSC Queue not created from this node.

NOTES

  1. Once created, a queue is generally used by multiple tasks for communication and synchronization. There is rarely a reason for deleting a queue, even when it is no longer used, except to allow reuse of the QCB.
  2. The calling task may be preempted after this call, if a task that is waiting for a message from the deleted queue has higher priority.
  3. Any pending messages are lost.
  4. q_delete() deletes an ordinary message queue. Use q_vdelete() to delete a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

If qid identifies a global queue, q_delete will notify the master node so that the queue may be removed from its Global Object Table. Thus, deletion of a global queue always causes activity on the master node.

CALLABLE FROM ISR No, only a task can call q_delete.

SEE ALSO q_create, q_vdelete

NAME

q_ident - Obtain the identifier of the named message queue

SYNTAX

#include <psos.h>
unsigned long q_ident(
         char name[4],           /* queue name */
         unsigned long node,     /* node selector */
         unsigned long *qid      /* queue identifier */
         )

DESCRIPTION

The intended purpose of this system call is to allow the calling task to obtain the queue ID of an ordinary message queue. However, since a variable length message queue is just a special type of message queue, q_ident() and q_vident() are functionally identical. Both return the queue ID of the first queue encountered with the specified name, whether it be ordinary or variable length.

Most system calls, except q_create()/q_vcreate() and q_ident()/q_vident(), reference a queue by its queue ID. For other tasks, one way to obtain the queue ID is to use q_ident()/q_vident(). Once obtained, the queue ID may then be used in all other operations relating to this queue.

The argument name specifies the name of the message queue whose ID is returned in the variable pointed to by qid. The argument node is a node selector. In a single node system, this argument must be 0. For multiprocessor systems, see Multiprocessor Considerations.

RETURN VALUE

The system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x04 ERR_NODENO Node specifier out of range.
0x09 ERR_OBJNF Named queue not found.

NOTES

  1. The pSOS+ kernel treats a queue name as a 32-bit integer, but the queue name is passed to the kernel as a four-byte character array when the application calls the kernel.
  2. The pSOS+ kernel does not check for duplicate queue names. If duplicate names exist, a q_ident() call can return the qid of any queue with the duplicate name.

MULTIPROCESSOR CONSIDERATIONS

  1. q_ident() converts a queue's name to its qid using a search order determined by the node input parameter, as described in pSOSystem System Concepts. Because queues created and exported by different nodes may not have unique names, the result of this binding may depend on the order in which the object tables are searched.
  2. If the master node's Global Object Table must be searched, the local kernel makes a q_ident() RSC to the master node.

CALLABLE FROM ISR No, only a task can call q_ident.

SEE ALSO q_create, q_vident

NAME

q_receive - Request a message from a message queue

SYNTAX

#include <psos.h>
unsigned long q_receive(
         unsigned long qid,       /* queue identifier */
         unsigned long flags,     /* queue attributes */
         unsigned long timeout,   /* timeout in clock ticks */
         unsigned long msg_buf[4] /* message buffer */
         )

DESCRIPTION

This system call allows a task or an ISR to obtain a message from an ordinary message queue.

The argument qid specifies the queue ID of the target queue. The argument flags specifies whether q_receive() will block waiting for a message. It should have one of the following values (defined in <psos.h>):

Q_NOWAIT
Don't wait for message.
Q_WAIT

The argument timeout specifies a timeout interval, in units of clock ticks. If the queue is non-empty, this call always returns the first message there. If the queue is empty and the caller specified Q_NOWAIT, then q_receive() returns with an error code. If Q_WAIT is elected, the caller will be blocked until a message is posted to the queue, or if the timeout argument is used, until the timeout occurs whichever happens first. If timeout is zero and Q_WAIT is selected, then q_receive() will wait forever. The timeout argument is ignored if Q_NOWAIT is selected. The message received is returned in msg_buf.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x01 ERR_TIMEOUT Timed out; this error code is returned only if a timeout was requested.
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity checks.
0x36 ERR_QKILLD Queue deleted while task waiting.
0x37 ERR_NOMSG Queue empty; this error code is returned only if Q_NOWAIT was selected.
0x54 ERR_NOAGNT Cannot wait; the remote node is out of agents.
HEX MNEMONIC DESCRIPTION
0x3A ERR_VARQ Queue is variable length.
0x65 ERR_STALEID Object's node has failed.
0x66 ERR_NDKLD Object's node failed while RSC waiting.

NOTES

  1. If it is necessary to block the calling task, q_receive() will enter the calling task at the message queue's task-wait queue. If the queue was created with the Q_FIFO attribute, then the caller is simply entered at the tail of the wait queue. If the queue was created with the Q_PRIOR attribute, then the task will be inserted into the wait queue by priority.
  2. q_receive() requests a message from an ordinary message queue. Use q_vreceive() to request a message from a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

If qid identifies a global queue residing on another processor node, the local kernel will internally make an RSC to that remote node to request a message from that queue. If the Q_WAIT attribute is elected, then the pSOS+m kernel on the target node must use an agent to wait for the message. If that node is temporarily out of agents, the call will fail. The number of agents on each node is defined by the mc_nagent entry in the Multiprocessor Configuration Table.

CALLABLE FROM ISR

SEE ALSO q_send, q_vreceive

NAME

q_send - Post a message to a message queue

SYNTAX

#include <psos.h>
unsigned long q_send(
         unsigned long qid,              /* queue identifier */
         unsigned long msg_buf[4]        /* message buffer */
         )

DESCRIPTION

This system call is used to send a message to a specified ordinary message queue. If a task is already waiting at the queue, the message is passed to that task, which is then unblocked and made ready to run. If no task is waiting, the input message is copied into a message buffer from the system pool or, if the queue has private buffers, into a private message buffer, which is then put in the message queue behind any messages already posted to the queue.

The argument qid specifies the queue ID of the target queue. The message to send is contained in the argument msg_buf.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x34 ERR_NOMGB Out of system message buffers.
0x35 ERR_QFULL Message queue at length limit.
0x3A ERR_VARQ Queue is variable length
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. If the caller is a task, it may be preempted as a result of this call.
  2. q_send() sends a message to an ordinary message queue. Use q_vsend() to send a message to a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid identifies a global queue residing on another processor node, the local kernel will internally make an RSC to that remote node to post the input message to that queue.
  2. If a task awakened by this call does not reside on the local node, the local kernel will internally pass the message to the task's node of residence, whose pSOS+m kernel will ready the task and give it the relayed message. Thus, a q_send() call, whether it is on the local or a remote queue, may cause pSOS+m activities on another processor node.

CALLABLE FROM ISR

SEE ALSO q_broadcast, q_receive, q_urgent, q_vsend

NAME

q_urgent - Post a message at the head of a message queue

SYNTAX

#include <psos.h>
unsigned long q_urgent(
         unsigned long qid,           /* queue identifier */
         unsigned long msg_buf[4]     /* message buffer */
         )

DESCRIPTION

This system call is identical in all respects to q_send() with one and only one exception: if one or more messages are already posted at the target queue, then the new message will be inserted into the message queue in front of all such queued messages.

The argument qid specifies the queue ID of the target queue. The message to send is defined in the argument msg_buf.

RETURN VALUE

This system call returns 0 on success, or an error code on failure.

ERROR CODES

HEX MNEMONIC DESCRIPTION
0x05 ERR_OBJDEL Queue has been deleted.
0x06 ERR_OBJID qid incorrect; failed validity check.
0x34 ERR_NOMGB Out of system message buffers.
0x35 ERR_QFULL Message queue at length limit.
0x3A ERR_VARQ Queue is variable length.
0x65 ERR_STALEID Object's node has failed.

NOTES

  1. q_urgent() is useful when the message represents an urgent errand and must be serviced ahead of the normally FIFO ordered messages.
  2. If the caller is a task, it may be preempted as a result of this call.
  3. q_urgent() sends a message to an ordinary message queue. Use q_vurgent() to send a message to a variable length message queue.

MULTIPROCESSOR CONSIDERATIONS

  1. If qid