Community Documents
Background: The MIL-STD-1553 standard defines a communication scheme that is used by many military, aviation, and aerospace products. Engineers involved in research, development, and test systems must implement hardware and software in order to communicate with and test MIL-STD-1553 products. Software and hardware packages are available from many suppliers. This document discusses using the MIL-STD-1553 line of hardware from Alta Data Technologies. The Alta API has a diverse and deep feature set, and this white paper focuses on how to achieve a buffered transmission to a 1553 device using a standard Windows PC. The buffered term refers to transmission messages that:
- Are formatted ahead of time (without relying on received messaged from the 1553 device)
- May be sent by the Alta card without requiring action by the PC on each transmission.
Example: For the purpose of this example, assume the Widget 2000 is a device that communicates using MIL-STD-1553. It expects to get a time data frame every 25ms.
Design: In order to guarantee each timing frame is sent out at the correct time with the correct data, a full second of timing messages will be put into a buffer on the Alta card that will send the data out. This way the PC only has to update the buffer a few times per second. When the PC updates the buffer, it can predict that the time frames will use the current time plus 25ms for each time frame in the buffer. The buffer size should be a multiple of 2, and as soon as half of the buffer has been output, that half can be refilled by the PC while the other half is being output.
The interrupt feature of the Alta device will be used to signal the PC that a half-buffer has been output and could be updated. The Alta API is then used to read the interrupt events and perform the buffer updates.
For this example, assume a single control block for the time frame messages and that a buffer size of 40 is used.
Implementation: The Alta driver API calls to accomplish the design above are broken down into 3 groups: initialization, handler, and close. From the Alta documentation, a bus controller configuration looks like the following:
Initialization: The ADT_L1_1553_BC_Init function includes a CSR word containing bit fields. One of these fields is BC_CSR_EN_SUBFRAMES, which should be turned on.
The numCDP field of the ADT_L1_1553_BC_CDP_Allocate function is set to 40.
The fields of ADT_L1_1553_BC_CB_Write are set up to specify 40 messages and a repeat rate of 25ms.
As part of initialization, the ADT_L1_1553_BC_CDP_Write is called over 20 iterations to pre-populate the first half buffer. Each iteration the CDP words are set to contain the time data (increasing by 25ms). However, the first call to ADT_L1_1553_BC_CDP_Write also sets the CDPControlWord to have the interrupt on message complete bit (CSR_INTMSGCOMP) to be on.
Handler: After initialization, the interrupts are monitored. This can be done by an interrupt callback, or by a polling loop using the function ADT_L1_1553_INT_IQ_ReadNewEntries to find when an interrupt has occurred.
When an interrupt occurs, the buffer index of the CDP that generated the index is returned. If the buffer index returned is 0, it means that the first buffer half is being output and buffer indices 20-39 should be updated. If the buffer index reported is 20, then it means the second buffer half is being output and buffer indices 0-19 should be updated.
Close: Call ADT_L1_1553_BC_Stop, ADT_L1_1553_BC_Close, and ADT_L1_1553_CloseDevice.
LabVIEW Example: The above logic is shown as programmed in LabVIEW:
Init Code:
Handle Code:
Close Code:
