ACC/PEG APIs
The ACC/PEG set of APIs provides the ability for an application running on an LMU-5530 to set accumulators, PEG actions, and LMU status data.
The calamp_app_acc_sdk_test example demonstrates how to read/write accumulators, issue a PEG action, and read the LMU shared memory.
Overview
LMU-55XX consists of multiple CalAmp Linux processes running concurrently to manage and control its platform GPS, cellular devices, and various I/O peripherals. Additional custom applications may be added to the platform that need access to the LMU-55XX hardware devices and CalAmp's LMU application accumulators.
Because CalAmp applications are designed to have exclusive access to the hardware platform's peripheral devices and its accumulators, an SDK needs to be designed to allow read access of the CalAmp's LMU application status information, allow read/write access to CalAmp's LMU application accumulators, and allow a co-resident application to generate PEG actions.
CalAmp LMU Status SDK
CalAmp LMU status information is available via Linux's SYS_V shared memory. In order for a co-resident Linux process to access the LMU-55XX CalAmp LMU status shared memory region, the process must use Linux's SYS_V shared memory handlers (ftok, shmget, shmat, and shmdt).
The LMU-55XX platform's ftok key is generated by using shmkey = ftok (“/etc/calamp/lmu/peg_acc_shm”, 1) and shmget SYS_V handlers.
The shared memory region is created by the CalAmp LMU application at system startup. The structure is defined as follows:
struct _lmu_status_shared
{
u_int32_t ttag; /* Update time tag, seconds since 1 Jan,1970 (1Sec LSB) */
u_int32_t tof; /* Time-of-Fix, Position Data valid at this time,
seconds since 1 Jan,1970 (1Sec LSB) */
int32_t lat; /* latitude in WGS84 degrees, LSB=1E-7deg */
int32_t lon; /* longitude in WGS84 degrees, LSB=1E-7deg */
int32_t alt; /* Distance above Datum, LSB = 0.01 meter */
u_int32_t speed; /* Speed (centimeters per second LSB) */
u_int16_t heading; /* Heading (degrees True) */
u_int8_t nsats; /* Number Sats used in fix */
u_int8_t fixstat; /* Locate Status Flags: bit0=Predicted,
bit1=Differentially Corrected, bit2=Last Known,
bit3=Fix Invalid, bit4=2D, bit5=History,
bit6=Invalid Time*/
u_int16_t network_id; /* Comm Network ID*/
int16_t rssi; /* Comm Receive RSSI (dBm)
u_int8_t comm_state; /* Comm State, bit mapped,
b0=Available, b1=Network Service,
b2=Data Service,
b3=Connected (PPP Session Up),
b4=Voice Call is active*/
u_int8_t hdop; /* GPS Horizontal Dilution of Precision of fix,
unitless, LSB=0.1*/
u_int8_t inputs; /* Input Line State, bit-mapped,
b0=Ignition,b1=input1,b2=input2,b3=input3*/
u_int8_t unit_status; /* Status of LMU, b0-b1=GPS Ant Status,
b2=Error Flag */
};
CalAmp PEG/Accumulator SDK
To provide a co-resident application access to the LMU CalAmp application accumulators and PEG actions, Linux SYS_V message queues are used. The co-resident application needs to generate a SYS_V message queue before sending any messages to the LMU. For the CalAmp LMU PEG/accumulator command queue, the following three commands are supported:
LMU_APP_PEG_ACC_CMD_READ_ACC = 256
LMU_APP_PEG_ACC_CMD_WRITE_ACC = 257
LMU_APP_PEG_ACC_CMD_ACTION = 258
To access the LMU-55XX CalAmp LMU PEG/accumulator command queue, generate a Linux key_t using keyid = ftok (“/etc/calamp/lmu/peg_acc_queue”, 1); and the shmget with the keyid returned.
When sending and receiving PEG/accumulator messages, define the max length as 32 bytes because you want to minimize backward compatibility between CalAmp firmware releases. The initial version of the firmware is sending/receiving 24 bytes of message data.
CalAmp Read Accumulator Interface
To read a CalAmp LMU application's accumulator, the co-resident application needs to generate a read_accum request message and send it to the CalAmp LMU PEG/accumulator command queue. The LMU application will then generate a response back to the co-resident's message queue with a read_accum response message. There are 254 accumulators within the CalAmp LMU application. The read_accum request and response message formats are defined as follows:
struct _lmu_app_peg_acc_hdr
{
int32_t msg_type; /* linux sysv message type = 1 for lmu, 2= client */
int32_t cmd; /* sdk command ( read acc, write acc, peg action ) */
int32_t transaction; /* client transaction id */
};
struct _lmu_app_peg_acc_read_acc_request
{
struct _lmu_app_peg_acc_hdr header;
int32_t client_qid; /* client's response queue id */
int32_t index; /* accumulator index */
int32_t spare1;
int32_t spare2;
int32_t spare3;
};
struct _lmu_app_peg_acc_read_acc_response
{
struct _lmu_app_peg_acc_hdr header;
int32_t status; /* request status , 0=good */
int32_t index; /* accumulator index ranges from 0 to 253 */
u_int32_t value; /* accumulator value */
};
CalAmp Write Accumulator Interface
To write a CalAmp LMU application's accumulator, the co-resident application needs to generate a write_accum request message and send it to the CalAmp LMU PEG/accumulator command queue. The LMU application will then generate a response back to the co-resident's message queue with a write_accum response message. The write_accum request and response message formats are defined as follows:
struct _lmu_app_peg_acc_hdr
{
int32_t msg_type; /* linux sysv message type = 1 for lmu, 2= client */
int32_t cmd; /* sdk command ( read acc, write acc, peg action ) */
int32_t transaction; /* client transaction id */
};
struct _lmu_app_peg_acc_write_acc_request
{
struct _lmu_app_peg_acc_hdr header;
int32_t client_qid; /* client's response queue id */
int32_t index; /* accumulator index */
int32_t new_value; /* accumulator's new value */
int32_t spare1;
int32_t spare2;
};
struct _lmu_app_peg_acc_write_acc_response
{
struct _lmu_app_peg_acc_hdr header;
int32_t status; /* request status , 0=good */
int32_t index; /* accumulator index ranges from 0 to 253 */
u_int32_t value; /* accumulator value after write */
};
CalAmp PEG Action Message Format
To generate a CalAmp LMU PEG action request, the co-resident application needs to generate a peg_action request message and send it to the CalAmp LMU PEG/accumulator command queue. The LMU application will then generate a response back (if the PEG action is not a sleep action) to the co-resident's message queue with a peg_action message response. The peg_action request and response message formats are defined as follows:
struct _lmu_app_peg_acc_hdr
{
int32_t msg_type; /* linux sysv message type = 1 for lmu, 2= client */
int32_t cmd; /* sdk command ( read acc, write acc, peg action ) */
int32_t transaction; /* client transaction id */
};
struct _lmu_app_peg_acc_action_request
{
struct _lmu_app_peg_acc_hdr header;
int32_t client_qid; /* co-resident application response queue id */
int32_t action; /* calamp peg action command */
int32_t modifier; /* calamp peg action modifier */
int32_t spare1;
int32_t spare2;
};
struct _lmu_app_peg_acc_action_response
{
struct _lmu_app_peg_acc_hdr header;
int32_t status; /* Calamp lmu peg action response status, 0=good */
};
Updated almost 3 years ago