programmer’s guide

MIL-STD-1553
Interface Module

AIM GmbH
Sasbacher Str. 2
79111 Freiburg, Germany

Tel: +49-761-45229-0
Fax: +49-761-45229-33

[email protected]
www.aim-online.com

May 2014
V22.9x Rev. A
MIL-STD-1553 Interface Module

Programmer's Guide
for
AyX1553-1/-2/-4/-8
AyI1553-1/-2
AMC1553-1/2/4/T (PMC Version)
APM1553-1 (PC-Card Version)
AP104-1553-1/2/4 (PC104+ Version)
APU1553-1/2 (USB Version)
AEC1553-1/2 (ExpressCard Version)
APE1553-1/2/4/DS (PCIe Version)
AXC1553-1/2/4/T (XMC Version)
AMCX1553-1/2/4/T (PMC Version)

V22.9x Rev. A

May 2014

AIM No. 60-11900-37-229X-A

 AIM WORLDWIDE
AIM GmbH
Sasbacher Str. 2
79111 Freiburg, Germany
+49-761-45 22 90
[email protected]

Munich Sales Office

Terofalstrasse 23 a
80689 Muenchen
+49-89-70 92 92 92
[email protected]

AIM-USA
Seven Neshaminy Interplex
Suite 211
TREVOSE, PA 19053
267-982-2600
877-520-1553
[email protected]

AIM UK
Cressex Business Park
Lincoln Rd, High Wycombe
Bucks HP12 3RB, England
+44-1494-44 68 44
[email protected]

Notice: The information that is provided in this document is believed to be accurate. No

responsibility is assumed by AIM for its use. No license or rights are granted by implication in
connection therewith. Specifications are subject to change without notice.

© Copyright 1999-2014 AIM

ii
DOCUMENT HISTORY

Version Cover Date Created by Description

V15.0x 4/2003 J. Furgerson Creation of document.
Revision number synchronized with associated 1553
Software
Reference Manual.
V18.1x 11/2003 J. Furgerson Updated to support BSP V7.10
V19.0x 3/2004 J. Furgerson BSP0801 support. No changes required.
V19.0x 4/14/04 Patrick Giesel Corrected phone number
Rev. B Changed page i to a common layout
V19.0x 4/19/04 Frank Schmid Small corrections
Rev. C
V19.3x 1/2/06 J. Furgerson Updated to support BSP V9.03
Rev. A
V19.3x 2/6/06 Patrick Giesel - Corrected front page
Rev. B - Changed chapter 1.4.2
- Added chapter 3.2.2
- Renamed chapter “3.2.3 Board Support Package”
to “3.2.3 Board Software Package”
- Corrected table 3.2.6.1-I
- Changed chapter 4.1.1 (32 modules supported,
up to 7 servers supported)
- Changed chapter 4.1.6 (corrected call to
ApiCmdSetIrigTime)
- Changed chapter 4.1.8 (corrected default dbg message
setting)
- Changed chapter 4.2.8 (added note)
- Changed chapter 5.2.1 (corrected call to
ApiCmdSetIrigTime)
V19.5x 1/18/07 Patrick Giesel - Changed chapter 1.2 (corrected name for section 6)
Rev. A - Corrected chapter 1.4.2 (updated document list)
- Corrected chapter 3.1
- Corrected chapter 3.2.2
- Corrected chapter 3.2.4
- Corrected chapter 4.1.4
- Corrected chapter 5.3
- Corrected chapter 6.2
V19.5x 7/07 S. Riedinger Unify names of products
Rev. B
V19.5x 8/07 S. Riedinger Update images
Rev. C
V21.0x 2/26/09 M. Haag Updated to support BSP V10
Rev. A
V21.0x 5/25/09 M. Haag - Corrected chapter 4.2.2
Rev. B
V21.5x 9/24/09 M. Haag Added new hardware AP104-1553-1/2/4
Rev. A
Version Cover Date Created by Description
V21.5x 11/03/09 M. Melcher Some minor corrections

iii
Rev. B

V21.5x 1/8/2010 M. Haag New samples

Rev. C
Merged VME and PCI Programmer’s Guide
V21.7x 12/2010 M. Haag Updated front page
Rev. A J. Pfaadt Moved Sample Description to Getting Started Manual
Removed Index
V22.0x February 2011 T.Jahn Updated to support BSP V11.00
Rev. A
V22.7x December M. Haag Updated to support BSP V11.20
Rev. A 2012
V22.7x January M. Haag QS Review
Rev. B 2013
V22.9x May M. Haag Updated to support BSP V11.30
Rev. A 2014 Added description of ApiExit

iv
TABLE OF CONTENTS

Section Title Page

1 INTRODUCTION.......................................................................................................... 1
1.1 General ...................................................................................................................... 1
1.2 How This Programmer's Guide is organized ........................................................ 1
1.3 Conventions Used ..................................................................................................... 3
1.3.1 General Documentation Conventions ...................................................................3
1.3.2 Parameter Naming Conventions ...........................................................................3
1.4 Reference Documents .............................................................................................. 5
1.4.1 Industry Standards ................................................................................................5
1.4.2 AIM Document Family.........................................................................................5

2 MIL-STD-1553 SPECIFICATION OVERVIEW....................................................... 7

3 AIM 1553 BUS INTERFACE MODULE OVERVIEW .......................................... 13

3.1 Hardware Architecture ......................................................................................... 15
3.2 Software Overview ................................................................................................. 18
3.2.1 Software Architecture .........................................................................................18
3.2.2 Necessary Files and Defines for New Application Programs.............................21
3.2.3 Windows Boards Software Package Content .....................................................23
3.2.4 Linux Board Software Package Content ............................................................24
3.2.5 VxWorks Board Software Package Content .......................................................25
3.2.6 API S/W Library Structure/Content ...................................................................25
3.2.7 Application Program Structure Overview ..........................................................26
3.2.8 MIL-STD-1553 Transfers and Frame Structure Overview ................................30
3.2.8.1 About MIL-STD-1553 Transfers .................................................................... 30
3.2.8.2 Major/Minor Frame Scheduling Design Concepts ......................................... 34

4 PROGRAMMING USING THE API LIBRARY..................................................... 35

4.1 Library Administration and System Programming ........................................... 35
4.1.1 Initializing Your Application and Application Interface to the AIM Board ......36
4.1.1.1 Only for Windows PC..................................................................................... 39
4.1.1.2 Only for VME Systems ................................................................................... 39
4.1.2 Getting AIM Board Status and Configuration Information ................................41
4.1.3 Defining MIL-STD-1553 Protocol .....................................................................41
4.1.4 Defining External Connectivity ..........................................................................41
4.1.5 Configuring Response Timeout ..........................................................................44
4.1.6 Utilizing IRIG-B .................................................................................................45
4.1.7 Interrupt Handling...............................................................................................46
4.1.8 Debugging...........................................................................................................52
4.1.9 GPIO Programming ............................................................................................53
4.2 Bus Controller Programming ............................................................................... 54
4.2.1 Initializing the BC ...............................................................................................55
4.2.2 Defining 1553 Transfers .....................................................................................56

v
4.2.3 BC Transmit and Receive Message Data Word Generation/Processing ............60
4.2.3.1 For BC-to-RT and BC Broadcast Type Transfers (BC Transmit) .................. 60
4.2.3.1.1 Dynamic Data Word Generation ................................................................... 62
4.2.3.1.2 Using FIFOs and Dataset Buffers for Data Generation................................. 63
4.2.3.2 For RT-to-BC Type Transfers (BC Receive).................................................. 65
4.2.4 BC Transfers with Error Injection ......................................................................65
4.2.5 Defining Minor/Major Frames Content & Timing .............................................66
4.2.5.1 Standard Framing Mode ................................................................................. 67
4.2.5.2 BC Instruction Table Mode ............................................................................ 69
4.2.6 Starting the Bus Controller .................................................................................72
4.2.7 Acyclic 1553 Transfers .......................................................................................77
4.2.8 BC Interrupt Programming .................................................................................78
4.2.8.1 How to Setup the 1553 Transfer to Cause an Interrupt .................................. 79
4.2.8.2 How to Setup the Minor Frame Transfer Sequence to Cause an Interrupt ..... 80
4.2.9 Status Word Exception Handling .......................................................................80
4.2.9.1 RT Service Request Processing ...................................................................... 82
4.2.10 Tracking BC Receive Data using Track Multiplex Buffers ...............................84
4.3 Remote Terminal Programming .......................................................................... 86
4.3.1 Initializing the RT ...............................................................................................87
4.3.2 Defining RT Subaddress/Mode Code for Communication with the BC ............88
4.3.2.1 RT Transmit/Receive Message Data Word Generation/Processing ............... 92
4.3.2.2 RT Transmit/Receive Mode Code Generation/Processing ............................. 96
4.3.2.3 RT Transmit/Receive Broadcast Message Generation/Processing ................. 98
4.3.3 RT Transfers Error Injection...............................................................................99
4.3.3.1 RT Transfers Error Injection into Status/Data Word ...................................... 99
4.3.3.2 RT Transfer Error Emulation via Status Word Response............................. 101
4.3.4 RT Interrupt Programming ...............................................................................102
4.3.4.1 How to Setup the RT Transfer to Cause an Interrupt ................................... 102
4.3.5 RT Global Configuration ..................................................................................103
4.3.6 Tracking RT Receive Data using Track Multiplex Buffers ..............................103
4.4 Bus Monitor Programming ................................................................................. 105
4.4.1 Bus Monitor Initialization.................................................................................110
4.4.2 Bus Monitor Capture Mode and Interrupt Mode Definition.............................110
4.4.3 Bus Monitor Triggers........................................................................................113
4.4.3.1 Bus Monitor Trigger Definition .................................................................... 114
4.4.3.1.1 Bus Monitor Static Trigger Definition ........................................................ 115
4.4.3.1.1.1 Trigger on Error Condition.......................................................................... 115
4.4.3.1.1.2 Trigger on External Event Condition .......................................................... 118
4.4.3.1.2 Bus Monitor Dynamic Trigger Definition ................................................... 119
4.4.3.1.2.1 Trigger on Received Word .......................................................................... 119
4.4.3.1.2.2 Trigger on Data Value Condition ................................................................ 122
4.4.3.2 Starting/Stopping the "Data Capture" Process .............................................. 124
4.4.3.3 Arming the Trigger ....................................................................................... 126
4.4.4 Bus Monitor Interrupts......................................................................................127
4.4.5 Format of Data Stored in the Monitor Buffer ...................................................129
4.4.6 Standard Data Capture Mode............................................................................132
4.4.7 Selective Data Capture Mode ...........................................................................134
4.4.8 Recording Mode ...............................................................................................134

vi
4.4.9 Recording Using Queuing ................................................................................135
4.4.10 Message Filter Recording Mode .......................................................................135
4.4.11 Additional Bus Monitor Filter ..........................................................................136
4.4.12 Additional Monitor Features .............................................................................136
4.4.12.1 Dynamic Tag Monitor................................................................................... 136
4.5 Replay Programming........................................................................................... 138

5 NOTES ........................................................................................................................ 141

5.1 Acronyms and Abbreviations ............................................................................. 141
5.2 Definition of Terms .............................................................................................. 144

vii
THIS PAGE INTENTIONALLY LEFT BLANK

viii
LIST OF FIGURES

Figure Title Page

Figure 2-1 1553 Configuration Example ...................................................................... 8

Figure 2-2 Word Formats ............................................................................................. 9
Figure 2-3 Information Transfer Formats ................................................................... 10
Figure 2-4 Broadcast Information Transfer Format ................................................... 10
Figure 2-4 Broadcast Information Transfer Format ................................................... 11
Figure 3-1 MIL-STD-1553 Bus Sample Configuration ............................................. 14
Figure 3.1-1 API1553-2 Hardware Diagram ................................................................. 17
Figure 3.2.1-1 Host/Target Software Interface Diagram .................................................. 18
Figure 3.2.1-2 Library and Program Interfaces ................................................................ 20
Figure 3.2.6-1 Basic Application Program Structure ....................................................... 27
Figure 3.2.7.1-1 API S/W Buffer Assignments for 1553Transfers ..................................... 32
Figure 3.2.7.1-2 FIFOs and Dataset Buffers I/ F to Message Buffer Pool .......................... 33
Figure 3.2.7.2-1 Major/Minor Frame Scheduling Diagram ................................................ 34
Figure 4.1.4-1 MILbus Output Amplitude vs. Voltage Control ....................................... 43
Figure 4.1.7-1 Interrupt Setup Process ............................................................................. 51
Figure 3.2.7.1-1 BC Buffer Header and Buffer Pool Interface ........................................... 57
Figure 4.2.3.1.1-1 Data Generation Functions Diagram ........................................................ 63
Figure 4.2.3.1.2-1 BC Transfer Data Generation via FIFO or Dataset Buffers ..................... 64
Figure 4.2.6-1 Minor Frame Timing Control Diagram .................................................... 74
Figure 4.2.6-2 Minor Frames within the Major Frame using Autoframing ..................... 74
Figure 4.2.6-3 Minor Frames within the Major Frame using External Pulse ................... 75
Figure 4.2.6-4 Minor Frames within the Major Frame using External Pulse and a Wait
Instruction................................................................................................. 75
Figure 4.2.9.1-1 Vector Word Format ................................................................................. 82
Figure 4.2.10-1 BC Track Process Example ...................................................................... 84
Figure 4.3.2-1 RT Buffer Header and Buffer Pool Interface............................................ 89
Figure 4.3.2-2 Status Word Bits ....................................................................................... 90
Figure 4.3.2.1-1 Data Generation Functions Diagram ........................................................ 93
Figure 4.3.2.1-2 RT Transfer Data Generation via FIFO or Dataset Buffers...................... 94
Figure 4.3.6-1 RT Track Process Example..................................................................... 104
Figure 4.4.3.2-1 Bus Monitor Function Trigger Word ...................................................... 125
Figure 4.4.3.3-1 Bus Monitor Trigger Index Word ........................................................... 127
Figure 4.4.5-1 Monitor Bus Word Entry ........................................................................ 129
Figure 4.4.5-2 Bus Word Entry ...................................................................................... 130
Figure 4.4.5-3 IRIG Time Tag Low Entry ..................................................................... 130
Figure 4.4.5-4 IRIG Time Tag High Entry..................................................................... 130
Figure 4.4.5-5 Error Word Entry .................................................................................... 131
Figure 4.4.5-6 Bus Monitor Buffer Entry Example........................................................ 132

ix
LIST OF TABLES
Table Title Page

Table - I API S/W Library Data Type Naming Conventions .................................... 4

Table 3.2.1-I Compatible Operating Systems / Recommended Compilers .................... 19
Table 3.2.7.1-I Transfer ID/Buffer Header ID Ranges...................................................... 30
Table 3.2.7.1-II Buffer ID Ranges ...................................................................................... 30
Table 4.1.7-I Available Interrupt Types and Related Function Call .............................. 49
Table 4.1.8-I Error Message Output Control Levels ...................................................... 52
Table 4.2.2-I 1553 BC Transfer Definition Structure (api_bc_xfer) ..................... 58
Table 4.2.2-II Transfer Setup for Different Types of 1553 Transfers ............................. 60
Table 4.2.3.1-I BC Transmit Buffer Fill Method Summary .............................................. 61
Table 4.2.3.1.1-I Dynamic Data Word Generation Summary .............................................. 62
Table 4.2.5.1-I Standard Framing Mode Instructions ....................................................... 67
Table 4.2.5.2-I BC Instruction Table Mode Instructions .................................................. 70
Table 4.2.6-I BC Start Modes ......................................................................................... 73
Table 4.2.8.1-I Setup for 1553 Transfers to Generate Interrupts ...................................... 79
Table 4.2.9-I BC Transfer Definition Parameters for Status Word Exception Handling80
Table 4.2.9-II Transfer Setup for Status Word Exception Handling Examples .............. 82
Table 4.2.9.1-I BC Response to RT Vector Word............................................................. 83
Table 4.3.2-I Transfer Setup for Different Types of RT Transfers ................................ 91
Table 4.3.2.1-I Function Calls Required for RT Data Word Transmission Scenarios ...... 94
Table 4.3.2.2-I Mode Codes .............................................................................................. 97
Table 4.3.4.1-I Setup for RT Transfers to Generate Interrupts ....................................... 103
Table 4.4-I Bus Monitor Modes and Output Format Summary ................................ 107
Table 4.4-I Bus Monitor Modes and Output Format Summary (Continued) ............ 108
Table 4.4-II Bus Monitor Modes and Function Summary .......................................... 109
Table 4.4.3.1-I Trigger Control Block Structure ............................................................. 115
Table 4.4.3.1.1.1-I Error Conditions for Triggering the Bus Monitor .................................. 116
Table 4.4.3.1.1.1-II TCB Parameters for Error Condition Trigger ......................................... 117
Table 4.4.3.1.1.2-I TCB Parameters for External Event Trigger .......................................... 118
Table 4.4.3.1.2.1-I Received Words Triggering the Bus Monitor......................................... 119
Table 4.4.3.1.2.1-II TCB Parameters for Dynamic Received Word Trigger.......................... 121
Table 4.4.3.1.2.2-I TCB Parameters for Dynamic Data Value Trigger ................................ 122
Table 4.4.3.2-I Bus Monitor Capture Scenarios .............................................................. 125
Table 4.4.4-I BM Interrupts Relative to Capture Mode ............................................... 128

x
 Section 1 - Introduction

1 INTRODUCTION

1.1 GENERAL

Welcome to the Programmer's Guide for MIL-STD-1553 (API1553, ACI1553, AVI1553,

APX1553, ACX1553, AVX1553, AMC1553, APM1553, AP104-1553, APU1553, AEC1553,
AXC1553, AMCX15553 and APE1553). This programmer's guide, in conjunction with the
associated MIL-STD-1553 Reference Manual, is intended to provide the software (s/w)
programmer with the information needed to develop a host computer application interface to
the aforementioned AIM bus interface card(s). The Programmer's Guide provides the MIL-
STD-1553 application developer with high-level s/w development information including high
level system design information, board support package (BSP) contents, user application
system design concepts, function call guidelines and sample programs for the AIM bus
interface card. The Software Library Reference Manual provides the user with detailed
programming information including s/w library function call and header file details and
specific troubleshooting information.

1.2 HOW THIS PROGRAMMER'S GUIDE IS ORGANIZED

This Programmers Guide is divided into the following sections:

Provides an introduction to the contents of the

Section 1
programmer's guide documentation conventions and
Introduction
applicable documents.

Section 2 Provides a high level overview of the MIL-STD-1553

MIL-STD-1553 communication protocol including Command, Data and
Overview Status word formats and message sequencing.

Section 3 Provides a high level overview of the hardware and

AIM1553 software architecture. Included in the software section is a
Module description of the Board Support Package, an application
Overview program structure overview and basics about 1553
message transfers and minor/major frame definition.

MIL-STD-1553 Programmer's Guide 1

 Section 1 - Introduction

Provides the programming guidelines for the Library

Administration and System functions as well as the 4 main
functional subsystems on the 1553 interface bus card including:
Bus Controller
RemoteTerminal(s)
Bus Monitor
Replay

4.1 4.2 4.3

Library Bus Remote
Admin & Controller Terminal
System

Describes the sample project shipped Section 5

with the BSP. And gives an overview Program
about the samples provided. There is Samples
also a description of the process of
creating an new project.

Section 6
Provides expansion for all acronyms
Notes
and definitions for terms used
frequently in this document.

2 MIL-STD-1553 Programmer's Guide

 Section 1 - Introduction

1.3 CONVENTIONS USED

1.3.1 General Documentation Conventions

We use a number of different styles of text and layout in this document to help differentiate
between the different kinds of information. Here are some examples of the styles we use and
an explanation of what they mean:

Italics - used as a placeholder for the actual name, filename, or version of the
software in use

Bold text - a function, or parameter, or used to highlight important information

Bold Blue - will be used to show reference documentation

Bold italics - caution, warning or note

Font - font used to show paths, directories and filenames within the body of text
will be shown in blue. For example:

C:\Windows\System32\Drivers\Aim_mil.sys

A smaller version of this font will be used to list

software code.

| - an action delineator that will lead you through nested menu items and dialog
box options to a final action, for example, the File | Open ..

In addition to text and layout convention, there are a couple of naming conventions used to
simplify the information herein. All of the aforementioned AIM bus interface cards utilize
the same s/w library functions also called the Application Programming Interface (API).
Therefore, for ease of documentation flow, the s/w library will be referred to from this point
on as the API S/W Library. In addition, the software and firmware contained on the AIM
bus interface cards will be referred to as the API Target S/W.

1.3.2 Parameter Naming Conventions

In order to understand the sample programs and individual programming examples contained
in this guide, we should review some of the parameter naming conventions used throughout
the API S/W Library. Naming conventions have been used for naming constants, structures,
function calls and data types.

MIL-STD-1553 Programmer's Guide 3

 Section 1 - Introduction

Note: All constants and structures used in the API S/W Library are defined in the
Ai1553i_def.h header file. Functions are defined in the file Ai1553i_fnc.h.
Data types used in the API S/W Library are defined in Ai_cdef.h. Both header
files are described in the associated S/W Library Reference Manual.

Naming conventions used include the following

• Constants - For every function call, a list of constants have been defined to
better describe the numerical value of the function input or output. (located in
Ai1553i_def.h). These constants will be used throughout this document.

• Structures - Named as ty_api_name where name is unique to the structure.

(located in Ai1553i_def.h)

• Functions - Named as either Apiname or ApiCmdname where name is

unique to the function (located in Ai1553i_fnc.h)

 Apiname functions do not involve driver commands to the bus

interface unit (biu)

 ApiCmdname functions involve driver commands to the biu

• Data Types - all variables are assigned an AIM equated data type as shown in
Table 1.3.2-I below (defined in Ai_cdef.h)

Table - I API S/W Library Data Type Naming Conventions

Size
API S/W Library Data Type
(in bytes)
AiInt int 4
AiUInt unsigned int 4
AiInt8 char 1
AiUInt8 unsigned char 1
AiInt16 short 2
AiUnt16 unsigned short 2
AiInt32 int 4
AiUInt32 unsigned int 4
AiInt64 long long 8
AiUInt64 unsigned long long 8
AiChar char 1
AiUChar unsigned char 1
AiDouble double 8
AiFloat float 4

4 MIL-STD-1553 Programmer's Guide

 Section 1 - Introduction

1.4 REFERENCE DOCUMENTS

1.4.1 Industry Standards

MIL-STD-1553B, Department of Defense Interface Standard for Digital Time Division

Command/Response Multiplex Data Bus, Notice 1-4, January 1996

PCI Local Bus Specification, Revision 2.1, June 1991

1.4.2 AIM Document Family

AIM has developed several documents that may be used to aid the developer with other
aspects involving the use of the PCI 1553 bus interface card. These documents and a
summary of their contents are listed below:
MIL-STD-1553 Reference Manual - provides the 1553 application developer with detailed
programming information including library function call and specific troubleshooting
information. This guide is to be used in conjunction with this Programmer's Guide.

MIL-STD-1553 Tutorial - provides a general overview of MIL-STD-1553 including MIL-

STD-1553 history and a complete annotated version of the MIL-STD-1553B
specification and an interpretation of the specification contents.

PCI 1553 Windows Getting Started Manual - assists the first time users of the AIM PCI
1553 boards with software installation, hardware setup and starting a sample project.

PCI 1553 Linux Getting Started Manual - assists the first time users of the AIM PCI 1553
boards with software installation, hardware setup and starting a sample project.

VME 1553 VxWorks Getting Started Manual - assists the first time users of the AIM
VME 1553 boards with software installation, hardware setup and starting a sample
project.

AIM Network Server (ANS) Users Manual - assists users with installation and initial setup
of the AIM Network Server software. Client and Server configuration and
software/hardware requirements are outlined with complete step by step instructions
for software installation.

MIL-STD-1553 Programmer's Guide 5

 Section 1 - Introduction

Hardware Manuals -- provide the hardware user’s manual for the specified modules. The
documents cover the hardware installation, the board connections the technical data
and a general description of the hardware architecture. The following hardware
manuals are available:

• ACI1553-3U Hardware Manual (cPCI Bus modules)

• API1553 Hardware Manual (PCI Bus modules)
• AVI1553 Hardware Manual (VME-Bus modules)
• AVX1553 Hardware Manual (VME-Bus modules )
• APX1553 Hardware Manual (PCIx Bus modules)
• ACX1553 Hardware Manual (PCIx Bus modules)
• AMC1553 Hardware Manual (PMC-Bus modules)
• APM1553 Hardware Manual (PCMCIA-Bus modules)
• AP104-1553 Hardware Manual (PC104+ Bus modules)
• APU1553 Hardware Manual (USB Bus modules)
• AEC1553 Hardware Manual (ExpressCard Bus modules)
• AMCX1553 Hardware Manual (PMC Bus modules)
• AXC1553 Hardware Manual (XMC Bus modules)
• APE1553 Hardware Manual (PCIe Bus modules)

6 MIL-STD-1553 Programmer's Guide

 Section 2 – MIL-STD-1553 Specification Overview

2 MIL-STD-1553 SPECIFICATION OVERVIEW

For any 1553 application, the user will define the requirements for the terminal under design.
Terminal device types include:

a. Bus Controller

 Manages all message traffic on the bus in a Command-Response fashion

 Only one bus controller is allowed, provisions for a backup BC to take

control if needed, but only one at a time

 Executes scheduled messages on the bus in a pre-determined priority

scheme, utilizing frame and sub-frame time scheduling

b. Remote Terminal

 Up to 32 RT devices, each with a unique individual address

 Respond only when requested by the BC

 Responds back to every BC command

c. Bus Monitor

 No address, no transmission on the bus

Figure 2-1 shows an example of a 1553 bus configuration.

MIL-STD-1553 Programmer's Guide 7

 Section 2– MIL-STD-1553 Specification Overview

Figure 2-1 1553 Configuration Example

BC
Mission
NAV RADAR
Computer
RT RT

A
MIL -STD -1553 BUS
B

Avionics Subsystem
RT - Remote Terminal
BC - Bus Controller
BM RT
BM - Bus Monitor
Display Weapon

The user's application will likely be required to adhere to an interface control document which
will define the data interfaces between the RT and BC. To insure common terminology and
understanding of the API programming design information contained in the following sections,
we will quickly review the basic concepts of the MIL-STD-1553 message content and transfer
protocol. Message traffic on the 1553 bus consists of command, data, and status words with
the format shown in Figure 2-2.

8 MIL-STD-1553 Programmer's Guide

 Section 2 – MIL-STD-1553 Specification Overview

Figure 2-2 Word Formats

Bit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Times

Command 5 1 5 5 1
Word
Sync Remote Terminal T/R Subaddress Data Word Count/ P
Address Mode Mode Code

Data 1
16
Word
Sync Data P

Status 5 1 1 1 3 1 1 1 1 1 1
Word

Broadcast Command

Subsystem Flag

Terminal Flag
Service Request Bit

Dynamic Bus Control

Instrumentation

Busy

Parity
Sync Remote Terminal Reserved
Message Error

Address

Note: T/R - transmit/receive

P - parity

MIL-STD-1553 defines 10 types of transfers as shown in Figure 2-3 and Figure 2-4. Each
transfer is composed of control words (command and status) and data words and is always
initiated by the BC. Normal communications start with a command from the BC, transmitted
to a selected RT address. The RT receives or transmits data - depending on the BC command -
and transmits a status word response. The BC can also initiate an information transfer between
two RTs by issuing one a transmit command and the other a receive command.

Mode commands are used in terminal control and systems checks. Mode commands may or
may not involve the transfer of a data word.

Broadcast commands are commands sent to multiple RTs at once. Although restricted under
Notice 1, Notice 2 allows broadcast command transmission but only a limited set. The RT is
responsible for distinguishing between broadcast and non-broadcast command messages.

Data transmission on the bus between terminal devices is performed in a deterministic manner
with no more or less than a 4-12 µsec response intermessage gap allowed.

MIL-STD-1553 Programmer's Guide 9

 Section 2– MIL-STD-1553 Specification Overview

Figure 2-3 Information Transfer Formats

Receive Data Data Data Status Next

Command Word Word ••• Word
** Word
# Command

Controller to RT Transfer

Transmit
Command
** Status Word Data
Word
Data
Word
••• Data
Word
# Next
Command

RT to Controller Transfer

Receive
Command
Transmit
Command
** Status
Word
Data
Word
Data
Word
••• Data
Word
** Status
Word
# Next
Command

RT-to-RT Transfer

Note:
Mode Status Next # Intermessage Gap
Command ** Word # Command * * Response Time
Mode Command without Data Word

Mode Status Data Next

Command ** Word Word # Command

Mode Command with Data Word (Transmit)

Mode Data Status Next

Command Word ** Word # Command

Mode Command with Data Word

(Receive)

10 MIL-STD-1553 Programmer's Guide

 Section 2 – MIL-STD-1553 Specification Overview

Figure 2-4 Broadcast Information Transfer Format

Receive
Command
Data
Word
Data
Word
••• Data
Word
# Next
Command

Controller to RT(s) Broadcast

Please refer to the AIM MIL-STD-1553 Tutorial for a specification of the standard.

Receive Transmit Status Data Data Data Next

Command Command ** Word Word Word •• Word
# Command

RT-to-RT(s) Broadcast

Mode Next
Command
# Command Note:
Mode Command without Data Word # Intermessage Gap
* * Response Time

Mode Data Next

Command Word
# Command

Mode Command with Data Word (Receive)

MIL-STD-1553 Programmer's Guide 11

 Section 2– MIL-STD-1553 Specification Overview

THIS PAGE INTENTIONALLY LEFT BLANK

12 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

3 AIM 1553 BUS INTERFACE MODULE OVERVIEW

The PCI 1553 modules are all part of a family of bus interface modules providing full function
test, simulation, monitoring and databus analyzer functions for MIL-STD-1553A/B
applications. Each module provides the following functions on one or more dual redundant
MIL-STD-1553 A/B buses:

a. Bus Controller - provides real-time Bus Controller functions concurrently with

Multiple RT and Bus Monitor operation. Key features include:

 Autonomous operation including sequencing of minor/major frames

 Support for acyclic message insertion/deletion

 Programmable BC Retry without host interaction

 Full error injection down to word and bit level (AS4112 Compliant)

 Multi-buffering for Data Consistency and Message Multiplexing

 Synchronization of BC operation to external trigger inputs

 4 µsec intermessage gaps

b. Multiple Remote Terminal - Simulates up to 32 Remote Terminals including

all subaddresses. Key features include:

 Programmable RT response time down to 4µsec for each simulated RT

 Programmable and intelligent response to mode codes

 Full error injection down to word and bit level (AS4112 Compliant)

 Multi-buffering with real-time data buffer updates

 Programmable response time out

c. Chronological Bus Monitor - Provides accurate time tagging of all bus traffic
to 1 µsec resolution including response time and gap time measurements down
to 0.25 µsec resolution. Key features include:

 100% data capture on two streams at full bus rates

 Autonomous message synchronization and full error detection

 Two dynamic complex trigger sequences

 Message filter and selective capture

MIL-STD-1553 Programmer's Guide 13

 Section 3 – AIM 1553 Bus Interface Module Overview

 Bus activity recording independent from trigger and capture mode

d. Bus Replay - Key features include:

 Reconstruction of previously recorded MIL-STD-1553A/B databus

traffic

 Recorded data selectively replayed with any or all RT responses enabled

e. IRIG-B time code decoder - Key features include:

 Allows synchronization of MIL-STD-1553A/B bus traffic using one

common IRIG-B time source or the on-board Time Code Generator

Figure 3-1 MIL-STD-1553 Bus Sample Configuration

Figure 3-1 shows a sample configuration of an APX1553-2 device with 32 RTs, a BC, BM and
Replay functionality. This visual graphic was generated by the PBA.pro software package
which runs on a host and controls an AIM 1553 bus interface. See the PBA.pro Bus Analyzer
Getting Started Manual for further information about the next generation AIM analyzer
software.

14 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Note: The PBA.pro software packages also utilize the API S/W Library to setup and control
the AIM bus interface modules.

If you have just purchased your module, the associated Getting Started Manual provides first
time users with instructions on software installation, hardware setup and starting a sample
project.

The following sections provide an overview of the hardware and software architecture, and a
description of the API S/W Library including Board Support Package (BSP) contents and
information needed to create your application program.

3.1 HARDWARE ARCHITECTURE

The AIM 1553 bus analyzers are based upon AIM’s "Common Core" hardware architecture
with different bus interfaces. Among others the following busses and form factors are
supported: PCI, cPCI, PCIX, PXI, VME, PMC, PC-Card, USB.

Block diagrams for the API1553-2 is shown in Figures 3.1-1 as an example. Detailed
hardware design information can be found in the associated hardware manuals. The main
hardware components in AIM’s "Common Core" design are illustrated in Figure 3.1-1 and its
basic functionality are as follows:

a. Application Support Processor (ASP) Section - performs the following tasks:

 Run the on-board driver software

 Setup the Global RAM for BIU Processor operation

 Control the RS-232 Maintenance and Debug Interface, if available.

 Configuration of the programmable BIU with the bit stream data from
FLASH

 Provides program data for the BIU processors

 Interface to the host

 ASP Memory provides Local ASP RAM for ASP local programs and
Shared RAM for Host-to-Target Communication:

Some boards don’t have an ASP Section on board, such as the APM1553 or the
APU1553. In these cases the ASP Section is included to the driver.

b. Bus Interface Unit (BIU) – each handles one dual-redundant MIL-STD-1553

stream and performs the following tasks:

MIL-STD-1553 Programmer's Guide 15

 Section 3 – AIM 1553 Bus Interface Module Overview

 Receives the incoming serial data stream, detects the synchronization

(sync) pattern, converts 16-bit Manchester encoded serial data to parallel
and receives the parity bit

 Generated command and data words on the bus using a Manchester

Encoder with full error injection capability

 Three trigger inputs and outputs provided at each MILbus channel

c. Timecode Processor - performs the following tasks:

 IRIG-B compatible Time Code Decoder and Encoder function for time-
tagging and multi-channel synchronization

 IRIG external and internal outputs available

 RS-232 interface for debugging during hardware and firmware

integration

d. Global RAM - 32-bit wide shared memory:

 Shared between the BIUs, the local bus of the ASP section and the
PCI/CompactPCI interface

Arbiter handles the prioritization of the bus requester in a round robin process.

16 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.1-1 API1553-2 Hardware Diagram

MILbus connector General I/O connector

Physical Bus Interface Daughterboard

BIU1 BIU2
MIL-STD High Speed serial MIL-STD
1553B 1553B
Encoder and Encoder and
Global RAM
Decoder One SRAM-Module Decoder
Max. 16MB

P P
BIU1 32
O O BIU2
Processor R R Processor
Strong ARM T T 32 Strong ARM
32

BIU1 PORT BIU2

Local 32
Local
Program Program
Memory Memory
Tri-port
Arbitration
Logic
Serial Timecode Serial Timecode
32

ASP Address and Databus

ASP Section
Application PCI and ASP Timecode
Board
Support System Memory Processor
Configuration
Processor Controller S ti Setup
Memory Serial
150MHz Max. 64MB Flash-PROM Interface Memory
RS-232 E2PROM
4MByte 512 Bytes

Bus
Debug and IRIG-B
Maintenance I/O
Interface

MIL-STD-1553 Programmer's Guide 17

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2 SOFTWARE OVERVIEW

3.2.1 Software Architecture

The AIM "Common Core" design, as shown in the previous section, provides for the utilization
of a common application s/w library of function calls to support host application interfaces to
the PCI 1553 modules. Figure 3.2.1-1 shows the high-level software architecture of the AIM
1553 bus interface module and it's interface to a host computer application.

Figure 3.2.1-1 Host/Target Software Interface Diagram

User's
PBA.pro Application
Bus Analyzer
Software
(optional)

API Unique 'C' function call / DLL

Software
Operating System independent
Library

I/O Layer

Operating System Application

dependent communication

System
OS sytem driver

PCI/cPCI/PCI-X/cPCI-X/
Host
PCMCIA/VME Bus
Target
Serial Interface
Target Level
Debug interface Driver-host Selftest (BITE)
interface

Support software: ASP Driver Software

- monitor software
- LCA-Boot software
(running on ASP)
UART / HW init

BIU Firmware
(running on PBI)
Encoder / Decoder
Monitor / Trigger
MIL-STD-1553B specific H/W

18 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

As shown in Figure 3.2.1-1, the API S/W Library is utilized by the User's Application program
to control the target module. (As an option, the application developer can utilize the AIM
PBA.pro Bus Analyzer Software Bus Monitor function to monitor bus traffic setup by the
User's Application.) Both the PBA.pro and the User's Application program utilize the same
API S/W Library.

The API S/W Library encapsulates operating system specific handling of Host-to-Target
communication in order to support multiple platforms with one set of library functions.
Operating systems and compilers supported by the API S/W Library are defined in Table 3.2.1-
I.

Table 3.2.1-I Compatible Operating Systems / Recommended Compilers

Operating Systems Compilers

Windows XP / Windows VISTA (32 bit) Microsoft Visual Studio 2008
Windows 7 (32 bit / 64 bit)

Common Linux distributions with Kernel GNU GCC 4.x

2.6.x (32 bit / 64 bit)

The API S/W Library is capable of supporting up to 32 AIM bus interface cards.

The AIM API S/W Library is supplied as a shared link library containing the collection of
functions used to setup and command the AIM bus interface modules. A function in a shared
library is only connected to a program that uses it, when the application is run. This is done on
each occasion the program is executed as shown in Figure 3.2.1-2.

On Windows two binary files are utilized by the application program including:

a. api_mil.dll - contains the executable code for the DLL.

b. api_mil.lib – defines the items exported by an AIM API S/W Library DLL
in a form which enables the linker to deal with references to exported items
when linking a program that uses the AIM API S/W Library DLL function.

On Linux the shared object file and a link to it is provided:

a. libaim_mil.so – A symbolic link to the current shared library version.

b. libaim_mil.so.xx.yy – The shared object file where xx is the major and

yy is the minor version of the library.

For VxWorks source code is provided. Using it a Tornado archive file can be generated.

MIL-STD-1553 Programmer's Guide 19

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.1-2 Library and Program Interfaces

API Library
Program C 2. load shared library
Program B
Program A
1. Program A is loaded

Program A library

Function
3. Link to library function

On Windows Operating systems the linkage information of a function in the shared library
(DLL) is obtained through the api_mil.lib file. These lib files are however compiler
specific.

a. Borland C/C++ Compiler version -

This version can be created with the implib

command delivered with the Boarland
compiler.

b. Microsoft Visual C/C++ Compiler version -

c:\Program Files\AIM GmbH\PCI-

1553-Windows-BSP-Vxxxx\lib32\.

In order to utilize the API S/W Library, api_mil.lib, the

library must be linked to the application program. Section
3.2.5 provides further detail with steps to accomplish this
process.

On Linux operating systems only one file is required. The libaim_mil.so file. This file is
provided in the directory:

/usr/local/lib/

20 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.2 Necessary Files and Defines for New Application Programs

This section will review the API S/W Library header files that need to be included in your
application program, and the shared library files that must be linked to your application
program in order to utilize the API S/W Library function calls.

For all platforms, the following C-syntax header files, located in the include directory are
provided:

a. Api1553.h

b. Ai_cdef.h

c. Ai1553i_def.h

d. Ai1553i_fnc.h

e. Api1553Cvi.h

f. AiOs.h

g. AiOsWindows.h

h. AiOsLinux.h

i. AiOsVxWorks.h

j. AiVmeGeneric.h

As shown in Figure 2.3.2-1, only the Api1553.h header file needs to be included in your
application program. This header file provides for the inclusion of the other header files.

The include path needs to be added to the project when compiling your new program. See
section 2.4 for further details on this process. For further information on the content of the API
S/W Library header files see the MIL-STD-1553 Reference Manual.

The DLL is created in _stdcall calling convention. To avoid problems, all callback functions
defined must use this calling convention, too!

The files AiOs.h, AiOsWindows.h, AiOsLinux.h and AiOsVxWorks.h provide plattform

specific functions. In order to use these functions the file AiOs.h must be included.

MIL-STD-1553 Programmer's Guide 21

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.2-1 API S/W Library Header File Relationships

Ai_cdef.h

data type definition

multi-platform support

Ai1553i_def.h

constant definition
Api1553.h
structure definition
#include "Ai_cdef.h" error code constants
#include "Ai1553i_def.h"
#include "Ai1553i_fnc.h"
#include "Ai1553Cvi.h"

Ai1553i_fnc.h

function defintion

Api1553Cvi.h

Like Ai1553i_def.h,
but needed for
use with LabWindows

AiVmeGeneric.h

Contains VME specific

prototypes, structures
and constants
(only for VME
environments)

22 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.3 Windows Boards Software Package Content

The BSP is downloaded to your computer upon s/w installation

for your device. The default BSP location is:

x:\Program Files\AIM GmbH\PCI-1553-Windows-BSP-

Vxxxx\.

The BSP contains the following folders:

Add-ons – Additional projects delivered with this

BSP.

ANS – Utility file for setting up the ANS - the

AIM Network Server – for remote
access to AIM modules.

Doc – Manuals.

include – Header files used during compilation (include directory).

LabView – LabView VIs.

lib32 – DLL and Import Library required to develop an application 32 bit

application.

lib64 – DLL and Import Library required to develop an application 64 bit

application.

Onboard-SW – Update utilities that are used to update onboard firmware.

Sample – Sample project for Microsoft Visual Studio 2008 and source code

SysDrv32/PCI – Windows XP/ Windows VISTA/ Windows 7 32 Bit PCI driver

SysDrv32/USB – Windows XP/ Windows VISTA/ Windows 7 32 Bit USB driver

SysDrv64/PCI – Windows 7 64 Bit PCI driver

SysDrv64/USB – Windows 7 64 Bit USB driver

MIL-STD-1553 Programmer's Guide 23

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.4 Linux Board Software Package Content

The extracted directory contains the following folders:

doc – Reference manuals

library – Source and binary of API

modules/pci – Source of PCI driver

modules/usb – Source of USB driver

samples – The samples source code

update – Onboard firmware update scrpts

The installed directories are:

/usr/local/include/aim_mil – The header files

/usr/local/lib/libaim_mil.so – The library

/lib/modules/linux/extra/aim_mil.ko – The PCI kernel module

/lib/modules/linux/extra/aim1553usb.ko – The USB kernel module

24 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.5 VxWorks Board Software Package Content

The BSP is downloaded to your computer upon s/w

installation for your device. The default BSP location is:

x:\Program
Files\AIM_GmbH\VME1553_VxWorks_Vxxxx\.

The BSP contains the following folders:

Doc – manuals.

Onboard-SW – Update utilities that are used to

update onboard firmware.

For_BSP_V0400_and_older -
contains a diskette that has to be
used to update boards whose
onboard software is of BSP V04.00 or older

PMC-PLCA-Update – contains a project that may be used to

update the onboard PCI LCA of an AMC429 board, in case a
compatibility warning appears

Update _Project – contains a project that may be used to update the

onboard software of an AVI429 board.

Sample_Project – Sample project for Tornado 2.2.1 and source code

source – Source and header files used during compilation

3.2.6 API S/W Library Structure/Content

The API S/W Library function calls are divided into the following subgroups and listed in the
tables indicated:

a. Library Administration/Initialization Functions - provide general library

initialization, and shutdown, interrupt handler setup, and error message handling
setup.

b. System Functions - provide general device control, response timeout setup,

IRIG setup, board configuration status and control of the generation of dynamic
data words/datasets.

MIL-STD-1553 Programmer's Guide 25

 Section 3 – AIM 1553 Bus Interface Module Overview

c. Calibration Functions - provide configuration of the physical bus including

coupling mode, transmitter amplitude output and data rate (default 1 Mbps).

d. Buffer Functions - provide setup and status of the RT/BC global RAM
message buffer memory area and ASP shared RAM dataset buffer area used for
message transfers. These functions will be discussed within the context of
defining and executing BC and RT transfers in sections 4.2 and 4.3.

e. First-in-first-out (FIFO) Functions - provide setup and status for FIFO buffers
used for 1553 message transfers. These functions will be discussed within the
context of defining and executing BC and RT transfers in sections 4.2 and 4.3.

f. Bus Controller Functions - provide definition of 1553 transfers within the

minor frame(s) and setup of the minor frame(s) within the major frame(s)
including definition of minor frame timing. The BC functions also provide
definition BC transfer properties and real-time BC transfer control including
insertion of acyclic messages.

g. Remote Terminal Functions - provide configuration, status and error insertion

for RT transfers.

h. Bus Monitor Functions - provide configuration of the Bus Monitor for

Chronological recording of all or filtered data streams.

i. Replay Functions - provide configuration of the Replay process to replay pre-

recorded Bus Monitor data entries in entirety or filtered by specified RTs.

3.2.7 Application Program Structure Overview

The API function calls can be used to simulate a BC and/or RT on the bus as well as monitor
bus activity and replay recorded data. Figure 3.2.6-1 shows the structure of a basic application
program and the API function categories associated with each major part of the program.

26 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.6-1 Basic Application Program Structure

Initialization--->Board setup--->
BC Simulation Setup---> RT Simulation Setup---> Bus Monitor Setup --->
Start BM/RT/BC--->
Retrieve Status/Captured Data --->
Shutdown

Decide if you need to simulate a BC, and/or one or more RT(s). Determine if you want to program
the BM to capture/replay data.

For BC simulations, know the BC-to-RT, RT-to-BC, and RT-to-RT transfers that must be initiated.
Determine how the data words will be generated and whether errors are to be injected into the
transfer. Know how all simulated transfers are to be included in the minor/major frame structure.

For RT simulations, know which RT's and RT SA's need to be simulated, the response time and the
status to be returned, or whether the RT is to be configured for mailbox monitoring (no response on
the bus). For RT-to-RT and RT-to-BC transfers, determine how the data words will be generated
and whether errors are to be injected into the transfer. Know whether the RT is required to respond
to Mode Codes and which mode codes are required.

If you want the databus to be monitored, know the capture mode that best suits your requirements
and how you want the monitor to be started (triggered) i.e trigger on error, external trigger, first
word received... Determine if you want all or specific RT SAs/Modecodes to be monitored.

Determine if you need an interrupt handler to handle BC, RT and/or BM interrupt signals. BC, RT
and BM function calls can be setup to produce interrupts based on certain conditions.

Follow the basic structure below utilizing the function call groups indicated to create your
application program.

Initialization
(1) Initialize API Library Library Administration Functions
(2) Open Stream
(3) Optional interrupt handler
setup

Module Handle
2

Board Setup
(1) Initialize device System Functions
(2) Define MILBus protocol(A or B) and Response
timeout
(3) Define MILBus coupling mode
(4) IRIG time setup

continued on next page…

MIL-STD-1553 Programmer's Guide 27

 Section 3 – AIM 1553 Bus Interface Module Overview

BC Simulation Setup
(1) Initialize the BC – retry mechanism, Service Request Control, define whether all  BC Functions
transfers use the same/different bus Buffer Functions
(2) Define the properties of each BC-to-RT, RT-to-RT, RT-to-BC transfer to be simulated FIFO Functions
including data word count, reponse control, retry control, status word handling,
error/gap injection, Status word handling and interrupt generation.
(3) Assign Header ID (to contain transfer pointers to Status queue, Event Queue and
messag buffer queue) and Message Buffers IDs (for transmission of data words) for
each transfer.
(4) Insert data words into the message buffers using one of 5 methods including inserting
fixed data, dynamically updating data using function generators, using FIFOs pre-
filled by user's application, using Dataset Buffers, using an interupt handler routine to
refill the buffer on end-of-transfer.
(5) Determine framing mode (Standard or BC Instruction Table mode) and configure
minor/major frames or BC instruction tables accordingly

RT Simulation Setup  RT Functions

Buffer Functions
(1) Initialize the RT defining the RT's address, whether RT is simulated or
FIFO Functions
configured for Mailbox monitoring (used to monitor non-simulated
"external" RTs), response time, and the Status word the RT will
respond with.
(2) Assign Header ID (to contain transfer pointers to Status queue, Event
Queue and messag buffer queue) and Message Buffers IDs (for
reception/ transmission of data words) for each transfer. Enable
interrupt generation if required.
(3) Enable the RT's SA for transmit, receive or modecode transfers, and
specific Status word response value.
(4) For RT-to-RT or RT-to BC transfers, insert data words into the
message buffers using one of 5 methods including inserting fixed data,
dynamically updating data using function generators, using FIFOs
pre-filled by user's application, using Dataset Buffers, using an
interupt handler routine to refill the buffer on end-of-transfer.
(5) For RT-to-RT (receive) or BC-to RT transfers, clear the Receive buffer
area if desired

Bus Monitor Setup  BM Functions

(1) Initialize monitor Buffer Functions
(2) Configure capture mode for Standard Capture, Selective
capture, Recording mode or Message Filter Recording mode
(3) Define when you want the monitor to interrupt your
application: on half buffer full, capture start/stop or end of
select capture.
(4) Define the trigger(s) for start of capture/arm the trigger and
whether the trigger creates an interrupt.
(4) If required, define filter captured data based on transfer ID.

continued on next page…

28 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Start Bus Monitor BM Functions

(1) Start receiving and/or monitoring the
MILBus data

Start RTs/BC  RT Functions

(1) Start all RTs BC Functions
(2) Start the BC

System Functions Retrieve Status/Data

BC Functions (1) BC Status
RT Functions (2) RT Status
BM Functions (3) Retrieve Captured data
Replay Functions

Stop RT/BC/BM - Shutdown

Library Administration Functions (1) Stop BC/RT/BM
BC Functions (2) Uninstall any interrupt handlers
RT Functions (3) Close each resource
BM Functions (4) Exit API library

MIL-STD-1553 Programmer's Guide 29

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.8 MIL-STD-1553 Transfers and Frame Structure Overview

Programming the AIM 1553 bus interface module to simulate a BC and/or RT revolves around
the concept of defining transfers. Additionally, for the BC the transfers must then be
scheduled into minor and major frames. The following two sections will provide an overview
of these two concepts.

3.2.8.1 About MIL-STD-1553 Transfers

In order to simulate the BC, the user must define BC transfers. A BC transfer is assigned a
Transfer ID and Header ID (usually the same number) for the BC side of the BC-to-RT, RT-to-
BC or RT-to-RT transfers to simulate on the 1553 bus. The BC Header ID points to memory
locations containing Status and Event information for a specific BC transfer and the Message
buffer(s) which contain the BC transmit/receive Data words within the 1553 transfer. In order
to simulate the RT SA using 1553 protocol standards the user must assign a Header ID which
is associated with all the RT SA properties, status and transmit/receive message buffers for the
RT side of the BC-to-RT, RT-to-BC or RT-to-RT transfers. For BC and RT simulations, the
maximum number of Transfers/Header IDs that can be defined will vary based on the amount
of Global RAM available on your board as shown in Table 3.2.7.1-I. Our examples will utilize
the maximum value of 511 Transfer/Header IDs.

Table 3.2.7.1-I Transfer ID/Buffer Header ID Ranges

Streams 1MB 2MB 4MB 8MB 16MB

1 x 1553 1..511 1..2047 1..4095 1..8191 1..16383
2 x 1553 - 1..511 1..2047 1..4095 1..8191
4 x 1553 - - 1..511 1..2047 1..4095

A BC transfer defines the characteristics/properties (including error injection) for the BC side
of any one of the MIL-STD-1553 Command/Data/Status.

All BC and RT message transfers utilize a common message buffer pool located in Global
RAM. All BC and RT message transfers require the user to assign at least one Global RAM
message buffer. For instance, for an application with a simulated BC and simulated RT, for
one BC-to-RT transfer, at least one message buffer will be assigned to the BC transmit
message and at least one message buffer assigned for the RT receive message. If there are no
MIL-STD-1553 Data words within the 1553 transfer, a message buffer will still need to be
assigned.

Table 3.2.7.1-II Buffer ID Ranges

Streams 1MB 2MB 4MB 8MB 16MB

1 x 1553 1..2047 1..8191 1..16383 1..32767 1..65536
2 x 1553 - 1..2047 1..8191 1..16383 1..32767
4 x 1553 - - 1..2047 1..8191 1..16383

30 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.7.1-1 shows the basic interface between the Transfer Descriptors (which are created
for each transfer defined by the user) and associated Buffer Headers and Data buffers. These
diagrams depict the basic memory structure and relationship for BC/RT simulation/status
information contained in shared global memory. The user is not required to physically address
into global memory to obtain the status information. The API provides the functions that allow
the user to easily configure and retrieve status information for the BC, RT and BM.

As shown in Figure 3.2.7.1-2, the AIM bus interface module is designed with additional buffer
areas which can be utilized, in combination with the message buffers described above

a. FIFO Area - used for creating large sets of data to be transmitted within a 1553
transfer.

b. Dataset Area - used for cycling through multiple 32 word buffers to be

transmitted within a 1553 transfer. (An alternative to cycling through Message
Buffers from the Global RAM Buffer Pool.)

These message buffer concepts are the core design concepts for 1553 transfers that will be
detailed further within the BC and RT Programming sections to follow.

MIL-STD-1553 Programmer's Guide 31

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.7.1-1 API S/W Buffer Assignments for 1553Transfers

BC Buffer Header BC - Status RT Buffer Header RT - Status

control word control word control word control word

status queue pointer received status words status queue pointer received status words

event queue pointer actual data buffer event queue pointer actual data buffer

Message buffer queue pointer time tag data buffer queue pointer time tag

BC - Event RT - Event

control word control word

res res

res res

res res

511 / BIU 511 / BIU

Buffer Pool
for LS data
(32 x 16Bit words each
1
2
3
4
5
6
User 7
Data
n-
Queue of n-
4 buffers
n- n:
See Table 3.2.6.1-II for
n Buffer Id ranges. Note:
The queue size can
The buffers are shared
selected as 2^k, where
between BC, RT on
k can have a range
both
0 to 8.

API S/W Buffer Assignments for Simulated BC and RT

LS Transfer - (xfer_id = a)
BC Assignments RT assignments
BC Buffer Header ID = b RT Buffer Header ID= d
Buffer(s) ID = c Buffer(s) ID = c
The number of ids depends on the Global RAM size and the number of
streams:
a.) See table 3.2.6.1-I
b.) See table 3.2.6.1-I
(Usually defined with the same number as the Transfer ID)
c.) See table 3.2.6.1-II
(Buffers shared by both RT and BC)
d.) See table 3.2.6.1-I

32 MIL-STD-1553 Programmer's Guide

 Section 3 – AIM 1553 Bus Interface Module Overview

Figure 3.2.7.1-2 FIFOs and Dataset Buffers I/ F to Message Buffer Pool

FIFO Buffer Pool Data from a FIFO can be Buffer Pool

associated with 1553
(ASP Shared RAM) transfers for BC or RT (Global RAM)
message transmissions for 1553 data
One FIFO is a 1 (32 x 16Bit words each buffer)
Queue of 128
32 16-bit word 2 Example 1: Example 1: 1
buffers FIFO 2 is XFR 1 (BC-to-RT) uses 2 buffers.
2
assigned to BC cycles through 128 32 word
3 XFR 1 buffers of assigned FIFO for each 3
message transmitted by the BC
4
4 5
Total of 32 6
FIFOs 5
7
available
6
n-3
7 n-2
n-1
Example 2:
XFR 2 (RT-to-BC) uses 1 n
buffer. RT cycles through three
dynamic dataset buffers n:
assigned for each message See Table 3.2.6.1-II for Buffer Id
transmitted by the RT ranges.
32 Board n

1553-1 2047

1553-2 4095
User
Data Dataset
Data from Dataset buffers
can be associated with
Buffer Pool 1553 transfers for BC or RT
(ASP Shared RAM) message transmissions
1 Example 2:
Dataset 1-3
2 buffers are
assigned to
3 XFR 2
Queue of 4
4095 32 16- 5
bit words
6
7

4095

MIL-STD-1553 Programmer's Guide 33

 Section 3 – AIM 1553 Bus Interface Module Overview

3.2.8.2 Major/Minor Frame Scheduling Design Concepts

Once the developer has determined the configuration and RT/BC interface requirements of the
1553 application, the scheduling of message transfers on the bus is required. The API S/W
supports 128 transfers per minor frame and 64 minor frames per major frame as shown in
Figure 3.2.5.2-1. In this diagram, a transfer consists any of the 1553 transfers on the 1553 bus.
Each transfer depicted in this diagram is defined by the API S/W Library as one of the
following types (all initiated by the BC):

a. BC-to-RT

b. RT-to-BC

c. RT-to-RT.

Figure 3.2.7.2-1 Major/Minor Frame Scheduling Diagram

Transfer 1 128 Transfers Max

per Minor Frame

Minor Frame 1 T1 T2 T3 T4 T5 T6 ••• Tn

Minor Frame 2 T1 T2 T3 T4 T6 ••• Tn
Minor Frame 3 T1 T2 T4 T5 T6 ••• Tn
Minor Frame 4 T1 T2 T4 T6 ••• Tn
Minor Frame 5 T1 T3 T4 T5 T6 ••• Tn
Minor Frame 6 T1 T3 T4 T6 T7 ••• Tn
Minor Frame 7 T1 T4 T5 T6 T7 ••• Tn Major Frame
Minor Frame 8 T1 T4 T6 T7 ••• Tn
Minor Frame 9 T1 T2 T3 T4 T5 T6 T7 ••• Tn

• • •
• • •
• • •
Minor Frame n T1 T2 T3 T4 T5 T6 T7 ••• Tn

64 Minor Frames
Max per Major Frame

34 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4 PROGRAMMING USING THE API LIBRARY

Let's now begin to focus on the concepts of writing application programs to setup and control
the device from the host. This section will define in more detail the functions calls required to
program the AIM 1553 bus interface module for the following:

a. Library Administration and System Programming

b. Bus Controller Programming

c. Remote Terminal Programming

d. Bus Monitor Programming

e. Replay Programming

4.1 LIBRARY ADMINISTRATION AND SYSTEM PROGRAMMING

This section will discuss some of the typical scenarios a programmer would encounter that
would require the use of the library administration, system, and calibration calls as listed in
Table 3.2.3-I, 3.2.3-II, and 3.2.3-III respectively. These scenarios include:

a. Initializing your application and application interface to the AIM board

 for AIM boards located on your computer

 for AIM boards located on a remote server

b. Getting AIM Board Status and Configuration Information

c. Defining MILbus protocol

d. Defining External Connectivity

e. Configuring response timeout

f. Utilizing IRIG-B

g. Interrupt handling

h. Discrete I/O programming

i. Debugging

MIL-STD-1553 Programmer's Guide 35

 Section 4 – Programming Using the API Library

4.1.1 Initializing Your Application and Application Interface to the AIM Board

The API S/W Library is capable of controlling AIM boards which are located on your
computer or located remotely on a network server also containing AIM Network Server (ANS)
software. (For more information about using ANS software, please refer to the ANS Users
Manual.) Initialization and shutdown commands required for your application depend on this
configuration. This section will discuss both configurations and the function calls required to
support each configuration.
Note: connecting to remote boards is only possible on Windows computers.

The basic Library Administrative and System functions supporting initialization &
shutdown include:

a. ApiInit (for local AIM boards) - initializes API S/W Library and determine
AIM board count. You must first initialize the API S/W Library interface and
find out how many AIM boards/modules are on the computer.

Note: A maximum of 32 boards can be supported by the API S/W Library.

Use the following initialization function for AIM boards located on the local
computer:

// Basic Initialization for Local AIM board(s)

boardCount = ApiInit();

ApiInit returns the count of boards on the system, (boardCount). On VME

systems this function always returns ‘1’.

b. ApiOpenEx - establishes connectivity to a stream on an AIM board for host-to-

target communication and determines module handle (board name).

For each stream on the system, the application interface to the target module
must then be opened to establish connectivity between the application interface
and the AIM board. The ApiOpenEx function will call operating system
routines to open the AIM board and initialize a shared memory area for host-to-
target communication. The following ApiOpenEx function opens the first
stream on the first AIM board in the system:

36 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

if (boardCount != 0)
{
// Open Device
AiInt16 wRetVal;
AiUInt32 ApiModuleHandle;
TY_API_OPEN xApiOpen;

xApiOpen.ul_Module = API_MODULE_1;
xApiOpen.ul_Stream = API_STREAM_1;
sprintf( xApiOpen.ac_SrvName, “local” );

wRetVal = ApiOpenEx( &xApiOpen, &ApiModuleHandle );

if( wRetVal == API_OK )

{
// -- work with module ---
}
}

ApiOpenEx returns the ApiModuleHandle which will be used to reference this

AIM stream for the rest of the program. It also returns status (retval) for
success/failure of the execution of the function. The parameter "local"
indicates the AIM boards are "local" to the PC. If the AIM boards are located
on a remote PC, this variable will be the ServerName or Internet Protocol (IP)
address.

Upon successful execution of the ApiInit and the ApiOpenEx functions, the
AIM stream is ready to be commanded with all other API S/W Library function
calls. Please read chapter 4.1.1.1 and 4.1.1.2 for exceptions from this rule

c. ApiCmdIni - initializes an AIM board and returns board configuration

For each board on the system, the board itself must then be initialized. The
ApiCmdIni function will perform initialization of the AIM board and return the
configuration of the board to the application. Use the following ApiCmdIni
function to initialize your AIM board:

ApiCmdIni(ApiModuleHandle, API_INIT_MODE_ALL, &api_ini_info);

ApiCmdIni will return the configuration of the AIM board at the address
specified in the third parameter, in this case api_ini_info.
API_INIT_MODE_ALL is a constant defined in Ai1553i_def.h (set to 0).
Information returned by this function includes but is not limited to the
following:

 Board Configuration - (simulator & monitor, simulator only, single

function (monitor, BC or RT), or not present)

 Channels supported - (single 1553, dual 1553 or more)

d. ApiCmdReset - resets an AIM board BIU and ASP driver software to initial
state

MIL-STD-1553 Programmer's Guide 37

 Section 4 – Programming Using the API Library

For each board on the system, the BIU hardware and ASP Driver software
structures and variables must be initialized. The ApiCmdReset function will
perform this initialization and report memory configuration information. The
following ApiCmdReset function will initialize hardware and ASP Driver
software structures and variables:

ApiCmdReset (ApiModuleHandle, 0, API_RESET_ALL, &api_res_info);

ApiCmdReset will return the Bus Monitor and Simulator buffer memory
size/address information at the address specified in the third parameter, in this
case api_res_info. API_RESET_ALL is a constant defined in
Ai1553i_def.h (set to 0).

Parameters (of many) initialized by ApiCmdReset include but is not limited to:

 MILBus protocol which is set to a default value of Type B (1553B)

 Response Timeout is set to a default value of 14µs

Note: The Monitor Buffer size is set to 512 Kbytes, the Simulator Buffer Size is
set to 256 Kbytes!.

e. ApiClose - closes an AIM board interface

The ApiClose function should complete communication to the AIM board(s).

The ApiClose function performs cleanup of the specified AIM board.
Subsequent calls of driver-related functions after issuing an ApiClose function
call will result in an error code and should be avoided. To re-establish
connection to the AIM board, the ApiOpenEx function must be called.

// Close Device
retVal = ApiClose(ApiModuleHandle);

f. ApiExit - clean up Library for unloading it

The ApiExit function frees internally used memory and stopps any DLL
internal threads. This function is the counterpart to ApiInit and should be called
before the application is terminated.

// Clean-up library
ApiExit();

38 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.1.1.1 Only for Windows PC

ApiConnectToServer (for remote AIM boards) – can be used instead of ApiInit. If

called it returns the AIM board count on the specified ANS server.

On Windows systems, use the following initialization function for AIM boards
located on a remote PC:

// Basic Initialization for Remote AIM board(s)

retVal = ApiConnectToServer(ServerName, &boardCount);

ApiConnectToServer returns the count of boards (boardCount) on the

remote PC and status for success/failure of the execution of the function.

Note: Up to seven remote server application interfaces at a

time (plus one local instance) are supported.

ApiDisconnectFromServer (for remote AIM boards) - disconnects the network

connection used for the remote PC connectivity

If a connection to a remote PC has been established, the

ApiDisconnectFromServer function should be issued to disconnect the
network connection to the remote PC.

retVal = ApiDisconnectFromServer(ServerName);

4.1.1.2 Only for VME Systems

On VME systems some additional steps have to be taken before being able to use the board.
a. ApiInit (for local AIM boards) - initializes API S/W Library. You must first
initialize the API S/W Library interface. On VME systems this function always
returns ‘1’
b. AiVmeExamineSlot (for VME bus) – reads the PCI header of all devices found
on the VME slot that corresponds to a given A16 address. It is assumed that
every board inserted to a VME slot has a unique A16 address that can be set
using the DIP switch (Please read the appropriate Hardware Manual for details).
The PCI headers are needed for further functions to complete the set up.
AiPciScan (for local PCI bus) – reads the PCI header of all devices found on
the local PCI bus. The PCI headers are stored internally and can be accessed by
using the command AiPciGetHeader.
c. AiVme1553MapModule – maps a board with a given PCI header to the PCI or
VME bus.

MIL-STD-1553 Programmer's Guide 39

 Section 4 – Programming Using the API Library

d. AiVmeInitGenericInterrupt – initializes the VME bus interrupts, so that interrupt

handling on the VME CPU can be used. This step is required, if the function
ApiInstIntHandler is used at a later point.
e. ApiOpenEx – from this point on the initialization is the same as for other systems.
Now ApiCmdIni and ApiCmdReset shall be called.

Example for boards on the local PCI bus of a VME system

boardCount = AiPciScan();
memset(&xVmeInitIn, 0, sizeof(xVmeInitIn));
xVmeInitIn.px_PCI_Info = AiPciGetHeader(0);
xVmeInitIn.ul_A32Addr = 0x86200000;
xVmeInitIn.ul_A32UserAccess = 0x46200000;
xConfig.ulDevice = AiVme1553MapModule(&xVmeInitIn);

Example for boards on the local PCI bus of a VME system

memset(&in, 0, sizeof(in));
in.ul_A16Addr = 0xFBFFC000;
in.ul_TempA32Addr = 0x08000000;
in.ul_TempA32UserAccess = 0x20000000;
AiVmeExamineSlot(&in, &x_PCI_Info1, &x_PCI_Info2);

memset(&xVmeInitIn, 0, sizeof(xVmeInitIn));
xVmeInitIn.px_PCI_Info = &x_PCI_Info1;
xVmeInitIn.ul_A32Addr = 0x08000000;
xVmeInitIn.ul_A32UserAccess = 0x20000000;
xConfig.ulDevice = AiVme1553MapModule(&xVmeInitIn);

Please note that the A32 address and the A32 user access address for the end system is
probably different from the values used for this example.

40 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.1.2 Getting AIM Board Status and Configuration Information

Once you have initialized and opened the connection to the AIM stream as described in the
previous section, you can obtain the status of the configuration of the board and the software
versions contained on your AIM board. The system functions that perform this status are as
follows:

a. ApiCmdBite - Performs a self-test of the AIM board

b. ApiCmdReadSWVersion - Reads the software version of the AIM board target

software

c. ApiReadBSPVersionEx - Returns the version number of all AIM board

software package components

d. ApiGetTcomStatus - Gets target communication status of command execution

e. ApiGetServerInfo - Retrieves information about AIM boards installed on the

ANS (remote) PC, if available.

4.1.3 Defining MIL-STD-1553 Protocol

If your application requires MIL-STD-1553 Type A for any or all RTs, you should include the
System function, ApiCmdDefMilbusProtocol, in your program.

a. ApiCmdDefMilbusProtocol - defines the MILbus protocol type (A or B) for

individual or single RTs. (ApiCmdReset initializes this parameter to Type B)

// Set all RTs for MILbus 1553A protocol

ApiCmdDefMilbusProtocol( ApiModuleHandle,0,
API_PROTOCOL_1553_A,
API_MODE_ALL_RT );

4.1.4 Defining External Connectivity

Initialization and configuration of the MILBus for your application may require the execution
of the following System and Calibration functions:

a. Define the coupling mode for the BIU using:

ApiCmdCalCplCon sets up the physical MILbus coupling mode for the PBI

The MILbus coupling network of the Programmable-PBI consists of

sophisticated relay circuitry which offers various coupling capabilities. The

MIL-STD-1553 Programmer's Guide 41

 Section 4 – Programming Using the API Library

coupling modes which can be programmed by your software application for

each MILbus (primary and secondary) include:

 Isolated (Internal termination) (API_CAL_CPL_ISOLATED)

 Transformer coupled (API_CAL_CPL_TRANSFORM)

 Direct coupled. (API_CAL_CPL_DIRECT)

 Transformer coupled with resistive network emulation. (on-board

MILbus network simulation) (API_CAL_CPL_EXTERNAL)

 Onboard, digital wrap-around loop between MILbus Encoder and

Decoder (API_CAL_CPL_WRAP_AROUND_LOOP)

Note: Have a look to the 1553 Reference Manual for some coupling restrictions
on various board types.

In the network emulation mode, the MILbus emulation circuitry emulates a

transformer-coupled network without the use of MILbus couplers (using a
resistor network). Thus, an external dual-redundant MIL-STD-1553 Terminal
can be directly connected to the module.

The following functions are examples of the ApiCmdCalCplCon function.

The coupling parameter you use will be dependent upon your MILbus
configuration.

// Setup for Isolated Bus Coupling

ApiCmdCalCplCon( ApiModuleHandle, 0,
API_CAL_BUS_PRIMARY,
API_CAL_CPL_ISOLATED );

ApiCmdCalCplCon( AiModuleHandle,0,
API_CAL_BUS_SECONDARY,
API_CAL_CPL_ISOLATED );

b. Define the output amplitude of the MILbus transceiver for the BIU.

ApiCmdCalXmtCon - defines the amplitude of the MILbus transceiver

The MIL-STD-1553 trapezoidal dual transceivers offer the capability to control

the output amplitude on the MILbus via the voltage control pins. If necessary
for your application, the output amplitude of the MILbus transceiver can be
adjusted using the ApiCmdCalXmtCon function. Figure 4.1.4-1 shows the
relationship between amplitude percentage and the Voltage control (Vcontrol).

The Vcontrol input follows the following formula

42 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Vcontrol = 2.56 x 5V x ( Input Value / 256)

The Input Value in this formula is the digital eight bit value (0..255) you
provide as input to the ApiCmdCalXmtCon function. The 100% value
depends on the transceiver type, the coupling mode and the bus termination. A
typical value is 22Volts for a transformer coupled stub terminated with 70 Ohm.

MILbus Output vs Vcontrol

100
90
80
MILbus Vout [%]

70
60
50
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9 10 11 12
Vcontrol [V]

Figure 4.1.4-1 MILbus Output Amplitude vs. Voltage Control

Note: These functions are not applicable on AMC1553-1/2 modules.

The ApiCmdCalXmtCon function below adjusts the output amplitude:

// Modify Output Amplitude (check with Scope) to 25%

ApiCmdCalXmtCon(ApiModuleHandle,0,API_CAL_BUS_PRIMARY,0x40);

// Modify Output Amplitude (check with Scope) to 63%

ApiCmdCalXmtCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,0xA0);

// Set Default
ApiCmdCalXmtCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,0x80);

Note: The output amplitude value is dependent on the coupling mode setting.

c. Enable/Disable a 1Mhz square wave calibration test signal on the BIU

ApiCmdCalSigCon - enables/disables a 1 Mhz square wave calibration test

signal

The AIM board is capable of generating a 1MHz test signal applied at the
Encoder outputs of the primary or secondary MILbus. This test signal can be
enabled/disabled using the ApiCmdCalSigCon Calibration function. The

MIL-STD-1553 Programmer's Guide 43

 Section 4 – Programming Using the API Library

amplitude of this signal can be controlled using the ApiCmdCalXmtCon as

described above. Following is sample code to enable the 1 Mhz test signal,
modify the amplitude output, reset the amplitude output to default, then disable
the 1 Mhz test signal.

// Enable Test Signal

ApiCmdCalSigCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,API_ENA);

// Modify Output Amplitude (check with Scope) to 63%

ApiCmdCalXmtCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,0xA0);

// Set Default
ApiCmdCalXmtCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,0x80);

// Disable Test Signal

ApiCmdCalSigCon(ApiModuleHandle,0, API_CAL_BUS_PRIMARY,API_DIS);

Note: The frequency of this test signal is not dependent on the coupling mode
setting.

d. ApiCmdDefMilbusProtocol - defines the MILbus protocol type (A or B) for

individual or single RTs. (ApiCmdReset initializes this parameter to 1553B)

If your application requires MIL-STD-1553A protocol for any or all RTs, you
should include the System function, ApiCmdDefMilbusProtocol, in your
program.

// Set all RTs for MILbus 1553A protocol

ApiCmdDefMilbusProtocol( ApiModuleHandle,0,
API_PROTOCOL_1553_A,
API_MODE_ALL_RT );

4.1.5 Configuring Response Timeout

Configuration of timeout values for your application may require the execution of the
following functions:

a. ApiCmdDefRespTime - defines the timeout value (default is 14 µs)

The Response Timeout value is used in all modes of operation to define the
minimum time the Bus Controller waits for a Status Word response. The
response timeout value is used by the Bus Controller and Bus Monitor as "No
Response" timeout and from the RT's to calculate the RT-to-RT Status Word
timeout. The default timeout value, as initially configured using the
ApiCmdReset function is set to 14µs for compliance with the specification
MIL-STD-1553B.

44 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

The Response Timeout value, however, can be modified by the

ApiCmdDefRespTout function within a range of 0 to 63.75 in .25 µs steps. In
the following example, the Response timeout is set to 17µs.

ApiCmdDefRespTout( ApiModuleHandle, 0, 17.00 )

Attention: Due to the Response-/Gap time measurement specification of

MIL-STD-1553, the Response time is measured from the mid-bit zero crossing
of the last bit of the previous word to the mid- zero crossing of the Command
Sync of the current word. Thus, timeout value of (e.g.) 14µs allows a Bus dead
time of 12µs at 1Mbit Transmission Mode and a Bus dead time of 10µs at
500Kbit Transmission Mode.

Note: For broadcast transfers, the response timeout is used to check that no
status word has responded. Therefore, if the response timeout is greater
than the Intermessage Gap Time in Standard Gap Mode, the
Intermessage Gap will be extended.

4.1.6 Utilizing IRIG-B

The API S/W Library provides two System function calls for IRIG-B processing, these
include:

a. ApiCmdSetIrigTime - Sets the IRIG-B time on the on-board IRIG timecode

encoder

b. ApiCmdGetIrigTime - Reads the IRIG-B time on the on-board IRIG timecode

encoder

The following is an example of the ApiCmdSetIrigTime/ ApiCmdGetIrigTime. Notice the

declaration of the api_irig_time as type TY_API_IRIG_TIME.
TY_API_IRIG_TIME is defined in the Ai1553i_def.h header file.

Note: To obtain an accurate time stamp value you should delay the immediate reading of the
IRIG time.

TY_API_IRIG_TIME api_irig_time;

// Set onboard IRIG time to Day 288 11:32:25 (Hours:Minutes:Seconds),

api_irig_time.day_hi = 1; //(0 or 1) Increases day by 256 if equal to 1
api_irig_time.day_lo = 32; //
api_irig_time.hour = 11;
api_irig_time.min = 32;
api_irig_time.sec = 25;
api_irig_time.sec = 25;
api_irig_time.mode = API_IRIG_SET;

MIL-STD-1553 Programmer's Guide 45

 Section 4 – Programming Using the API Library

ApiCmdSetIrigTime(ApiModuleHandle, &api_irig_time);

// ... wait 2 seconds here ..

sleep(2000);

ApiCmdGetIrigTime(ApiModuleHandle, &api_irig_time);

printf(" IrigTime is Day:%d, Time %02d:%02d:%02d, ms:%04d\r\n",

((AiUInt16)api_irig_time.day_hi<<8) + api_irig_time.day_lo,
api_irig_time.hour, api_irig_time.min, api_irig_time.sec,
((AiUInt16)api_irig_time.ms_hi<<8)+ api_irig_time.ms_lo);

The above sample code produced the console output:

IrigTime is Day:288, Time 11:32:26, ms:0907

Note: IRIG time starts with "DAY one" (First of January) not with "DAY zero".

4.1.7 Interrupt Handling

If setup by the user, interrupts can be generated by the BC, RT, BM and/or Replay functions
for events listed in Table 4.1.7-I. Interrupt Log list Event Entries (see ApiInstIntHandler in
API reference manual for Log list Event Entry format) are updated by the BIU when an
interrupt occurs.

The user-developed interrupt handler should include code to check the Interrupt Log list Event
Entry for expected interrupts and process as required based on the user's application
requirements. The Log list Event Entries that are updated by the BIU for the available
interrupts are shown in Table 4.1.7-I.

Note: The interrupts are asserted at the end of a transfer. Thus, more than one interrupt
event for a BC/RT transfer can become valid. In this case, only one interrupt entry
with multiple interrupt reason bits set is written to the interrupt log-list and one
physical interrupt on the ASP will be asserted.

Figure 4.1.7-1 shows the basic steps involved in setting up and creating an application utilizing
interrupts.

The software setup required for the BC, RT, BM and/or Replay functions is discussed in the
associated section of this document as listed in Table 4.1.7-I.

The functions available to setup interrupts and interrupt handler execution include the
following Library Administration functions:

a. AiVmeInitGenericInterrupt - (only for VME environments)

Allows to provide environment specific interrupt setup and to set interrupt level
and vector of the VME bus interrupt.

46 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

b. ApiInstIntHandler - Provides a pointer to the interrupt handler function. The

following code installs an Interrupt Handler function named
userInterruptFunction to handle interrupts generated by the BC
(API_INT_BC) and the RT (API_INT_RT). On 1553 modules the second
argument is always API_INT_LS.

//Install Interrupt Handler function to handle BC and RT interrupts

ApiInstIntHandler( ApiModuleHandle,
API_INT_LS,
API_INT_BC,
userInterruptFunction );

ApiInstIntHandler( ApiModuleHandle,
API_INT_LS,
API_INT_RT,
userInterruptFunction );

 The Interrupt Handler function is a function that you create to perform

application specific processing based on the type of interrupt to be
monitored.

 Only one interrupt handler is required, however, you can also create one
interrupt handler for each type of interrupt.

 On Windows interrupt callbacks must be defined as __stdcall.

MIL-STD-1553 Programmer's Guide 47

 Section 4 – Programming Using the API Library

 Interrupt Handler function input parameters must follow a pre-defined

format as defined in the ApiInstIntHandler function call in the
associated S/W Library Reference Manual

void __stdcall userInterruptFunction( AiUInt32 ul_Module,

AiUInt8 uc_LsHs,
AiUInt8 uc_Type,
TY_API_INTR_LOGLIST_ENTRY x_Info );

c. ApiDelIntHandler - Removes the pointer interface to the interrupt handler

function. This function should be called prior to the module close (ApiClose).
The following code uninstalls an Interrupt Handler function used to handle
interrupts generated by the BC (API_INT_BC) and the RT
(API_INT_RT).

//Uninstall the BC and RT interrupt handler function(s)

ApiDelIntHandler( ApiModuleHandle, API_INT_LS, API_INT_BC );
ApiDelIntHandler( ApiModuleHandle, API_INT_LS, API_INT_RT );

In addition, the sample program, ls_interrupt_sample.c is included and provides an excellent

example of Interrupt Handling programming for MIL-STD-1553 transfers.

48 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Table 4.1.7-I Available Interrupt Types and Related Function Call

Interrupt Indications in Loglist Entry

Section
Interrupt Generation Setup ul_Lla ul_Llb ul_Llc ul_Lld
Reference
Bus Controller
ApiCmdBCXferDef
- End of Transfer INT_TYPE, PGI, BC Xfr Descriptor TRANS_ID Int Source and
RBI Pointer Data Buf Index
- Transfer Error INT_TYPE, AEI, BC Xfr Descriptor TRANS_ID Int Source and
RBI Pointer Data Buf Index
- Status Word exception INT_TYPE, UXI, BC Xfr Descriptor TRANS_ID Int Source and
RBI Pointer Data Buf Index
ApiCmdBCFrameDef,
ApiCmdBCAcycPrep
ApiCmdBCInstrTblGen

- Any transfer or instruction within a minor INT_TYPE, PGI, BC Xfr Descriptor TRANS_ID Int Source and
frame RBI Pointer Data Buf Index

ApiCmdBCStart
- On BC Halt when setup for non-cyclic INT_TYPE, BCH BC Xfr Descriptor TRANS_ID Int Source and
transmission RBI Pointer Data Buf Index
Remote Terminals
ApiCmdRTSACon
- End of Transfer INT_TYPE, PGI, RTSA/ModeCode RT_ADDR, Int Source and
RBI Descriptor Ptr T/R, RT_SUB, Data Buf Index
MODE_CODE
- Transfer Error INT_TYPE, AEI, RTSA/ModeCode RT_ADDR, Int Source and
RBI Descriptor Ptr T/R, RT_SUB, Data Buf Index
MODE_CODE
Bus Monitor
ApiCmdBMIntrMode
- Monitor Buffer Full or Half Buffer Full INT_TYPE, MBF Monitor Buffer N/A N/A
(Recording) Pointer

- Capture Start INT_TYPE, MSI Monitor Buffer N/A N/A

Pointer
- Capture Stop or End of Selective INT_TYPE, MST Monitor Buffer N/A N/A
Capture Event Pointer

ApiCmdBMTCBIni N/A N/A

- Trigger Control block condition is true INT_TYPE, MTI, Monitor Buffer N/A N/A
TCBI Pointer
- Trigger on external event INT_TYPE, METI Monitor Buffer N/A N/A
Pointer
Replay
ApiCmdReplayIni
- Half Buffer Transmitted Replay Buffer N/A N/A
Pointer

MIL-STD-1553 Programmer's Guide 49

 Section 4 – Programming Using the API Library

INT_TYPE
Description
RT Interrupt Type
BC Interrupt Type
BM Interrupt Type
Replay Interrupt Type
BC Branch Interrupt Type
UPF Update Flag
If set to 1, Interrupt Loglist Entry was updated
AEI Any Error Interrupt
If set to 1, an interrupt was asserted if any error was detected during transfer.
IXI Index Interrupt
If set to 1, an interrupt was asserted due to the current buffer index.
PGI Programmed Transfer (BC) or SA (RT) Interrupt
For BC: If set to 1, an interrupt was asserted due to programmed BC Iinterrupt.
For RT: If set to 1, an interrupt was asserted due to programmed RTSA Iinterrupt
BCH Bus Controller Halt
If set to 1, an interrupt was asserted due to BC Halt (1553 protocol only)
UXI Unexpected (Status Word) Response Interrupt
If set to 1, an unexpected Status Word response interrupt was asserted (1553 protocol only)
METI Monitor External Trigger Event during bus idle time
If set to 1, an interrupt was asserted if no bus traffic takes place and an external trigger event was detected.
This trigger type provides neither a trigger control block index (TCBI) nor a monitor buffer pointer (MBP) to the
interrupt loglist entry (1553 protocol only)
MTI Monitor Trigger Interrupt
If set to 1, an interrupt was asserted if a trigger event becomes valid during the trigger control block processing
(1553 protocol only)
MBF Monitor Buffer Full Interrupt (or Half Buffer Full Interrupt in Recording Mode)
If set to 1, an interrupt was asserted due to the Monitor Buffer Full event is standard or selective data capture
mode and due to the Half Buffer Full event in recording mode
MSI Monitor Start Interrupt
If set to 1, an interrupt was asserted due to a Monitor start trigger event
MST Monitor Stop Interrupt
If set to 1, an interrupt was asserted due to a Monitor stop trigger event (1553 protocol only)
RSO Replay Stop Interrupt
If set to 1, an interrupt was asserted if the replay operation expired due to an expired count.
RPI Replay Half Buffer Interrupt
If set to 1, an interrupt was asserted if one half buffer was replayed and indicates a buffer reload request.
RBI Relative Buffer Index
Value Description
0..255 Indicates the buffer index of the currently used buffer that is
related to this interrupt
TCBI Trigger Control Block Index
Value Description
0..255 Indicates the index of the trigger control block that created the
interrupt. This field is only updated if the interrupt is asserted
by the trigger control block processing (METI or MTI).
this field is not used on MBF, MSI, or MST events.
Int Source Information about who has generated the interrupt. (E.g BIU7)

Note: On occurrence of the METI event, the TCBI field will not be initialized.

50 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Figure 4.1.7-1 Interrupt Setup Process

Decide which type of interrupt is required for

your application

Create an Interrupt Handler application to process interrupt/data when interrupt

occurs. Interrupt Loglist Event Entries (See ApiInstIntHandler in the API reference
manual) are updated by the BIU when an interrupt occurs. The interrupt handler should
include code to check the Interrupt Loglist Event Entry for expected interrupts and
process as required based on the user's application requirements.

Include function call ApiInstIntHandler

to intialize the stream with a pointer to your
Interrupt Handler.

Setup the BC/RT/Bus Montitor/Replay

function(s) interrupt(s) as required by your
application (See Table 4.1.7-I)

Delete the the host-to-AIM board

interrupt setup prior to the end of your
application using ApiDelIntHandler.

Further definition and examples of these interrupt scenarios can be found in the BC, RT, BM
or Replay applicable sections to follow. In addition, the sample program,
LS_Interrupt_Sample.c is included and provides an excellent example of Interrupt Handling
programming.

MIL-STD-1553 Programmer's Guide 51

 Section 4 – Programming Using the API Library

4.1.8 Debugging

The API S/W Library provides the developer with the capability to control the output of error
messages which are detected by the API S/W Library functions using the ApiSetDllDbgLevel
function. One, multiple, or all types of error messages can be enabled/disabled by using this
function. The types of error message outputs are shown in Table 4.1.8-I.

The default setting provides for the output of DBG_ERROR outputs to warn the application
user of "out of range" parameters within the Api function parameters used in the software
program and if any errors occur within the on-board software that are detected by the Api_Io
function internal to the API S/W Library. (See MIL-STD-1553 Reference Manual for
additional help with troubleshooting errors within your application.)

Table 4.1.8-I Error Message Output Control Levels

Constant Description
DBG_DISABLED Force no debug output
DBG_INT Force interrupt related debug output
DBG_INIT Force initialization related debug output
DBG_OPEN Force module open related debug output
DBG_CLOSE Force module close related debug output
DBG_IO Force module I/O related debug output
DBG_READREC Force recording related debug output
DBG_WRITEREP Force replay related debug output
DBG_MUTEX Force mutex related debug output
DBG_TRACE Log function calls in aim_mil.log
DBG_INFO Force informational debug output
DBG_ERROR Force general error related debug output
(e.g. range check errors)
DBG_ERRORMSG Force error message box, if I/O to the
board fails with error or range check fails
DBG_ALL Force all available debug output

52 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.1.9 GPIO Programming

The APX1553 and APM1553 modules include a Board to Board connector that provides eight
GPIO Discrete I/O signals. Each GPIO can be used as a simple input or output to generate a
strobe to another APX/APM1553 board or to sense a digital input signal from another
APX/APM1553 board. Please see the associated Hardware Manual for connector pinout
information for the eight GPIO signals.

The following function calls are required to generate outputs or receive inputs from these
GPIO pins:

a. ApiCmdInitDiscretes – used to define whether the GPIO signal is to be as an

input or output signal. This function call must be called before either of the
following two function calls.

b. ApiCmdWriteDiscretes – used to generate a discrete output to one or more of

the eight discrete GPIO pins which have previously been configured as output
with ApiCmdInitDiscretes.

c. ApiCmdReadDiscretes. – used to read whether the GPIO discrete register has

been set. The GPIO register bit set must have previously been configured as
input with ApiCmdInitDiscretes.

MIL-STD-1553 Programmer's Guide 53

 Section 4 – Programming Using the API Library

4.2 BUS CONTROLLER PROGRAMMING

The main function of the BC is to provide data flow control for all transfers on the bus. In
addition to initiating all data transfers, the BC must transmit, receive and coordinate the
transfer of information on the data bus. All information is communicated in
command/response mode. The BC sends a command to the RTs, which reply with a response.
Information Transfer Formats are shown in Section 2.

Normal BC dataflow control includes transmitting commands to RTs at predetermined time

intervals as defined in the minor/major frame definition. The commands may include data or
request for data (including status) from RTs. Command word, Data word and Status word
formats are shown in Section 2. The BC has control to modify the flow of bus data based on
changes in the operating environment. These changes could be a result of an air-to-ground
attack mode changing to air-to-air, or the failure mode of a hydraulic system. The BC is
responsible for detecting these changes and initiating action to counter them. Error detection
may require the BC to attempt communication to the RT on the redundant, backup bus.

If your application requires the simulation of a BC, this section will provide you with the
understanding of the BC programming functions required for use within your application.
Programming the BC may require the use of more than just the BC functions. Also needed
may be the Buffer and FIFO functions. This section will discuss some of the typical scenarios
a programmer would encounter that would require the use of the Buffer, FIFO and BC
functions as listed in Tables 3.2.3-IV, 3.2.3-V, and 3.2.3-VI respectively. These scenarios
include:

a. Initializing the BC

b. Defining 1553 transfers

 BC transfers using single buffers

 BC transfers using multiple buffers

 BC transfers using FIFOs

 BC transfers with dynamic data

c. BC transfers with error injection

d. Defining Minor/Major frames

 Standard Framing Mode

 BC Instruction Table Mode

e. Starting the BC

54 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

f. Acyclic 1553 transfers

g. BC Interrupt programming

h. Status word exception handling

i. Tracking BC-receive 1553 data via Track Multiplex Buffers

4.2.1 Initializing the BC

Initialization of the BC must be the first BC setup function call issued. This function call,
ApiCmdBCIni, will perform setup of the BC global transfer characteristics including:

a. Transfer Retry Protocol - Definition of the number of retries the BC will

perform if a transfer is erroneous, the retry mechanism and the bus switching
protocol include selection of one of the following:

 Retry disabled

 One retry on the alternate bus

 One retry on the same bus, one retry on the alternat bus

 Two retries on the same bus, then one retry on the alternate bus

b. Service Request Control - When enabled the BC will perform specific pre-
defined actions when the Service Request bit in the status word received by the
BC is set. The specific pre-defined action the BC will perform is defined for
each transfer using the ApiCmdBCXferDef function. When this Service
Request function is enabled (with the ApiCmdBCIni function), and the BC
receives a status word with the Service Request Bit set, the BC will
automatically generate and transmit to the RT a Transmit Vector Word mode
code (Mode code 16). A Vector Word will then be transmitted by the RT
containing information indicating the next action to be taken by the BC. The
actions taken by the BC following the receipt of the vector word are also
defined by the ApiCmdBCXferDef function

Note: If Status Word Exception handling is required for any RT, this function
must enable Service Request capability for the BC.

c. BC Transfer Bus Mode/Global Start Bus- Provides one of the following

options:

 Allows the user to select the bus (primary or secondary) used for a
transfer on a transfer-by-transfer basis (using ApiCmdBCXferDef)

 Allows the user to specify a default bus (primary or secondary) for all
MILBus transfers

MIL-STD-1553 Programmer's Guide 55

 Section 4 – Programming Using the API Library

The following code example uses API S/W Library constants to initialize the BC for Retry
disabled, Service Request disabled, Transfer Bus Mode setup so that individual transfers can
define the bus used for the transfer using ApiCmdBCXferDef. (The last parameter is ignored
since the bus used for transfers can be defined individually.)

ApiCmdBCIni( ApiModuleHandle,0,
API_DIS,API_DIS,API_TBM_TRANSFER,
API_XFER_BUS_PRIMARY));

Note: ApiCmdBCIni must be called first when programming the BC regardless of the framing
mode (Standard or Instruction Table Mode).

4.2.2 Defining 1553 Transfers

Transfers controlled/generated by the BC will follow the formats/protocol as shown in the

Information Transfer Formats in Section 2. The API S/W Library divides transfers into three
basic types: BC-to-RT, RT-to-BC and RT-to-RT. Variations of these types of transfers
include Mode commands and Broadcast commands.

The API S/W Library supports definition of a default value of 511 unique 1553 transfers. A
transfer ID must be assigned by the user for each transfer. The method used by the AIM 1553
bus interface module to accomplish the transfer of the Command, Status and/or Data words
within the transfers is to utilize a common buffer pool containing the message buffers located
in Global RAM as shown in Figure 3.2.8.1-1. All BC message transfers require the user to
assign at least one Global RAM message buffer. The message buffer will be used to
transmit/receive the Data words within the message transfer. If there are no Data words within
the transfer, a message buffer will still need to be assigned. (However, the API S/W Library
does not prevent the user from using the same buffers in more than one transfer, therefore, the
same message buffer can be assigned for transfers that do not require the
transmission/reception of Data word(s)). Each message buffer has a unique ID which must be
assigned by the user.

In addition to the assignment of the message buffer(s) for each transfer, a Buffer Header ID
must be assigned for the BC to enable the processor to identify the location of the buffers used
and status and event data generated for each transfer.

1553 transfers will require the use of the following BC function calls:

a. ApiCmdBCBHDef - this BC function will define a BC Buffer Header

structure. As shown in Figure 3.2.8.1-1, the BC Buffer Header structure
enables the processor to identify the location of the message buffers used and
status and event data generated for each 1553 transfer. The BC Buffer Header
information to be setup by this function includes the following:

 BC Buffer Header ID - the ID of the BC Buffer Header structure.

 1553 Transfer ID - the ID of the 1553 Transfer (later defined with

ApiCmdBCXferDef below)

56 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

 Message Buffer ID - the ID of the first buffer in the Global RAM

message buffer pool to be used for the transfer of the Data words. See
Table 3.2.6.1-II for the number of possible Buffer IDs. The buffers are
shared between BC and RT. A Message Buffer ID of 20 would indicate
that the 20th buffer in the Global RAM Buffer Pool will be used. See
Figure 3.2.8.1-1for a diagram of the structure of these message buffers.

 Buffer Queue Size - the number of Global RAM message buffers to be

used for the transfer of the Data words. One or more buffers can be used
for the transfer. You will always need to assign at least one message
buffer from the Global RAM Buffer Pool for your transfer. For
example, assigning API_QUEUE_SIZE_8 for a transfer indicates that
8 contiguous buffers. Using the example of Message Buffer ID of 20
above, and a queue size of 8, message buffers 20 - 27 would be used for
the transfer.

 Buffer Queue Mode - specifies the order in which multiple buffers as

specified in the Buffer Queue Size, will be filled. In most cases, users
will choose to store the Data words into the Message Buffers in a cyclic
fashion (API_BQM_CYCLIC)

 Data Buffer Store Mode - will allow the user to indicate the actions to
be taken in case of error in the transmission or reception of Data words
such as whether to keep transmitting the same message buffer at transfer
error, or continue with the next buffer in the queue for the next
transmission.

Note: Buffer Queue Size, Buffer Queue Mode, Data Buffer Store Mode, and
Buffer Size and the Current Buffer Index can be modified "on the fly"
(i.e. after the BC has been started) using the Buffer function call
ApiBHModify.

b. ApiCmdBCXferDef - this BC function will utilize the api_bc_xfer

structure to define the properties of a 1553 transfer. Information contained in
this structure will be used to create the Command word, Data word(s)/Mode
Code and define the process for handling the Status word. It will also include
error injection setup. This information will be sent to the BIU when this
function is called. The information contained in the structure includes the
information defined in Table 4.2.2-I. This table denotes the structure elements
that are used by the BC simulation to form the Command Word.

Figure 3.2.8.1-1BC Buffer Header and Buffer Pool Interface

BC Buffer BC - Status

control word control word

status queue pointer received status words

event queue pointer actual data buffer

Message buffer queue pointer time tag

MIL-STD-1553 Programmer's Guide 57

BC - Event
 Section 4 – Programming Using the API Library

Table 4.2.2-I 1553 BC Transfer Definition Structure (api_bc_xfer)

BC Transfer Definition CW
Structure
Element in
api_bc_xfer
xid Transfer ID
hid Buffer Header ID - defines the ID of the Buffer Header
that tracks the message buffer(s) used for this
transfer.
type Transfer Type - BC-to-RT, RT-to-BC, RT-to-RT 
chn MILbus - Primary or secondary bus to be used for this
transfer
xmt_rt Transmitting RT - RT address/number of the 
transmitting terminal (N/A for BC-to-RT transfer)
rcv_rt Receiving RT - RT address/number of the receiving RT 
(N/A for RT-to-BC transfer)
xmt_sa Transmitting RT subaddress - RT subaddress of the 
transmitting terminal or mode control indication (0 or
31)(N/A for BC-to-RT transfer)
rcv_sa Receiving RT subaddress - RT subaddress of the 
receiving terminal or mode control indication (0 or 31)
(N/A for RT-to-BC transfer)
wcnt Word Count/Mode Code field - contains either the word 
count or the Mode code
tic Interrupt control - setup for generation of a BC
interrupt upon end of transfer, transfer error or
status word exception
hlt Halt control - setup to halt the BC upon end of
transfer, transfer error, status word exception or any
interrupt
sxh Status word exception handling - defines the process to
execute upon occurrence of a Status word Service
Request
sxh Status word exception handling - defines process to
execute upon occurrence of a status word exception
swxm Status Word Exception Mask - defines the bits in the
status word received by the RT that will be checked by
the BC
rsp Expected Response - defines the response the BC expects
from the RT such as basic response as defined by
ApiCmdDefMilbusProtocol, no status word 1 expected, or
no status word 2 expected.
rte Retry enable flag - enables or disables retry of this
transfer upon transfer error. Also allows the user to
alternate tranmission of this transfer between the
Primary and the Secondary bus.
res Reserved
gap_mode Gap Mode - defines the gap between this transfer and
the next transfer
gap Gap Value - defines the transfer wait time for the gap
mode specified above.
err.type Error Injection Type - defines 1 of the 14 possible
error injection schemes
err.sync Error Sync Pattern - sync pattern to be used for
command sync or data sync error injection scheme
err.contig Gap Error or Zero Crossing Error Value - the # of half
bits to be used for the Gap Sync Error injection scheme
or the Zero Crossing Error value to be used for the
Zero Crossing Error injection scheme.
err.err_spec Reserved
err.err_spec Word Position - the location of the 1553 transfer word
for which the specified error will occur
err.err_spec Bit Position- the location of the bit in the 1553
transfer word (above) for which the specified error
will occur
err.err_spec Number of bits - the number of bits at the location of
the bit (above) in the 1553 transfer word (above) for
which the specified error will occur

58 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

The following excerpt of code is an example of setting up the BC for a BC-to-RT transfer to
RT1, SA1 with a data word count of 4. The IDs assigned to this transfer include:

Transfer - BC-to-RT (xfer_id = 2)

BC Assignments
BC Buffer Header ID = 2
Buffer ID = 2

This 1553 transfer is to be put on the secondary bus, has no associated interrupts, no requests
for halt control, no service request handling, no error injection and specifies a gap of 0 µs that
will cause the BC to generate an intermessage gap of approximately 11 µs.

// BC-RT Transfer XF2: C01_R_01_04 (RT01,RCV,SA01,WC4)

memset( &api_bc_xfer, 0, sizeof(api_bc_xfer) );

xfer_id = 2; buf_id = 2; bc_hid = 2;

api_bc_xfer.xid = xfer_id; /* Transfer ID */
api_bc_xfer.hid = bc_hid; /* BID Buffer Header ID*/
api_bc_xfer.type = API_BC_TYPE_BCRT; /* Transfer Type */
api_bc_xfer.chn = API_BC_XFER_BUS_SECONDARY; /* MILbus */
api_bc_xfer.xmt_rt = 0; /* XMT-RT */
api_bc_xfer.rcv_rt = 1; /* RCV-RT */
api_bc_xfer.xmt_sa = 0; /* XMT-SA */
api_bc_xfer.rcv_sa = 1; /* RCV-SA */
api_bc_xfer.wcnt = 4; /* Word Count field */
api_bc_xfer.tic = API_BC_TIC_NO_INT; /* Interrupt control */
api_bc_xfer.hlt = API_BC_HLT_NO_HALT; /* Halt control */
api_bc_xfer.rsp = API_BC_RSP_AUTOMATIC; /* Response control */
api_bc_xfer.sxh = API_BC_SRVW_DIS; /* Service Req Handling*/
api_bc_xfer.rte = API_DIS; /* Retry disabled */
api_bc_xfer.swxm = 0; /* Status Word Exception Mask */
api_bc_xfer.gap_mode = API_BC_GAP_MODE_DELAY; /* Gap Mode */
api_bc_xfer.gap = 0; /* use default gap */

ApiCmdBCXferDef(ApiModuleHandle,0, &api_bc_xfer, &addr);

ApiCmdBCBHDef( ApiModuleHandle,0,bc_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,
0,0,0,0,&api_bc_bh_desc);

All structs should be initialized to zero with a memset call. All zero parameters can then be
skipped during struct initialization.

MIL-STD-1553 Programmer's Guide 59

 Section 4 – Programming Using the API Library

Table 4.2.2-II provides examples of how to change the values in the Transfer definition to
setup different types of 1553 transfers.

Table 4.2.2-II Transfer Setup for Different Types of 1553 Transfers

1553 BC Transfer Definition Parameters

Transfer structure Broadcast Xfer RT-to-BC Xfer to Mode code Xfer RT-to-RT Xfer
with word count RT02, SA03 with to RT05 SA0 from RT04 SA2 to
of 2 word count of 5 where mode code RT03 SA1 with
= 17 word count = 32
(synchronize)
api_bc_xfer.xid (1 - 511)* (1 - 511)* (1 - 511)* (1 - 511)*
api_bc_xfer.hid (1 - 511)* (1 - 511)* (1 - 511)* (1 - 511)*
api_bc_xfer.type API_BC_TYPE_BCRT API_BC_TYPE_RTBC API_BC_TYPE_BCRT API_BC_TYPE_RTRT
api_bc_xfer.xmt_rt 0 2 0 4
api_bc_xfer.rcv_rt 31 0 5 3
api_bc_xfer.xmt_sa 0 3 0 2
api_bc_xfer.rcv_sa 1 0 0 1
api_bc_xfer.wcnt 2 5 17 0
* Board dependant, see table 3.2.6.1-I

4.2.3 BC Transmit and Receive Message Data Word Generation/Processing

Now that you are familiar with the method used to define the characteristics of the 1553
transfers generated by a simulated BC, we can now discuss the following:

 How to setup and place data into the message buffers assigned for Data word
transmissions by the BC for BC-to-RT and BC Broadcast type transfers.

 How to setup and obtain data from the message buffers used for Data word
reception by the BC for RT-to-BC type transfers.

4.2.3.1 For BC-to-RT and BC Broadcast Type Transfers (BC Transmit)

The API S/W Library provides several methods to insert real-time/dynamic/fixed user data into
the Global RAM 1553 Message Buffers used by the BC transmitting side of the 1553 transfer
and specified in the ApiCmdBCBHDef function described in the previous section. The
methods and functions used for each method are summarized in Table 4.2.3.1-I.

60 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Table 4.2.3.1-I BC Transmit Buffer Fill Method Summary

BC Transmit Functions Used

Message
Source
Fixed Data 1. ApiCmdBCBHDef
2. ApiCmdBCXferDef
3. ApiCmdBufDef to initialize buffer with fixed data words (or ApiCmdBufWrite
to initialize a buffer with a single 16-bit word)
With Dynamic 1. ApiCmdBCBHDef
Data Words 2. ApiCmdBCXferDef
3. ApiCmdBufDef to setup non-dynamic data
4. ApiCmdBCDytagDef to setup 1-4 dynamic data words
Using FIFOs 1. ApiCmdBCBHDef
2. ApiCmdBCXferDef
3. ApiCmdFifoIni to initialize the FIFO
4. ApiCmdBCAssignFifo to assign the FIFO to the transfer
5. ApiCmdFifoReadStatus to determine how much FIFO data to reload
6. ApiCmdFifoWrite to fill the FIFO with data
With Dynamic 1. ApiCmdBCBHDef
Dataset Buffers 2. ApiCmdBCXferDef
3. ApiCmdRamWriteDataset to fill the dataset buffers with data to be used in
the message buffers
4. ApiCmdSystagDef to assign the Dataset buffers to the transfer

Using an interrupt See Section 4.2.7

handler routine to
interrupt on end-
of-transfer
The Dynamic Data Word Generation method and the FIFO and Dynamic Dataset methods are
described further in the following sections.

MIL-STD-1553 Programmer's Guide 61

 Section 4 – Programming Using the API Library

4.2.3.1.1 Dynamic Data Word Generation

Using the API function calls describe in the previous section, you can setup function
generators to dynamically change data words within the transmit message buffer. The
Function generators available are summarized in Table 4.2.3.1.1-I.

Table 4.2.3.1.1-I Dynamic Data Word Generation Summary

Mode Description
Function Mode Provides for up to two dynamic data words per transfer using any
combination of the following functions as pictured in Figure 4.2.3.1.1-1

1. Positive Ramp
2. Negative Ramp
3. Positive Triangle
4. Negative Triangle
5. Transmit a Data word from a different Message Buffer

Tagging Mode Provides for up to four dynamic data words per transfer using Sawtooth
Tagging. The Sawtooth Tagging mode provides an incrementer by 1,
which is performed on the user-specified location with each execution of
the associated BC transfer. The location to be incremented can be setup
with an initial value to be incremented each transfer, or the existing value
can be incremented. The options are to increment any combination of
the following byte or words:

1. 16-Bit Sawtooth
2. 8-Bit Sawtooth LSB (lower byte of word)
3. 8-Bit Sawtooth MSB (upper byte of word)

62 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Figure 4.2.3.1.1-1 Data Generation Functions Diagram

Positive Ramp Function Negative Ramp Function

Upper Upper

Start Start

Lower Lower

Positive Triangle Function Negative Triangle Function

Upper Upper

Start Start

Lower Lower

4.2.3.1.2 Using FIFOs and Dataset Buffers for Data Generation

BC transfer data can be defined using FIFOs or Datasets using the API function calls described
in Section 4.2.3.1. The basic concept of each method is described below and shown in Figure
4.2.3.1.2-1:

a. Assign a FIFO (ASP Shared RAM) to the transfer. (Each FIFO consists of 128
32-word buffers. There are 32 FIFOs.) Pre-fill the FIFO with application data,
the data transmitted in the Global RAM message transmit buffer will be
obtained from the FIFO. Re-fill the FIFO as needed.

b. Assign Dataset buffers (ASP Shared RAM) to the transfer. (There are 4095 32-
word buffers in the Dataset Buffer pool.) Pre-fill the Dataset buffer(s) with
application data, the data transmitted in the Global RAM message transmit
buffer will be obtained from the Dataset buffers. Refill the Dataset buffers as
needed.

MIL-STD-1553 Programmer's Guide 63

 Section 4 – Programming Using the API Library

Figure 4.2.3.1.2-1 BC Transfer Data Generation via FIFO or Dataset Buffers

FIFO Buffer Pool Data from a FIFO can be Buffer Pool

associated with 1553
(ASP Shared RAM) transfers for BC or RT (Global RAM)
message transmissions for 1553 data
One FIFO is a 1 (32 x 16Bit words each buffer)
Queue of 128
32 16-bit word 2 Example 1: Example 1: 1
buffers FIFO 2 is XFR 1 (BC-to-RT) uses 2 buffers.
2
assigned to BC cycles through 128 32 word
3 XFR 1 buffers of assigned FIFO for each 3
message transmitted by the BC
4
4 5
Total of 32 6
FIFOs 5
7
available
6
n-3
7 n-2
n-1
Example 2:
XFR 2 (RT-to-BC) uses 1 n
buffer. RT cycles through three
dynamic dataset buffers n:
assigned for each message See Table 3.2.6.1-II for Buffer
transmitted by the RT Id ranges.
32 Board n

1553-1 2047

1553-2 4095
User
Data Dataset
Data from Dataset buffers
can be associated with
Buffer Pool 1553 transfers for BC or RT
(ASP Shared RAM) message transmissions
1 Example 2:
Dataset 1-3
2 buffers are
assigned to
3 XFR 2
Queue of 4
4095 32 16- 5
bit words
6
7

4095

64 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.2.3.2 For RT-to-BC Type Transfers (BC Receive)

Before the BC receives the Data words from the RT, as part of the setup process, you may
choose to clear your receive buffer to avoid any Data word transmission confusion. The
receive buffers can be cleared before use by using the ApiCmdBufDef function.

After the BC has received Data words from an RT, software will need to be added to process
the data. Processing data received by the BC can be accomplished in one of two ways: polling
at pre-defined intervals to examine the BC data, or setting up the transfer to interrupt at end-of-
transfer. To accomplish the interrupt on end-of-transfer method of processing the data, an
interrupt handler routine would need to be developed to handle the interrupt which will occur
after all Data words have been received. Upon end-of transfer interrupt, the interrupt handler
would be called at which time the buffer could be read and processed as required by the
application. Interrupt handling is discussed further in Section 4.2.8.

4.2.4 BC Transfers with Error Injection

BC transfers can be configured for error injection in any Command word or Data word
transmitted by the BC. The BC is capable of injecting one of the following errors for a defined
transfer:

a. Command Sync Error - changes the transmitted Command word sync pattern
to one specified by the user

b. Data Sync Error - changes the transmitted Data word sync pattern to one
specified by the user

c. Parity Error - creates a parity error for the Command word or specified Data
word

d. Manchester stuck at high error - creates a Manchester stuck at high error for a
specified Command word, or Data Word at a specified bit position

e. Manchester stuck at low error - creates a Manchester stuck at low error for a
specified Command word, or Data Word at a specified bit position

f. Gap error - inserts specified Gap after defined Command or Data word

g. Word Count High - transmits the number of Data words defined for the
original transfer plus one

h. Word Count Low - transmits the number of Data words defined for the
original transfer minus one

i. Bit Count High - transmits a specified number (1-3) additional bits for
specified Command word or Data word.

MIL-STD-1553 Programmer's Guide 65

 Section 4 – Programming Using the API Library

j. Bit Count Low - transmits a specified number (1-3) less bits for specified
Command word or Data word.

k. Zero Crossing Low Deviation Error - implements zero crossing low deviation
at a specified Command word or Data word position, bit position with four
predefined deviation values.

l. Zero Crossing High Deviation Error - implements zero crossing high

deviation at a specified Command word or Data word position, bit position with
four predefined deviation values.

To setup for BC Command/Data word error injection, the transfer definition parameters
pertaining to error injection should be set. The following error injection sample code will
setup the transfer to inject a Data Sync Error on the third data word. The transfer definition
parameters and the values required for error injection are shown in bold text.

Set BC to RT RT01 RCV SA01 WC15 (Inject Data Sync Error in 3rd data word)
xfer_id = 1; // Defines the transfer descriptor that will be assigned to this
transfer
bc_hid = 1; // Defines the buffer header that will be assigned to this transfer ID
buf_id = 1; // Defines the buffer ID that will be used by the Buffer Header ID.
type = API_ERR_TYPE_DATA_SYNC;
sync = 0x30; // set invalid data sync 110000
contig = 0; // not used
wpos = 3; // Inject Error on the 3 data word
bpos = 0; // not used
bc_bits = 0; // not used

memset( &api_bc_xfer, 0, sizeof(api_bc_xfer) );

api_bc_xfer.xid = xfer_id; /* Transfer ID */

api_bc_xfer.hid = bc_hid; /* BID Buffer Header ID */
api_bc_xfer.type = API_BC_TYPE_BCRT; /* Transfer Type */
api_bc_xfer.chn = API_BC_XFER_BUS_PRIMARY; /* MILbus */
api_bc_xfer.rcv_rt = 1; /* RCV-RT */
api_bc_xfer.rcv_sa = 1; /* RCV-SA */
api_bc_xfer.wcnt = 15; /* Word Count field */
api_bc_xfer.gap_mode = API_BC_GAP_MODE_DELAY; /* Gap Mode */
api_bc_xfer.err.type = API_ERR_TYPE_DATA_SYNC; /* error injection type */
api_bc_xfer.err.sync = sync;
api_bc_xfer.err.contig = contig;
api_bc_xfer.err.err_spec = 0;
api_bc_xfer.err.err_spec |= (wpos << 16); /* wpos */
api_bc_xfer.err.err_spec |= (bpos << 8); /* bpos */
api_bc_xfer.err.err_spec |= (bc_bits << 0); /* bc_bits */
ApiCmdBCXferDef(ApiModuleHandle,0, &api_bc_xfer, &addr);

4.2.5 Defining Minor/Major Frames Content & Timing

Once you have defined your 1553 transfers you will then need to program the device to insert
the transfers into the minor/major frames as defined by your unique application requirements.
In addition, you can program the BC with one of various options to time the transmission of

66 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

the minor frames within the major frames. There are two methods provided in the API S/W
Library to define the minor and major frames of the BC Bus traffic as follows:

a. Standard Framing Mode - use this method if your application requires no

more than 512 minor frames per major frame and no more than 128 transfers
per minor frame. This method is more simplistic in that fewer functions are
required.

b. BC Instruction Table Mode - use this method if your application requires

more than 512 minor frames per major frame, more than 128 transfers per minor
frame, or the Standard Framing mode does not provide the BC instructions
needed to support your framing requirements. In BC Instruction Table mode,
major/minor frame size is only limited by allocation of the BC instruction list
size in Global Memory. It is more complex, but it provides greater flexibility
allowing creation of all available firmware instructions to be defined within the
BC Instruction List and usage of several more minor frame transfer/instruction
options.

Each mode utilizes the same API S/W Library function, ApiCmdBCStart, to start execution
of the BC as defined in Section 4.2.6. The next two subsections will describe the instructions
required for each framing mode.

4.2.5.1 Standard Framing Mode

In Standard Framing mode, the MIL-STD-1553 device supports up to 128 transfers per minor
frame and 512 minor frames per major frame. With Standard Framing mode, you will first be
defining all the minor frames (ApiCmdBCFrameDef) then defining which of those minor
frames will be placed in the major frame (ApiCmdBCMFrameDefEx). Further definition of
these two API S/W Library function calls associated with the definition of the minor/major
frames for this mode include:

a. ApiCmdBCFrameDef - Defines the sequence of 1553 transfers within a minor

frame. The Minor frame characteristics defined by this function include:

 Minor Frame ID - an ID that you define for the minor frame (1 - 64 is

available)

 Number of Instructions (Transfers) in the Minor frame

 Type of instruction - Generally this parameter is the 1553 Transfer ID,

however, the API S/W Library provides for advanced programming of
the minor frames other than transfer identification. Instructions which
can be executed by the BC at the programmed location in the minor
frame are shown in Table 4.2.5.1-I:

Table 4.2.5.1-I Standard Framing Mode Instructions

Constant Description

MIL-STD-1553 Programmer's Guide 67

 Section 4 – Programming Using the API Library

API_BC_INSTR_TRANSFER Execute BC Transfer

API_BC_INSTR_SKIP BC Skip (skip a specified number of instructions)
API_BC_INSTR_WAIT BC Wait (wait a specified delay time).
API_BC_INSTR_STROBE BC external Strobe (output strobe pulse)

b. ApiCmdBCMFrameDefEx - Defines the sequence of minor frames within the

major frame using the Minor Frame IDs defined in the ApiCmdBCFrameDef
function above. Therefore, this function should be executed after the
ApiCmdBCFrameDef function above.

The following
example defines
Transfer Wait 1
minor/major frames
using the Standard
Minor Frame 1 T1 T2 W1 T3 T4 Framing mode.
Major Frame
Minor Frame 2 T1 This sample code
Minor Frame Time = 10 ms demonstrates the
setup of minor and
major frames and
the starting of the BC using 4 previously setup transfers with Transfer IDs of 1 through 4. The
first minor frame includes 5 instructions; (1) execute Transfer 1, (2) execute Transfer 2, (3)
execute a wait delay of 1 millisecond, (4) execute Transfer 3, (5) execute Transfer 4. The
second minor frame has only one instruction; (1) execute Transfer 1.

Define Minor Frames

/* Minor Frame 1 Transfer sequence */
api_bc_frame.id = 1; /* Minor frame Identifier*/
api_bc_frame.cnt = 5; /* Number of instruction in the minor frame /*

api_bc_frame.xid[0] = 1; /* Transfer 1 */
api_bc_frame.instr[0] = API_BC_INSTR_TRANSFER;

api_bc_frame.xid[1] = 2; /* Transfer 2 */
api_bc_frame.instr[1] = API_BC_INSTR_TRANSFER;

api_bc_frame.xid[2] = 4000; /* Insert 1 ms delay after Transfer 2 */

/* delays are in 250ns increments */
api_bc_frame.instr[2] = API_BC_INSTR_WAIT;

api_bc_frame.xid[3] = 3; /* Transfer 3 */
api_bc_frame.instr[3] = API_BC_INSTR_TRANSFER;

api_bc_frame.xid[4] = 4; /* Transfer 4 */
api_bc_frame.instr[4] = API_BC_INSTR_TRANSFER;
ApiCmdBCFrameDef(ApiModuleHandle,0,&api_bc_frame); /*Define Minor Frame 1*/

/* Minor Frame 2 Transfer sequence */

api_bc_frame.id = 2;/* Minor frame Identifier*/
api_bc_frame.cnt = 1; /* Number of instruction in the minor frame /*

api_bc_frame.xid[0] = 1; /* Transfer 1 */
api_bc_frame.instr[0] = API_BC_INSTR_TRANSFER;
ApiCmdBCFrameDef(ApiModuleHandle,0,&api_bc_frame); /*Define Minor Frame 2*/

68 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Define Major Frames

/* Minor Frame sequence in Major Frame */
api_bc_mframe_ex.cnt = 2; /* Number of Minor Frames
api_bc_mframe_ex.fid[0] = 1; /* Minor Frame 1 */
api_bc_mframe_ex.fid[1] = 2; /* Minor Frame 2 */
ApiCmdBCMFrameDefEx(ApiModuleHandle,0,&api_bc_mframe_ex);

4.2.5.2 BC Instruction Table Mode

In BC Instruction Table mode, the number of minor frame and major frames supported is
limited only by the amount of memory allocated for the BC Instruction Table list. In this
mode, the user defines both minor and major frames within one Instruction Table
(ApiCmdBCInstrTblGen). Each minor frame defined in the Table is associated with a user-
defined label. If you are using BC Instruction Table mode to setup your minor/major frames,
all programmed actions the BC is to take is to be entered into the BC Instruction Table
manually using the appropriate BC Instruction mode functions defined below.

There are two API S/W Library function calls associated with the definition of the minor/major
frames and minor frame timing for this mode including:

a. ApiCmdBCInstrTblIni - Initializes the BC Instruction Table mode. This

function internally calls ApiCmdSysMemLayout to obtain the size and start
address of the BC Instruction List from the Global memory layout.

b. ApiCmdBCInstrTblGen - Clears/Converts/Writes the BC Instruction Table

which contains the minor frame(s) and the major frame information/definition

Clears - Initializes the BC Instruction Table to all zeros. (Zeros are considered
No-Op instructions by the BC controller.)

Converts - Converts the user-defined BC Instruction Table entries into an array

of firmware instruction long-words (which are written into the BC Instruction
list area of Global Memory using the Write command). Prior to the execution
of this command the user must define the BC Instruction Table entries using
TY_API_BC_FW_INSTR structure for each BC Instruction Table entry. BC
Instruction Table entries include the following:

 Label - a unique user-defined 16-Bit value used as address

 Firmware Operational code (Opcode) - instructions to be executed

within the minor fame. These instructions consist of one or more of the
codes shown in Table 4.2.5.2-I:

 Instruction parameters - parameters required for the Firmware

Instruction

MIL-STD-1553 Programmer's Guide 69

 Section 4 – Programming Using the API Library

Writes - Writes the converted BC Instruction Table to the Instruction List

global memory area.

Table 4.2.5.2-I BC Instruction Table Mode Instructions

Constant Description
API_BC_FWI_XFER Execute BC Transfer (defined using ApiCmdBCXferDef)
API_BC_FWI_CALL Call Subtable - allows you to jump to a subtable/minor frame definition identified with a label.
Return from Subtable - used to return to the main BC Instruction Table entry following the
API_BC_FWI_RET
related API_BC_FWI_CALL opcode.
Jump to Subtable / Instruction - absolute jump to an Instruction Table entry identified by a
API_BC_FWI_JUMP
label.
API_BC_FWI_SKIP Relative Branch (Skip) - skip a user-specified number of instructions
Wait for BC Trigger input - ties the external pulse to start of minor frames, or starts
API_BC_FWI_WTRG
execution of the major frame based on the external pulse
API_BC_FWI_STRB Strobe BC Trigger output - instruction to output a strobe signal
Decrement and Jump on Zero - When using non-cyclic major frame (as specified in
API_BC_FWI_DJZ ApiCmdBCStart) you can jump to a label in the BC Instruction Table when the major frame
counter is decremented to zero.
Wait for next Minor Frame Time slot - instruction to wait until the next minor frame time slot
API_BC_FWI_WMFT
begins, then continue with the following entry in the BC Instruction Table
API_BC_FWI_HALT BC Operation Halt - Halt the BC
Delay - delay the execution of the next entry in the BC Instruction Table by a user-specified
API_BC_FWI_DELAY
time
Change Minor Frame Time - instruction to change the minor frame time "on-the-fly" to a
API_BC_FWI_CMFT
user-specified value.
Reset Major Frame - instruction to swap between several different major frames in one BC
API_BC_FWI_RESMF
setup.

Two other API S/W Library functions can be called in order to read the contents of the Global
memory BC Instruction List including: ApiCmdBCInstrTblGetAddrFromLabel which
obtains the address of the BC Instruction List for a user-specified label, and
ApiReadBlockMemData to read the Global Memory's BC Instruction List at the address
returned by ApiCmdBCInstrTblGetAddrFromLabel.

The following
Transfer Wait 1 example defines
minor/major frames
Minor Frame 1 T1 T2 W1 T3 T4 using the BC
Major Frame Instruction Table
Minor Frame 2 T1
mode. This sample
code demonstrates
the setup of minor
and major frames and the starting of the BC using 4 previously setup transfers with Transfer
IDs of 1 through 4. The first minor frame includes 5 instructions; (1) execute Transfer 1, (2)
execute Transfer 2, (3) execute a wait delay of 1 millisecond, (4) execute Transfer 3, (5)
execute Transfer 4. The second minor frame has only one instruction; (1) execute Transfer 1.
(Note: This is the same minor/major frame architecture setup as defined in the example for
Standard Framing mode in Section 4.2.5.1.)

Note: If you want to setup a cyclic major frame then the last instruction has to be
API_BC_FWI_JUMP (back to the start of the major frame).

70 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Define Minor/Major Frames

AiUInt32 i, line;
AiUInt8 rval;
TY_API_BC_FW_INSTR instr_tbl[7];
AiUInt32 ctbl[7];

/* Get BC resources by initializing to BC Instruction Table mode*/

ApiCmdBCInstrTblIni(ApiModuleHandle,0);

/* Clear BC Instruction Table structure */

ApiCmdBCInstrTblGen(ApiModuleHandle,0, 0 /*mode=CLEAR*/, 8 /*# of entries */,
0L/*dest_cnt*/, 0L/*dest_offset*/,instr_tbl, ctbl, &line, &rval);

/* Setup BC Instruction Table */

instr_tbl[0].label = 0x1111; // Label for first minor frame

instr_tbl[0].op = API_BC_FWI_XFER;
instr_tbl[0].par1 = 1; /* Transfer 1*/

instr_tbl[1].op = API_BC_FWI_XFER;
instr_tbl[1].par1 = 2; /* Transfer 2 */

instr_tbl[2].op = API_BC_FWI_DELAY;
/* delays are in 250ns increments */
instr_tbl[2].par1 = 4000; /* Insert 1 ms delay after Transfer 2 */

instr_tbl[3].op = API_BC_FWI_XFER;
instr_tbl[3].par1 = 3; /* Transfer 3 */

instr_tbl[4].op = API_BC_FWI_XFER;
instr_tbl[4].par1 = 3; /* Transfer 4 */

instr_tbl[5].op = API_BC_FWI_WMFT; /* Wait for Next Minor Frame Time */

instr_tbl[6].label = 0x2222; // Label for second minor frame

instr_tbl[6].op = API_BC_FWI_XFER;
instr_tbl[6].par1 = 1; /* Transfer 1 */

instr_tbl[7].op = API_BC_FWI_WMFT; /* Wait for Next Minor Frame Time */

Instr_Tbl[8].op = API_BC_FWI_JUMP; /* Setup this major frame to be cyclic */

Instr_Tbl[8].par1 = 0x1111; /* by jumping back to the first min frame */

/* Convert and Write BC Instruction Table to memory image in ctbl */

ApiCmdBCInstrTblGen(ApiModuleHandle,0, 3/*mode=CONVERT & WRITE*/, 9 /*# of
entries*/,8 /*dest_cnt*/, 0L/*dest_offset*/,instr_tbl, ctbl,
&line, &rval);

MIL-STD-1553 Programmer's Guide 71

 Section 4 – Programming Using the API Library

4.2.6 Starting the Bus Controller

The BC can be started after the minor/major frame definition has been performed as defined in
Section 4.2.5. The function, ApiCmdBCStart, starts the execution of pre-defined BC
transfers/instructions and defines minor frame timing as defined below:

a. Minor Frame Time - the time allotted by the BC for each minor frame
transmission. Figure 4.2.6-1 shows how the Minor Frame Time parameter is
used by the BC to control the timing of the minor frames. In essence, the timing
starts at the beginning of the minor frame, the minor frame transfers/instructions
are executed back-to-back then the BC waits for the Minor Frame Time
(specified by the user) to expire

b. Bus Controller Start Mode - Defines the method the BC will use to begin the
transmission of the major/minor frames including one of the modes as defined
in Table 4.2.6-I.

The Autoframing method, as shown in Figure 4.2.6-2, of inserting minor frames

into the major frame is used for all start modes, with the exception of
API_BC_START_EXTERNAL_PULSE.

Figures 4.2.6-3 and 4.2.6-4 show two scenarios using an external pulse to frame
the minor frames. The first scenario (Figure 4.2.6-3) shows how the rising edge
of the pulse controls the transmission of the minor frame. The second scenario
adds a wait instruction (using the ApiCmdBCFrameDef function) as the first
instruction the BC executes after the rising edge of the pulse is detected.

c. Number of times the major frames will execute. The user can specify "cyclic"
in order to continuously execute the major frame (in Standard Framing mode
only), or the user can specify a major frame count from 1 to 255 to indicate the
number of times the major frame will be transmitted.

Note: To create cyclic execution in BC Instruction Table mode, the programmer

must include the API_BC_FWI_JUMP instruction at the end of the BC
Instruction Table major frame using the ApiCmdBCInstrTblGen
function.

72 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Table 4.2.6-I BC Start Modes

Value Constant Description

1 API_BC_START_IMMEDIATELY Start BC operation / Transfer execution
immediately
2 API_BC_START_EXT_TRIGGER Start BC operation / Transfer execution by
external BC trigger input
3 API_BC_START_RT_MODECODE Start BC operation / Transfer execution by RT
Modecode Dynamic Bus Control
4 API_BC_START_EXTERNAL_PULSE Drive minor framing from external pulse (BC
trigger input)
5 API_BC_START_SETUP Prepare BC Instruction sequence
(= Minor and Major Frame sequence) in the
Board Global memory for a fast start with
API_BC_START_FAST.
6 API_BC_START_FAST Start BC operation / Transfer execution
immediately fast.
Note that API_BC_START_SETUP and
API_BC_START_FAST shall be used in
conjunction.
7 API_BC_START_INSTR_TABLE Start BC operation / Transfer execution with
predefined BC Instruction Table (refer to
ApiCmdBCInstrTblGen)
8 API_BC_START_CONTINUE_ON_BC_HALT Continue BC operation (only applicable with
predefined BC Instruction Table, BC operation
must be already started with
API_BC_START_INSTR_TABLE)

Note: Not available for type AMC1553-4

Note: Modes 1-6 are applicable only to Standard Framing Mode. Modes 7 - 8 are
applicable only to BC Instruction Table Mode.

MIL-STD-1553 Programmer's Guide 73

 Section 4 – Programming Using the API Library

Figure 4.2.6-1 Minor Frame Timing Control Diagram

BC Transfer Frame (Minor WAIT-MFT

BC Start / Re-Starts Wait for Minor
Frame Time

Transfer i Transfer j Transfer k Transfer n

Minor Frame

Transfer Sequence within the Major Frame:

i, j, k, ..., n, WAIT-MFT
MFT: Minor Frame Time

Figure 4.2.6-2 Minor Frames within the Major Frame using Autoframing

BC Transfer Cycle (Major

BC starts / re-starts automatically
(Autoframing

Minor Minor Minor Minor

Frame i Frame j Frame k Frame n

MF MF MF MF

Major Frame (Cycle)

Minor Frame Sequence within the Major Frame:

i, j, k, ..., n

MFT: Minor Frame Time

74 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

Figure 4.2.6-3 Minor Frames within the Major Frame using External Pulse

BC Transfer Cycle (Major

BC Trigger Input, minimum pulse width: >75ns

Minor Frame i Minor Frame j Minor Frame k Minor Frame n

1553
messages

Major Frame (Cycle)

Minor Frame Sequence within the Major Frame:

i, j, k, ..., n

Figure 4.2.6-4 Minor Frames within the Major Frame using External Pulse and a
Wait Instruction

BC Transfer Cycle (Major

BC Trigger Input, minimum pulse width: >75ns

Minor Frame i Minor Frame j Minor Frame k Minor Frame n

1553
messages

WAIT x-us WAIT x-us WAIT x-us WAIT x-us

Major Frame (Cycle)

Minor Frame Sequence within the Major Frame:

i , j, k, ..., n

MIL-STD-1553 Programmer's Guide 75

 Section 4 – Programming Using the API Library

Following are three examples of starting the BC; one for Standard Framing mode, and the
other two for BC Instruction Table mode. In each example, the minor frame time will be set to
last 10 milliseconds.

Define Minor Frame Timing and Start the Bus Controller (for Standard Framing Mode)
frame_cnt = 0; /* 0 = cyclic 1 –255 = number of major frame executions */
frame_time = 10; /* Minor Frame Time in milliseconds */

ApiCmdBCStart(ApiModuleHandle,0, API_BC_START_IMMEDIATELY, frame_cnt /*0 = cyclic*/,

frame_time /* frame time in ms */,0 /* start address n/a in this mode */,
&ul_MajFrameAddr, aul_MinFrameAddr);

When using BC Instruction Table mode, only the API_BC_START_INST_TABLE or

API_BC_START_CONTINUE_ON_BC start modes are applicable. In the example below,
the execution of the BC Instruction Table will start at the beginning of the table.

Define Minor Frame Timing and Start the Bus Controller (for BC Instruction Table
Mode)
frame_time = 10; /* Minor Frame Time in milliseconds */
frame_cnt = 0; /* (0 = cyclic is N/A value for BC Instruction Tbl mode. However,
*/
/* you can specify the major frame count for non-cyclic major */
/* frames: 1 –255 = number of major frame executions */

ApiCmdBCStart(ApiModuleHandle,0, API_BC_START_INSTR_TABLE, frame_cnt /*0 = cyclic*/,

frame_time /* frame time in ms */, 0 /* BC Instr Tbl start address */
&ul_MajFrameAddr, aul_MinFrameAddr);
Note: To create cyclic execution in BC Instruction Table mode, the programmer must include
the API_BC_FWI_JUMP instruction at the end of the BC Instruction Table major
frame using the ApiCmdBCInstrTblGen function. When in this mode, the user can
specify a major frame count for non-cyclic BC Instruction Table lists.

To start execution from a different instruction in the BC Instruction, the instruction must have
a label defined. You would then need to get the address of the label (using
ApiCmdBCInstrTblGetAddrFromLabel), and use that address in the ApiCmdBCStart
function call as shown below. (This example uses the BC Instruction Table minor frame/major
frame definition example shown in section 4.2.5.2.)
Define Minor Frame Timing and Start the Bus Controller (for BC Instruction Table
Mode with execution start at a label other than the first label in the table.)
frame_time = 10; /* Minor Frame Time in milliseconds */
frame_cnt = 0; /* (0 = cyclic is N/A value for BC Instruction Tbl mode. However,
*/
/* you can specify the major frame count for non-cyclic major */
/* frames: 1 –255 = number of major frame executions */

ApiCmdBCInstrTblGetAddrFromLabel(ApiModuleHandle, 0, 0x2222 /*label for 2nd minor

frame*/, 8 /*# of entries*/,instr_tbl, &saddr, &line);

ApiCmdBCStart(ApiModuleHandle,0, API_BC_START_INSTR_TABLE, frame_cnt /*0 = cyclic*/,

frame_time /* frame time in ms */, saddr /* BCInstr Tbl start address*/,
&ul_MajFrameAddr, aul_MinFrameAddr);

76 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.2.7 Acyclic 1553 Transfers

Acyclic 1553 transfers may be required in your application if there are certain conditions under
which you may want to insert a sequence of transfer(s) "on the fly" (or at a pre-defined time)
into the major frame. The new acyclic frame containing the sequence of transfers will be
inserted into the major frame by the BC one time upon the completion of the BC
transfer/instruction currently being executed. In order to prepare for the "on the fly" insertion,
you must first have the transfers defined as described in Section 4.2.2. The following
additional functions must be used including:

a. ApiCmdBCAcycPrep - Defines the properties of the acyclic "on-the-fly" BC

transfers/instructions to be inserted into the BC framing sequence. This
instruction is basically identical to the ApiCmdBCFrameDef without the
definition of a Minor Frame ID (since it will be sent "on the fly").

b. ApiCmdBCAcycSend - Starts the insertion of the acyclic "on-the-fly" transfers

using one of the following methods:

1. Insert immediately into the BC framing sequence upon transmission

completion of the current BC transfer/instruction

2. Insert at a user-specified-time

3. Insert after the current normal minor frame is completed and before the
next normal minor frame starts.

Examples of acyclic transfer programming using the BC functions described above can be
found in the ls_acyclic_sample.c program. The following sample code demonstrates
the insertion of two transfers immediately upon request using two previously setup transfers
with Transfer IDs of 1 and 2. Once normal BC operations have started, the acyclic transfer can
be sent.

Define the transfers that will be sent in the acyclic frame. A maximum of 127 Transfers
can be sent in one Acyclic Frame.

// Prepare Acyclic Transfer sequence

api_bc_acyc.cnt = 2;
api_bc_acyc.xid[0] = 1; // Transfer 1
api_bc_acyc.instr[0] = API_BC_INSTR_TRANSFER;
api_bc_acyc.xid[1] = 2; // Transfer 2
api_bc_acyc.instr[1] = API_BC_INSTR_TRANSFER;
ApiCmdBCAcycPrep(ApiModuleHandle,0, &api_bc_acyc);

***Wait until the BC has started execution ***

Send the Acyclic Transfer

ApiCmdBCAcycSend(ApiModuleHandle,0, API_BC_ACYC_SEND_IMMEDIATELY,0 ,0);

MIL-STD-1553 Programmer's Guide 77

 Section 4 – Programming Using the API Library

Note: Acyclic transfers can be performed when using either the Standard Framing mode or
the BC Instruction Table mode for minor/major frame definition.
Note: The function returns before all acyclic data has been sent!

4.2.8 BC Interrupt Programming

As introduced in Section 4.1.7, the BC is capable of producing interrupts upon the occurrence
of certain events. Interrupt Handler(s) must be created to process the interrupts which occur
after the BC has been started and an interrupt occurs. Some possible BC Interrupt Handler
functions may include: (1) refilling the message buffer at the end-of-transfer interrupt, and/or
(2) reporting transfer errors on a transfer error interrupt. The functions required to setup BC
interrupts and interrupt handler execution include the Library Administration and Initialization
functions as defined in section 4.1.7, and one or more of the BC function calls (as your
application requires) defined as follows:

a. ApiCmdBCXferDef - Setup the BC to perform an interrupt on any of the

following conditions:

 Interrupt on End of Transfer

 Interrupt on Transfer Error

 Interrupt on Status Word exception

b. ApiCmdBCFrameDef, ApiCmdBCAcycPrep, or ApiCmdBCInstrTblGen -

Within the sequence of transfer instructions defined within a minor frame, you
can setup an instruction to generate an interrupt.

 Interrupt upon occurrence of a transfer instruction defined as BC Skip

instruction with interrupt enabled

c. ApiCmdBCStart – when setup for non-cyclic major frame transmission

 Interrupt after the user-specified count of major frames have been

transmitted and BC is halted.

Once you have configured the BC to generate an interrupt and you have created an Interrupt
Handler function to handle the interrupt, then start the BC using the ApiCmdBCStart function
to start data flow. If the BC determines that an interrupt has occurred, the BC will initiate a
call to the Interrupt Handler function and provide information about the interrupt as defined in
the ApiInstIntHandler handler definition in the associated MIL-STD-1553 Reference
Manual.

The following sub-sections describe how to setup the BC transfer to create an interrupt.

78 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

4.2.8.1 How to Setup the 1553 Transfer to Cause an Interrupt

As described above, the BC can be setup to interrupt during a transfer on one of the following
conditions as shown in Table 4.2.8.1-I.:

a. Interrupt on End of Transfer - an interrupt will be logged to the interrupt loglist

when the when the transfer is complete (including status word/frame)

b. Interrupt on Transfer Error - an interrupt will be logged to the interrupt loglist

when a transfer error is detected

c. Interrupt on Status Word exception - an interrupt will be logged to the interrupt

loglist when the Staus Word received by the BC AND'd with the Status Word
Exception Mask indicates a non-zero condition. When configuring your
transfer to interrupt on a Status Word Exception, you must set the Status Word
Exception Mask to indicate the Status Word Exception the BC is to look for. In
the Status Word Exception Interrupt Transfer defined in Table 4.2.8.1-I, the
Status Word Exception Mask is setup to look for a "Busy" condition in the
Status Word.

Table 4.2.8.1-I Setup for 1553 Transfers to Generate Interrupts

MIL-STD-1553 BC Transfer Definition Parameters defined using ApiCmdBCXferDef

Transfer
Structure
element in
api_bc_xfer End of Transfer Interrupt Transfer Error Interrupt Status Word Exception Interrupt
xid (1 - 511)* (1 - 511)* (1 - 511)*
hid (1 - 511)* (1 - 511)* (1 - 511)*
type any type any type any type
tic API_BC_TIC_ON_XFER_END API_BC_TIC_INT_ON_XFER_ERR API_BC_TIC_ON_STATUS_EXCEPT
swxm 0x0008 (See Status Word
Exception Mask below)
rsp API_BC_RSP_AUTOMATIC
* Board dependant, see table 3.2.6.1-I

Status Word Exception Mask

15...............11 10 9 8 7....5 4 3 2 1 0
5 1 1 1 3 1 1 1 1 1
Dynamic Bus
Service request

Acceptance
Broadcast

received
Instrumentation

Command

Busy

Sub System Flag

Control

Terminal Flag
Message Error

Remote Terminal Address Reserved

See Section 5.2.2, ls_interrupt_sample.c for an example of how to program the BC to

"interrupt on end of transfer" and how to setup an interrupt handler service routine to handle
those interrupts.

MIL-STD-1553 Programmer's Guide 79

 Section 4 – Programming Using the API Library

4.2.8.2 How to Setup the Minor Frame Transfer Sequence to Cause an Interrupt

Although used less frequently, the BC can be setup to generate an interrupt between transfers
in a minor frame or acyclic frame. This can be accomplished using the functions
ApiCmdBCFrameDef (for minor frame transfer sequence definition in Standard Framing
mode), ApiCmdBCInstrTblGen (for minor frame transfer sequence definition in BC
Instruction Table mode), and ApiCmdBCAcycPrep (for acyclic frame transfer sequence
definition).

a. For ApiCmdBCFrameDef and ApiCmdBCAcycPrep, the two function

parameters associated with this setup include the transfer instruction, "inst",
and the transfer ID "xid". These two parameters should be setup as follows:

 "inst" - set to the Skip Instruction (inst = API_BC_INSTR_SKIP)

 "xid" - set the Skip Count to 1 (which basically is interpreted as a "No

operation" instruction) and enable the interrupt.

b. For ApiCmdBCInstrTblGen the two function parameters associated with this

setup include the transfer instruction, "op" and the instruction parameter
"par2". These two parameters should be setup as follows:

 "op" - set to the Skip Instruction (inst = API_BC_FWI_SKIP)

 "par2" - set INT = 1 to enable the interrupt.

4.2.9 Status Word Exception Handling

The BC can be programmed to monitor bits in the Status word received from an RT SA/Mode
code. If any of the Status word bits (programmed to be monitored) are set in the Status word
received from the RT SA/Mode code, the BC can also be programmed to halt the BC or
generate an interrupt such that a user-developed interrupt handler can provide further
processing.

There is one function associated with programming the BC to handle Status word Exceptions:
ApiCmdBCXferDef. (Handling of the Service Request in the RT Status word is a special case
and is discussed in Section 4.2.9.1.) As defined in section 4.2.2, the ApiCmdBCXferDef BC
function will utilize the api_bc_xfer structure to define the properties of a 1553 transfer.
Information contained in this structure is not only used to create the Command word, Data
word(s)/Mode Code, it is also used to define the process for handling the Status word
generated by the RT(s) SA/Mode code associated with the transfer. The api_bc_xfer
structure parameters associated with Status word exception handling are shown in Table 4.2.9-
I.

Table 4.2.9-I BC Transfer Definition Parameters for Status Word Exception Handling

80 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

MIL-STD-1553 BC Transfer Definition Parameters defined using ApiCmdBCXferDef

Transfer Structure
element in
api_bc_xfer Definition
tic Interrupt control - setup for generation of a BC
interrupt upon end of transfer, transfer error or
status word exception (See Section 4.2.8)
hlt Halt control - setup to halt the BC upon end of
transfer, transfer error, status word exception or
any interrupt
sxh Status word exception handling - defines the process
to execute upon occurrence of a Status word Service
Request
swxm Status Word Exception Mask - defines the bits in the
status word received from the RT that will be checked
by the BC
rsp Expected Response - defines the response the BC
expects from the RT such as basic response as defined
by ApiCmdDefMilbusProtocol, no status word 1
expected, or no status word 2 expected.

The Status Word Exception Mask (swxm) is used to mask (AND mask) the status word
response of the RT SA/Mode code. The Status Word Exception Mask is used for both
responses received by the BC for RT-to-RT transfers. If the result of the mask process is not
zero, an interrupt is asserted, if enabled via the tic parameter and/or the BC is halted, if
enabled via the hlt parameter. Unexpected responses (a non-zero result of the mask process)
are not counted as errors and cause no Error Interrupt or Retry.

Table 4.2.9-II provides some examples of how to setup the parameters for
ApiCmdBCXferDef for Status word exception handling. Note that in each case the Expected
Response control (rsp) is setup to check both Status Word 1 and Status Word 2 (RT-RT
transfers only). This parameter, however, can be modified to check only Status word 1 or only
Status word 2. In the following table, three examples are setup. The first example shows the
parameter setup for configuring the BC transfer such that the BC will check the Message Error
bit (bit 10) in the Status word and interrupt if that bit is set in the Status word received by the
BC. The second example configures the BC to halt the BC if the Instrumentation error bit (bit
9) is set in the Status word. The third example configures the BC transfer such that the BC will
interrupt if either the Message Error bit (bit 10) or the Busy bit (bit 3) is set in the Status word

MIL-STD-1553 Programmer's Guide 81

 Section 4 – Programming Using the API Library

Table 4.2.9-II Transfer Setup for Status Word Exception Handling Examples

1553 BC Transfer Definition Parameters

Interrupt on Message Halt the BC on Interrupt on Busy set or
Error in RT Status Instrumentation Error in Message Error in RT Status
Word RT Status Word Word
api_bc_xfer.xid (1 - 511)* (1 - 511)* (1 - 511)*
api_bc_xfer.hid (1 - 511)* (1 - 511)* (1 - 511)*
api_bc_xfer.type any type any type any type
api_bc_xfer.hlt API_BC_HLT_NO_HALT API_BC_HALT_ON_STAT_EXCEP API_BC_HLT_NO_HALT
T
api_bc_xfer.tic API_BC_TIC_ON_STATUS_E API_BC_TIC_NO_INT API_BC_TIC_ON_STATUS_EXCEP
XCEPT T
api_bc_xfer.swxm 0x0400 (See Status 0x0200 (See Status Word 0x0408 (See Status Word
Word Exception Mask Exception Mask below) Exception Mask below)
below)
api_bc_xfer.rsp API_BC_RSP_AUTOMATIC API_BC_RSP_AUTOMATIC API_BC_RSP_AUTOMATIC
* Board dependant, see table 3.2.6.1-I

Status Word Exception Mask

15...............11 10 9 8 7....5 4 3 2 1 0
5 1 1 1 3 1 1 1 1 1
reserved (0)

Dynamic Bus
Service request

Acceptance
Broadcast

received

Control
Instrumentation

Command

Busy

Sub System Flag

Terminal Flag
Message Error

Reserved (0)

4.2.9.1 RT Service Request Processing

The BC can be programmed to transmit a Vector Word Mode code (Mode code 16) when the
Service Request bit in the RT Status word (Status Word 1 only) is set. Setup required for this
process to occur includes the following:

a. ApiCmdBCIni - Enable Service Request / Vector Word Mode Control (svrq)

b. ApiCmdBCXferDef - Setup the Status word exception mask (swxm) with the
Service Request bit set (bit 8). Configure the Status Word Exception Service
Request handling control parameter (sxh = 1) for the BC to generate automatic
Transmit Vector Word Mode code (16) when the Service Request bit is set.

As response on the Mode code, the RT transmits a Vector Word to the BC, which is interpreted
and handled by the BC following the description given in the 'AVS Databus Usage Report R-J-
403-V-1209 Par7.2'. The format of the Vector Word expected to be sent by the RT after
receipt of the Transmit Vector Word Mode code is shown in Figure 4.2.9.1-1.

Figure 4.2.9.1-1 Vector Word Format

Bit 15..12 Bit 11..7 Bit 6..0

Vector Word ID RT-Address Subaddress / MID

82 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

The Vector Word IDs and BC automatic response is shown in Table 4.2.8.1-I. In order for the
BC to respond as requested by the RT's Vector Word, a BC transfer must be setup as defined in
the last column of Table 4.2.9.1-I.

Table 4.2.9.1-I BC Response to RT Vector Word

Vector Word BC Response BC Setup Required

ID
Request Single A pre-defined transfer is executed once ApiCmdBCXferDef - setup a
RX/TX immediately (acyclic) after receipt and vector word driven transfer for
(1000/1001) decoding of the vector word. this request with parameter sxh
= 1.
Request A pre-defined transfer is appending to ApiCmdBCXferDef - setup a
Multiple the end of the current BC minor frame vector word driven transfer for
RX/TX (Cyclic execution until disabled). this request with parameter sxh
(1010/1011) =2
Delete RX/TX The related BC transaction is disabled
(1100/1101) by deleting it from the end of the
related BC minor frame. Re-enabling
requires receipt of the corresponding
vector word code (Request Multiple
RX/TX 1010/1011). Only BC transfers
which have been enabled by a previous
'Request Multiple RX/TX' vector word
can be disabled.

Note: Only BC-RT and RT-BC transfer types can be defined to be 'vector word driven
transactions'.

The BC function ApiCmdBCSrvReqVecStatus can be used to obtain the status of the number
of Service Requests issued by the RT and to obtain the Last Vector Word received from the
RT.

MIL-STD-1553 Programmer's Guide 83

 Section 4 – Programming Using the API Library

4.2.10 Tracking BC Receive Data using Track Multiplex Buffers

The BC can be programmed to store RT-to-BC 1553 Data message "tracks" received by the
BC into a Track Multiplex Buffer (accessible by the user-application), thus, providing a means
to analyze specific filtered 1553 data transferred over the MILbus. Tracks are defined as 1-32
data words of a 1553 Data message. The length of the Track, and the Xfer ID associated with
the Track is specified using the function ApiCmdTrackDefEx. When the 1553 Data message
with the defined Xfer ID is received by the BC, the BC will store the Track into a Track
Multiplex Buffer at the Track Multiplex Buffer Index contained within the 1553 Data message.
The Track Multiplex Buffer and location of the Track Multiplex Buffer Index in the 1553 Data
message are also specified using the function ApiCmdTrackDefEx. Figure 4.2.10-1 provides
an example of the Track process.

Figure 4.2.10-1 BC Track Process Example

T12 T1n
Track
Multiplex Data Buffer = 32 words Data Buffer = 32 words
Buffer 0 1 7
Index 21 words 21 words ........ 21 words
(at
location Track Track Track
word 5
bits 13-15)

Track Multiplex
Buffer ID 0
T1 Track
(at Index 0)
T1 Track
(at Index 1)
........

T1Track
(at Index 7)

In Figure 4.2.10-1 Example, T1 is a pre-defined 1553 transfer with 32 data words scheduled to
transfer each minor frame.

Using ApiCmdTrackDefEx the user specifies:

a. The Xfer ID of the RT-to-BC Transfer in which a "Track" is defined. In our

example, the Xfer ID is 1 (The BC Transfer must be an RT-to-BC transfer
previously defined using ApiCmdBCXferDef.)

84 MIL-STD-1553 Programmer's Guide

 Section 4 – Programming Using the API Library

b. The ID of the Track Multiplex Buffer (Ex. 0) used to store the multiplexed
tracks (Range is 0 - 31). The Track Multiplex Buffers are shared by the RT and
BC functions.

c. The Track Multiplex Buffer Index location in the 1553 Data Buffer. In this
example, word 5, bits 13-15 were used. This allows a three bit index which
limits the number of Tracks (item (d) below) in the Track Multiplex Buffer to 8.
The Track Multiplex Buffer Index will be located in the first word of the Track.

d. The number of multiplexed tracks (Ex. 8) to be located in the Track Multiplex

Buffer (Range is 1 - 1024). The number of multiplexed tracks allowed depends
on the bit size of the Track Multiplex Buffer Index (item (c) above). In our
example, 3 bits were used for the index, thus allowing 8 tracks in the Track
Mutiplex Buffer.

e. The Track start location (Ex. word 5) and Track Length (Ex. 21). The
Track can start at any word within the 1553 Data Buffer (0-31) and be up to 32
words long. The first word of the track will contain the Track Multiplex Buffer
Index.

f. Number of contiguous Track Buffers (Ex. 1) the number of continuous

Tracks located in the Data buffer. If more than one Track is located in the Data
Buffer, the BC will store the additional Tracks into the Track Multiplex Buffer
at the Track Multiplex Buffer Index specified in each Track.

Using ApiCmdTrackReadEx the entire Track Multiplex Buffer or specific tracks can be read
from a specific Track Multiplex Buffer.

MIL-STD-1553 Programmer's Guide 85

 Section 4 - Programming Using the API Library

4.3 REMOTE TERMINAL PROGRAMMING

The remote terminal (RT) is a device designed to interface various subsystems with the 1553
data bus. The interface device may be embedded within the subsystem itself, or may be an
external interface to tie a non-1553 compatible device to the bus. As a function of the interface
requirement, the RT receives and decodes commands from the BC, detects any errors and
reacts to those errors. The RT must be able to properly handle both protocol errors (missing
data, extra words, etc.) and electrical errors (waveform distortion, rise time violations, etc).
RTs are the largest segment of bus components. Up to 31 remote terminals can be connected to
the data bus and each remote terminal can have 31 subadresses. The remote terminal shall not
speak unless spoken to first by the bus controller and specifically commanded to transmit. The
commands may include data or request for data (including status) from RTs. Command word,
Data word and Status word formats are shown in Section 2.

If your application requires the simulation of an RT, this section will provide you with the
understanding of the RT programming functions required for use in your application.
Programming the RT may require the use of more than just the RT functions. Also needed
may be the Buffer and FIFO functions. This section will discuss some of the typical scenarios
a programmer would encounter that would require the use of the Buffer, FIFO and RT
functions as defined in Tables 3.2.5-IV, 3.2.5-V, 3.2.5-VII respectively. These scenarios
include:

a. Initializing the RT

b. Defining RT Subaddresses

 RT transfers using single buffers

 RT transfers using multiple buffers

 RT transfers using FIFOs

 RT transfers with dynamic data

c. RT transfers with error injection

 Into Status/Data word

 Via Status Word Response

d. RT Interrupt programming

e. RT Global Configuration

f. Tracking RT-receive 1553 data via Track Multiplex Buffers

86 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

4.3.1 Initializing the RT

Initialization of the RT must be the first RT setup function call issued. This function call,
ApiCmdRTIni, required for each RT to be initialized, will perform setup of the RT global
transfer and Status word response characteristics for a specified RT including:

a. RT Address - Address (0 - 31) of the simulated RT

b. RT Operation Control - This control parameter configures the RT for one of

the following two operational modes:

 RT Simulation - In this mode the RT will behave in the manner you

have set it up to behave.

 RT Mailbox Monitoring - In this mode, the RT will capture RT message

data on a subaddress level without affecting bus traffic (i.e. without
generating a response on the bus). This mode is used to monitor non-
simulated "external" RT's.

c. Response Time - defines the default value defining the time it will take for the
RT to respond with a status word. As shown in Figure 4.2.1-1, the response time
is the time between the BC Command/Data word and the RT Status word. This
value can be programmed from 4.0 to 63.75µs in 0.25µs steps.

Note: There is an additional Response Time configuration function,

ApiCmdRTRespTime, that allows you to change the defaulted response time
after basic initialization has been performed.

d. RT Next Status Word - defines the value of the status word that the RT will
respond with after the BC Command/Data word is received.

Next Status Word

15...............11 10 9 8 7....5 4 3 2 1 0
5 1 1 1 3 1 1 1 1 1
Sub System

Dynamic Bus

Acceptance
Instrumentati

request

Broadcast

received

Control
on

Command

Busy

Flag

Flag
Error
Message

Service

Terminal

Remote Terminal Address Reserved

The following code example uses API S/W Library constants to initialize the RTs, 1, and 2 for
Simulation enabled, Response time default set to 8 µs, and the Next Status word is setup to
disable any errors or service requests. (The only bits that are set in the Next Status word
indicate the RT address.)

// Remote Terminal Initialization Commands

MIL-STD-1553 Programmer's Guide 87

 Section 4 - Programming Using the API Library

ApiCmdRTIni(ApiModuleHandle,0, 1/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x0800);

ApiCmdRTIni(ApiModuleHandle,0, 2/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x1000);

Note: Default operation of the RT is to respond to Command Words from both the primary
and secondary busses.

4.3.2 Defining RT Subaddress/Mode Code for Communication with the BC

For MIL-STD-1553 BC-to-RT, RT-to-RT and RT-to-BC transfers, the user must first assign an
RT Buffer Header ID to the RT to enable the processor to identify the location of status and
event data generated for each transfer as shown in Figure 4.3.2-1. The status and event data
queues associated with the assigned Buffer Header will contain the command and status
information required to process the 1553 transfer as well as the pointers to the buffers used to
transfer the 1553 Data Words.

The message buffers will be assigned to transmit/receive the Data words within the 1553
transfer. If there are no Data words within the 1553 transfer, a message buffer will still need to
be assigned. (However, the API S/W Library does not prevent the user from using the same
buffers in more than one transfer, therefore, the same message buffer can be assigned for
transfers that do not require the transmission/reception of Data word(s)). Each message buffer
has a unique ID (ID range Table 3.2.6.1-II) which must be assigned by the user.

In addition, the characteristics of the RT SA must be defined.

To configure an RT to respond to each type of transfer will require the use of the following RT
function calls:

a. ApiCmdRTBHDef - this RT function will define an RT Buffer Header

structure. As shown in Figure 4.3.2-1, the RT Buffer Header structure enables
the processor to identify the location of the message buffers used and status and
event data generated for each RT message transfer. The RT Buffer Header
information to be setup by this function includes the following:

 RT Buffer Header ID – the ID of the RT Buffer Header structure

 Message Buffer ID - the ID of the first buffer in the Global RAM

message buffer pool to be used for the transfer of the Data words. See
Table 3.2.6.1-II for the number of message buffers available. A
Message Buffer ID of 20 would indicate that the 20th buffer in the
Global RAM Buffer Pool will be used. See Figure 4.3.2-1 for a diagram
of the structure of these message buffers.

 Buffer Queue Size - the number of Global RAM message buffers to be

used for the transfer of the Data words. One or more buffers can be used
for the transfer. You will always need to assign at least one message
buffer from the Global RAM Buffer Pool for your transfer. For

88 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

example, assigning API_QUEUE_SIZE_8 for this transfer indicates

that 8 contiguous buffers would be used. Using the example of Message
Buffer ID of 20 above, and a queue size of 8, message buffers 20 - 27
would be used for the transfer.

 Buffer Queue Mode - specifies the order in which multiple buffers as

specified in the Buffer Queue Size, will be filled. In most cases, users
will choose to store the Data words into the Message Buffers in a cyclic
fashion (API_BQM_CYCLIC)

 Data Buffer Store Mode - will allow the user to indicate the actions to
be taken in case of error in the transmission or reception of Data words
such as whether to keep transmitting the same message buffer at transfer
error, or continue with the next buffer in the queue for the next
transmission.

Note: Buffer Queue Size, Buffer Queue Mode , Data Buffer Store Mode, and
Buffer Size and the Current Buffer Index can be modified "on the fly"
(i.e. after the RT has been started) using the Buffer function call
ApiBHModify.

Figure 4.3.2-1 RT Buffer Header and Buffer Pool Interface

RT Buffer RT - Status

control word control word

status queue pointer received status words

event queue pointer actual data buffer

data buffer queue pointer time tag

RT - Event
Buffer Pool
for 1553 control word

(32 x 16Bit words each res

1 res

2 res
3 511 / BIU
4
5

6
User 7
Data
n-
Queue of n-
4 buffers
n- n:
See Board
Table 3.2.6.1-IIn for
n Buffer Id ranges.
1553-1 2047 Note:
The queue size can
The buffers are shared
selected as 2^k, where 1553-2 4095 between BC, RT on
k can have a range
0 to 8.

MIL-STD-1553 Programmer's Guide 89

 Section 4 - Programming Using the API Library

b. ApiCmdRTSACon - this function defines the subaddresses to be simulated and

the mode codes the RT is required to respond to. This enables the RT to be able
to properly respond to the Command/Action word with a user-defined Status
word and/or Data word Transmission. For each of the RT's Subaddresses or
Mode codes simulated by your application you will need to use this function
call. All RT characteristics defined by this function are associated with the
Bufer Header ID identified with ApiCmdRTBHDef . This function provides

 Subaddress Type – allows the user to define whether the Subaddress

specifed by the user (sa) (0 – 31) is enabling response functionality for
a Mode code or is enabling a subaddress for data transfers.

 Subaddress Control - provides a method to disable the individual SA,

and setup interrupt processing including whether the RT SA will
interrupt after the transfer is complete or interrupt on any transfer error.

 Buffer Locations - It also associates the RT SA/Mode code to a pre-

defined RT Buffer Header ID (see item (a) above) such that the buffer
location for all action (Data word receive/transmit), and status for that
RT SA/Mode code is known.

 Status Word Response - provides the capability for a unique Status

Word Response (shown in Figure 4.3.2-2) to be sent for each individual
RT SA's or Mode codes. The Status Word response is defined by
masking in any desired Status word bits to the Next Status Word defined
using the global RT function, ApiCmdRTIni.

Figure 4.3.2-2 Status Word Bits

Status Word
15...............11 10 9 8 7....5 4 3 2 1 0
5 1 1 1 3 1 1 1 1 1
Sub System Flag
Instrumentation

Remote Terminal Address Reserved

Service request
Message Error

Terminal Flag
Dynamic Bus

Acceptance
Command
Broadcast

received

Control
Busy

The following code is an example of setting up the RT for a BC-to-RT transfer to RT1, SA1
with a data word count of 4. The IDs assigned to this transfer include:

RT Assignments
RT Buffer Header ID = 1
Buffer ID = 10

This setup performed in this example will configure RT1, SA1 to receive Data words into a
message buffer (buf_id = 10). With the ApiCmdRTBHDef function, the Queue size is set to 1,
such that the same buffer will be used each time the RT receives Data words from the BC.

90 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Using the ApiCmdRTSACon function, RT1 Receive SA1 is associated with RT Header ID =
1, the subaddress is enabled with no interrupt (API_RT_ENABLE_SA), the Status Word Mask
control and mask is set to logically "OR" the value of 0 with the Next Status word specified in
the ApiCmdRTIni function. (In essence, the RT1 Receive SA1 will use the default Next
Status word instead of defining a unique Status word.)

rt_hid = 1; buf_id = 10;

ApiCmdRTBHDef(ApiModuleHandle,0,rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,
&api_rt_bh_desc);

ApiCmdRTSACon( ApiModuleHandle, 0, 1/*RT*/, 1/*SA*/, rt_hid/*HID*/,

API_RT_TYPE_RECEIVE_SA, API_RT_ENABLE_SA, 0/*rmod*/, API_RT_SWM_OR, 0/*swm*/);

Section 4.2 Program Sample Code, provides many examples of setting up multiple RTs.
Table 4.3.2-I provides examples of how to change the parameters in the ApiCmdRTSACon
function to setup different types of RT transfers.

Table 4.3.2-I Transfer Setup for Different Types of RT Transfers

RT Transfer Definition Parameters

ApiCmdRTSACon Broadcast RT-to-BC Mode code Xfer RT-to-RT Xfer from RT04
parameters Xfer with Xfer to to RT05 SA0 SA2 to RT03 SA1 with
word count RT02, SA03 where Mode code word count = 32
of 2 with word = 17
count of 5 (synchronize)
Remote Terminal 31 2 5 4 3
Subaddress/ 1 - 30 3 17 2 1
Mode code
Header ID 1 – 511* 1 – 511* 1 – 511* 1 – 511* 1 – 511*
Subaddress Type RECEIVE_SA TRANSMIT_SA RECEIVE_MODECODE TRANSMIT_SA RECEIVE_SA
Subaddress x x x * *
Control
Status Word Mask x x x x x
Control
Status Word Mask x x x x x
* Board dependant, see table 3.2.6.1-I
x - Indicates this parameter is application dependent. Depending upon your application you
can setup the subaddress control to interrupt on any transfer, or interrupt on transfer error. In
addition, the status word response for the SA/Mode code can be modified using the Status
Word Mask Control and the Status Word Mask.

Note: If you want to setup the RT such that it will detect illegal Mode codes, you will need to
configure the RT using the ApiCmdRTSACon function for every illegal Mode code and
set the RT's Status word to indicate Message Error. See Section 4.3.3.2 for further
details.

MIL-STD-1553 Programmer's Guide 91

 Section 4 - Programming Using the API Library

4.3.2.1 RT Transmit/Receive Message Data Word Generation/Processing

Now that you are familiar with the method used to define the characteristics of the RT transfers
generated by a simulated RT, we can now discuss how to setup and place data into the message
buffers assigned for RT Data word transmissions for RT-to-BC and RT-to-RT type transfers.
Also described will be how to setup and obtain data from the message buffers used for RT
Data word reception for BC-to-RT and RT-to-RT type transfers.

For RT-to-BC and RT-to-RT Type Transfers (RT Transmit)

The API S/W Library provides several methods to insert real-time/dynamic/fixed user data into
the Global RAM 1553 Message Buffers used by the transmitting side of the RT transfer and
specified in the ApiCmdRTBHDef function described in the previous section. Regardless of
how many buffers have been allocated in the Global RAM message buffer pool for the
transmission of RT data, any of the following methods can be used to insert Data words into
the Message Buffer(s). Following is a summary of the different scenarios you may choose:

a. Insert fixed data into the Message Buffer(s) using the ApiCmdBufDef Buffer
function.

b. Insert dynamically updating data into the Message Buffer(s) using the
ApiCmdRTDytagDef function. This function provides dynamically changing
data words within the transmit message buffer using one of the following
dynamic data generation modes/functions:

 Function mode: provides for up to two dynamic data words per transfer
using any combination of the following functions as pictured in Figure
4.3.2.1-1

1. Positive Ramp

2. Negative Ramp

3. Positive Triangle

4. Negative Triangle

5. Transmit a Data word from a different Message Buffer

 Tagging Mode - provides for up to four dynamic data words per transfer
using Sawtooth Tagging. The Sawtooth Tagging mode provides an
incrementer by 1, which is performed on the user-specified location with
each execution of the associated RT transfer. The location to be
incremented can be setup with an initial value to be incremented each
transfer, or the existing value can be incremented. The options are to
increment any combination of the following byte or words:

92 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

1. 16-Bit Sawtooth

2. 8-Bit Sawtooth LSB (lower byte of word)

3. 8-Bit Sawtooth MSB (upper byte of word)

Figure 4.3.2.1-1 Data Generation Functions Diagram

c. Assign a FIFO (ASP Shared RAM) to the transfer. (Each FIFO consists of 128
32-word buffers. There are 32 FIFOs.) Pre-fill the FIFO with application data,
the data transmitted in the Global RAM message transmit buffer will be
obtained from the FIFO. Re-fill the FIFO as needed. (See Figure 4.3.2.1-2)

d. Assign Dataset buffers (ASP Shared RAM) to the transfer. (There are 4095 32-
word buffers in the Dataset Buffer pool.) Pre-fill the Dataset buffer(s) with
application data, the data transmitted in the Global RAM message transmit
buffer will be obtained from the Dataset buffers. Refill the Dataset buffers as
needed. (See Figure 4.3.2.1-2)

e. Create an interrupt handler routine and setup the interrupt control defined for
the transfer to interrupt on end-of-transfer. Upon end-of transfer interrupt, the
interrupt handler will be called at which time the buffer can be filled with new
data. See Section 4.3.4 for more information on RT Interrupt handling.

MIL-STD-1553 Programmer's Guide 93

 Section 4 - Programming Using the API Library

Figure 4.3.2.1-2 RT Transfer Data Generation via FIFO or Dataset Buffers

The BC, Buffer, and/or FIFO function calls required for each scenario described above are
summarized in the Table 4.3.2.1-I.

For BC-to-RT and RT-to-RT Type Transfers (RT Receive)

Before the RT receives the Data words from the BC or an RT, as part of the setup process, you
may choose to clear your receive buffer to avoid any Data word transmission confusion. The
receive buffers can be cleared before use by using the ApiCmdBufDef function.

After the RT has received Data words from the BC or an RT, software will need to be added to
process the data. Processing data received by the RT can be accomplished in one of two ways:
n:
polling at pre-defined intervals to examine the RT data, or setting up theSeetransfer
Table 3.2.6.1-IIto
Buffer Id ranges.
forinterrupt at

end-of-transfer. To accomplish the interrupt on end-of-transfer method of processing the data,

an interrupt handler routine must also be developed to handle the interrupt which will occur
after all Data words have been received. Upon end-of transfer interrupt, the interrupt handler
will be called at which time the buffer can be read and processed as required by the
application. Interrupt handling is discussed further in Section 4.3.4.

Table 4.3.2.1-I Function Calls Required for RT Data Word Transmission Scenarios

BC Transmit Functions Used Other Examples

Message
Source
Fixed Data 1. ApiCmdRTBHDef LS_BC_RT_BM_Sampl
2. ApiCmdRTSACon e.c
3. ApiCmdBufDef to initialize buffer with fixed data words
(or ApiCmdBufWrite to initialize a buffer with a single
16-bit word)

With Dynamic 1. ApiCmdRTBHDef

Data Words 2. ApiCmdRTSACon
3. ApiCmdBufDef to setup non-dynamic data
4. ApiCmdRTDytagDef to setup 1-4 dynamic data words
Using FIFOs 1. ApiCmdRTBHDef
2. ApiCmdRTSACon
3. ApiCmdFifoIni to initialize the FIFO
4. ApiCmdRTSAAssignFifo to assign the FIFO to the
transfer
5. ApiCmdFifoReadStatus to determine how much FIFO
data to reload
6. ApiCmdFifoWrite to fill the FIFO with data
With Dynamic 1. ApiCmdRTBHDef
Dataset Buffers 2. ApiCmdRTSACon
3. ApiCmdRamWriteDataset to fill the dataset buffers

94 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

with data to be used in the message buffers

4. ApiCmdSystagDef to assign the Dataset buffers to the
transfer

MIL-STD-1553 Programmer's Guide 95

 Section 4 - Programming Using the API Library

4.3.2.2 RT Transmit/Receive Mode Code Generation/Processing

The RT can be programmed to respond to any Mode code command including the reserved
Mode codes. As discussed in Section 4.3.2, enabling or disabling Mode codes is achieved
using the ApiCmdRTSACon function. This function will allow the RT to process up to 32
receive and 32 transmit Mode codes.

Note: No difference is made between received Mode code commands using the subaddress 0
or 31 if the RT operates in MIL-STD-1553B protocol mode. If the RT operates in MIL-
STD-1553A protocol mode, only Subaddress zero is used for received Mode
Commands.

If your application requires that the RT be capable of processing Mode codes, this section will
provide further detail into this process. Table 4.3.2.2-I provides a list of the Mode codes
defined in MIL-STD-1553B. The codes not shaded are codes which are simulated in the
API/ACI1553 module's RT interface if the RT operates in the MIL-STD-1553B protocol
mode.

If the RT operates in the MIL-STD-1553B protocol mode, special Mode code handling is
provided for the Mode codes as follows:

a. Transmit Status Word (00010) - The Last Status word sent for each
simulated RT is maintained by the onboard RT interface software. If a
simulated RT is setup to receive this Mode code using the ApiCmdRTSACon
function the RT interface will automatically send the Last Status word for the
specific RT upon receipt of this Mode code. If the last transfer was a Broadcast
transfer, the RT interface will set the "Broadcast Received" bit in the Status
word response.

b. Transmit Last Command Word (10010) - The Last Status word sent for
each simulated RT is maintained by the onboard RT interface software. In
addition, the Last Command word received by each simulated RT is
maintained by the onboard RT interface software. If the simulated RT is setup
to receive this Mode code using the ApiCmdRTSACon function the RT
interface will automatically send the specific RTs Last Status word followed
by a single Data word containing the Last Command word upon receipt of this
Mode code. If the last transfer was a Broadcast transfer, the RT interface will
set the "Broadcast Received" bit in the Status Word response and fetch the
Last Command word from RT31 (the Broadcast RT).

96 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.3.2.2-I Mode Codes

Broadcast
Mode Associated Command
T/R Bit Code Function Data Word Allowed
Dynamic Bus
1 00000 Control N N

1 00001 Synchronize N Y
Transmit Status
1 00010 Word N N

1 00011 Initiate Self Test N Y

Transmitter
1 00100 Shutdown N Y
Override
1 00101 Transmitter N Y
Inhibit Terminal
1 00110 Flag Bit N Y
Override Inhibit
1 00111 Terminal Flag Bit N Y

1 01000 Reset RT N Y

1 01001 Reserved N TBD

1 01111 Reserved N TBD

Transmit Vector
1 10000 Word Y N

0 10001 Synchronize Y Y
Transmit Last
1 10010 Command Y N
Transmit BIT
1 10011 Word Y N
Selected
0 10100 Transmitter Y Y
Override Selected
0 10101 Transmitter Y Y

1 or 0 10110 Reserved Y TBD

1 or 0 11111 Reserved Y TBD

MIL-STD-1553 Programmer's Guide 97

 Section 4 - Programming Using the API Library

c. Transmitter Shutdown (00100) - If the simulated RT is setup to receive this

Mode code using the ApiCmdRTSACon function, then upon receipt of this
Mode code the RT interface will automatically disable the transmission on the
alternate Bus for this specific RT. If this Mode code is broadcasted (with
RT31 setup to receive this Mode code), the RT interface will disable the
transmission on the alternate Bus for all simulated RTs.

d. Override Transmitter Shutdown (00101) - If the simulated RT is setup to

receive this Mode code using the ApiCmdRTSACon function, then upon
receipt of this Mode code the RT interface will automatically enable the
transmission on the alternate Bus for this specific RT. If this Mode code is
broadcasted (with RT31 setup to receive this Mode code), the RT interface will
enable the transmission on the alternate Bus for all simulated RTs.

e. Reset Remote Terminal (01000) - If the simulated RT is setup to receive this

Mode code using the ApiCmdRTSACon function, then upon receipt of this
Mode code the RT interface will automatically enable the transmission on both
Busses for this specific RT. If this Mode code is broadcasted (with RT31 setup
to receive this Mode code), the RT interface will enable the transmission on
both Busses for all simulated RTs.

Note: The special Mode code handling described above is not provided when the RT is
operating in Mailbox Monitoring mode.

For all other Mode codes not automatically processed by the RT interface, yet are still required
for processing by your application, the application developer will need to configure the
simulated RT to receive the required Mode code and generate an interrupt upon transfer. This
setup can be accomplished using the ApiCmdRTSACon function as described in Section
4.3.2. The user-developed interrupt service routine can be called to process the Mode code for
the simulated RT. See Section 4.3.4 for further information regarding RT Interrupt Handling.

4.3.2.3 RT Transmit/Receive Broadcast Message Generation/Processing

To implement the capability for your simulated RT to receive Broadcast messages you will
need to setup RT31 to receive/transmit application required Mode codes and/or Data Broadcast
messages using the functions discussed in Section 4.3.2.

As discussed in Section 4.3.2.2 above, the RT interface will provide automatic processing for
RT31 of the Mode codes listed in Section 4.3.2.2, items (a) - (e). All other Mode codes not
automatically handled by the RT interface will need to be processed by your application. The
application developer will need to configure the RT31 to receive these required Mode codes
and generate an interrupt upon transfer. This setup can be accomplished using the
ApiCmdRTSACon function as described in Section 4.3.2. See Section 4.3.4 for further
information regarding RT Interrupt Handling. The user-developed interrupt service routine can
be called to process the Broadcasted Mode code for the simulated RT(s). Broadcast Message
processing required by your application may include:

98 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

a. Updating the Next Status word for all other simulated RTs with the "Broadcast
Command Received" bit set such that when each of the simulated RTs receives
the next command, the status word sent in response to that command will
include the "Broadcast Command Received Bit" set. Setting of the Next Status
word for an individual RT can be accomplished using the ApiCmdRTNXW
function.

b. Updating the Last Command word for all other simulated RTs with the bits 4-
19 of the Command word received in the Broadcast Transfer such that if any of
the simulated RTs receive a Transmit Last Command Mode code, the Last
Command will be the Broadcast Command last received. Setting of the Last
Command word for an individual RT can be accomplished using the
ApiCmdRTLCW function.

c. Performing the functions necessary to simulate the Mode code command issued.
As shown in Table 4.3.2.2-I, not all Mode codes are allowed for Broadcast.

4.3.3 RT Transfers Error Injection

There are two methods that you can use to inject errors into an RT transmission:

a. Use the ApiCmdRTSAConErr function for error injection in any Status word
or Data word transmitted by an RT

b. Manipulate the Status word Busy or Message Error bits using the Status word
masking ability in either the ApiCmdRTIni function, the ApiCmdRTSACon
function or the ApiCmdRTNXW function.

These two methods are described in the following sections.

4.3.3.1 RT Transfers Error Injection into Status/Data Word

RT transmissions can be configured for error injection in any Status word or Data word
transmitted by an RT. The RT is capable of injecting one of the following errors for a defined
transfer:
a. Status Sync Error - changes the transmitted Status word sync pattern to one
specified by the user

b. Data Sync Error - changes the transmitted Data word sync pattern to one
specified by the user

c. Parity Error - creates a parity error for the Status word or specified Data word

d. Manchester stuck at high error - creates a Manchester stuck at high error for a
specified Status word, or Data Word at a specified bit position

MIL-STD-1553 Programmer's Guide 99

 Section 4 - Programming Using the API Library

e. Manchester stuck at low error - creates a Manchester stuck at low error for a
specified Status word, or Data Word at a specified bit position

f. Gap error - inserts specified Gap after defined Status or Data word

g. Word Count High - transmits the number of Data words defined for the
original transfer plus one

h. Word Count Low - transmits the number of Data words defined for the
original transfer minus one

i. Bit Count High - transmits a specified number (1-3) additional bits for
specified Status word or Data word.

j. Bit Count Low - transmits a specified number (1-3) less bits for specified
Status word or Data word.

k. Alternate Bus Error - responds on the wrong bus

l. Zero Crossing Low Deviation Error - implements zero crossing low deviation
at a specified Status word or Data word position, bit position with four
predefined deviation values.

m. Zero Crossing High Deviation Error - implements zero crossing high

deviation at a specified Command word or Data word position, bit position with
four predefined deviation values.

To setup for error injection, the ApiCmdRTSAConErr function should be used after the RT
has been setup to transmit data using the ApiCmdRTBHDef and ApiCmdRTSACon
functions. The following error injection sample code will setup the transfer to inject a Data
Sync Error on the third data word. The transfer definition parameters and the values required
for error injection are shown in bold text.

Set RT-to-BC RT01 Transmit SA02 WC15 (Inject Data Sync Error in 3rd data word)
rt_hid = 1; // Defines the buffer header that will be assigned to this RT transfer
buf_id = 13; // Defines the buffer ID that will be used by the RT Buffer Header ID.

ApiCmdRTBHDef(ApiModuleHandle,0,rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,
&api_rt_bh_desc);

ApiCmdRTSACon( ApiModuleHandle, 0, 1/*RT*/, 2/*SA*/, rt_hid/*HID*/,

API_RT_TYPE_TRANSMIT_SA, API_RT_ENABLE_SA, 0/*rmod*/, API_RT_SWM_OR, 0/*swm*/);

type = API_ERR_TYPE_DATA_SYNC;
sync = 0x30; // set invalid data sync 110000
contig = 0; // not used
wpos = 3; // Inject Error on the 3 data word
bpos = 0; // not used
bc_bits = 0; // not used

ty_api_rt_err.type = API_ERR_TYPE_DATA_SYNC; /* error injection type */

ty_api_rt_err.sync = sync;
ty_api_rt_err.contig = contig;
ty_api_rt_err.err_spec = 0;

100 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

ty_api_rt_err.err_spec |= (wpos << 16); /* wpos */

ty_api_rt_err.err_spec |= (bpos << 8); /* bpos */
ty_api_rt_err.err_spec |= (bc_bits << 0); /* bc_bits */

ApiCmdRTSAConErr( ApiModuleHandle, 0, 1/*RT*/, 2/*SA*/, rt_hid/*HID*/,

API_RT_TYPE_TRANSMIT_SA, &ty_api_rt_err);

4.3.3.2 RT Transfer Error Emulation via Status Word Response

The Status word sent by an RT upon receipt of a BC Command/Data word can be manipulated
to indicate that the RT is Busy or that it detected a Message Error. If either of these bits (See
Figure 4.3.2-2, Status Word Bits) is set by the user, the RT SA/Mode code will only respond
with the Status word, and not the requested data transmission/receipt. This can be
accomplished using one of the following two methods:

a. When initializing the RT using the ApiCmdRTIni function, the Next RT

Status word parameter can be initialized with either of the bits set. However,
this will cause the bit(s) to be set for Subaddresses and Mode code initialized
for that RT. The following example initializes RT1 with the busy bit (4th bit)
set for the Next Status word

// Remote Terminal Initialization of RT1 with the busy bit set in Next Status word
ApiCmdRTIni(ApiModuleHandle,0, 1/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x0808);

b. When setting up the RT Subaddress/Mode code using the ApiCmdRTSACon

function, the Status Word Mask control (smod) and Status Word Mask (swm)
parameters can be setup to raise the Busy or Message Error bits of the Status
word. The following example shows RT1 Transmit SA2 setup such that the it's
Status Word response Message Error bit will be set (11th bit). The Status word
Mask Control (smod) is set to use logical "OR" function as the masking
mechanism.

// RT1 Transmit SA2 initialized with the Message Error bit set in Next Status word

ApiCmdRTSACon( ApiModuleHandle, 0, 1/*RT*/, 2/*SA*/, rt_hid/*HID*/,

API_RT_TYPE_TRANSMIT_SA, API_RT_ENABLE_SA, 0/*rmod*/, API_RT_SWM_OR/*smod*/,
0x0400/*swm*/);

MIL-STD-1553 Programmer's Guide 101

 Section 4 - Programming Using the API Library

4.3.4 RT Interrupt Programming

As introduced in Section 4.1.7, the RT is capable of producing interrupts upon the occurrence
of certain events. Interrupt Handler(s) must be created to process the interrupts which occur
after the RT has been started and an interrupt occurs. Some possible RT Interrupt Handler
applications may include: (1) refilling a transmit buffer at the end of a transfer interrupt, (2)
gathering the data words received in the receive message buffer at the end of the transfer
and/or (3) reporting transfer errors on a transfer error interrupt. The functions required to setup
RT interrupts and interrupt handler execution include the Library Administration and
Initialization functions as defined in section 4.1.7, and the RT function call defined as follows:

a. ApiCmdRTSACon - Setup the RT Subaddress to perform an interrupt on any

of the following conditions:

 Interrupt on End of Transfer

 Interrupt on Transfer Error

Once you have configured the RT(s) to generate an interrupt and you have created an Interrupt
Handler function to handle the interrupt, then start the RT using the ApiCmdRTStart function
to start data flow. If the RT determines that an interrupt has occurred, the RT will initiate a
call to the Interrupt Handler function and provide information about the interrupt as defined in
the ApiInstIntHandler handler definition in the associated Software Library Reference
Manual for Windows Applications.

The following section describes how to setup an RT transfer to create an interrupt.

4.3.4.1 How to Setup the RT Transfer to Cause an Interrupt

As described above, using the ApiCmdRTSACon function, the RT can be setup to interrupt
during a transfer on one of the following conditions as shown in Table 4.3.4.1-I.:

a. Interrupt on End of Transfer

b. Interrupt on Transfer Error

102 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.3.4.1-I Setup for RT Transfers to Generate Interrupts

RT Transfer Definition Parameters

ApiCmdRTSACon End of Transfer Interrupt Transfer Error Interrupt
parameters
Remote Terminal 0 - 31 0 - 31
Subaddress/ 1 - 30 1 - 30
Mode code
Header ID 1 – 511* 1 – 511*
Subaddress Type any any
Subaddress Control API_RT_ENABLE_SA_INT_XFER API_RT_ENABLE_SA_INT_ERR
* Board dependant, see table 3.2.6.1-I

4.3.5 RT Global Configuration

If your application consists of many non-complex RT simulations, you may choose to use the
RT Global Configuration function, ApiCmdRTGlobalCon to perform the setup of your RTs.
This function is a combination of both the ApiCmdRTIni and the ApiCmdRTSACon plus it
allows initialization of the buffers used for RT data transmission.

4.3.6 Tracking RT Receive Data using Track Multiplex Buffers

An RT can be programmed to store 1553 Data message "tracks" received by an RT SA/Mode

code into a Track Multiplex Buffer (accessible by the user-application), thus, providing a
means to analyze specific filtered 1553 data transferred over the MILbus. Tracks are defined
as 1-32 data words of a 1553 Data message. The length of the Track, and the RT SA/Mode
code associated with the Track is specified using the function ApiCmdTrackDefEx. When the
1553 Data message is received at the user-specified RT SA/Mode code, the RT will store the
Track into a Track Multiplex Buffer at the Track Multiplex Buffer Index contained within the
1553 Data message. The Track Multiplex Buffer and location of the Track Multiplex Buffer
Index in the 1553 Data message are also specified using the function ApiCmdTrackDefEx.
Figure 4.3.6-1 provides an example of the Track process.

RT1 SA1 RX RT1 SA1 RX RT1 SA1 RX

Track
Multiplex Data Buffer = 32 words Data Buffer = 32 words Data Buffer = 32 words
Buffer 0 1 7
Index 21 words 21 words ........ 21 words
(at
location Track Track
word 5
bits 13-15)

Track Multiplex
Buffer ID 0
Track
(at Index 0)
Track
(at Index 1)
........

MIL-STD-1553 Programmer's Guide 103

Track
(at Index 7)
 Section 4 - Programming Using the API Library

Figure 4.3.6-1 RT Track Process Example

In Figure 4.3.6-1 Example, RT1 SA1 is receiving is a 1553 Data message with 32 data words.

Using ApiCmdTrackDefEx the user specifies:

a. The RT SA/Mode code in which a "Track" is defined within a received 1553

Data message. In our example, the RT1 SA1 is used (The RT SA/Mode code
must be previously defined using ApiCmdRTSACon.)

b. The ID of the Track Multiplex Buffer (Ex. 0) used to store the multiplexed
tracks (Range is 0 - 31). The Track Multiplex Buffers are shared by the RT and
BC functions.

c. The Track Multiplex Buffer Index location in the 1553 Data Buffer. In this
example, word 5, bits 14-16 were used. This allows a three bit index which
limits the number of Tracks (item (d) below) in the Track Multiplex Buffer to 8.
The Track Multiplex Buffer Index will be located in the first word of the Track.

d. The number of multiplexed tracks (Ex. 8) to be located in the Track Multiplex

Buffer (Range is 1 - 1024). The number of multiplexed tracks allowed depends
on the bit size of the Track Multiplex Buffer Index (item (c) above). In our
example, 3 bits were used for the index, thus allowing 8 tracks in the Track
Mutiplex Buffer.

e. The Track start location (Ex. word 5) and Track Length (Ex. 21). The
Track can start at any word within the 1553 Data Buffer (0-31) and be up to 32
words long. The first word of the track will contain the Track Multiplex Buffer
Index.

f. Number of contiguous Track Buffers (Ex. 1) the number of continuous

Tracks located in the Data buffer. If more than one Track is located in the Data
Buffer, the BC will store the additional Tracks into the Track Multiplex Buffer
at the Track Multiplex Buffer Index specified in each Track.

Using ApiCmdTrackReadEx the entire Track Multiplex Buffer or specific tracks can be read
from a specific Track Multiplex Buffer.

Note: The ApiCmdTrackDefEx and ApiCmdTrackReadEx functions can also be used when the
RT
SA/Mode code is in mailbox mode.

104 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

4.4 BUS MONITOR PROGRAMMING

The bus monitor (BM) listens to all messages on the bus and records selected activities. The
BM is a passive device that collects data for real-time or post capture analysis. The BM can
store all or portions of traffic on the bus, including electrical and protocol errors. BMs are
primarily used for instrumentation and data bus testing.

In monitor mode, the AIM Bus Analyzer module implements a chronological recording of all
MILbus traffic. The monitor data is stored in a cyclic Monitor buffer implemented in the
Global RAM Monitor Memory area on the Bus Analyzer module (size = 0x80000 bytes for
each BIU). The following sections will define the steps required to setup the BM for different
types of data capturing, data triggering, and filter definition using the Buffer and BM functions
as defined in Tables 3.2.5-V, and 3.2.5-VIII respectively. In general, the order in which you
will need to setup your Bus Monitor Configuration is as follows:

a. Initialization (ApiCmdBMIni)

b. Decide which capture mode you would like to use (ApiCmdBMCapMode):

 Standard Data Capture Mode

 Selective Data Capture Mode

 Recording Mode

 Message Filter Recording Mode

 Recording Mode using Queues (ApiCmdQueueIni) is also a BM

Capture mode and does not require the ApiCmdBMCapMode function

c. Define the interrupt mode (ApiCmdBMIntrMode) defining what type of

interrupt, if any, you would like the BM to generate.

d. If triggers are required:

 Define the triggers you want to use to begin the data capture process
(ApiCmdBMTCBIni). Two dynamic triggers are allowed.

 Define the scheme for starting the trigger and stopping the trigger
(ApiCmdBMFTWIni)

1. For dynamic triggers, you may not want to start the data capture
after the first trigger has occurred - you may want to wait until
several layers of the dynamic trigger have occurred before you
start capturing the data. For instance, if you need to find out what
is happening when a command value equals a certain bit pattern,
and a word in the data message equals a certain bit pattern, you

MIL-STD-1553 Programmer's Guide 105

 Section 4 - Programming Using the API Library

may not want to actually start capturing the data until the second
condition is met.

 Arm the Trigger - setup the BM to evaluate the defined Trigger(s)

(ApiCmdBMTIWIni)

e. Determine if you want to exclude any RT Subaddresses or Mode codes from the
data capture (ApiCmdBMFilterIni)

f. After the Data Capture has been performed, you will need to know how to
examine the data recorded.

g. Additional monitor features:

 Monitor 8-bit or 16-bit incrementing values within the Data words

received/transmitted by an RT SA or Modecode for good/bad/stale
status values

Each of the BM Data Capture modes provides the user with various ways to capture the
MILbus traffic, and methods of storing and generating output reports. The Bus Monitor
functions required in your application are based on the Capture mode which best suits your
application. Table 4.4-I provides a summary of the Capture Modes and the output formats that
can be generated based on how the data is stored in the Monitor Buffer.

Table 4.4-II provides a summary of the BM functions required for each of the BM Capture
Modes, whether triggers are applicable and the BM data read functions applicable to each
mode. These modes and applicable functions will be described in the following sections.

Once you have determines the mode which best suits your application, you can refer to the
applicable sub-sections within this section for guidance on programming your application.

106 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.4-I Bus Monitor Modes and Output Format Summary

Capture Usage Structure to Read Output Format Characteristics

Mode Monitor Data
Standard When you want to record typedef struct Each 16-bit word transmitted on the bus is tagged
Data the user-specified bus ty_api_bm_stack_dsp { with the following information:
Capture traffic before and after AiUInt32 entry; 1. Type of word and on what bus received
the Start Trigger Event, } TY_API_BM_STACK_DSP; 2. Time since the last word was received
but also want to know 3. IRIG time tag
which word caused the 4. If error, type of error
Start Trigger Event. 5. Start Trigger Event flag

RT-specific filters still an After obtaining the pointer into the Monitor
option. Buffer using the ApiCmdBMStackpRead
function, the ApiCmdBMStackEntryRead can
be issued to read one entry (32-bits each)
containing the 16-bit word or information about
the word using the ty_api_bm_stack_dsp
structure.

If you want to read more than one entry at a time,

use the ApiReadBlockMemData Buffer
function after you obtain the pointer into the
Monitor Buffer using the
ApiCmdBMStackpRead function

Note: Message Filter Recording Format 3/4 can

be used when in this capture mode to
retrieve multiple msgs.
Selective When you want to Same as Standard Data Capture Same as Standard Data Capture Mode.
Data capture only message Mode.
Capture traffic immediately
following the trigger for
a certain number of
messages.
RT-specific filters are
still an option.
Recording When you need typedef struct Data is recorded in the same format as defined
continuous data ty_api_bm_rec { for Standard and Selective Data Capture Modes.
recording. Mainly used AiUInt8 status;
for replay or post- AiUInt8 padding1; ApiReadRecData function can be issued at the
processing data analysis. AiUInt16 padding2; Half buffer interrupt to copy the Monitor Buffer
AiUInt32 hfi_cnt; data to an application buffer memory area using
RT-specific filters are AiUInt32 saddr; the ty_api_bm_rec structure. This buffer
still an option. AiUInt32 size; can later be used for replay.
} TY_API_BM_REC;
Note: Message Filter Recording Formats 3/4
can be used when in this capture mode
to retrieve multiple msgs.

MIL-STD-1553 Programmer's Guide 107

 Section 4 - Programming Using the API Library

Table 4.4-I Bus Monitor Modes and Output Format Summary (Continued)

Capture Usage Structure to Read Output Format Characteristics

Mode Monitor Data
Recording When you want to typedef struct Recorded data is stored in a manner that
using record the user- ty_api_queue_buf { allows you to read a single 1553 transfer
Queuing specified bus traffic AiUInt8 rt_addr; from the head of the message queue. Each
AiUInt8 sa_mc;
and read one single AiUInt8 sa_type;
transfer stored contains the following
entire transfer at a AiUInt8 word_cnt; information:
time. Triggers are AiUInt8 rbf_trw; 1. Time tag (seconds and microseconds)
applicable in this AiUInt8 padding1; 2. Message error information
mode. AiUInt16 msg_trw ; 3. Command
AiUInt16 4. Status word
RT-specific filters are buffer[32]; 5. Data words.
still an option. AiUInt32 ttag;
} TY_API_QUEUE_BUF;
ApiCmdQueueRead function can be issued
to read one msg from the top of the queue
using the structure ty_api_queue_buf.
The pointer is incremented automatically
such that another ApiCmdQueueRead can
be performed immediately after. A loop to
read each message received would be
necessary to read all messages in the queue.
Message When your application No data structure is used for Recorded data is stored in a manner that
Filter calls for reading reading recorded data in this allows you to read multiple transfers. Each
Recording multiple 1553 mode. recorded message transfer recorded contains
transfers. the following information:
1. IRIG time or (milliseconds &
As an option, you can microseconds)
filter the data recorded 2. Message Error information
based on command 3. Status word value
word values. You can 4. Command word value
filter using up to 40 5. Data words
command word values.
Four available output formats specified
Triggers can be used providing:
to define the start of Format 0 - LS-byte first with milli- and
the read monitor data microseconds
process. Format 1 - MS-byte first with milli- and
microseconds
RT-specific filters are Format 2 - LS-byte first with IRIG time
still an option. Format 3 - Same as Format 2. (To be used
when in Standard Data Capture mode,
Selective Data Capture mode or Recording
mode.)

Data recorded can be obtained based on the

start of a trigger.

108 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.4-II Bus Monitor Modes and Function Summary

Capture BM functions Start Trigger Stop Trigger Read Monitor Data

Mode (minimum needed) Event Event functions
Standard ApiCmdBMIni FTW Start TATC = 0 or ApiCmdBMStackpRead +
Data ApiCmdBMIntrMode Trigger Mask = FTW Stop ApiReadBlockMemData
Capture ApiCmdBMCapMode = 0 Monitor Status Trigger Mask = or
ApiCmdBMTCBIni for Trigger pattern Monitor Status ApiCmdBMStackpRead +
each trigger * Trigger pattern ApiCmdBMStackEntryRead
ApiCmdBMFTWIni *
ApiCmdBMTIWIni * or
ApiCmdBMStart ApiCmdBMReadMsgFltRec
ApiCmdBMHalt (Format 3/4)
Selective ApiCmdBMIni FTW Start Message Capture ApiCmdBMStackpRead +
Data ApiCmdBMIntrMode Trigger Mask = Counter = 0 or ApiReadBlockMemData
Capture ApiCmdBMCapMode = 1 Monitor Status TATC = 0 or or
ApiCmdBMTCBIni for Trigger pattern ApiCmdBMStackpRead +
each trigger ApiCmdBMStackEntryRead
ApiCmdBMFTWIni
ApiCmdBMTIWIni or
ApiCmdBMStart ApiCmdBMReadMsgFltRec
ApiCmdBMHalt (Format 3/4)
Recording ApiCmdBMIni N/A N/A ApiReadRecData
ApiCmdBMIntrMode
ApiCmdBMCapMode = 2 or
ApiCmdBMStart ApiCmdBMReadMsgFltRec
ApiCmdBMHalt (Format 3/4)
Recording ApiCmdBMIni N/A N/A ApiCmdQueueRead
using ApiCmdBMIntrMode
Queuing ApiCmdQueueIni
ApiCmdQueueStart
ApiCmdBMHalt
Message ApiCmdBMIni N/A N/A ApiCmdBMReadMsgFltRec
Filter ApiCmdBMIntrMode or (Formats 0 - 2)
Recording ApiCmdBMCapMode = 3 FTW Start
ApiCmdBMTCBIni for Trigger Mask =
each trigger * Monitor Status
ApiCmdBMFTWIni * Trigger pattern *
ApiCmdBMTIWIni *
ApiCmdBMIniMsgFltRec
ApiCmdBMStart
ApiCmdBMHalt
* Optional

MIL-STD-1553 Programmer's Guide 109

 Section 4 - Programming Using the API Library

The sample programs ls_bc_rt_bm_sample.c and ls_recording_replay_sample.c provide

examples of Bus Monitor setup and control.

4.4.1 Bus Monitor Initialization

Before you begin sending function calls to setup the Bus Monitor, it must first be initialized.
Initialization is performed using the ApiCmdBMIni function. This function will initialize the
Bus Monitor as follows:

a. Enables the capturing of all RT Transmit and Receive Subaddresses and Mode
codes. (This can later be modified using the ApiCmdBMFilterIni function.)

b. Sets the BM Status Word Exception Mask to 0x07FF such that all error/status
bits in the Status word will be evaluated by the Bus Monitor if the user sets up
an Error trigger to trigger on Status word Exception. (This can later be
modified using the ApiCmdBMSWXMIni function.)

c. Disables the Illegal Command/Mode code tagging feature of the Bus Monitor
for all RT Transmit and Receive Subaddresses and Mode codes. (This can later
be modified using the ApiCmdBMIllegalIni function.)

Following is a coding example that initializes the Bus Monitor.

//Initialize the Bus Monitor.

ApiCmdBMIni(ApiModuleHandle,0);

4.4.2 Bus Monitor Capture Mode and Interrupt Mode Definition

The first function calls required to begin the setup of the Bus Monitor function include the
functions to setup the mode of capture/recording, ApiCmdBMCapMode, and to setup the
associated interrupt/strobe output generation scheme ApiCmdBMIntrMode.

a. ApiCmdBMCapMode - This BM function configures the Capture Mode. The

monitor operation provides three types of Data Buffer Capturing Modes.

 Standard Data Capture Mode - data capturing is controlled by the

Start and Stop Trigger events. In this mode, the monitor begins to
store the MILbus traffic in the monitor buffer, immediately after the
monitor has been synchronized on the data stream. (Synchronization
occurs after a received word is detected with a "Command SYNC" and
if the word is preceded by a gap, which is greater than the System
Response Timeout value.) Afterwards, if the first Start Trigger Event
occurs "Data Capture" begins. This means, that the Monitor Start

110 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Trigger Pointer is set to the buffer entry location which released the first
Start Trigger Event and the Trace After Trigger Count is now
decremented for every buffer entry related to the transfer.

When data capturing is active, the monitor fills the Monitor buffer with
the MILbus data until the data capturing is stopped by a Stop Trigger
Event or if the Trace After Trigger Count is expired. In case of the
Stop Trigger Event, the data capturing can be restarted by the next Start
Trigger Event. This Start and Stop Trigger mechanism can be repeated
until the Trace After Trigger Count is expired. If the Trace After Trigger
Count is decremented to zero, the Trigger Control Block processing
facility and the Transfer and Error Counter are still working, but no
further data is stored in the buffer.

 Selective Data Capture Mode - data capturing is controlled by the

Start Trigger events and the Monitor Message Capture Count. This
mode is used for selective data captures such as the following examples:

1. Capture a message only when the value of a specific Data Word

is within specified limits.

2. Capture only faulty transfers (or messages with a certain error

type).

3. Capture only messages with a certain Status Word response.

In this mode, the monitor begins to store the MILbus traffic in the
monitor buffer, immediately after the monitor has been synchronized on
the data stream. But if the Start Trigger Event does not occur during the
recorded transfer, the recorded monitor entries are discarded from the
monitor buffer.

If the Start Trigger Event occurs during the transfer, "Data Capture"
begins and the monitor stores the number of transfers in the buffer, as
defined by the Message Capture Count word and the Trace After
Trigger Count is now decremented for every buffer entry related to the
transfer. When the Message Capture Count is expired, the data
capturing is stopped until the next Start Trigger Event occurs, which
restarts the data capturing for the next transfer sequence.

This data capturing mechanism can be repeated, until the Trace After
Trigger Count is decremented to zero. After the Trace After Trigger
Count is expired, the Trigger Control Block processing facility and the
Transfer and Error Counter are still working, but no further data is
stored in the buffer.

Note: If the data capturing is started (Start Trigger Event) during a transfer,
the whole message will be captured in the monitor.

MIL-STD-1553 Programmer's Guide 111

 Section 4 - Programming Using the API Library

 Recording Mode - the data capturing is continuously active. This

mode is useful for recording large amounts of data which may be used
for replay or post-processing analysis. In this mode, the monitor begins
to store the MILbus traffic in the monitor buffer immediately after the
monitor has been synchronized on the data stream. An interrupt will be
asserted at every half buffer full condition, if enabled. The first Half
Buffer Interrupt is asserted if the buffer is filled by half, relative to the
first entry of the transfer. (At this point the data can be logged to the
host.) In this state of operation, the monitor goes on with continuous
data capturing (except the transfers which are not enabled at the
corresponding Monitor Activity Recording and Message Filtering
descriptors), until the Monitor operation is disabled.

In the Recording Mode, the Transfer and Error Counter are still
working. The Trace After Trigger Count is not processed with this
Capture Mode.

 Message Filter Recording Mode - the data capturing is continuously

active. This mode is similar to the Recording mode with the following
differences:

1. Data recorded is filtered based on up to 255 user-specified

Command word values using the ApiCmdBMIniMsgFltRec
function.

If desire, the data recorded by the BM can be setup to begin upon

a Start Trigger Event.

2. This mode provides for one of four possible user-selectable

formatted Bus Monitor message output formats using the
ApiCmdBMReadMsgFltRec function.

b. ApiCmdBMIntrMode -configures the associated BM interrupt and output

strobe output related to the Bus Monitor. This function is dependent on the
ApiCmdBMCapMode function described above in that some interrupts or
strobes are not applicable to some of the capture modes defined above.

 You can setup the BM to generate an interrupt on one of the following

conditions. Of course, an interrupt handler service routine will need to
be created to handle this interrupt. (See section 4.4.5 for further
information regarding BM Interrupt Handling.)

1. Interrupt when the Monitor Buffer is half full

2. Interrupt on Capture Start (as defined for the Standard

Capture, Selective Capture and Message Filter Recording
modes above)

3. Interrupt on Capture Stop or End of Select Capture

112 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

 You can setup the BM to generate an output strobe signal on the BM

Trigger output pin when one of the same conditions defined above is
met. (See the associated AIM Hardware Manual for pin location).

The following sample code sets up the BM to Standard Capture Mode which will record
MILBus traffic immediately upon synchronization, and start decrementing the Trace after
Trigger counter (set to 100) after the first Start Trigger Event, "Capture Start", occurs. (Which
still needs to be setup with the Trigger Control Block Function, ApiCmdBMTCBIni, defined
in the following section.) The Bus Monitor will stop recording after the Trace After Trigger
counter reaches 0 or a Stop Trigger Event occurs. An interrupt will occur when the Start
Trigger Event occurs.

//Set BM to Standard Capture Mode and define the number of messages to be stored in
//the Monitor Buffer after the Trigger Start Event set to 100

api_bm_cap.cap_mode = API_BM_CAPMODE_ALL;
api_bm_cap.cap_tat = 100; /* trace after trigger counter */
api_bm_cap.cap_mcc = 0;
api_bm_cap.cap_fsize = 0;
ApiCmdBMCapMode(ApiModuleHandle,0,&api_bm_cap);

//Enable interrupt on Capture start, disable strobe output

ApiCmdBMIntrMode(ApiModuleHandle,0,API_BM_MODE_START_EVENT_INT, API_BM_NO_STROBE,0);

4.4.3 Bus Monitor Triggers

If your Capture mode requires a Start Trigger Event or you want to tag the recorded monitor
data where the trigger occurs, you will need to setup at least one trigger. This section will
describe the following:

a. Trigger Definition (using ApiCmdBMTCBIni) - defines the types of triggers

that are available and how to setup a Trigger Control Block (TCB)

b. Starting/Stopping the "Data Capture" Process (using ApiCmdBMFTWIni)

- defines the software functions required to create a Start Trigger Event and a
Stop Trigger Event

c. Arming the Trigger (using ApiCmdBMTIWIni) - defines the functions

required to communicate to the Bus Monitor which triggers to evaluate.

MIL-STD-1553 Programmer's Guide 113

 Section 4 - Programming Using the API Library

4.4.3.1 Bus Monitor Trigger Definition

The Bus Monitor is capable of monitoring bus traffic using up to two dynamic triggers in
parallel to determine the start/stop of data capture. Triggers provide the user with the
capability to monitor bus traffic for the occurrence of a specific error condition (such as parity
error) and/or a discrete external trigger received at the BM Trigger input pin (See the
corresponding Hardware Manual). Dynamic triggers provide the user with the capability to
monitor the bus traffic for a sequence of events. An example of a sequence of events could be:
SEQ1-a word received on the primary bus, SEQ2-the word is a status word, and SEQ3-the
word has bit 8 set.

Each trigger requires that the user first configure a Trigger Control Block (TCB) which
contains information about the conditions of the trigger. All triggers use the function
ApiCmdBMTCBIni to configure their TCB. The user has the capability of pre-defining up to
254 TCBs, then using them as the BM application requires. This section will describe how to
setup a TCB, however, to tell the BM the scheme to be used to start and stop the "Data
Capture" process and which TCBs to evaluate, you will need to issue two additional commands
to the BM as defined in Sections 4.4.3.2 and 4.4.3.3.

Table 4.4.3.1-I contains the list of parameters associated with the TCB. The values for each
parameter are dependent upon the Type of Trigger you are setting up. The following sections
will discuss the parameter setup for different Triggers.

As shown in Table 4.4.3.1-I, there are 4 parameters that apply to all two types of triggers.
These parameters will be described in this section as follows:

a. Generate External Strobe on Trigger - when set, if this TCB is active as one
of the two possible Triggers, and the condition specified in the TCB is met, the
BM will output a strobe signal on the external BM Trigger output pin.

b. Generate Interrupt on Trigger - when set, if this TCB is active as one of the
two possible Triggers, and the condition specified in the TCB is met, the BM
will generate a TCB Interrupt and pass the TCB number to the BM Interrupt
Handler Routine (user program)

c. Trigger Reset - This parameter tells the BM what bits to reset in the Monitor
Status Word if the trigger condition is met. See Section 4.4.3.2 for a more
detailed description of the Trigger Start/Stop processing performed by the BM.

d. Trigger Set - This parameter tells the BM what bits to set in the Monitor
Status Word if the trigger condition is met. See Section 4.4.3.2 for a more
detailed description of the Trigger Start/Stop processing performed by the BM.

114 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.4.3.1-I Trigger Control Block Structure

Trigger Control Block Parameter Definitions

Structure Parameter Description Type of Trigger it Applies to
api_bm_tcb.tt Trigger Type - Trigger on: All
0 - Error Condition
1 - External Event
2 - Received Word
3 - Data Value
api_bm_tcb.sot Generate External Strobe on All
Trigger
api_bm_tcb.tri Generate Interrupt on All
Trigger
api_bm_tcb.inv Invert Result of Limit Check Data Value Trigger only
api_bm_tcb.tres Trigger Reset - the bits in All
the Monitor Status Trigger
pattern to be reset when the
trigger condition is met
api_bm_tcb.tset Trigger Set - the bits in All
the Monitor Status Trigger
pattern to be set when the
trigger condition is met
api_bm_tcb.tsp Trigger Specification - Data Value Trigger & Received Word
Trigger
api_bm_tcb.next Next Trigger Control Block Data Value Trigger & Dynamic Word
Trigger
api_bm_tcb.eom Next Trigger Control Block Data Value Trigger & Received Word
on End of Message Trigger
api_bm_tcb.tdw Trigger Data word Error Condition Trigger &
Received Word Trigger
api_bm_tcb.tmw Trigger Mask - defines bits Data Value Trigger & Received Word
of word relevant to Received Trigger
word or Data value trigger
api_bm_tcb.tuli Trigger Upper Limit - for Data Value Trigger
range checks of Data Value
Triggers
api_bm_tcb.tlli Trigger Lower Limit - for Data Value Trigger
range checks of Data Value
Triggers

4.4.3.1.1 Bus Monitor Static Trigger Definition

A Static Trigger is configured using the ApiCmdBMTCBIni function. A static trigger is a

dynamic trigger sequence with only one trigger:

a. Trigger on Error Condition

b. Trigger on External Event (strobe or pulse) detected on the BM input Trigger

pin.

The following two sections describe the parameters in the Trigger Control Block that are
associated with these triggers.

4.4.3.1.1.1 Trigger on Error Condition

You can setup the BM to trigger on any one or more error conditions. If you specify more than
one error condition for the Trigger Control Block, the trigger will be considered valid if any

MIL-STD-1553 Programmer's Guide 115

 Section 4 - Programming Using the API Library

one of the error conditions is detected. The types of errors that can be setup to cause a Trigger
Start/Stop Event in the Bus Monitor are shown in Table 4.4.3.1.1.1-I.

Table 4.4.3.1.1.1-I Error Conditions for Triggering the Bus Monitor

Parameter Bit Error Description

Bit ID #
ERR 15 Any Error (Logical OR of Bits 14 to 0).
ALTER 14 Alternate Bus Response Error
LCNT 13 Low Word count Error
HCNT 12 High Word count Error
STAT 11 Status Word Exception Error*
TADDR 10 Terminal Address Error / RT-RT Protocol Error
GAP 9 Early Response or Gap too short
ILLEGL 8 Illegal Command Word/ Reserved Mode Code Error
TX 7 Transmission on both MILbus channels
IWGAP 6 Interword Gap Error
ISYNC 5 Inverted Sync Error
PAR 4 Parity Error
LBIT 3 Low Bit Count Error
HBIT 2 High Bit Count Error
MANCH 1 Manchester Coding Error
NRESP 0 Terminal No Response Error
*Note: The default Status word Exception mask is set to 0x07ff with the
ApiCmdBMIni function (all status bits are checked). If you want
the BM to trigger on only a subset of bits in the Status word, you
must setup the Status Word Exception Mask using the BM function
ApiCmdBMSWXMIni accordingly.

The subset of parameters in the Trigger Control Block Structure that define an Error Trigger
include the parameters shown in Table 4.4.3.1.1.1-II

116 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.4.3.1.1.1-II TCB Parameters for Error Condition Trigger

Trigger Control Block Parameter Definitions Applicable to Error Condition Trigger

api_bm_tcb.tt Trigger Type - Trigger on: 0
0 - Error Condition
1 - External Event
2 - Received Word
3 - Data Value
api_bm_tcb.sot Generate External Strobe on If desired
Trigger
api_bm_tcb.tri Generate Interrupt on If desired
Trigger
api_bm_tcb.tres Trigger Reset - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be reset when the
trigger condition is met
api_bm_tcb.tset Trigger Set - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be set when the
trigger condition is met
api_bm_tcb.tdw Trigger Data word Set the appropriate bit(s) in this
word for one or more of the error
conditions as defined in Table
4.4.3.1.1-I to trigger on

The following code sample sets up a Static Trigger Control Block with an Error Condition
trigger to trigger on a Parity error and a Low Word Count error. When the trigger condition is
met, the BM will not reset any bits in the Monitor Status Trigger pattern, but will set bits 0x0F
in the Monitor Status Trigger pattern. (The parameters applicable to this type of trigger are
bolded.)

// Setup Static Trigger - Error Condition

// init TCB 3 for Trigger on Parity error and a Low Word Count error
api_bm_tcb.tt = API_BM_TRG_ERR_CONDITION; // Trigger Type
api_bm_tcb.sot = API_DIS; // External Trigger
api_bm_tcb.tri = API_DIS; // Interrupt on Trigger
api_bm_tcb.inv = API_DIS; // Inversion of Limit
Check
api_bm_tcb.tres = 0x00; // Monitor Status Trigger pattern Reset Bits
api_bm_tcb.tset = 0x0F; // Monitor Status Trigger pattern Set Bits
api_bm_tcb.tsp = 0x00; // Trigger spec
api_bm_tcb.next = 0xFF; // next TCB (disabled for Static trigger)
api_bm_tcb.eom = 0xFF; // next TCB End of Message control
(disabled)
api_bm_tcb.tdw = 0x2010; // Trigger Data Word - indicating check for parity
and
// low word count
api_bm_tcb.tmw = 0xFFFF; // Trigger mask word
api_bm_tcb.tuli = 0x0000; // Trigger upper limit
api_bm_tcb.tlli = 0x0000; // Trigger lower limit

ApiCmdBMTCBIni(ApiModuleHandle, 0, 3 /*tid*/, API_ENA, &api_bm_tcb);

MIL-STD-1553 Programmer's Guide 117

 Section 4 - Programming Using the API Library

4.4.3.1.1.2 Trigger on External Event Condition

The External Event Condition Static Trigger will trigger on an external strobe or pulse detected
on the BM input Trigger pin. This type of Static Trigger is the least complex to setup. The
subset of parameters in the Trigger Control Block Structure that define an External Event
Trigger include the parameters shown in Table 4.4.3.1.1.2-I

Table 4.4.3.1.1.2-I TCB Parameters for External Event Trigger

Trigger Control Block Parameter Definitions

api_bm_tcb.tt Trigger Type - Trigger on: 1
0 - Error Condition
1 - External Event
2 - Received Word
3 - Data Value
api_bm_tcb.sot Generate External Strobe on If desired
Trigger
api_bm_tcb.tri Generate Interrupt on If desired
Trigger
api_bm_tcb.tres Trigger Reset - the bits in See Section 4.4.4 for description
the Monitor Status Trigger on how to setup
pattern to be reset when the
trigger condition is met
api_bm_tcb.tset Trigger Set - the bits in See Section 4.4.4 for description
the Monitor Status Trigger on how to setup
pattern be set when the
trigger condition is met

The following code sample sets up a Static Trigger Control Block with an External Event
trigger. When the trigger condition is met, the BM will not reset any bits in the Monitor Status
Trigger pattern, but will set bits 0x0F in the Monitor Status Trigger pattern. (The parameters
applicable to this type of trigger are bolded.)

// Setup Static Trigger - External Event - External strobe or pulse detected on the
BM // input Trigger pin

// init TCB 4
api_bm_tcb.tt = API_BM_TRG_EXTERNAL_EVENT; // Trigger Type
api_bm_tcb.sot = API_DIS; // External Trigger
api_bm_tcb.tri = API_DIS; // Interrupt on Trigger
api_bm_tcb.inv = API_DIS; // Inversion of Limit
Check
api_bm_tcb.tres = 0x00; // Monitor Status Trigger pattern Reset
Bits
api_bm_tcb.tset = 0x0F; // Monitor Status Trigger pattern Set Bits
api_bm_tcb.tsp = 0x00; // Trigger spec
api_bm_tcb.next = 0xFF; // next TCB (disabled for Static trigger)
api_bm_tcb.eom = 0xFF; // next TCB End of Message control
(disabled)
api_bm_tcb.tdw = 0xFFFF; // Trigger data word
api_bm_tcb.tmw = 0xFFFF; // Trigger mask word
api_bm_tcb.tuli = 0x0000; // Trigger upper limit
api_bm_tcb.tlli = 0x0000; // Trigger lower limit

ApiCmdBMTCBIni(ApiModuleHandle, 0, 4 /*tid*/, API_ENA, &api_bm_tcb);

118 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

4.4.3.1.2 Bus Monitor Dynamic Trigger Definition

A Dynamic Trigger is a sequence of triggers focusing containing more than one trigger. A
Dynamic Trigger is also configured using the ApiCmdBMTCBIni function. Two Dynamic
triggers can be active at one time. In addition to the already defined error trigger and external
event trigger this chapter will introduce:

a. Trigger on Received word

b. Trigger on Data Value.

If your Dynamic Trigger involves more than one trigger condition, then multiple TCBs will
need to be defined for the dynamic trigger and linked together using the Next TCB parameter
in the TCB. The first trigger in the sequence will reference the TCB of the next trigger to
evaluate when the first trigger condition is met, and so on. Following is a High Level
Language example of a Dynamic Sequence Trigger using pre-defined TCBs (1 - 4):
Dynamic Sequence Trigger (T0)
IF TCB1 [Received word = Command Word = Data value]
THEN
Set Bit 0 of the Monitor Status Trigger pattern
Evaluate TCB2 (Next TCB)
ELSE ReARM TCB1 (EOM TCB)

IF TCB2 [Data Word 3 is in range (100-1000)]

THEN
Set Bit 1 of the Monitor Status Trigger pattern
Evaluate TCB3 (Next TCB)
ELSE Return to TCB1 Evaluation (EOM TCB)

IF TCB3 [Received word = Command Word = Data Value]

THEN
Set Bit 2 of the Monitor Status Trigger pattern
Evaluate TCB4 (Next TCB)
ELSE Return to TCB1 Evaluation (EOM TCB)

IF TB4 [Data Word 6 Bit 5 AND Bit 8 Set]

THEN
Set Bit 3 of the Monitor Status Trigger pattern
Evalute TCBxx (Next Index, ARM TBxx)
ELSE Return to TCB3 Evaluation (EOM Index)

The following two sections describe the parameters in the Trigger Control Block that are
associated with these triggers.

4.4.3.1.2.1 Trigger on Received Word

The Trigger on Received word enables the user to setup the Bus Monitor to search for a
Command word (1 or 2), Status word or Data word on the Primary or Secondary Bus with a
specified value. The bits defined for setup in the Trigger Specification (tsp) include the
Received words as defined in Table 4.4.3.1.2.1-I:

Table 4.4.3.1.2.1-I Received Words Triggering the Bus Monitor

MIL-STD-1553 Programmer's Guide 119

 Section 4 - Programming Using the API Library

Parameter Bit Received Word Description

Bit ID #
RXA 5 Word received on Primary Bus
RXB 4 Word received on Secondary Bus
&
CW2 3 Word is second Command Word for RT-RT transfer
ST 2 Word is Status Word
DW 1 Word is Data Word
CW 0 Word is Command Word

The subset of parameters in the Trigger Control Block Structure that define a Trigger on
Received word include the parameters shown in Table 4.4.3.1.2.1-II

The trigger condition is valid, if the following expression becomes valid:

[(The word is received on the Primary or Secondary Bus) AND (The word is Command word
2 OR Status word OR Data word OR Command word) AND ( Compare Value Check ==
True)]

120 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Table 4.4.3.1.2.1-II TCB Parameters for Dynamic Received Word Trigger

Trigger Control Block Parameter Definitions Applicable to Received Word Trigger

api_bm_tcb.tt Trigger Type - Trigger on: 3
0 - Error Condition
1 - External Event
2 - Received Word
3 - Data Value
api_bm_tcb.sot Generate External Strobe on If desired
Trigger
api_bm_tcb.tri Generate Interrupt on If desired
Trigger
api_bm_tcb.tres Trigger Reset - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be reset when the
trigger condition is met
api_bm_tcb.tset Trigger Set - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be set when the
trigger condition is met
api_bm_tcb.tsp Trigger Specification - Set the appropriate bit(s) in this
word the Received word conditions
as defined in Table 4.4.3.2.1-I to
trigger on
api_bm_tcb.next Next Trigger Control Block Next TCB to evaluate after this
trigger condition is met. (A value
of 0xFF indicates the same TCB will
be evaluated next.)
api_bm_tcb.eom Next Trigger Control Block Next TCB to evaluate if this
on End of Message trigger control block condition is
not met for this transfer. (A value
of 0xFF indicates the same TCB will
be evaluated next.)
api_bm_tcb.tdw Trigger Data word The value of the received word the
BM is setup to trigger on
api_bm_tcb.tmw Trigger Mask - defines bits Set the bits of this word to show
of word relevant to Received the bits of the received word that
word or Data value trigger are relevent to the word compare

The following code sample sets up a Dynamic Trigger Control Block (TCB 5) with an
Received Word Condition trigger to trigger on reception of a Command word received on the
Primary or Secondary Bus for RT1 Transmit SA1 with a 32 data word count. When the trigger
condition is met, the BM will not reset any bits in the Monitor Status Trigger pattern, but will
set bits 0x01 in the Monitor Status Trigger pattern. The BM will then begin to evaluate TCB 6
for the next word received by the BM which is indicated when you set the Next TCB (next)
to 0xFF. If the Trigger condition is not fully met by the end of the transfer, the BM will
continue to monitor TCB 5 which is indicated when you set the EOM TCB (eom) to 0xFF.
(The parameters applicable to this type of trigger are bolded.)

MIL-STD-1553 Programmer's Guide 121

 Section 4 - Programming Using the API Library

// Setup Dynamic Trigger - Received Word - Command word received on primary or

// secondary bus for RT1 SA1 with a 32-word data
count

// init TCB 5 for Trigger on Command from RT1 Transmit SA1 with Data word count = 32
api_bm_tcb.tt = API_BM_TRG_RECEIVED_WORD; // Trigger Type
api_bm_tcb.sot = API_DIS; // External Trigger
api_bm_tcb.tri = API_DIS; // Interrupt on Trigger
api_bm_tcb.inv = API_DIS; // Inversion of Limit
Check
api_bm_tcb.tres = 0x00; // Monitor Status Trigger pattern Reset Bits
api_bm_tcb.tset = 0x01; // Monitor Status Trigger pattern Set Bits
api_bm_tcb.tsp = 0x31; // Trigger spec bits set for Pri or Sec Bus & CW
api_bm_tcb.next = 0x06; // next TCB
api_bm_tcb.eom = 0xFF; // next TCB End of Message control
api_bm_tcb.tdw = 0x0C20; // Cmd = RT1TSA1 with word count = 32
api_bm_tcb.tmw = 0xFFFF; // Trigger mask word - all bits applicable
api_bm_tcb.tuli = 0x0000; // Trigger upper limit
api_bm_tcb.tlli = 0x0000; // Trigger lower limit

ApiCmdBMTCBIni(ApiModuleHandle, 0, 5 /*tid*/, API_ENA, &api_bm_tcb);

4.4.3.1.2.2 Trigger on Data Value Condition

The Trigger on Data Value Trigger enables the user to setup the Bus Monitor to evaluate a
specific Data value in a word position value 1 to 32 which corresponds directly with Data
Word Location 1 to 32 of a MILbus transfer. This type of Dynamic Trigger is best used in
conjunction with a Received Word Trigger defined in the previous section in order to provide a
filtering of the transfer message prior to data word evaluation. The subset of parameters in the
Trigger Control Block Structure that define a Dynamic Data Value Trigger include the
parameters shown in Table 4.4.3.1.2.2-I

The received MILbus Word is masked (bitwise logical AND) with the Trigger Mask word
(tmw). The result is compared with the Upper limit (tuli) and Lower limit (tlli). Proper
setting of these values allow masking for certain bit fields as well as for dedicated values.

The trigger condition is valid, if the following expression becomes valid:

[(Received Bus Word AND Trigger Mask word) >= Lower limit ] AND [(Received Bus
Word AND Trigger Mask word) <= Upper limit ]

Note: If the Inversion of Limit Check (inv) is enabled the result of the Masked Word Limit
Check is inverted to get the result of an "Out of Limit" check.

Table 4.4.3.1.2.2-I TCB Parameters for Dynamic Data Value Trigger

122 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Trigger Control Block Parameter Definitions Applicable to Data Value Trigger

api_bm_tcb.tt Trigger Type - Trigger on: 3
0 - Error Condition
1 - External Event
2 - Received Word
3 - Data Value
api_bm_tcb.sot Generate External Strobe on If desired
Trigger
api_bm_tcb.tri Generate Interrupt on If desired
Trigger
api_bm_tcb.inv Invert Result of Limit Check If required
api_bm_tcb.tres Trigger Reset - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be reset when the
trigger condition is met
api_bm_tcb.tset Trigger Set - the bits in See Section 4.4.3.2 for description
the Monitor Status Trigger on how to setup
pattern to be set when the
trigger condition is met
api_bm_tcb.tsp Trigger Specification - Position of the Data word to
evaluate (1-32)
api_bm_tcb.next Next Trigger Control Block TCB to evaluate after this trigger
condition is met. (A value of 0xFF
indicates the same TCB will be
evaluated next.)
api_bm_tcb.eom Next Trigger Control Block TCB to evaluate if this trigger
on End of Message control block condition is not met
for this transfer. (A value of 0xFF
indicates the same TCB will be
evaluated next.)
api_bm_tcb.tdw Trigger Data word The value of the data word the BM
is setup to compare to
api_bm_tcb.tmw Trigger Mask - defines bits Set the bits of this word to show
of word relevant to Received the bits of the data word that are
word or Data value trigger relevent to the word compare
api_bm_tcb.tuli Trigger Upper Limit - for Upper limit of the data value to
range checks of Data Value check
Triggers
api_bm_tcb.tlli Trigger Lower Limit - for Lower limit of the data value to
range checks of Data Value check
Triggers

The following code sample sets up a Dynamic Trigger Control Block (TCB 6) with a Data
Value Condition trigger to trigger on reception of a 4th Data word equal to 0x0033. It is
designed to be used in sequence with the TCB 5 which was setup in the previous section If
the BM determines that the 4th word does equal 0x0033, the BM will not reset any bits in the
Monitor Status Trigger pattern, but will set bits 0x0E in the Monitor Status Trigger pattern. It
will then be re-armed with TCB5 which is indicated when you set the Next TCB (next) to
0x05. If the 4th word does not equal 0x0033, no action is taken with the Monitor Stats
Trigger word bits and the BM will be re-armed using TCB 5 which is indicated when you set
the EOM TCB (eom) to 0x05. (The parameters applicable to this type of trigger are bolded.)

MIL-STD-1553 Programmer's Guide 123

 Section 4 - Programming Using the API Library

// Setup Dynamic Trigger - Data Value - 4th Data word equal to 0x0033.

// init TCB 6 for Trigger on Command from RT1 Transmit SA1 with Data word count = 32
api_bm_tcb.tt = API_BM_TRG_DATA_VALUE; // Trigger Type
api_bm_tcb.sot = API_DIS; // External Trigger
api_bm_tcb.tri = API_DIS; // Interrupt on Trigger
api_bm_tcb.inv = API_DIS; // Inversion of Limit
Check
api_bm_tcb.tres = 0x00; // Monitor Status Trigger pattern Reset Bits
api_bm_tcb.tset = 0x0E; // Monitor Status Trigger pattern Set Bits
api_bm_tcb.tsp = 0x04; // Check the 4th Data word for value in .tdw
api_bm_tcb.next = 0x05; // next TCB
api_bm_tcb.eom = 0x05; // next TCB End of Message control
api_bm_tcb.tdw = 0x0033; // Compare value = 0x0033
api_bm_tcb.tmw = 0xFFFF; // Trigger mask word - all bits applicable
api_bm_tcb.tuli = 0xFFFF; // Trigger upper limit
api_bm_tcb.tlli = 0x0000; // Trigger lower limit

ApiCmdBMTCBIni(ApiModuleHandle, 0, 6 /*tid*/, API_ENA, &api_bm_tcb);

4.4.3.2 Starting/Stopping the "Data Capture" Process

Each user-defined Trigger Control Block contains two parameters associated with starting or
stopping the "Data Capture" process. These two parameters include:

a. Trigger Set Bits - define the Trigger bits in the Monitor Status Word to set

b. Trigger Reset Bits - define the Trigger bits in the Monitor Status Word to reset

Each time a TCB condition is met, the Bus Monitor will set/reset the Trigger bits (8 bits) of the
Monitor Status Word (internal to the Bus Monitor) as the user specifies in the TCB
parameters: Trigger Set Bits (tset) and Trigger Reset Bits (tres). (The 8 Trigger bits of the
Monitor Status Word are referred to as the Monitor Status Trigger pattern.) This provides
the user with the capability to "build" a "Data Capture" Start Trigger Event or to cause a Stop
Trigger Event. Thus, providing the user with the capability to create an infinite number of
scenarios to start or stop the "Data Capture" process.

In order for this capability to work, the user must specify the final bit value that the Bus
Monitor will associate as the Start Trigger Event and/or the Stop Trigger Event. This bit
value is defined within the Function Trigger Word using the ApiCmdBMFTWIni function.
As shown in Figure 4.4.3.2-1, the Function Trigger Word defines the bit patterns used to
create a Start Trigger Event and a Stop Trigger Event. The BIU Processor uses the
Function Trigger Word and the Monitor Status Trigger pattern to determine the start and
stop of the "Data Capture".

124 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Figure 4.4.3.2-1 Bus Monitor Function Trigger Word

Function Trigger Word
31 .......................... 24 23 .......................... 16 15 ........................... 8 7 ............................. 0
Stop Trigger Mask or Stop Trigger Compare Start Trigger Mask Start Trigger Compare
Reserved or
Reserved.

The Start Trigger Event condition is met if the state of the Monitor Status Trigger pattern
masked (logical "AND") with the Start Trigger Mask is equal to the Start Trigger Compare
pattern.

The Stop Trigger Event condition is met if the state of the Monitor Status Trigger pattern
masked (logical "AND") with the Stop Trigger Mask is equal to the Stop Trigger Compare
pattern.

Note: The Stop Trigger Mask and Compare field are only used during Standard Data
Capture Mode

This feature is most useful for Dynamic triggers containing more than one sequence of TCBs
or a combination of a single trigger and Dynamic Triggers. For instance, you may not want the
"Data Capture" to start when the first TCB condition is met. You may want the "Data
Capture" Start Trigger Event to occur after two or more TCB conditions have been met. In
addition, you may want the Stop Trigger Event condition to occur with the last TCB or upon
the occurrence of a trigger such as an external pulse or error condition.

There may be some cases where you would require the use of the Stop Trigger Event, but in
most cases, you would most likely use the Trace After Trigger Counter (TATC) to stop the
bus monitor processing. Table 4.4.3.2-I shows some examples of how you would set the
"tset" bits in the TCB and the Function Trigger Word, to create a Start Trigger Event and
a Stop Trigger Event and how the Capture Mode relates to the entire Bus Monitor process.

Table 4.4.3.2-I Bus Monitor Capture Scenarios

Function Trigger Word
"tset" parameter

"tset" parameter

Trigger Counter

Capture Count
Start Trigger

Start Trigger

Stop Trigger

Stop Trigger
Trace After
in last TCB
in 1st TCB
definition

definition

Message

Compare

Compare
(TATC)

Mask

Mask

Capture
Scenario Data Capture Start Data Capture Stop Mode
Capture 1000 entries upon the
occurance of an External Pulse. 0x0F N/A Start Trigger Event TATC = 0 Standard 1000 N/A 0x0F 0x0F 0x00 0xFF
Capture 1000 entries upon the
occurance of an Error Condition. 0x0F N/A Start Trigger Event TATC = 0 Standard 1000 N/A 0x0F 0x0F 0x00 0xFF

Capture only the first 10 messages after

the occurance of an Error Condition. 0x0F N/A Start Trigger Event TATC = 0 Selective 1000 10 0x0F 0x0F 0x00 0xFF
Capture 1000 entries after the last TCB
condition in the Dynamic Sequence of 4
TCBs is met. 0x00 0x0F Start Trigger Event TATC = 0 Standard 1000 N/A 0x0F 0x0F 0x00 0xFF
Capture all entries between the
occurance of the first TCB and the last
TCB in a dynamic sequence of 10 Stop Trigger Event or
TCBs. 0x0F 0xFF Start Trigger Event TATC = 0 Standard 100000 N/A 0x0F 0x0F 0xFF 0xFF
Capture all entries on the bus
continuously after the occurance of a
command to RT1. 0x0F N/A Start Trigger Event N/A Recording 0 N/A 0x0F 0x0F 0x00 0xFF

MIL-STD-1553 Programmer's Guide 125

 Section 4 - Programming Using the API Library

In the previous section (Section 4.4.3.1), we have example code for an External Event trigger
(TCB 4), and an Error Condition trigger (TCB3). There are also two TCBs (TCB 5 and 6)
which are linked together to form one Dynamic Sequence Trigger. The first two TCBs are
defined with parameters "tset" = 0x0F. The Dynamic TCBs set the "tset" sequentially
(TCB5 sets "tset" = 0x01, TCB6 sets "tset" = "0x0E") such that when both conditions are
met the Monitor Status Trigger pattern equals 0x0F. In each trigger condition, the final
trigger pattern to create a Start Event Trigger is 0x0F, therefore, the following code shows
how to configure the Function Trigger Word in the BM to start "Data Capture" when the
Monitor Status Trigger pattern equals 0x0F:

// Set the Function Trigger Word with Mask and compare Values the Stop Trigger Mask
and Compare is not used in this example.

ApiCmdBMFTWIni(ApiModuleHandle, 0, API_BM_WRITE_ALL, 0x00 /*Stop Trigger Mask*/,

0xFF /*Stop Trigger Compare*/, 0x0F /*Start Trigger Mask*/, 0x0F /*Start Trigger
Compare*/);

4.4.3.3 Arming the Trigger

As stated earlier in this section, the Bus Monitor is capable of monitoring bus traffic using up
to two trigger sequences in parallel. To enable the Bus Monitor to evaluate the Trigger(s) you
have defined in your Trigger Control Blocks, you must setup the Trigger Index Word using
the ApiCmdBMTIWIni function.

Issuing the ApiCmdBMTIWIni function command tells the BM which TCB(s) to evaluate for
each the two triggers allowed to be evaluated simultaneously.

a. Dynamic Trigger sequences

 Sequence 0 - the start of the first trigger sequence

 Sequence 1 - the start of the second trigger sequence

The BM Trigger Index Word which is setup for the BM when this command is issued is
shown in Figure 4.4.3.3-1.

126 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Figure 4.4.3.3-1 Bus Monitor Trigger Index Word

Trigger Index Word
31 .......................... 24 23 ......................... 16 15 .......................... 8 7 ............................. 0
reserved reserved Sequence Trigger 1 Sequence Trigger 0
TCB Index TCB Index

In the previous section (Section 4.4.3.1), we have example code for an single External Event
trigger (TCB 4), an single Error Condition Trigger (TCB3). In addition, two TCBs (TCB 5
and 6) are linked together to form one Dynamic Sequence Trigger. If we want to enable the
BM to evaluate two of these TCBs simultaneously we should issue the ApiCmdBMTIWIni
function as follows:

// Set the Trigger Index Word with the indexes of the TCBs
ApiCmdBMTIWIni(ApiModuleHandle, 0, API_BM_WRITE_ALL,
0 /*reserved*/,
0 /*reserved*/,
3 /*sequence 0 TCB single error trigger */,
5 /*sequence 1 TCB dynamic trigger sequence */);

4.4.4 Bus Monitor Interrupts

As introduced in Section 4.1.7, the BM is capable of producing interrupts upon the occurrence
of certain events. Interrupt Handler(s) must be created to process the interrupts which occur
after the BM has been started and an interrupt occurs. (Polling the interrupt status is also a
method of handling interrupts.) Some possible BM Interrupt Handler applications may
include: (1) extracting Monitored Data for evaluation or display, (2) archiving Monitored Data
and/or (3) searching for error conditions tagged by the BM in the Monitored Data. The
functions required to setup BM interrupts and interrupt handler execution include the Library
Administration and Initialization functions as defined in section 4.1.7, and one or more of the
BM function calls (as your application requires) defined as follows:

a. Setup the BM to perform an interrupt on any of the following conditions (See

Table 4.4.5-I) using the associated function to perform the setup:

 ApiCmdBMIntrMode - this function is described in section 4.4.2

1. Monitor Buffer Full or Half Buffer Full

2. Interrupt on Capture Start

3. Interrupt on Capture Stop or End of Selective Capture Event

MIL-STD-1553 Programmer's Guide 127

 Section 4 - Programming Using the API Library

 ApiCmdBMTCBIni - this function is described in Section 4.4.3. The

parameter in the Trigger Control Block structure (Table 4.4.3.1-I) which
can be enabled to configure the trigger to generate an interrupt is
api_bm_tcb.tri. An interrupt can be generated for all four types of
triggers.

1. Interrupts if the trigger condition becomes true

Table 4.4.4-I BM Interrupts Relative to Capture Mode

Buffer Full /
Capture Start

Capture Stop

Half Full

Trigger
Mode
Standard Data Capture X X X X
Selective Data Capture X X X X
Recording X
Recording with Queues X
Message Filter Recording X X
Note: To enable Half Buffer Full Interrupt for Standard and
Selective Data Capture modes, the Trace After
Trigger Counter must equal 0)

Once you have configured the BM to generate an interrupt and you have created an Interrupt
Handler function to handle the interrupt, then start the BM using the ApiCmdBMStart
function (or, if using Queues, use the ApiCmdQueueStart function) to start data flow. If the
BM determines that an interrupt has occurred, the BM will initiate a call to the Interrupt
Handler function and provide information about the interrupt as defined in the
ApiInstIntHandler handler definition in the Software Library Reference Manual for PCI
1553 Windows Applications.

The sample program, ls_interrupt_sample.c provides an example of BC Interrupt Handling

programming.

128 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

4.4.5 Format of Data Stored in the Monitor Buffer

The Monitor stores all received words from the bus together with Time Tag information and
possible error entries, as 32 bit entries in the cyclic monitor buffer. The monitor buffer is
located in the Global RAM Monitor Memory area on the Bus Analyzer module (size =
0x80000 for each BIU).

The Monitor stores the received MILbus words and additional tags as a Monitor Bus Word
Entry as shown in Figure 4.4.5-1. Figures 4.4.5-2 through 4.4.5-5 show the possible values for
the Entry.
Figure 4.4.5-1 Monitor Bus Word Entry
Monitor Bus Word Entry
31 ....... 28 27 26 ............................................................................................................... 0
EntryType ECON Entry - Dependent on the EntryType:
1. Bus Word Entry
2. Time Tag Low Entry
3. Time Tag High Entry
4. Error Word Entry
Where:
Entry Entry Definition General Type
Type: Type
0h: Entry not Updated (Initialization status)
1h: Error Word. (Error Word Entry)
2h: Time Tag Low Word. (Time Tag Entry)
3h: Time Tag High Word. (Time Tag Entry)
4h – 7h: Reserved.
8h: Command Word on Primary Bus. (Bus Word Entry)
9h: Command Word 2 on Primary Bus. (Bus Word Entry)
Ah: Data Word on Primary Bus. (Bus Word Entry)
Bh: Status Word on Primary Bus. (Bus Word Entry)
Ch: Command Word on Secondary Bus. (Bus Word Entry)
Dh: Command Word 2 on Secondary Bus. (Bus Word Entry)
Eh: Data Word on Secondary Bus. (Bus Word Entry)
Fh: Status Word on Secondary Bus. (Bus Word Entry)
ECON: Entry Connection flag. - Set to one if an additional entry follows which is
logically connected to this entry. This bit is always set, if during a single word
receive operation more than one entry is written to the buffer. For example,
this can happen if the first command word of a transfer is received and the Time
tag information is additionally stored in the buffer. Also, it can happen if an
erroneous word is received and an the error entry is written to the buffer.
Entry: Figures 4.4.5-2 through 4.4.5-5 show the possible values for the Entry.

MIL-STD-1553 Programmer's Guide 129

 Section 4 - Programming Using the API Library

Figure 4.4.5-2 Bus Word Entry

Bus Word Entry (Entry Type 8h to Fh)
26 25 24 ................................ 16 15 ............................................................................... 0
Start Res. Gap Time Bus Word

Where:
Start: Start Trigger Flag - If Start Trigger flag is set, the Bus Word Entry is related
to the start trigger event which starts capturing of MILbus traffic
Gap Gap Time Value - The Gap Time value reports the time between the current
Time: and the previous received MILbus Words, in 0.25µs steps. If the words are
received continuously, the reported gap time will be 2µs, according to the
"MIL-STD1553 Gap time Measurement Definition". The range of the gap time
values is 2µs to 109.75µs. If the reported gap time value is zero, the gap time
was greater than 109.75µs.
Bus Received MILbus Word - The received MILbus includes Word which was
Word: received by the current operation. The word type (command, status or data ) is
defined by the EntryType field.
Bit position 15 of the Bus Word Entry corresponds to bit time 4 of the MILbus
word and Bit position 0 of the Bus Word Entry corresponds to bit time 19 of
the MILbus word.

Figure 4.4.5-3 IRIG Time Tag Low Entry

Time Tag Low Entry (Entry Type 2h)
26 25 .................... 20 19 ......................................................................................................... 0
Reserved Seconds of Microseconds of second
. minute 0 to 999999
0 to 59

Figure 4.4.5-4 IRIG Time Tag High Entry

Time Tag High Entry (Entry Type 2h)
26 ....................................... 20 19 ........................ 11 10 .......................... 6 5 ............................ 0
Reserved Days of year Hours of day Minutes of hour
1 to 365 0 to 23 0 to 59

130 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

Figure 4.4.5-5 Error Word Entry

Error Word Entry (Entry Type 1h)

26 25 .......................... 17 16 15 ................................................................................ 0
18
Start Reserved TX RX Error Type

Where:
Start: Start Trigger Flag - If Start Trigger flag is set, the Error Word Entry is related
to the start trigger event, which starts capturing of MILbus traffic.
TX: Transmit RT - This bit position is set if the Error Word Entry is related to a
transmit command.
RX: Receive RT - This bit position is set if the Error Word Entry is related to a
receive command.
Error The Error Type field indicates error type which was detected during the receive
Type operation of the related, received word.* If set, the indication is as follows:
Field:
Bit 15: ANY-ERROR (Logical OR of Bits 14 to 0)
Bit 14: Alternate Bus Response Error
Bit 13: Low Word count Error
Bit 12: High Word count Error
Bit 11: Status Word Exception**
Bit 10: Terminal Address Error / RT-RT Protocol Error
Bit 9: Early Response or Gap Time too short Error
Bit 8: Illegal Command Word / Reserved Mode Code Error
Bit 7: Transmission on both MILbus channels
Bit 6: Interword Gap Error
Bit 5: Inverted Sync Error
Bit 4: Parity Error
Bit 3: Low Bit Count Error
Bit 2: High Bit Count Error
Bit 1: Manchester Coding Error
Bit 0: Terminal No Response Error

*Note: If an error is detected during a RT- RT- transfer, it will be related to the
currently active RT. If the monitor detects a protocol error during a RT-
RT- transfer, it will be related to both RT's.
**Note: The default Status word Exception mask is set to 0x07ff with the
ApiCmdBMIni function (all status bits are checked). If you want
the BM to detect an error on only a subset of bits in the Status
word, you must setup the Status Word Exception Mask using the
BM function ApiCmdBMSWXMIni accordingly.

The following example shows how the BM makes entries in the Monitor Buffer for a sample of
MILbus transfers. The number of entries depends on the received word type, the time framing
and the word validity. Gap Time Entries are made every time the data stream is not contiguous
and the gap time is shorter than 109.75µs. If a new Command Word is received a Time Tag

MIL-STD-1553 Programmer's Guide 131

 Section 4 - Programming Using the API Library

Entry is generated. Figure 4.4.5-6 shows a typical flow of BM traffic and the associated
entries that will be made on the Bus Monitor Buffer.
Figure 4.4.5-6 Bus Monitor Buffer Entry Example

Monitored Message on Primary MILbus

Command Data  Status with Error # Command

 RT response Time
# BC Intermessage Gap

The BIU Processor stores in the Monitor Buffer the following entries.

Relative Flags Entry Entry Type Description

Byte Type
Address Code
0h ECON = 1 3h Time Tag High Word IRIG Time (high).
4h ECON = 1 2h Time Tag Low Word IRIG Time (low).
8h 8h Command Word on Command Word 1 with Gap
Primary Bus Time if time to previous word <
(Bus Word Entry) 108µs.
Ch Ah Data Word on Primary Data Word.
Bus
(Bus Word Entry)
10h ECON = 1 Bh Status Word on Status Word with Gap Time if
Primary Bus time to previous word < 108µs.
(Bus Word Entry)
14h 1h Error Word Entry Error in Status Word
18h ECON = 1 3h Time Tag High Word IRIG Time (high).
1Ch ECON = 1 2h Time Tag Low Word IRIG Time (low).
20h 8h Command Word on Command Word 2 with Gap
Primary Bus Time if time to previous word <
(Bus Word Entry) 108µs.

4.4.6 Standard Data Capture Mode

The Standard Data Capture Mode is setup when the ApiCmdBMCapMode is set to 0
(Standard Data Capture Mode). In the Standard Data Capture Mode data recording begins
after the monitor has synchronized on the first command word and continues until the BM is
halted, a Start Trigger Event has occurred and the Trace after Trigger Counter (TATC) is
decrement to zero, or when a Stop Trigger Event occurs. Triggers are not required in this
mode, however, if you are trying to track down a communications error, then a trigger would
be helpful. As shown in Table 4.4-I, you would use Standard Data Capture Mode if you want
to limit the amount of data recorded in the Monitor Buffer based on the Trace After Trigger

132 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

counter or the Stop Trigger. This mode must first be setup using the ApiCmdBMIni,
ApiCmdBMIntrMode, and the ApiCmdBMCapMode functions defined in sections 4.4.1
and 4.4.2 respectively. In addition, the following functions are available to provide the user
with the following capabilities:

a. Triggers can be used in this mode and require the ApiCmdBMTCBIni,

ApiCmdBMFTWIni, and ApiCmdBMTIWIni functions as defined in Section
4.4.3. Using triggers in this mode provide you with these recording/data
retrieval options:

 The word that caused the Start Trigger Event to occur is flagged by the
BM in the Monitor word entry.

 The data retrieved can be retrieved starting from the Start Trigger Event

b. Data Retrieval - There are a couple of options for analyzing the data recorded
in the Standard Data Capture Mode:

 Reading one entry at a time (entry is defined in Section 4.4.5) using the
ApiCmdBMStackpRead to establish the Monitor Buffer pointer and
ApiCmdBMStackEntryRead function to read one Monitor Buffer
entry

 Use the ApiCmdBMStackpRead to establish the Monitor Buffer

pointer, then use the ApiReadBlockMemData function to read a block
of Monitor buffer entries and perform data analysis or data reformatting
without having to issue multiple I/O functions to the Bus Analyzer
module.

 The ApiCmdBMStackpRead provides you with the capability to begin

reading the Monitor Buffer from one of three points:

1. Start of Monitor Buffer recording

2. Start Trigger Event

3. End of the Monitor Buffer

c. The Start Trigger Event and/or Half Buffer Full Interrupt can be used in this
mode to aid in the data retrieval process. (If using the Half Buffer Full Interrupt,
the Trace After Trigger Counter must be set to 0 with the
ApiCmdBMCapMode function.)

MIL-STD-1553 Programmer's Guide 133

 Section 4 - Programming Using the API Library

4.4.7 Selective Data Capture Mode

The Selective Data Capture Mode is setup when the ApiCmdBMCapMode is set to 1
(Selective Data Capture Mode). In the Selective Data Capture Mode the only data recorded is
data received after the Start Trigger Event and before the Message Capture Count is
decremented to 0 (See Section 4.4.2). This provides the user with the capability to look at only
the messages following and including the trigger event message. The recording of this data
will continue until the BM is halted, or the Trace after Trigger Counter (TATC) is decremented
to zero. (See Section 4.4.2) As shown in Table 4.4-I, you would use Selective Data Capture
Mode if you want to limit the amount of data recorded in the Monitor Buffer based on the
trigger. This mode must first be setup using the ApiCmdBMIni, ApiCmdBMIntrMode, and
the ApiCmdBMCapMode functions defined in sections 4.4.1 and 4.4.2 respectively. In
addition, the following functions are available to provide the user with the following
capabilities:

a. Trigger(s) must be used in this mode and require the ApiCmdBMTCBIni,

ApiCmdBMFTWIni, and ApiCmdBMTIWIni functions as defined in Section
4.4.3. Using triggers in this mode provides you with these recording/data
retrieval options.:

 The word that caused the Start Trigger Event to occur is flagged by the
BM in the Monitor word entry.

 The data retrieved can be retrieved starting from the Start Trigger Event

b. Data Retrieval - Same as the Standard Capture Mode

c. The Start Trigger Event and/or Half Buffer Full Interrupt can be used in this
mode to aid in the data retrieval process. (If using the Half Buffer Full
Interrupt, the Trace After Trigger Counter must be set to 0 with the
ApiCmdBMCapMode function.)

4.4.8 Recording Mode

The Recording Mode is setup when the ApiCmdBMCapMode is set to 2 (Recording Mode).
In the Recording Mode the all data is recorded after the BM is started. A half buffer is asserted
(if enabled using the ApiCmdBMIntrMode function) when the Monitor buffer is half full,
and when it is full. This provides the user with the capability to copy the recorded data to a file
for either post-analysis or replay purposes. The recording of this data will continue until the
BM is halted. (See Section 4.4.2) As shown in Table 4.4-I, you would use Recording Mode
if you want the BM data to be continuously recorded. This mode must first be setup using the
ApiCmdBMIni, ApiCmdBMIntrMode, and the ApiCmdBMCapMode functions defined in
sections 4.4.1 and 4.4.2 respectively. In addition, the following functions are available to
provide the user with the following capabilities:

134 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

a. ApiReadRecData - this System function can be issued at the Half/Full buffer

interrupt to copy the Monitor Buffer data to an application buffer memory area
using the ty_api_bm_rec structure. This buffer can later be used for replay.

4.4.9 Recording Using Queuing

The BM can be setup to store the data to the Monitor Buffer such that 1553 transfers can be
retrieved in a queuing fashion. This mode is the most simplistic mode to use. As shown in
Table 4.4-I, you would use Queuing if you want to record the user-specified bus traffic and do
not require the use of a trigger for data analysis and/or if you prefer the structured outputs
available in this recording mode. In addition to the ApiCmdBMIni and
ApiCmdBMIntrMode function defined in sections 4.4.1 and 4.4.2 respectively, the Recording
with Queuing process requires the use of the following functions:

a. ApiCmdQueueIni - this function is used to initialize the BM Queuing process.

This function takes the place or the ApiCmdBMCapMode.

b. ApiCmdQueueStart - this function will start queuing the BM data to the

Monitor Buffer. (This function takes the place of ApiCmdBMStart.)

c. ApiCmdQueueRead - this function will return a Message entry on each call.

It is a First-in, First-out manner. If no message is on the stack then the return
value will indicate this. The Monitor Buffer pointer starts at the first entry of
the queue and is automatically updated to the next transfer entry upon
completion of the ApiCmdQueueRead function. At that time an additional
ApiCmdQueueRead function can be issued to read the next entry.

4.4.10 Message Filter Recording Mode

The Message Filter Recording mode is setup when the ApiCmdBMCapMode is set to 3
(Message Filter Recording Mode). As shown in Table 4.4-I, you would use Message Filter
Recording mode if you prefer the structured outputs available in that recording mode, prefer to
grab multiple 1553 messages from the Monitor buffer, and/or require only 1553 transfers
containing certain command words to be recorded. Triggers can be used in this mode to
identify the starting pointer into the Monitor buffer from where you want to read the recorded
data. This mode must first be setup using the ApiCmdBMIni, ApiCmdBMIntrMode, and
the ApiCmdBMCapMode functions defined in sections 4.4.1 and 4.4.2 respectively. In
addition, the following functions are available to provide the user with the following
capabilities:

a. Using the ApiCmdBMReadMsgFltRec function allows retrieval of multiple

1553 message transfers from the Monitor Buffer in one of five special formats
as listed in Table 4.4-I and detailed in the PCI 1553 Software Library
Reference Manual.

 The formatted data is copied into a buffer file specified by the user.

MIL-STD-1553 Programmer's Guide 135

 Section 4 - Programming Using the API Library

 In this mode it is possible to set up a trigger using the

ApiCmdBMTCBIni, ApiCmdBMFTWIni, and ApiCmdBMTIWIni
functions as defined in Section 4.4.3.

b. The ApiCmdBMIniMsgFltRec function must be used to define the command

words to record. It is possible to filter the MILbus traffic by using up to 255
pre-defined command word filters.

c. The Half Buffer Full Interrupt can be used in this mode to aid in the data
retrieval process.

4.4.11 Additional Bus Monitor Filter

There is one additional function that will aid the developer in filtering out bus traffic that is not
required for evaluation or recording. This function is applicable to all Capture modes and is
defined as follows:

a. ApiCmdBMFilterIni - Enables/disables the recording of 1553 transfers based

on user-specified RT Transmit and Receive Subaddresses and Mode codes.
(When the BM is initialized using the ApiCmdBMIni function, all RT
Transmit and Receive Subaddresses and Mode codes are enabled).

4.4.12 Additional Monitor Features

4.4.12.1 Dynamic Tag Monitor

Monitor up to 64 8-bit or 16-bit incrementing values within the Data words

received/transmitted by one or more RTs (SA's or Modecodes) for good/bad/stale status values.
This feature requires the user to issue the following function calls prior to ApiCmdBMStart:

a. ApiCmdBMDytagMonDef - defines the Data Word location for an

incrementing value for an RT Subaddress or Modecode that contains the
inrementing value to be monitored. The value can be 8-bit or 16 bits in length.
A Dytag Monitor ID (1 – 64) is associated with this location.

b. ApiCmdBMDytagMonRead - provides good/bad/stale status indication for the

requested Dytag Monitor ID.

136 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

MIL-STD-1553 Programmer's Guide 137

 Section 4 - Programming Using the API Library

4.5 REPLAY PROGRAMMING

If Replay is enabled, the BIU Processor physically replays a file in the format as recorded
during the Monitor Operation. Before Replay can be started, the first entries of the file must be
copied to the Replay buffer area with ApiWriteRepData. With each call of this function half
of a Replay buffer can be written. Call this function twice in order to fill the complete buffer.
The replay buffer size in the Global RAM is 20000 Hex for each stream. Once started, the BIU
Processor reads and transmits the data from the Replay Buffer. If programmed, an interrupt
can be asserted each time half of the Replay buffer is transmitted. This provides for double
buffer type refill strategy. When the Replay Buffer end is reached, the processor will wrap
around to the replay buffer start address. This operation continues until the number of entries,
as specified in the Replay Entry Count location are processed or a monitor entry indicating
"Entry not Updated" is found.

Note: ApiWriteRepData does automatically write to the half buffer wich is currently not
replayed.

The replay mode can be configured to disable replay for a selected RT. If the selected RT is
disabled for Replay, an external RT should be connected to the bus to respond to the BC
commands to that RT. Special handling is provided to cope with differences in the response
time between the recorded and the actual external RT.

The protocol type (MIL-STD-1553A or MIL-STD-1553B) must match the protocol type of the
recorded RT's.

Since the Replay function is the bus master and issues the command words on the MIL-STD-
1553 bus it can not be combined with BC operation. Any attempt to enable the Replay mode
together with the BC mode will be rejected. However, the Replay mode can be combined with
RT and Bus Monitor Mode. RTs can be setup to mailbox the data from the replay file or from
external RT's, or actively respond to commands issued from the replay module.

Note: The Replay mode does not reproduce any recorded error conditions nor does it provide
special error handling for external RT's during the replay process. The only exception
handling is a timeout feature which inhibits a lock-up if external RT's are used which
do not respond.

In general, the order in which you will need to setup your Replay Configuration using the
Replay functions defined in Table 4-IX is as follows:

a. Initialization (ApiCmdReplayIni) - provides initialization of the following:

 Enable/disable half buffer transmitted interrupt

 Time Tag replay setup:

138 MIL-STD-1553 Programmer's Guide

 Section 4 - Programming Using the API Library

1. Replay of the IRIG time tag

2. Replay only the Low IRIG Time Tag (seconds and

microseconds)

3. Disable time tag replay

 Definition of the amount of data (in bytes) to be replayed

b. Copy the recorded Monitor data to the Replay Buffer area in Global RAM using
the ApiWriteRepData System function. This function allows you to write a
half buffer size (0x10000) or less to the currently inactive half Replay Buffer.

c. An optional choice now would be to disable any RTs for which you do not wish
the data to be replayed. If you disable an RT, you will need to connect an
External RT to respond to the BC commands to the RT which are present in the
data to be replayed. The ApiCmdReplayRT function provides the disable RT
capability.

d. Start the Replay using the ApiCmdReplayStart function.

e. Refill the Replay Buffer:

 If a Half-Buffer transmitted interrupt has been enabled, and an interrupt

handler has been developed to handle the interrupt, then the Replay
Buffer can be refilled.

The ls_recording_replay_sample.c demonstrates how to fill both halves of the Replay Buffer,
then start the Replay function. The Entry count of the Replay Buffer is continuously
monitored, and when the count = 0, the Replay is stopped. Each time the replay interrupt count
is incremented (a half Replay buffer was replayed to the bus) another half Replay buffer is
loaded.

MIL-STD-1553 Programmer's Guide 139

 Section 4 - Programming Using the API Library

THIS PAGE INTENTIONALLY LEFT BLANK

140 MIL-STD-1553 Programmer's Guide

 Section 5 – Notes

5 NOTES

5.1 ACRONYMS AND ABBREVIATIONS

Ω ohms
µs microseconds
ACI AIM Compact PCI I-Architecture
ACK Acknowledge
addr address
ANS AIM Network Server
API AIM PCI I-Architecture
App Appendix
ASP Application Support Processor
AVI AIM VME I-Architecture
AXI AIM VXI I-Architecture
BC Bus Controller
BCD Binary-Coded Decimal
BH Buffer Header
BIP Bus Interface Processor
BIT Built in Test
BIU Bus Interface Unit
BM Bus Monitor
bpos bit position
BSP Board Support Package
CMD Command
CPCI Compact PCI
CTP capture start trigger pointer
D/A Digital to Analog
DBTE Databus test equipment
DDL Direct Digital Link
DLL Dynamic-Link Library
DRAM Dynamic Random Access Memory
DSUB D-Subminiature
EBRC Extended RT Broadcast Emulation
EEPROM Electrically Erasable and Programmable Read Only Memory
EFABus European Fighter Aircraft Bus
EFEx Eurofighter Express Standard
EOM end of message
EPROM Erasable Programmable Read Only Memory
ETP end trigger pointer
fct function
FIFO First in/First out
FLASH Page oriented electrical erasable and programmable memory
FOFE Fiber Optic Front End
AIM GmbH Gesellschaft für angewandte Informatik und Mikroelektronik

MIL-STD-1553 Programmer's Guide 141

 Section 5 - Notes

m.b.H - German for "Company for applied information

technology and microelectronics"
hid header identifier
HS High Speed
I/O input/output
INT integer
IP Internet Protocol
IRIG Inter Range Instrumentations Group
IRIG-B Inter Range Instrumentations Group Time code Format Type B
Kbit kilobit
kHz kilohertz
LCA Logic Cell Array (XILINX - Programmable Gate Array)
LS low speed
LSB Least Significant Bit
Mbps Mega bit per second
MHz Mega hertz
MID Message Identifier
MIL-STD Military Standard
MILbus MIL-STD-1553 bus
ms millisecond
MSB most significant bit
NOP No operation - indicates no executable code
PBA MIL-STD-1553 Databus Analyzer Software for Windows
PBI Physical Bus Interface
PC Personal Computer
PCI Peripheral Component Interconnect
PMC Peripheral Component Interconnect Mezzanine Card
PROM Programmable Read Only Memory
PSC PCI and System Controller
RAM Random Access Memory
RPC Remote Procedure Call
RS232 Hardware Interface Protocols
RT Remote Terminal
s/w software
SA subaddress
SRAM Static Random Access Memory
STANAG Standardization Agreement
STP start trigger pointer
SWM status word mask
TATC Trace After Trigger Counter
TCB Trigger Control Block
UINT unsigned integer
VME Versa Module Eurocard
VxD Virtual Device Driver
VXI Vmebus Extensions for Instrumentation
WDM Windows Driver Model
WDF Windows Driver Foundation
wpos word position

142 MIL-STD-1553 Programmer's Guide

 Section 5 – Notes

xid transfer identifier

MIL-STD-1553 Programmer's Guide 143

 Section 5 - Notes

5.2 DEFINITION OF TERMS

Big Endian a system of memory addressing in which numbers that occupy more than
one byte in memory are stored "big end first" with the uppermost 8 bits at
the lowest address.
Broadcast commands sent to multiple RTs at once. The RTs are responsible for
distinguishing between broadcast and non-broadcast command messages.
An RT address of 11111 (31) indicates a broadcast message.
Buffer Header information detailing the location of the data buffer(s) used for the 1553
transfer(s), and the status and event information associated with the
transfer. A buffer header is to be associated with the data buffer(s) by
the programmer for any 1553 transfer to/from the BC or RT
Buffer Header ID an ID number associated with the Buffer Header structure
Data Buffer an area of memory on the API/ACI1553 device (global RAM) assigned
by the programmer to accommodate 1553 transfer(s) to/from the BC or
RT (2047 data buffers available)
Direct Digital Link Direct Digital Link (DDL) mode indicates that the monitor is not low
speed controlled – the HS bus is continuously scanned for valid HS
transfers. BC and RT are still triggered from the LS-BIU via Action
Word strobes, but the transmitter initlize value is ignored and the HS
transmission is immediately started.
Driver Command command used by the AIM target s/w to control the 1553 device
Dual Stream indicates the AIM 1553 board supports two dual redundant MIL-STD-
1553 data stream
FLASH page oriented electrical erasable and programmable memory
function a self-contained block of code with a specific purpose that returns a
single value.
Header File file containing C++ code consisting of definitions which are used by the
executable code
intermessage gap the time between 1553 message transmissions with a minimum gap time,
as specified in MIL-STD-1553, of 4.0 microseconds
interrupt a signal from a device attached to a computer or from a program within
the computer that causes the main program that operates the computer
(the operating system) to stop and figure out what to do next
Little Endian a system of memory addressing in which numbers that occupy more than
one byte in memory are stored "little end first" with the lowest 8 bits at
the lowest address.
Major Frame sequence of minor frames defined for transfer (max 64 minor frames in a
major frame)
MIL-STD-1553 military specification defining a digital time division command/response
multiplexed databus

144 MIL-STD-1553 Programmer's Guide

 Section 5 – Notes

MIL-STD-1760 based on MIL-STD-1553B, augmented with requirements to support the

aircraft/store electrical interconnection system between aircraft and
stores (any external device attached to the aircraft (such as bombs,
missiles, etc.)
Minor Frame sequence of 1553 transfers (max 128 transfers defined in a minor frame)
Mode code Unique five bit codes that are sent to specific RTs to check their status,
control their operation and manage the bus.
Monitor Status 8 bits in the Monitor Status Word that reflect the results of the Monitor
Trigger pattern Trigger Block execution of the BIU Processor.
Monitor Status reflects the current status of Bus Monitor operation
Word
Prototype a prototype of a function provides the basic information that the compiler
need to check that a function is used correctly
Response Time The time between the BC Command/Data word and the RT Status word
Response Timeout The maximum time the Bus Controller will wait for a Status word
Value response from the RT before indicating a "Response Timeout".
Single Stream indicates the AIM 1553 board supports one dual redundant MIL-STD-
1553 data stream
S-Record An S-record file consists of a sequence of specially formatted ASCII
character strings. An S-record will be less than or equal to 78 bytes in
length. The general format of an S-record follows:
+-------------------//------------------//-----------------------+
| type | count | address | data | checksum |
+-------------------//------------------//-----------------------+

STANAG3910 based on MIL-STD-1553B, a 1 Mbit/sec dual redundant low speed bus,

augmented by a high speed fiber optic dual redundant bus operating at 20
Mbits/sec
spg sample program
Strobe a strobe is a signal that is sent that validates data or other signals on
adjacent parallel lines
Target Refers to the software/communication active on the PCI1553 device
Transfer Descriptor an area of memory assigned by the target s/w to store status of the 1553
(BC) transfer
Transfer Descriptor an area of memory assigned by the target s/w to store status of the 1553
(RT) transfer
Transfer ID an ID number associated with the 1553 transfer structure that defines the
characteristics of the 1553 transfer
Transfer Type BC-to-RT, RT-to-BC, RT-to-RT
Vector Word Transmitted by the RT when requested by the BC with the Mode code
command "Transmit Vector Word" which is Mode code 16. The vector
word will contain information indicating the next action to be taken by
the BC.

MIL-STD-1553 Programmer's Guide 145