User Manual Part 6

User Guide to Q4000/QPRO
Document Number 1135-4713 Rev G
THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION. IT MAY BE USED BY
RECIPIENT ONLY FOR THE PURPOSE FOR WHICH IT WAS TRANSMITTED AND WILL BE RETURNED UPON REQUEST OR WHEN NO LONGER NEEDED
BY RECIPIENT. DISCLOSURE TO UNAUTHORIZED THIRD PARTIES OR DUPLICATION WITHOUT THE EXPRESS WRITTEN PERMISSION OF QUAKE
GLOBAL IS PROHIBITED.
Page 146
CONFIDENTIAL
Information classified Confidential
-
Do not copy (See last page for obligations)
The message packet should not be freed by the application; this is done by the
foundation code.
complete with the name of the function in which the error occurred, the line number, and a string
identifying the type of error.
15.13 QMM module (Messages)
The QMM module implements QUAKE’s Message Manager. The firmware code in the module
checks for network availability, and handles the details of transferring messages from one
network to another based on availability. This is all transparent to the application. The primary
public API implemented in this module is MSG_send() ; this and other APIs for actions such as
deleting messages and getting a current message count are described in the API Function
Reference.
15.14 SYS module (System)
On the Q4000/QPRO, the Real-Time Operating System (RTOS) is abstracted to QUAKE calls so
that regardless of any changes to the underlying RTOS calls, the APIs available on QUAKE
modems remain constant. This abstraction is performed by the SYS module. Functionality to
manage tasks and message queues is provided with names like SYS_taskCreate() or
SYS_taskSuspend() which clearly indicate the functionality to any application developer
familiar with using an RTOS on an embedded target. For most applications, no direct calls to the
SYS module need to be made since the foundation code and the event driven architecture allow
complex applications to be developed without direct calls to the RTOS. For those applications
that need direct RTOS access, however, it is provided by the SYS module.
SYS_pwrDown() is used to power down the Q4000/QPRO in a controlled fashion. Everything
is shut off cleanly in the correct order, ensuring that on a subsequent reboot no data will have
been lost and the Q4000/QPRO is in an appropriate state.
15.15 SERIAL module
Access to the serial ports is provided by the QUAKE Serial Manager module. One goal in
developing SERIAL was to provide a high-level serial interface that allows different tasks, such as
OSI, QCT, or an AT protocol, that are managing different serial protocols, to share a single
physical serial port. These sorts of activities are handled by the foundation and should not be
needed by the application. Calls to SERIAL_readBytes() and SERIAL_write() allow
the application to read and write to the serial ports. The UARTPORTS are enumerated in
User_libQuake.h. SERIAL_openPort and SERIAL_closePort are provided, as well as
SERIAL_portFlush , and are described in the API Function Reference.
15.16 RELAY module
The RELAY module provides access to the relay hardware on the Q4000/QPRO. Four relay lines
are implemented. Two of them, UBATT0 and UBATT1, when asserted, provide closure to the
supply voltage at pins 25 and 27, respectively. The other two, GND0 and GND1, when asserted,
provide closure to ground at pins 26 and 28. The RELAY_CHAN_NAME type is enumerated in
User_libQuake.h. The RELAY module APIs allow the application to read the state of the lines or
assert or deassert the lines by individual channel number.
Note: