a pi 1553 prog guide

Programmer's Guide

for

API1553-1/2 (PCI Version) ACI1553-1/2 (cPCI Version)

APX1553-1/2/DS (PCI-X Version) ACX1553-3U-1/2/4/DS (PXI Version)

ACX1553-6U-4/8/DS (cPCI-X Version) AMC1553-1/2/4/T (PMC Version)

APM1553 (PC-Card Version) AP104-1553-1/2/4 (PC104 Version)

ANI1553

Windows Applications

November 2009 V21.5x Rev. B

AIM GmbH Sasbacher Str. 2

79111 Freiburg, Germany

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

[email protected]

www.aim-online.com

Programmer's Guide

for

API1553-1/2 (PCI Version) ACI1553-1/2 (cPCI Version)

APX1553-1/2 (PCI-X Version) ACX1553-3U-1/2/4/DS (PXI Version)

ACX1553-6U-4/8/DS (cPCI-X Version) AMC1553-1/2/4/T (PMC Version)

APM1553 (PC-Card Version) AP104-1553-1/2/4 (PC104 Version)

ANI1553

Windows Applications

V21.5x Rev. B

November 2009

AIM No. 60-11200-37-215X-B

ii

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

3703 North 200th

Street Elkhorn, NE 68022

866-AIM-1553 866-AIM-A429

[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 2006-2009: AIM

www.aim-online.com

iii

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 Rev. B

4/14/04 Patrick Giesel Corrected phone number Changed page i to a common layout

V19.0x Rev. C

4/19/04 Frank Schmid Small corrections

V19.3x Rev. A

1/2/06 J. Furgerson Updated to support BSP V9.03

V19.3x Rev. B

2/6/06 Patrick Giesel - Corrected front page - 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 Rev. A

1/18/07 Patrick Giesel - Changed chapter 1.2 (corrected name for section 6) - 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 Rev. B

7/07 S. Riedinger Unify names of products

V19.5x Rev. C

8/07 S. Riedinger Update images

V21.0x Rev. A

2/26/09 M. Haag Updated to support BSP V10

V21.0x Rev. B

5/25/09 M. Haag - Corrected chapter 4.2.2

V21.5x Rev. A

9/24/09

M. Haag Added new hardware AP104-1553-1/2/4

V21.5x Rev. B

11/03/09 M. Melcher Some minor corrections

iv

THIS PAGE INTENTIONALLY LEFT BLANK

v

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................................................................................................. 19

3.2.1 Software Architecture .........................................................................................19

3.2.2 Necessary Files and Defines for New Application Programs.............................22

3.2.3 Board Software Package Content .......................................................................24

3.2.4 API S/W Library Structure/Content....................................................................25

3.2.5 Application Program Structure Overview ..........................................................34

3.2.6 MIL-STD-1553 Transfers and Frame Structure Overview.................................38

3.2.6.1 About MIL-STD-1553 Transfers .................................................................... 38

3.2.6.2 Major/Minor Frame Scheduling Design Concepts ......................................... 42

4 PROGRAMMING USING THE API LIBRARY..................................................... 43

4.1 Library Administration and System Programming ........................................... 43

4.1.1 Initializing Your Application and Application Interface to the AIM Board.......44

4.1.2 Getting AIM Board Status and Configuration Information ................................47

4.1.3 Defining MIL-STD-1553 Protocol .....................................................................47

4.1.4 Defining External Connectivity ..........................................................................47

4.1.5 Configuring Response Timeout ..........................................................................50

4.1.6 Utilizing IRIG-B .................................................................................................51

4.1.7 Interrupt Handling...............................................................................................52

4.1.8 Debugging...........................................................................................................57

4.1.9 GPIO Programming ............................................................................................58

4.2 Bus Controller Programming ............................................................................... 59

4.2.1 Initializing the BC...............................................................................................60

4.2.2 Defining 1553 Transfers .....................................................................................61

4.2.3 BC Transmit and Receive Message Data Word Generation/Processing ............66

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

4.2.3.1.1 Dynamic Data Word Generation ................................................................... 68

vi

4.2.3.1.2 Using FIFOs and Dataset Buffers for Data Generation ................................. 69

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

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

4.2.4 BC Transfers with Error Injection ......................................................................71

4.2.5 Defining Minor/Major Frames Content & Timing .............................................73

4.2.5.1 Defining Minor/Major Frame Content & Timing - Standard Framing Mode 73

4.2.5.2 Defining Minor/Major Frame Content & Timing - BC Instruction Table

Mode ......................................................................................................... 75

4.2.6 Starting the Bus Controller .................................................................................79

4.2.7 Acyclic 1553 Transfers .......................................................................................84

4.2.8 BC Interrupt Programming .................................................................................85

4.2.8.1 How to Setup the 1553 Transfer to Cause an Interrupt................................... 86

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

4.2.9 Status Word Exception Handling .......................................................................87

4.2.9.1 RT Service Request Processing ...................................................................... 89

4.2.10 Tracking BC Receive Data using Track Multiplex Buffers................................91

4.3 Remote Terminal Programming........................................................................... 93

4.3.1 Initializing the RT...............................................................................................94

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

4.3.2.1 RT Transmit/Receive Message Data Word Generation/Processing ............... 99

4.3.2.2 RT Transmit/Receive Mode Code Generation/Processing ........................... 103

4.3.2.3 RT Transmit/Receive Broadcast Message Generation/Processing ............... 105

4.3.3 RT Transfers Error Injection.............................................................................106

4.3.3.1 RT Transfers Error Injection into Status/Data Word .................................... 106

4.3.3.2 RT Transfer Error Emulation via Status Word Response............................. 108

4.3.4 RT Interrupt Programming ...............................................................................109

4.3.4.1 How to Setup the RT Transfer to Cause an Interrupt.................................... 109

4.3.5 RT Global Configuration ..................................................................................110

4.3.6 Tracking RT Receive Data using Track Multiplex Buffers..............................110

4.4 Bus Monitor Programming ................................................................................. 113

4.4.1 Bus Monitor Initialization.................................................................................118

4.4.2 Bus Monitor Capture Mode and Interrupt Mode Definition.............................118

4.4.3 Bus Monitor Triggers........................................................................................121

4.4.3.1 Bus Monitor Trigger Definition.................................................................... 122

4.4.3.1.1 Bus Monitor Static Trigger Definition ........................................................ 123

4.4.3.1.1.1 Trigger on Error Condition.......................................................................... 123

4.4.3.1.1.2 Trigger on External Event Condition .......................................................... 126

4.4.3.1.2 Bus Monitor Dynamic Trigger Definition................................................... 127

4.4.3.1.2.1 Trigger on Received Word .......................................................................... 127

4.4.3.1.2.2 Trigger on Data Value Condition ................................................................ 130

4.4.3.2 Starting/Stopping the "Data Capture" Process.............................................. 132

4.4.3.3 Arming the Trigger ....................................................................................... 134

4.4.4 Bus Monitor Interrupts......................................................................................135

4.4.5 Format of Data Stored in the Monitor Buffer ...................................................137

4.4.6 Standard Data Capture Mode............................................................................140

4.4.7 Selective Data Capture Mode ...........................................................................142

4.4.8 Recording Mode ...............................................................................................142

vii

4.4.9 Recording Using Queuing.................................................................................143

4.4.10 Message Filter Recording Mode.......................................................................143

4.4.11 Additional Bus Monitor Filter ..........................................................................144

4.4.12 Additional Monitor Features.............................................................................144

4.4.12.1 Dynamic Tag Monitor................................................................................... 144

4.5 Replay Programming........................................................................................... 146

5 PROGRAM SAMPLES............................................................................................. 151

5.1 Program Samples Overview................................................................................ 151

5.1.1 Sample Programs ..............................................................................................154

5.2 Program Sample Code......................................................................................... 167

5.2.1 LS_BC_RT_BM_Sample.c ..............................................................................167

5.2.2 LS_Interrupt_Sample.c .....................................................................................181

5.3 API S/W Library Function Calls vs. Program Samples................................... 192

6 CREATING A NEW MICROSOFT VISUAL C/C++ APPLICATION

PROGRAM............................................................................................................... 198

6.1 Steps to Create and Compile............................................................................... 198

7 NOTES........................................................................................................................ 202

7.1 Acronyms and Abbreviations ............................................................................. 202

7.2 Definition of Terms.............................................................................................. 205

API S/W LIBRARY INDEX.................................................................................................... 208

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.1-2 ACI1553-1 3U Hardware Diagram ..................................................................... 17

Figure 3.1-2 ACI1553-1 3U Hardware Diagram ..................................................................... 18

Figure 3.2.1-1 Host/Target Software Interface Diagram ......................................................... 19

Figure 3.2.1-2 DLL and Program Interfaces ............................................................................. 21

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

Figure 3.2.4-1 Basic Application Program Structure ......................................................... 35

Figure 3.2.6.1-1 API S/W Buffer Assignments for 1553Transfers....................................... 40

Figure 3.2.6.1-2 FIFOs and Dataset Buffers I/ F to Message Buffer Pool ............................ 41

Figure 3.2.6.2-1 Major/Minor Frame Scheduling Diagram .................................................. 42

Figure 4.1.4-1 MILbus Output Amplitude vs. Voltage Control......................................... 49

Figure 4.1.7-1 Interrupt Setup Process............................................................................... 56

Figure 3.2.6.1-1 BC Buffer Header and Buffer Pool Interface ............................................. 63

Figure 4.2.3.1.1-1 Data Generation Functions Diagram .......................................................... 69

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

Figure 4.2.6-1 Minor Frame Timing Control Diagram...................................................... 81

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

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

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

Instruction................................................................................................. 82

Figure 4.2.9.1-1 Vector Word Format................................................................................... 89

Figure 4.2.10-1 BC Track Process Example ........................................................................ 91

Figure 4.3.2-1 RT Buffer Header and Buffer Pool Interface.............................................. 96

Figure 4.3.2-2 Status Word Bits......................................................................................... 97

Figure 4.3.2.1-1 Data Generation Functions Diagram ........................................................ 100

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

Figure 4.3.6-1 RT Track Process Example ...................................................................... 111

Figure 4.4.3.2-1 Bus Monitor Function Trigger Word........................................................ 133

Figure 4.4.3.3-1 Bus Monitor Trigger Index Word............................................................. 135

Figure 4.4.5-1 Monitor Bus Word Entry.......................................................................... 137

Figure 4.4.5-2 Bus Word Entry........................................................................................ 138

Figure 4.4.5-3 IRIG Time Tag Low Entry ....................................................................... 138

Figure 4.4.5-4 IRIG Time Tag High Entry....................................................................... 138

Figure 4.4.5-5 Error Word Entry...................................................................................... 139

Figure 4.4.5-6 Bus Monitor Buffer Entry Example ......................................................... 140

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 / Compilers .............................................. 20

Table 3.2.4-I Library Administration Function Descriptions........................................... 26

Table 3.2.3-II System Function Descriptions .................................................................... 27

Table 3.2.3-III Calibration Function Descriptions.............................................................. 28

Table 3.2.3-IV Buffer Function Descriptions ..................................................................... 28

Table 3.2.3-V FIFO Function Descriptions ....................................................................... 29

Table 3.2.3-VI Bus Controller Function Descriptions ........................................................ 30

Table 3.2.3-VII Remote Terminal Function Descriptions.................................................... 31

Table 3.2.3-VIII Bus Monitor Function Descriptions ........................................................... 32

Table 3.2.3-IX Replay Function Descriptions ................................................................... 33

Table 3.2.6.1-I Transfer ID/Buffer Header ID Ranges........................................................ 38

Table 3.2.6.1-II Buffer ID Ranges........................................................................................ 38

Table 4.1.7-I Available Interrupt Types and Related Function Call ................................ 54

Table 4.1.8-I Error Message Output Control Levels........................................................ 57

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

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

Table 4.2.3.1-I BC Transmit Buffer Fill Method Summary................................................ 67

Table 4.2.3.1.1-I Dynamic Data Word Generation Summary................................................... 68

Table 4.2.5.1-I Standard Framing Mode Instructions ......................................................... 74

Table 4.2.5.2-I BC Instruction Table Mode Instructions .................................................... 77

Table 4.2.6-I BC Start Modes .......................................................................................... 80

Table 4.2.8.1-I Setup for 1553 Transfers to Generate Interrupts ........................................ 86

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

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

Table 4.2.9.1-I BC Response to RT Vector Word .............................................................. 90

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

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

Table 4.3.2.2-I Mode Codes.............................................................................................. 104

Table 4.3.4.1-I Setup for RT Transfers to Generate Interrupts ......................................... 110

Table 4.4-I Bus Monitor Modes and Output Format Summary.................................. 115

Table 4.4-I Bus Monitor Modes and Output Format Summary (Continued).............. 116

Table 4.4-II Bus Monitor Modes and Function Summary ........................................... 117

Table 4.4.3.1-I Trigger Control Block Structure............................................................... 123

Table 4.4.3.1.1.1-I Error Conditions for Triggering the Bus Monitor .................................... 124

Table 4.4.3.1.1.1-II TCB Parameters for Error Condition Trigger........................................... 125

Table 4.4.3.1.1.2-I TCB Parameters for External Event Trigger ............................................ 126

Table 4.4.3.1.2.1-I Received Words Triggering the Bus Monitor .......................................... 128

Table 4.4.3.1.2.1-II TCB Parameters for Dynamic Received Word Trigger............................ 129

Table 4.4.3.1.2.2-I TCB Parameters for Dynamic Data Value Trigger................................... 131

Table 4.4.3.2-I Bus Monitor Capture Scenarios................................................................ 133

Table 4.4.4-I BM Interrupts Relative to Capture Mode ................................................. 136

x

Table 5.1-I Program Samples Overview ..................................................................... 152

Table 5.1.1-I Interrupt_Sample.c ................................................................................... 154

Table 5.1.1-II LS_BC_Acyclic_Xfers_Sample.c ............................................................ 155

Table 5.1.1-III LS_BC_Dynamic_Data_and_1760_Sample.c.......................................... 156

Table 5.1.1-IV LS_BC_Dynamic_Data_Dytag_Sample.c................................................ 156

Table 5.1.1-V LS_BC_Dynamic_Data_Systag_Sample.c............................................... 157

Table 5.1.1-VI LS_BC_External_BC_Trigger_Sample.c................................................. 157

Table 5.1.1-VII LS_BC_Fifo_Sample.c............................................................................. 158

Table 5.1.1-VIII LS_BC_Multibuffer_Sample.c................................................................. 159

Table 5.1.1-IX LS_BC_RT_BM_Sample.c ...................................................................... 160

Table 5.1.1-X LS_BC_RT_FW_Sample.c ...................................................................... 161

Table 5.1.1-XI LS_BM_Message_Filter_Recording_Sample.c ....................................... 162

Table 5.1.1-XII LS_BM_Queue_Sample.c ........................................................................ 163

Table 5.1.1-XIII LS_Recording_Sample.c .......................................................................... 164

Table 5.1.1-XIV LS_Replay_Sample.c................................................................................ 165

Table 5.1.1-XV LS_RT_Global_Con_Sample.c ................................................................ 166

Table 5.3-I API S/W Library Function Calls vs. Program Samples............................ 192

Programmer's Guide for PCI 1553 Windows Applications 1

Section 1 - Introduction

1 INTRODUCTION

1.1 General

Welcome to the Programmer's Guide for PCI 1553 (API1553, ACI1553, APX1553,

ACX1553, AMC1553, APM1553, AP104-1553 and ANI1553) Windows Applications. This

programmer's guide, in conjunction with the associated Software Library Reference Manual

for PCI 1553 Windows Applications, 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 a high level overview of the MIL-STD-1553

communication protocol including Command, Data and

Status word formats and message sequencing.

Section 2

MIL-STD-1553

Overview

Section 1

Introduction

Provides an introduction to the contents of the

programmer's guide documentation conventions and

applicable documents.

Provides a high level overview of the hardware and

software architecture. Included in the software section is a

description of the Board Support Package, an application

program structure overview and basics about 1553

message transfers and minor/major frame definition.

Section 3

API1553

Overview

2 Programmer's Guide for PCI 1553 Windows Applications


4.1

Library

Admin &

System

4.2

Bus

Controller

4.3

Remote

Terminal

4.4

Bus

Monitor

4.5

Replay Mode

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

Section 5

Program

Samples

Section 6

Creating a

New

Program

Provides an explanation of two

complete sample programs, a

description of the sample programs

provided in the Board Support Package

and references for function calls used in

the sample programs.

Section 4

Design and

Programming

Overview

Provides the necessary steps to create

and compile a new application program.

Section 7

Notes Provides expansion for all acronyms

and definitions for terms used

frequently in this document.



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.



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

API S/W Library Data Type Size

(in bytes)

AiInt Integer 4

AiUInt unsigned integer 4

AiInt8 character 1

AiInt16 short integer 2

AiInt32 long integer 4

AiUInt32 unsigned long integer 4

AiUnt16 unsigned short integer 2

AiUInt8 unsigned character 1

AiChar character 1

AiUChar unsigned character 1

AiDouble double floating point 8

AiFloat single floating point 4



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:

PCI 1553 Software Library Reference Manual - provides the 1553 application developer

with detailed API/ACI/APX/ACX/AMC/AP104/ANI programming information

including library function call and header file details 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 Getting Started Manual - assists the first time users of the AIM PCI 1553 boards

with software installation, hardware setup and starting a sample project.

ACI1553-3U Hardware Manual - provides the hardware user’s manual for the ACI1553

CompactPCI-Bus modules. The document covers the hardware installation, the board

connections the technical data and a general description of the hardware architecture.

API1553-1/2 Hardware Manual- provides the hardware user’s manual for the API1553-1

and API1553-2 PCI-Bus modules. The document covers the hardware installation, the

board connections the technical data and a general description of the hardware

architecture.

AMC1553 Hardware Manual - provides the hardware user’s manual for the AMC1553

PMC-Bus interface module. The document covers the hardware installation, the

board connections the technical data and a general description of the hardware

architecture.



APM1553 Hardware Manual - provides the hardware user’s manual for the APM1553

PCMCIA-Bus interface module. The document covers the hardware installation, the

board connections, the technical data and a general description of the hardware

architecture.

APX1553 Hardware Manual - provides the hardware user’s manual for the APX1553 PCI-

X-Bus interface module. The document covers the hardware installation, the board

connections, the technical data and a general description of the hardware architecture.

ACX1553 Hardware Manual - provides the hardware user’s manual for the ACX1553

cPCI-X-Bus interface module. The document covers the hardware installation, the

board connections, the technical data and a general description of the hardware

architecture.

PBA.pro Bus Analyzer Getting Started – introduces the PBA.pro Bus Analyzer and

contains links to further documentation.

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.


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.


Section 2– MIL-STD-1553 Specification Overview

Figure 2-1 1553 Configuration Example

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.

A

B MIL - STD - 1553 BUS

NAV Mission

Computer RADAR

Display Weapon

Avionics Subsystem

RT - Remote Terminal

BC - Bus Controller

BM - Bus Monitor

BC

RT RT

BM RT

A

B - -

NAV Mission

Computer RADAR

Display Weapon

BC



Figure 2-2 Word Formats

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.

Mes

sag

e E

rro

r

Inst

rum

enta

tio

n

Ser

vic

e R

equ

est

Bit

Bu

sy

Su

bsy

stem

Fla

g

Par

ity

1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0

5 5 5 1

16 1

1 1 1 1 1 1 5 3 1 1 1

1

Sync Remote Terminal

Address

T/R Subaddress

Mode

Data Word Count/

Mode Code

P

Command

Word

Sync Data P

Sync Remote Terminal

Address

Reserved

Data

Word

Status

Word

Note: T/R - transmit/receive

P - parity

Bit

Times

Bro

adca

st C

om

man

d

Dy

nam

ic B

us

Co

ntr

ol

Ter

min

al F

lag



Figure 2-3 Information Transfer Formats

Receive

Command Transmit

Command Status

Word Data

Word Data

Word Data

Word Status

Word Next

Command

RT-to-RT Transfer

Mode

Command Status

Word Next

Command

1.1.1.1.1.1.1 Mode Command without Data Word

Mode

Command Status

Word Next

Command

Mode Command with Data Word (Transmit)

Data

Word

Note:

# Intermessage Gap

* * Response Time

Mode

Command Status

Word Next

Command

Mode Command with Data Word (Receive)

Data

Word

Transmit

Command Status Word Data

Word Data

Word Data

Word Next

Command

RT to Controller Transfer

Receive

Command Data

Word Data

Word Data

Word Status

Word Next

Command

Controller to RT Transfer

• • • * * #

• • • * * #

• • • * * # * *

* * #

* * #

* * #



Figure 2-4 Broadcast Information Transfer Format

Please refer to the AIM MIL-STD-1553 Tutorial for further instruction on the MIL-STD-

1553, its history and specification.

Receive

Command Transmit

Command Status

Word Data

Word Data

Word Next

Command

1.1.2.1.1.1.1 RT-to-RT(s)

Mode

Command Next

Command

1.1.2.1.1.1.2 Mode Command without Data Word

Mode

Command Next

Command

Mode Command with Data Word (Receive)

Data

Word

Receive

Command Data

Word Data

Word Data

Word Next

Command

Data

Word

Note:

# Intermessage Gap

* * Response Time

• • •

**

#

• • #

#

#


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

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 full-up configuration of an API1553-1 device with 32 RTs, a BC, BM and

Replay functionality. This visual graphic was generated by the PBA2000 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.

Note: the PBA2000 and 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. The API1553 (PCI), ACI1553 (cPCI) and APX1553 (PCI-X)

modules come in either a -1 (one MIL-STD-1553A/B dual redundant data stream) or -2 (two

MIL-STD-1553A/B dual redundant data streams) configuration. For the APX cards exists also

a -4 version. The ACX1553 modules for cPCI-X are available as -1, -2 and -4 versions. The

ACI1553 modules are either 3U or 6U in height dependant on single or dual channel.

Block diagrams for each of the API1553-2 and ACI1553-1 are shown in Figures 3.1-1 and 3.1-

2 respectively. 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

Figures 3.1-1 and 3.1-2 and their 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

Configuration of the programmable BIU with the bit stream data from

FLASH

Provides program data for the BIU processors

Interface to PCI/CompactPCI bus

ASP Memory provides Local ASP RAM for ASP local programs and

Shared RAM for Host-to-Target Communication:

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

stream and performs the following tasks:

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.



Figure 3.1-1 API1553-2 Hardware Diagram

Note: The API1553-1 implements only the BIU 1 section.

ASP Section

BIU2

DSUB 9 MILbus connector

Physical Bus Interface Daughterboard

MIL-STD

1553B

Encoder and

Decoder

BIU1

Processor

Strong ARM

200MHz

BIU1

Local

Program

Memory

MIL-STD

1553B

Encoder and

Decoder

BIU2

Processor

Strong ARM

BIU2

Local

Program

Memory

High Speed serial Bus

Global RAM One SRAM-Module

Max. 16MB

P

O

R

T

PORT

P

O

R

T

ASP

Memory

Max. 64MB

PCI and

System

Controller

PCIBus

Application

Support

Processor

150MHz

Board

Configuration

Memory

Flash-PROM

4MByte

Debug and

Maintenance

Interface

Timecode

Processor

Section Serial

Interface

RS-232

Setup

Memory

E2PROM

512 Bytes

IRIG-B

I/O

32

Serial Timecode

32

32

32

32

Tri-port Arbitration

Logic

Serial Timecode

ASP Address and Databus

DSUB 15 General I/O

BIU1



Figure 3.1-2 ACI1553-1 3U Hardware Diagram

DSUB 9 MILBus connector DSUB 15 General I/O

Physical Bus Interface Daughterboard

BIU Processor

Strong ARM

BIU

Local Program

Memory

256Kbyte

MIL-STD

1553B

Encoder and

Decoder Global RAM

1MB

Fast Static

P

O

R

T

PORT

ASP

Memory

16MB

PCI and

System

Controller

CompactPCI-Bus

Application

Support

Processor

150MHz

Board

Configuration

Memory

Flash-PROM

4MByte

Debug and

Maintenance

Interface

Timecode

Processor Section

Serial

Interface

RS-232

Setup

Memory

E2PROM

512 Bytes

IRIG-B

I/O

32

Serial Timecode

32

32

Global-

RAM Arbitration

Logic

ASP Address and Databus

BIU

ASP Section



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

NT Device Driver

API Software Library

Host-Target

Unique 'C' function call / DLL

Operating System independent

Operating System dependent communication

System Level

Application Level

Host

Target

Target Level

Windows 2000/XP/VISTA Driver

PCI/cPCI/PCI-X/cPCI-X/ PCMCIA Bus

User's Application

Support software: - monitor software - LCA-Boot software UART / HW init

Debug interface Driver-host interface Selftest (BITE)

ASP Driver Software (running on ASP)

BIU Firmware (running on BIP Strong ARM)

Encoder / Decoder Monitor / Trigger

API/ACI/AMC/APM/APX1553 / MIL-STD-1553B specific H/W

PBA.pro Bus Analyzer

Software (optional)

Serial Interface



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 / Compilers

Operating Systems Compilers

Windows 2000 / XP / VISTA (32 bit)

Windows NT 4.0 (32 bit)

Microsoft Visual C/C++ (v6.0 or

higher) for 32-bit applications

Borland C/C++ (v5.02 or higher) for

32-bit applications

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 dynamic link library (DLL) containing the

collection of functions used to setup and command the AIM bus interface modules. A function

in a DLL 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. 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.



Figure 3.2.1-2 DLL and Program Interfaces

In order to support both the Microsoft Visual C/C++ and the Borland C/C++ compilers, the

api_mil.lib and api_mil.dll files are provided in two forms. These files are located

as follows:

a. Borland C/C++ Compiler version -

x:\Program Files\AIM GmbH\PCI

1553-Windows-BSP-

Vxxxx\bin\bc\win32.

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

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

Vxxxx\bin\msvc\ win32.

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.

api_mil.dll

ProgramC.exe

Program B.exe

Program A.exe

Program A api_mil.dll

The address of the function

is obtained from

api_mil.lib and it is used to

call the function.

3. Linkage to DLL function

1. Program A is loaded

2. api_mil.dll is loaded

Function



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 binary library and DLL 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 three C-syntax header files, located in x:\Program

Files\AIM GmbH\PCI-1553-Windows-BSP-Vxxxx\spg are provided:

a. Api1553.h

b. Ai_cdef.h

c. Ai1553i_def.h

d. Ai1553i_fnc.h

e. Api1553Cvi.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 two header files.

All header files need to be included in the search path 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 S/W Library Reference Manual for PCI 1553 Windows

Applications.

The DLL is created in _stdcall calling convention. To avoid problems, the application shall use

this calling convention, too!



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

Api1553.h

#include "Ai_cdef.h" #include "Ai1553i_def.h" #include "Ai1553i_fnc.h" #include "Ai1553Cvi.h"

Ai_cdef.h

data type definition

multi-platform support

Ai1553i_def.h

constant definition

structure definition

error code constants

Api1553Cvi.h

Like Ai1553i_def.h,

but needed for

use with LabWindows

Ai1553i_fnc.h

function defintion



3.2.3 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\PCI-1553-Windows-BSP-Vxxxx\read_dll.txt.

The BSP contains the following folders:

ANS – Utility file for setting up the ANS - the AIM Network Server – for remote access

to AIM modules.

bin – DLL and Import Library required to develop an application using the Borland or

MS Visual C++ compiler.

Doc – Reference manuals.

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

sample – Sample project for Borland and MS compiler.

spg – Header files used during compilation. Also contains several subfolders with

sample applications that demonstrate how to use the card in all modes of

operation.

SysDrv – Windows XP/2000/VISTA driver and the Windows NT driver.



3.2.4 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. See Table 3.2.3-I for a list of Library Administrative Functions.

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. See Table 3.2.3-II for a list of System Functions.

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

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

See Table 3.2.3-III for a list of Calibration Functions.

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. See Table 3.2.3-IV for a list of Buffer Functions. All of

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. See Table 3.2.3-V for a list of FIFO

Functions. All of 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. See Table 3.2.3-VI for a list of BC Functions.

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

for RT transfers. See Table 3.2.3-VII for a list of RT Functions.

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

Chronological recording of all or filtered data streams. See Table 3.2.3-VIII

for a list of BM Functions.

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

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

Table 3.2.3-IX for a list of Replay Functions.



Table 3.2.4-I Library Administration Function Descriptions

Function Description

ApiInit Initializes the API S/W Library Application Interface - performed first

ApiOpenEx Opens a stream on a AIM module and provides the handle for future board commands

ApiClose Closes AIM module interface - called last

ApiGetTgEmul Gets target command emulation state

ApiSetTgEmul Enables/disables target command emulation mode

ApiGetTcomStatus Gets target communication status of command execution

ApiGetOpenErr Gets error code after unsuccessful ApiOpenEx

ApiInstIntHandler Provides a pointer to the interrupt handler function

ApiDelIntHandler Removes the pointer interface to the interrupt handler function

ApiConnectToServer Establishes a network connection to a specified PC server where AIM Network Server (ANS) software is running.

ApiDisconnectFromServer Disconnects the network connection

ApiPrintfOnServer Prints message on console output of ANS console

ApiGetServerInfo Retrieves information about AIM boards installed on the ANS PC

ApiSetDllDbgLevel Sets the debug output level

ApiGetLibraryInfo Reads extended information about the current library settings

ApiGetBoardInfo Read extended information about the board capabilities.



Table 3.2.3-II System Function Descriptions


ApiCmdIni Initializes AIM board and returns board configuration

ApiCmdReset Resets the AIM board and ASP driver software data to initial state

ApiCmdBite Performs a selftest on the AIM board

ApiCmdDefRespTout Defines the response timeout value (default is 14 µsec)

ApiCmdReadSWVersion Reads software version of AIM board target software

ApiReadBSPVersionEx Returns the version # of all AIM board s/w package components

ApiCmdPSCTimerCon Configures up to 4 PCI and System Controller (PSC) s/w timers

ApiCmdTimerIntrCheck Reads the interrupt status of the selected PSC s/w timer

ApiCmdBiuIntrCheck Reads the interrupt status of the selected BIU

ApiCmdLoadSRec Downloads S-Record formatted strings to the AIM board target

ApiCmdProgFlash Inserts data into the AIM board on-board Flash-PROM

ApiCmdExecSys Executes a system-related function on the AIM board

ApiCmdSetIrigTime Sets the time of the on-board IRIG timecode encoder

ApiCmdGetIrigTime Reads the time on the on-board IRIG timecode encoder

ApiCmdDefMilbusProtocol Defines MILbus Protocol type (A or B) for individual or single RTs

ApiReadRecData Provides for the storing of data recorded by the BM function to an application buffer

ApiWriteRepData Writes and copies replay data

ApiCmdSystagDef Defines the generation of dynamic data words or datasets in BC and RT mode

ApiCmdSystagCon Suspends or resumes the generation of dynamic data words or datasets in BC and RT mode.

ApiCmdTrackDefEx Defines an area (track) in the 1553 Data Buffer to be copied and stored in a Shared memory area and multiplexed with tracks from subsequent buffers transmitted/received with the same XID/RT SA

ApiCmdTrackPreAlloc Pre-allocates the memory of a list of multiplex states

ApiCmdTrackScan Get information of all received multiplex states

ApiCmdTrackReadEx Reads the multiplexed 1553 message data defined as a track with ApiCmdTrackDefEx

ApiCmdSysSetMemPartition Configures the Global RAM of the board

ApiCmdSysGetMemPartition Reads the configuration of the Global RAM of the board

ApiCmdReadDiscretes Reads from the onboard discrete register

ApiCmdWriteDiscretes Writes to the onboard discrete register

ApiCmdInitDiscretes Initializes the onboard discrete behaviour

ApiCmdSyncCounterGet Reads all synchronization counter values

ApiCmdSyncCounterSet Initializes the synchronization counter value



Table 3.2.3-III Calibration Function Descriptions


ApiCmdCalCplCon Sets up the physical MILbus coupling mode

ApiCmdCalSigCon Enables/disables 1 Mhz square wave calibration test signal

ApiCmdCalTransCon Controls the data rate of MILbus (500 kbps or 1 Mbps).

ApiCmdCalXmtCon Modifies the output amplitude of the MILbus/test signal

Table 3.2.3-IV Buffer Function Descriptions


ApiCmdBufDef Defines the contents of the BC/RT transmit/receive message buffer

ApiCmdBufRead Reads the contents of the BC/RT transmit/receive message buffer

ApiCmdBufWrite Writes a data word/bits to variable positions of the BC/RT transmit/receive message buffer

ApiCmdRamWrite Writes data words to the AIM board global memory

ApiCmdRamRead Reads data words from the AIM board global memory

ApiCmdRamWriteLWord Writes data long word (32-bit) to the AIM board global memory

ApiCmdRamWriteWord Writes data word (16-bit) to the AIM board global memory

ApiCmdRamWriteByte Writes data byte (8-bit) to the AIM board global memory

ApiCmdRamReadLWord Reads data long word (32-bit) from the AIM board global memory

ApiCmdRamReadWord Reads data word (16-bit) from the AIM board global memory

ApiCmdRamReadByte Reads data byte (8-bit) from the AIM board global memory

ApiCmdRamWriteDataset Writes 32-word dataset to ASP Local RAM when in Dynamic Dataset mode

ApiCmdRamReadDataset Reads 32-word dataset from ASP Local RAM when in Dynamic Dataset mode

ApiReadMemData Reads a byte/word/longword from AIM board memory bypassing AIM board cmd/ack interface

ApiWriteMemData Writes a byte/word/longword to AIM board memory bypassing AIM board cmd/ack interface

ApiReadBlockMemData Reads a datablock from AIM board memory bypassing AIM board cmd/ack interface

ApiWriteBlockMemData Writes a datablock to AIM board memory bypassing AIM board cmd/ack interface

ApiCmdBufC1760Con Enables/Disables the generation of MIL-STD-1760 checksum

ApiBHModify Modifies the BC/RT buffer header on-the-fly



Table 3.2.3-V FIFO Function Descriptions


ApiCmdFifoIni Initializes up to 32 FIFOs, each with up to 128 32-word buffers, in shared ASP Local RAM for 1553 transfers

ApiCmdFifoWrite Loads/reloads buffers of a FIFO with data

ApiCmdFifoReadStatus Reads the status of the number of 16-bit words in FIFO to reload

ApiCmdBCAssignFifo Links a BC transfer to a FIFO. The FIFO becomes the source of the BC message buffer data transmitted.

ApiCmdRTSAAssignFifo Links an RT data transmission to a FIFO. The FIFO becomes the source of the RT message buffer data transmitted.



Table 3.2.3-VI Bus Controller Function Descriptions


ApiCmdBCAcycPrep Defines the properties of the acyclic "on-the-fly" BC transfers to be inserted into the BC framing sequence

ApiCmdBCAcycSend Starts the insertion of the acyclic transfers into the BC framing sequence "on-the-fly" or at a pre-defined time

ApiCmdBCBHDef Defines a BC Buffer Header ID, Buffer Queue size, Queue mode & error protocol

ApiCmdBCBHRead Reads the Data Buffer ID, Buffer Queue size, Queue mode, and error protocol of a BC Buffer Header ID

ApiCmdBCDytagDef Defines the generation of dynamic data words for BC transmissions

ApiCmdBCFrameDef Defines the sequence of 1553 transfers within a minor frame with options for inserting delays, strobe pulse outputs, and skip transfer instructions

ApiCmdBCGetDytagDef Read Dytag settings for the generation of dynamic data words for BC-RT transfer type or for BC broadcast transfer type

ApiCmdBCGetMajorFrameDefinition Read the sequence of Minor Frames within the Major Frame

ApiCmdBCGetMinorFrameDefinition Read the sequence of Bus Controller Transfers within a Minor Frame sequence

ApiCmdBCGetXferBufferHeaderInfo Get the buffer header id of given transfer

ApiCmdBCGetXferDef Get all transfer properties of a Bus Controller Transfer

ApiCmdBCHalt Stops BC transfers

ApiCmdBCIni Initializes the BC with information controlling # of retries and bus switching

ApiCmdBCInstrTblGen Provides an alternate method of defining minor and major frame sequences

ApiCmdBCInstrTblGetAddrFomLabel

Obtains the address of a BC Instruction Table entry pre-defined by the user using the ApiCmdBCInstrTblGen function

ApiCmdBCInstrTblIni Initializes the memory area associated with creating a BC Instruction Table for major and minor frame sequencing

ApiCmdBCMFrameDefEx Defines the sequence of minor fames within the major frame

ApiCmdBCSrvReqVecCon Set the sub address where the modecode “Last Vector Word” is sent to in case of a service request handling

ApiCmdBCSrvReqVecStatus Read BC Service Request and Vector Word Status information maintained by the BC for a specific RT

ApiCmdBCStart Starts the execution of pre-defined BC transfers within minor/major frame structure and defines minor fame timing

ApiCmdBCStatusRead Reads execution status of the BC

ApiCmdBCXferCtrl Enables/Disables the BC Transfer

ApiCmdBCXferDef Defines all transfer properties including source/destination information, error insertion and interrupt generation

ApiCmdBCXferReadEx Reads status of an individual BC transfer

ApiCmdBcModeCtrl Enable / disable various BC functionality on-the-fly



Table 3.2.3-VII Remote Terminal Function Descriptions


ApiCmdRTBHDef Defines an RT Buffer Header to be assigned to an RT SA/Mode code

ApiCmdRTBHRead Read the RT-SA buffer header structure

ApiCmdRTDytagDef Defines dynamic data to be inserted into the RT transmit Data words

ApiCmdRTEnaDis Enables/Disables a selected RT on the fly

ApiCmdRTGetDytagDef Read the Dytag settings for the generation of dynamic data words for a RT transmit SA

ApiCmdRTGetSABufferHeaderInfo Get the buffer header id of a certain RT/SA combination

ApiCmdRTGetSAConErr Read the error injection settings of the specified RT Sub-address/Mode code

ApiCmdRTGetSimulationInfo Read the simulation and monitoring status of an RT

ApiCmdRTGlobalCon Initializes multiple RTs at one time (combination of ApiCmdRTIni and ApiCmdRTSACon)

ApiCmdRTHalt Stops the RT operation for all assigned RTs

ApiCmdRTIni Initializes a select RT including configuration for simulation/mailbox mode, Response time and Next Status word

ApiCmdRTLCW Redefines the Last Command word associated with the RT

ApiCmdRTLSW Redefines the Last Status word associated with the RT

ApiCmdRTMsgRead Reads the individual RT's Next/Last Status word, Last Command word and message and error counter

ApiCmdRTMsgReadAll Reads the RT message and error counter for all 32 RTs

ApiCmdRTNXW Redefines the Next Status word associated with the RT

ApiCmdRTRespTime Redefines the Response time associated with the RT

ApiCmdRTSACon Defines the properties of the RT SA/Mode code such as interrupt control, and unique Next Status word setup

ApiCmdRTSAConErr Defines the error injection of the RT SA/Mode code

ApiCmdRTSAMsgReadEx Reads the execution status for an RT SA/Mode code

ApiCmdRTStart Starts the RT operation for all assigned RTs

ApiCmdRTStatusRead Reads the execution status of the general RT operation and the RT global message and error counters

ApiCmdRtModeCtrl Enable/disable various RT functionality on-the-fly



Table 3.2.3-VIII Bus Monitor Function Descriptions


ApiCmdBMActRead Reads BM Bus Activity transfer/error counters

ApiCmdBMCapMode Configures the Capture/Recording mode of the BM

ApiCmdBMDytagMonDef Define a dytag monitor id

ApiCmdBMDytagMonRead Read the actual dytag monitor status

ApiCmdBMFilterIni Disables the monitoring of specific RT SA/Mode codes

ApiCmdBMFTWIni Defines the bit pattern to be used by the BM to initiate a Start Trigger Event and/or Stop Trigger Event used for Start/Stop of the "Data Capture"

ApiCmdBMHalt Stopps the chronological BM operation

ApiCmdBMIllegalIni Sets up the BM to tag/not tag illegal command transfers to specific RT SA/Mode codes

ApiCmdBMIni Initializes the Bus Monitor

ApiCmdBMIniMsgFltRec Defines the command words used for filtering 1553 transfers to determine what data the BM will record when in Message Filter Recording Mode

ApiCmdBMIntrMode Enables/disables the generation of interrupt and strobe outputs for various BM conditions

ApiCmdBMReadMsgFltRec Retrieves multiple 1553 message transfers from the Monitor Buffer in one of four special formats (for data recorded in Message Filter Recording Mode)

ApiCmdBMRTActRead Reads the BM transfer/error counters for a specified RT

ApiCmdBMRTSAActRead Reads the BM transfer/error counters for a specified RT Subaddress

ApiCmdBMStackEntryFind Finds a specific BM entry in the Monitor buffer

ApiCmdBMStackEntryRead Obtains information about a specific BM entry in the BM buffer

ApiCmdBMStackpRead Obtains the BM buffer pointers to be used to index into the Monitor Buffer to read entries

ApiCmdBMStart Starts the chronological BM operation

ApiCmdBMStatusRead Reads the status of the BM

ApiCmdBMSWXMIni Enables the bits in the BM Status Word Exception Mask to be used by the BM to check the status word for errors/exceptions

ApiCmdBMTCBIni Sets up the Trigger Control Block which defines the conditions evaluated by the BM to generate a Start/Stop Trigger Event

ApiCmdBMTCIIni Defines the next Trigger Control Block to be evaluated for the next trigger

ApiCmdBMTIWIni Arms the BM with the Triggers to be evaluated

ApiCmdQueueFlush Flush the messages recorded while in Record with Queuing mode

ApiCmdQueueHalt Stops queueing bus data to the Monitor buffer

ApiCmdQueueIni Initializes the Record with Queueing process

ApiCmdQueueRead Read a queued 1553 transfer message in the Monitor buffer

ApiCmdQueueStart Starts queueing bus data to the Monitor buffer



Table 3.2.3-IX Replay Function Descriptions


ApiCmdReplayIni Initializes Replay interrupts, Time tag replay and defines the size of the data to be replayed

ApiCmdReplayStart Starts the Replay of data in the Replay buffer

ApiCmdReplayStop Stops the Replay of data in the Replay buffer

ApiCmdReplayStatus Reads the status of the Replay activity

ApiCmdReplayRT Disables replay of one or more specific RT(s)



3.2.5 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.4-1 shows the structure of a basic application

program and the API function categories associated with each major part of the program.



Figure 3.2.4-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

(2) Open Stream

(3) Optional interrupt handler

setup

Board Setup (1) Initialize device

(2) Define MILBus protocol(A or B) and Response

timeout

(3) Define MILBus coupling mode

(4) IRIG time setup

1

2

Library Administration Functions

System Functions

Module Handle

continued on next page…



BC Simulation Setup (1) Initialize the BC – retry mechanism, Service Request Control, define whether all

transfers use the same/different bus

(2) Define the properties of each BC-to-RT, RT-to-RT, RT-to-BC transfer to be simulated

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

4

5

Bus Monitor Setup (1) Initialize monitor

(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.

BM Functions Buffer Functions

3

BC Functions Buffer Functions

FIFO Functions

RT Simulation Setup

(1) Initialize the RT defining the RT's address, whether RT is simulated or

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

continued on next page…

RT Functions Buffer Functions FIFO Functions



7

Start RTs/BC

(1) Start all RTs

(2) Start the BC

6

Start Bus Monitor (1) Start receiving and/or monitoring the

MILBus data

BM Functions

Retrieve Status/Data (1) BC Status

(2) RT Status

(3) Retrieve Captured data

System Functions BC Functions RT Functions BM Functions

Replay Functions

9

Stop RT/BC/BM - Shutdown (1) Stop BC/RT/BM

(2) Uninstall any interrupt handlers

(3) Close each resource

Library Administration Functions BC Functions RT Functions BM Functions

8

RT Functions BC Functions



3.2.6 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.6.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.6.1-I. Our examples will utilize

the maximum value of 511 Transfer/Header IDs.

Table 3.2.6.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.6.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



Figure 3.2.6.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.6.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.



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

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

Buffer Pool for LS data

(32 x 16Bit words each buffer) 1 2 3 4

6 5

7

n-

n n-

n-

Queue of 4 buffers

The queue size can be selected as 2^k, where k can have a range from 0 to 8.

Note: The buffers are shared between BC, RT on both BIUs

BC - Status Queue

BC - Event Queue

received status words actual data buffer

control word

res

res res

control word

511 / BIU

time tag

RT Buffer Header RT - Status Queue

RT - Event Queue


control word

res

res res

control word

511 / BIU

time tag

User

Data

control word status queue pointer

Message buffer queue pointer

event queue

BC Buffer Header


data buffer queue

event queue

n :

See Table 3.2.6.1-II for

Buffer Id ranges.



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

Buffer Pool (Global RAM)

for 1553 data (32 x 16Bit words each buffer)

1 2 3 4

6 5

7

n-3

n n-1 n-2

Example 1: XFR 1 (BC-to-RT) uses 2 buffers. BC cycles through 128 32 word

buffers of assigned FIFO for each message transmitted by the BC

Example 2: XFR 2 (RT-to-BC) uses 1 buffer. RT cycles through three dynamic dataset buffers assigned for each message transmitted by the RT

n Board 2047 1553-1 4095 1553-2

1

2

3

4

6

5

7

32

One FIFO is a Queue of 128 32 16-bit word

buffers

FIFO Buffer Pool (ASP Shared RAM)

1 2 3 4

6 5

7

4095

Queue of 4095 32 16-

bit words

Dataset Buffer Pool

(ASP Shared RAM)

Data from a FIFO can be associated with 1553 transfers for BC or RT

message transmissions

Example 1: FIFO 2 is assigned to XFR 1

Total of 32 FIFOs

available

Example 2: Dataset 1-3 buffers are assigned to XFR 2

Data from Dataset buffers can be associated with

1553 transfers for BC or RT message transmissions

User

Data

n :

See Table 3.2.6.1-II for Buffer Id

ranges.



3.2.6.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.6.2-1 Major/Minor Frame Scheduling Diagram

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

Minor Frame 2 T1 T2 T3 T4 T6 ••• Tn


Minor Frame 4 T1 T2 T4 T6 ••• Tn




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

• •

•

• •

•

• •

•

Transfer 1 128 Transfers Max per Minor Frame

64 Minor Frames Max per Major Frame

Major Frame

512 Minor Frames Max per Major Frame


Section 4 – Programming Using the API Library Library Administration and System Programming

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

via AIM boards located on your PC

via 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



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 PC 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. Reference Section 5.2.1, LS_BC_RT_BM_Sample.c, for

additional examples of the function calls described in this section.

The basic Library Administrative and System functions supporting initialization &

shutdown include:

a. ApiInit (for local AIM boards) or ApiConnectToServer (for remote 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 local PC or remote system.

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

PC:

// Basic Initialization for Local AIM board(s) boardCount = ApiInit();

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

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.

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:

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 (or ApiConnectToServer) and the

ApiOpenEx functions, the AIM stream is ready to be commanded with all other

API S/W Library function calls.

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, or dual 1553)

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

state

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. 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.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.

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

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

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.

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

MILbus Output vs Vcontrol

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7 8 9 10 11 12

Vcontrol [V]

MIL

bu

s V

ou

t [%

]



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

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.

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; 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. 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.

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 userInterruptFunction( AiUInt32 ul_Module, AiUInt8 uc_LsHs, AiUInt8 uc_Type, TY_API_INTR_LOGLIST_ENTRY x_Info );

b. 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.



Table 4.1.7-I Available Interrupt Types and Related Function Call

Interrupt Indications in Loglist Entry

Interrupt Generation Setup ul_Lla ul_Llb ul_Llc ul_Lld Section

Reference

Bus Controller

ApiCmdBCXferDef

- End of Transfer

INT_TYPE, PGI, RBI

BC Xfr Descriptor Pointer

TRANS_ID Data Buf Index

- Transfer Error

INT_TYPE, AEI, RBI



- Status Word exception

INT_TYPE, UXI, RBI



ApiCmdBCFrameDef, ApiCmdBCAcycPrep

ApiCmdBCInstrTblGen

- Any transfer or instruction within a minor frame

INT_TYPE, PGI, RBI



ApiCmdBCStart

- On BC Halt when setup for non-cyclic transmission

INT_TYPE, BCH RBI



Remote Terminals

ApiCmdRTSACon

- End of Transfer INT_TYPE, PGI, RBI

RTSA/ModeCode Descriptor Ptr

RT_ADDR, T/R, RT_SUB, MODE_CODE

Data Buf Index

- Transfer Error INT_TYPE, AEI, RBI

RTSA/ModeCode Descriptor Ptr

RT_ADDR, T/R, RT_SUB, MODE_CODE

Data Buf Index

Bus Monitor

ApiCmdBMIntrMode

- Monitor Buffer Full or Half Buffer Full (Recording)

INT_TYPE, MBF Monitor Buffer Pointer

N/A N/A

- Capture Start INT_TYPE, MSI Monitor Buffer Pointer

N/A N/A

- Capture Stop or End of Selective Capture Event

INT_TYPE, MST Monitor Buffer Pointer

N/A N/A

ApiCmdBMTCBIni

N/A N/A

- Trigger Control block condition is true

INT_TYPE, MTI, TCBI

Monitor Buffer Pointer

N/A N/A

- Trigger on external event INT_TYPE, METI Monitor Buffer Pointer

N/A N/A

Replay

ApiCmdReplayIni

- Half Buffer Transmitted

Replay Buffer Pointer

N/A N/A



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.

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



Figure 4.1.7-1 Interrupt Setup Process

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.

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.

Delete the the host-to-AIM board

interrupt setup prior to the end of your

application using ApiDelIntHandler.

1

2

4

Setup the BC/RT/Bus Montitor/Replay

function(s) interrupt(s) as required by your

application (See Table 4.1.7-I)

3



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 S/W Library Reference Manual for

Windows Applications 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



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.


Section 4 – Programming Using the API Library Bus Controller Programming

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



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

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.6.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.6.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)

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.6.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.6.1-1 BC Buffer Header and Buffer Pool Interface

Buffer Pool for 1553 data

(32 x 16Bit words each buffer) 1 2 3 4 6 5

7

n-3

n n-1 n-2 Queue of

4 buffers The queue size can be selected as 2^k, where k can have a rang from 0 to 8.

n Board 2047 1553-1

BC Buffer

BC - Status Queue

BC - Event Queue


Message buffer queue pointer event queue pointer


control word

res

res res

control word

511 / BIU

time tag

User

Data

n :


Buffer Id ranges.



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

BC Transfer

Structure

Element in

api_bc_xfer

Definition CW

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



The following excerpt of code from the LS_BC_RT_BM_Sample.c sample program (Section

4.2.1) 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) 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.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type*/ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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);

One message buffer(Buf_id = 2)

is then assigned to this transfer.

(Queue size is set to 1)

BC-to-RT xfer

RT1 SA1

word count = 4



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

with word count

of 2

RT-to-BC Xfer to

RT02, SA03 with

word count of 5

Mode code Xfer

to RT05 SA0

where mode code

= 17

(synchronize)

RT-to-RT Xfer

from RT04 SA2 to

RT03 SA1 with

word count = 32

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.



Table 4.2.3.1-I BC Transmit Buffer Fill Method Summary

BC Transmit Message Source

Functions Used Other Examples

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)

LS_BC_RT_BM_Sample.c

With Dynamic Data Words

1. ApiCmdBCBHDef 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 Dataset Buffers

1. ApiCmdBCBHDef 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 handler routine to interrupt on end-of-transfer

See Section 4.2.7

The Dynamic Data Word Generation method and the FIFO and Dynamic Dataset methods are

described further in the following sections.



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)



Figure 4.2.3.1.1-1 Data Generation Functions Diagram

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.

Upper Limit

Lower Limit

Start

Positive Ramp Function Upper Limit

Lower Limit

Start

Negative Ramp Function

Upper Limit

Lower Limit

Start

Positive Triangle Function

Upper Limit

Lower Limit

Start

Negative Triangle Function



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

4.2.3.2



1 2 3 4

6 5

7

n-3

n n-1 n-2




n Board 2047 1553-1 4095 1553-2

1

2

3

4

6

5

7

32


buffers


1 2 3 4

6 5

7

4095

Queue of 4095 32 16-

bit words

Dataset Buffer Pool

(ASP Shared RAM)




Total of 32 FIFOs

available




User

Data

n :

See Table 3.2.6.1-II for Buffer

Id ranges.



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.



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 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.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 = 15; /* 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 Request Handling */ api_bc_xfer.rte = API_DIS; /* Retry disabled */ api_bc_xfer.res = 0; /* Reserved */ 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 */

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 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 Defining Minor/Major Frame Content & Timing - Standard Framing Mode

In Standard Framing mode, the API/ACI1553 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


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

minor/major frames

using the Standard

Framing 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.

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;

Minor Frame 1 T1 T2 Minor Frame 2 T1

Transfer

Major Frame T3 T4

Wait 1

W1

Minor Frame Time = 10 ms



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*/

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 Defining Minor/Major Frame Content & Timing - 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

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


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.

API_BC_FWI_RET Return from Subtable - used to return to the main BC Instruction Table entry following the related API_BC_FWI_CALL opcode.

API_BC_FWI_JUMP Jump to Subtable / Instruction - absolute jump to an Instruction Table entry identified by a label.

API_BC_FWI_SKIP Relative Branch (Skip) - skip a user-specified number of instructions

API_BC_FWI_WTRG Wait for BC Trigger input - ties the external pulse to start of minor frames, or starts execution of the major frame based on the external pulse

API_BC_FWI_STRB Strobe BC Trigger output - instruction to output a strobe signal

API_BC_FWI_DJZ

Decrement and Jump on Zero - When using non-cyclic major frame (as specified in ApiCmdBCStart) you can jump to a label in the BC Instruction Table when the major frame counter is decremented to zero.

API_BC_FWI_WMFT Wait for next Minor Frame Time slot - instruction to wait until the next minor frame time slot begins, then continue with the following entry in the BC Instruction Table

API_BC_FWI_HALT BC Operation Halt - Halt the BC

API_BC_FWI_DELAY Delay - delay the execution of the next entry in the BC Instruction Table by a user-specified time

API_BC_FWI_CMFT Change Minor Frame Time - instruction to change the minor frame time "on-the-fly" to a user-specified value.

API_BC_FWI_RESMF Reset Major Frame - instruction to swap between several different major frames in one BC 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

example defines

minor/major frames

using the BC

Instruction Table

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).

Minor Frame 1 T1 T2 Minor Frame 2 T1

Transfer

Major Frame T3 T4

Wait 1

W1



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].label = 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*/, 8 /*# of entries*/,8 /*dest_cnt*/, 0L/*dest_offset*/,instr_tbl, ctbl, &line, &rval);



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.



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.



Figure 4.2.6-1 Minor Frame Timing Control Diagram

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

Transfer Sequence within the Major Frame: i, j, k, ..., n, WAIT-

Minor Frame

MFT: Minor Frame

Transfer i Transfer j Transfer k Transfer n

BC Start / Re-Starts

WAIT-MFT Wait for Minor

Frame Time

BC Transfer Frame (Minor

BC starts / re-starts automatically

(Autoframing

BC Transfer Cycle (Major

Minor Frame i

Major Frame

Minor Frame Sequence within the Major Frame: i, j, k, ...,

Minor Frame j

Minor Frame

k

Minor Frame n

MFMFMFMF

MFT: Minor Frame



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

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

Wait Instruction

BC Trigger Input, minimum pulse width: >75ns

BC Transfer Cycle (Major Frame)

1553 messages

Minor Frame i

WAIT x-us

Major Frame (Cycle)

Minor Frame Sequence within the Major Frame: i , j, k, ..., n

Minor Frame j

WAIT x-us

Minor Frame k

WAIT x-us

Minor Frame n

WAIT x-us

BC Trigger Input, minimum pulse width: >75ns

BC Transfer Cycle (Major Frame)

1553 messages

Minor Frame i

Major Frame (Cycle)

Minor Frame Sequence within the Major Frame: i, j, k, ..., n

Minor Frame j Minor Frame k Minor Frame n



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);



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_BC_Acyclic_Xfers_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);



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 Software Library Reference

Manual for Windows Applications.

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



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


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

Remote Terminal Address

Mes

sag

e E

rro

r

Inst

rum

enta

tio

n

Ser

vic

e re

qu

est

Reserved

Bro

adca

st

Co

mm

and

rece

ived

Bu

sy

Su

b S

yst

em F

lag

Dy

nam

ic B

us

Co

ntr

ol

Acc

epta

nce

Ter

min

al F

lag

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.



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

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



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

1553 BC Transfer Definition Parameters

Interrupt on Message Error in RT Status Word

Halt the BC on Instrumentation Error in RT Status Word

Interrupt on Busy set or Message Error in RT Status 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_EXCEPT

API_BC_HLT_NO_HALT

api_bc_xfer.tic API_BC_TIC_ON_STATUS_EXCEPT

API_BC_TIC_NO_INT API_BC_TIC_ON_STATUS_EXCEPT

api_bc_xfer.swxm 0x0400 (See Status Word Exception Mask below)

0x0200 (See Status Word Exception Mask below)

0x0408 (See Status Word Exception Mask below)

api_bc_xfer.rsp API_BC_RSP_AUTOMATIC API_BC_RSP_AUTOMATIC API_BC_RSP_AUTOMATIC


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)

Mes

sag

e E

rro

r

Inst

rum

enta

tio

n

Ser

vic

e re

qu

est

Reserved (0)

Bro

adca

st

Co

mm

and

rece

ived

Bu

sy

Su

b S

yst

em F

lag

Dy

nam

ic B

us

Co

ntr

ol

Acc

epta

nce

Ter

min

al F

lag

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



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

ID

BC Response BC Setup Required

Request Single

RX/TX

(1000/1001)

A pre-defined transfer is executed once

immediately (acyclic) after receipt and

decoding of the vector word.

ApiCmdBCXferDef - setup a

vector word driven transfer for

this request with parameter sxh

= 1.

Request

Multiple

RX/TX

(1010/1011)

A pre-defined transfer is appending to

the end of the current BC minor frame

(Cyclic execution until disabled).

ApiCmdBCXferDef - setup a

vector word driven transfer for

this request with parameter sxh

= 2

Delete RX/TX

(1100/1101)

The related BC transaction is disabled

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.



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

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.)

........

....

....

Track Multiplex

Buffer ID 0

T1 Track

(at Index 0)

T1 Track

(at Index 1)

T1Track

(at Index 7)

T11

Data Buffer = 32 words

Track

21 words 00

Track

Multiplex

Buffer

Index

(at

location

word 5

bits 13-15)

T12


Track

21 words 01

T1n


Track

21 words 07



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.


Section 4 - Programming Using the API Library Remote Terminal Programming

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.4-IV, 3.2.4-V, 3.2.4-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



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


Mes

sag

e

Err

or

Inst

rum

enta

ti on

Ser

vic

e

req

ues

t

Reserved

Bro

adca

st

Co

mm

and

rece

ived

Bu

sy

Su

b S

yst

em

Fla

g

Dy

nam

ic B

us

Co

ntr

ol

Acc

epta

nce

Ter

min

al

Fla

g

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 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

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

Buffer Pool for 1553 data

(32 x 16Bit words each buffer)

1 2 3 4

6 5

7

n-

n n-

n-

Queue of 4 buffers

The queue size can be selected as 2^k, where k can have a range from 0 to 8.

n Board 2047 1553-1 4095 1553-2

Note: The buffers are shared between BC, RT on

RT Buffer RT - Status Queue

RT - Event Queue


data buffer queue

event queue


control word

res

res res

control word

511 / BIU

time tag

User

Data

n :


Buffer Id ranges.



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


Mes

sag

e E

rro

r

Inst

rum

enta

tio

n

Ser

vic

e re

qu

est

Reserved

Bro

adca

st

Co

mm

and

rece

ived

Bu

sy

Su

b S

yst

em F

lag

Dy

nam

ic B

us

Co

ntr

ol

Acc

epta

nce

Ter

min

al F

lag

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.

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 parameters

Broadcast

Xfer with

word count

of 2

RT-to-BC

Xfer to

RT02, SA03

with word

count of 5

Mode code Xfer

to RT05 SA0

where Mode code

= 17

(synchronize)

RT-to-RT Xfer from RT04

SA2 to RT03 SA1 with

word count = 32

Remote Terminal 31 2 5 4 3

Subaddress/ Mode code

1 - 30 3 17 2 1

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 Control

x x x * *

Status Word Mask Control

x x x x x

Status Word Mask x x x x x


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.



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:



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.

Upper Limit

Lower Limit

Start

Positive Ramp Function Upper Limit

Lower Limit

Start

Negative Ramp Function

Upper Limit

Lower Limit

Start

Positive Triangle Function

Upper Limit

Lower Limit

Start

Negative Triangle Function



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:

polling at pre-defined intervals to examine the RT data, or setting up the transfer to interrupt at



1 2 3 4

6 5

7

n-3

n n-1 n-2




n Board 2047 1553-1 4095 1553-2

1

2

3

4

6

5

7

32


buffers


1 2 3 4

6 5

7

4095

Queue of 4095 32 16-

bit words

Dataset Buffer Pool

(ASP Shared RAM)




Total of 32 FIFOs

available




User

Data

n :


Buffer Id ranges.



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 Message Source

Functions Used Other Examples

Fixed Data 1. ApiCmdRTBHDef 2. ApiCmdRTSACon 3. ApiCmdBufDef to initialize buffer with fixed data words

(or ApiCmdBufWrite to initialize a buffer with a single 16-bit word)


With Dynamic Data Words

1. ApiCmdRTBHDef 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 Dataset Buffers

1. ApiCmdRTBHDef 2. ApiCmdRTSACon 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



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).



Table 4.3.2.2-I Mode Codes

T/R Bit

Mode

Code Function

Associated

Data Word

Broadcast

Command

Allowed

1 00000

Dynamic Bus

Control N N

1 00001 Synchronize N Y

1 00010

Transmit Status

Word N N

1 00011 Initiate Self Test N Y

1 00100

Transmitter

Shutdown N Y

1 00101

Override

Transmitter N Y

1 00110

Inhibit Terminal

Flag Bit N Y

1 00111

Override Inhibit

Terminal Flag Bit N Y

1 01000 Reset RT N Y

1 01001 Reserved N TBD

1 01111 Reserved N TBD

1 10000

Transmit Vector

Word Y N

0 10001 Synchronize Y Y

1 10010

Transmit Last

Command Y N

1 10011

Transmit BIT

Word Y N

0 10100

Selected

Transmitter Y Y

0 10101

Override Selected

Transmitter Y Y

1 or 0 10110 Reserved Y TBD

1 or 0 11111 Reserved Y TBD



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:

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


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




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

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;

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*/);



4.3.4 RT Interrupt Programming

As introduced in Section 4.1.7, the RT is capable of producing interrupts upon the occurrence


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



Table 4.3.4.1-I Setup for RT Transfers to Generate Interrupts

RT Transfer Definition Parameters

ApiCmdRTSACon parameters

End of Transfer Interrupt Transfer Error Interrupt

Remote Terminal 0 - 31 0 - 31

Subaddress/ Mode code

1 - 30 1 - 30

Header ID 1 – 511* 1 – 511*

Subaddress Type any any

Subaddress Control API_RT_ENABLE_SA_INT_XFER API_RT_ENABLE_SA_INT_ERR


See Section 5.2.2, LS_Interrupt_Sample.c for an example of how to program the RT to

"interrupt on end of transfer" and "interrupt on transfer error", and how to setup an interrupt

handler service routine to handle those interrupts.

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.



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.

........ ..

....

..

Track Multiplex

Buffer ID 0

Track

(at Index 0)

Track

(at Index 1)

Track

(at Index 7)

RT1 SA1 RX


Track

21 words 00

Track

Multiplex

Buffer

Index

(at

location

word 5

bits 13-15)

RT1 SA1 RX


Track

21 words 01

RT1 SA1 RX


Track

21 words 07



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.


Section 4 - Programming Using the API Library Bus Monitor Programming

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.4-V, and 3.2.4-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

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.



Table 4.4-I Bus Monitor Modes and Output Format Summary

Capture

Mode

Usage Structure to Read

Monitor Data

Output Format Characteristics

Standard

Data

Capture

When you want to

record the user-

specified bus traffic

before and after the

Start Trigger Event,

but also want to know

which word caused the

Start Trigger Event.

RT-specific filters still

an option.

typedef struct ty_api_bm_stack_dsp AiUInt32 entry; TY_API_BM_STACK_DSP;

Each 16-bit word transmitted on the bus is

tagged with the following information:

1. Type of word and on what bus received

2. Time since the last word was received

3. IRIG time tag

4. If error, type of error

5. Start Trigger Event flag

After obtaining the pointer into the Monitor

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

Data

Capture

When you want to

capture only message

traffic immediately

following the trigger

for a certain number of

messages.

RT-specific filters are

still an option.

Same as Standard Data

Capture Mode.

Same as Standard Data Capture Mode.

Recording When you need

continuous data

recording. Mainly

used for replay or post-

processing data

analysis.


still an option.

typedef struct ty_api_bm_rec AiUInt8 status; AiUInt8 padding1; AiUInt16 padding2; AiUInt32 hfi_cnt; AiUInt32 saddr; AiUInt32 size; TY_API_BM_REC;

Data is recorded in the same format as

defined for Standard and Selective Data

Capture Modes.

ApiReadRecData function can be issued at

the Half 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.

Note: Message Filter Recording Formats

3/4 can be used when in this

capture mode to retrieve multiple

msgs.



Table 4.4-I Bus Monitor Modes and Output Format Summary (Continued)

Capture

Mode

Usage Structure to Read

Monitor Data

Output Format Characteristics

Recording

using

Queuing

When you want to

record the user-

specified bus traffic

and read one single

entire transfer at a

time. Triggers are

applicable in this

mode.


still an option.

typedef struct ty_api_queue_buf AiUInt8 rt_addr; AiUInt8 sa_mc; AiUInt8 sa_type; AiUInt8 word_cnt; AiUInt8 rbf_trw; AiUInt8 padding1; AiUInt16 msg_trw ; AiUInt16 buffer[32]; AiUInt32 ttag; TY_API_QUEUE_BUF;

Recorded data is stored in a manner that

allows you to read a single 1553 transfer

from the head of the message queue. Each

transfer stored contains the following

information:

1. Time tag (seconds and microseconds)

2. Message error information

3. Command

4. Status word

5. Data words.

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

Filter

Recording

When your application

calls for reading

multiple 1553

transfers.

As an option, you can

filter the data recorded

based on command

word values. You can

filter using up to 40

command word values.

Triggers can be used to

define the start of the

read monitor data

process.


still an option.

No data structure is used for

reading recorded data in this

mode.

Recorded data is stored in a manner that

allows you to read multiple transfers. Each

recorded message transfer recorded contains

the following information:

1. IRIG time or (milliseconds &

microseconds)

2. Message Error information

3. Status word value

4. Command word value

5. Data words

Four available output formats specified

providing:

Format 0 - LS-byte first with milli- and

microseconds

Format 1 - MS-byte first with milli- and

microseconds

Format 2 - LS-byte first with IRIG time

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.



Table 4.4-II Bus Monitor Modes and Function Summary

Capture

Mode

BM functions

(minimum needed)

Start Trigger

Event

Stop Trigger

Event

Read Monitor Data

functions Standard

Data

Capture

ApiCmdBMIni

ApiCmdBMIntrMode

ApiCmdBMCapMode = 0

ApiCmdBMTCBIni for each

trigger *

ApiCmdBMFTWIni *

ApiCmdBMTIWIni *

ApiCmdBMStart

ApiCmdBMHalt

FTW Start

Trigger Mask =

Monitor Status

Trigger pattern

TATC = 0 or

FTW Stop

Trigger Mask =

Monitor Status

Trigger pattern

ApiCmdBMStackpRead +

ApiReadBlockMemData

or


ApiCmdBMStackEntryRead

or

ApiCmdBMReadMsgFltRec

(Format 3/4)

Selective

Data

Capture

ApiCmdBMIni

ApiCmdBMIntrMode

ApiCmdBMCapMode = 1


trigger

ApiCmdBMFTWIni

ApiCmdBMTIWIni

ApiCmdBMStart

ApiCmdBMHalt

FTW Start

Trigger Mask =

Monitor Status

Trigger pattern

Message Capture

Counter = 0 or

TATC = 0 or


ApiReadBlockMemData

or



or


(Format 3/4)

Recording ApiCmdBMIni

ApiCmdBMIntrMode

ApiCmdBMCapMode = 2

ApiCmdBMStart

ApiCmdBMHalt

N/A N/A ApiReadRecData

or


(Format 3/4)

Recording

using

Queuing

ApiCmdBMIni

ApiCmdBMIntrMode

ApiCmdQueueIni

ApiCmdQueueStart

ApiCmdBMHalt

N/A N/A ApiCmdQueueRead

Message

Filter

Recording

ApiCmdBMIni

ApiCmdBMIntrMode

ApiCmdBMCapMode = 3


trigger *

ApiCmdBMFTWIni *

ApiCmdBMTIWIni *

ApiCmdBMIniMsgFltRec

ApiCmdBMStart

ApiCmdBMHalt

N/A

or

FTW Start

Trigger Mask =

Monitor Status

Trigger pattern *

N/A ApiCmdBMReadMsgFltRec

(Formats 0 - 2)

* Optional



The sample Program, LS_BC_RT_BM_Sample.c in Section 5.2.1 provides an example of Bus

Monitor setup and control. LS_BC_RT_FW_Sample.c also provides sample software involved

in programming the BM.

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 ApiCmdBCIni 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

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.

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

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.



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.



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: 0 - Error Condition 1 - External Event 2 - Received Word 3 - Data Value

All

api_bm_tcb.sot Generate External Strobe on Trigger

All

api_bm_tcb.tri Generate Interrupt on Trigger

All

api_bm_tcb.inv Invert Result of Limit Check Data Value Trigger only

api_bm_tcb.tres Trigger Reset - the bits in the Monitor Status Trigger pattern to be reset when the trigger condition is met

All

api_bm_tcb.tset Trigger Set - the bits in the Monitor Status Trigger pattern to be set when the trigger condition is met

All

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 on End of Message

Data Value Trigger & Received Word Trigger

api_bm_tcb.tdw Trigger Data word Error Condition Trigger & Received Word Trigger

api_bm_tcb.tmw Trigger Mask - defines bits of word relevant to Received word or Data value trigger

Data Value Trigger & Received Word Trigger

api_bm_tcb.tuli Trigger Upper Limit - for range checks of Data Value Triggers

Data Value Trigger

api_bm_tcb.tlli Trigger Lower Limit - for range checks of Data Value Triggers

Data Value Trigger

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



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 ID BBiitt

## EErrrroorr DDeessccrriippttiioonn

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



Table 4.4.3.1.1.1-II TCB Parameters for Error Condition Trigger

Trigger Control Block Parameter Definitions Applicable to Error Condition Trigger


0


If desired


If desired


See Section 4.4.3.2 for description

on how to setup



on how to setup

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);



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


1


If desired


If desired


See Section 4.4.4 for description

on how to setup

api_bm_tcb.tset Trigger Set - the bits in the Monitor Status Trigger pattern be set when the trigger condition is met

See Section 4.4.4 for description

on how to setup

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.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




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



ELSE Return to TCB1 Evaluation (EOM TCB)

IF TCB3 [Received word = Command Word = Data Value]

THEN



ELSE Return to TCB1 Evaluation (EOM TCB)

IF TB4 [Data Word 6 Bit 5 AND Bit 8 Set]

THEN


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

Parameter

Bit ID BBiitt

## RReecceeiivveedd WWoorrdd DDeessccrriippttiioonn

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)]



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


3


If desired


If desired



on how to setup



on how to setup

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.)


Next TCB to evaluate if this

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


Set the bits of this word to show

the bits of the received word that

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.)



// 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.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


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:

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.

[(Received Bus Word AND Trigger Mask word) >= Lower limit ] AND [(Received Bus

Word AND Trigger Mask word) <= Upper limit ]



Table 4.4.3.1.2.2-I TCB Parameters for Dynamic Data Value Trigger

Trigger Control Block Parameter Definitions Applicable to Data Value Trigger


3


If desired


If desired

api_bm_tcb.inv Invert Result of Limit Check If required



on how to setup



on how to setup

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.)


TCB to evaluate if this 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 data word the BM

is setup to compare to


Set the bits of this word to show

the bits of the data word that are

relevent to the word compare

api_bm_tcb.tuli Trigger Upper Limit - for range checks of Data Value Triggers

Upper limit of the data value to

check

api_bm_tcb.tlli Trigger Lower Limit - for range checks of Data Value Triggers

Lower limit of the data value to

check

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.)



// 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.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


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".



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

Reserved

Stop Trigger Compare

or

Reserved.

Start Trigger Mask Start Trigger Compare

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

Sta

rt T

rig

ger

Mask

Sta

rt T

rig

ger

Co

mp

are

Sto

p T

rig

ger

Mask

Sto

p T

rig

ger

Co

mp

are

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 0xFFCapture 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 0xFFCapture 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 0xFFCapture all entries between the

occurance of the first TCB and the last

TCB in a dynamic sequence of 10

TCBs. 0x0F 0xFF Start Trigger Event

Stop Trigger Event or

TATC = 0 Standard 100000 N/A 0x0F 0x0F 0xFF 0xFFCapture 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

Function Trigger Word

Scenario "tset"

para

mete

r

in 1

st

TC

B

defi

nit

ion

"tset"

para

mete

r

in last

TC

B

defi

nit

ion

Data Capture Start Data Capture Stop

Capture

Mode Tra

ce A

fter

Tri

gg

er

Co

un

ter

(TA

TC

)

Messag

e

Cap

ture

Co

un

t



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.



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

TCB Index

Sequence Trigger 0

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


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



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

Mode Ca

ptu

re S

tart

Ca

ptu

re S

top

Bu

ffer

F

ull

/

Ha

lf F

ull

Tri

gg

er

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 is included in Section 4.2.2 and provides an

example of BC and RT Interrupt Handling programming.



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

Type:

Entry

Type

Definition General 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.



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

Time:

Gap Time Value - The Gap Time value reports the time between the current

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

Word:

Received MILbus Word - The received MILbus includes Word which was

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 minute 0 to 59

Microseconds of second 0 to 999999

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 1 to 365

Hours of day 0 to 23

Minutes of hour 0 to 59



Figure 4.4.5-5 Error Word Entry

Error Word Entry (Entry Type 1h)

26 25 .......................... 18 17 16 15 ................................................................................ 0

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

Type

Field:

The Error Type field indicates error type which was detected during the receive

operation of the related, received word.* If set, the indication is as follows:

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



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

The BIU Processor stores in the Monitor Buffer the following entries.

Relative

Byte

Address

Flags Entry

Type

Code

Entry Type Description

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

Primary Bus

(Bus Word Entry)

Command Word 1 with Gap

Time if time to previous word <

108µs.

Ch Ah Data Word on Primary

Bus

(Bus Word Entry)

Data Word.

10h ECON = 1 Bh Status Word on

Primary Bus

(Bus Word Entry)

Status Word with Gap Time if

time to previous word < 108µs.

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

Primary Bus

(Bus Word Entry)

Command Word 2 with Gap

Time if time to previous word <

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

Monitored Message on Primary MILbus

k RT response Time

# BC Intermessage Gap

Command Data Status with Error Command k #



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 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.)



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:

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.

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.


Section 5 - Program Samples

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:



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 following sample 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.

/************************************ Some Macros and defines ************************************/ //Half Buffer size = 0x10000 #define HALF_BUFF_SIZE 0x10000 AiUInt16 boardCount,retVal; AiUInt32 bytes_written; AiInt32 bytes_read,reload; AiUInt32 rep_buf[HALF_BUFF_SIZE]; AiUInt32 prev_rpi_cnt; AiUInt32 diff; TY_API_INI_INFO api_ini_info; TY_API_RESET_INFO api_res_info; TY_API_REP_STATUS api_rep_stat; AiInt32 file_size; FILE *rep_fp; char replay_fname[100]="sam_rec.prc";



// Open previously recorded file "sam_rec.prc" rep_fp = fopen(replay_fname,"rb"); if ( rep_fp != NULL) file_size = filelength( fileno ( rep_fp ) ); // Initialize the Replay to replay only Low Time Tag, and to assert // a half buffer transmitted interrupt // replay full file size of "sam_rec.prc" ApiCmdReplayIni( ApiModuleHandle, 0, 1/*cet*/, 0/*nct*/, 0 /*cyc*/, 0/*nimg*/, 0/*alt*/, 0/*rlt*/, 1 /*rint*/, 0L/*min*/, 0/*msec*/, 1/*sign*/, file_size ); // Read one halfbuffer from the file. bytes_read = fread( rep_buf, sizeof(AiUInt8), HALF_BUFF_SIZE, rep_fp ); if( bytes_read > 0 ) // Get the number of entries to be replayed. ApiCmdReplayStatus( ApiModuleHandle, 0, &api_rep_stat ); // Calculate the number of required half buffer reloads. reload = api_rep_stat.entry_cnt * 4 / HALF_BUFF_SIZE; // Check if we need one more reaload in the end which is smaller than 0x10000. if( api_rep_stat.entry_cnt * 4 % HALF_BUFF_SIZE ) reload++; printf("Status: rpi_cnt:%3ld entry_cnt:%7ld (Required reloads:%3ld)\r\n", api_rep_stat.rpi_cnt, api_rep_stat.entry_cnt, reload ); // Pre-fill the replay buffer. // Set the number of bytes to copy to the replay buffer. // This is normally 0x10000, only the last buffer may be of a smaller size. api_rep_stat.size = bytes_read; // Copy the data read from the file to the 1st half of the Replay Buffer ApiWriteRepData( ApiModuleHandle, 0, &api_rep_stat, rep_buf, &bytes_written ); reload--; // Read the next data block from the file. bytes_read = fread( rep_buf, sizeof(AiUInt8), HALF_BUFF_SIZE, rep_fp ); if( bytes_read > 0) // Pre-Fill the second half of the replay buffer. api_rep_stat.size = bytes_read; ApiWriteRepData( ApiModuleHandle, 0, &api_rep_stat, rep_buf, &bytes_written ); reload--; // Start the replay of data to the 1553 MILbus ApiCmdReplayStart(ApiModuleHandle,0); prev_rpi_cnt = 0; while(1) ApiCmdReplayStatus( ApiModuleHandle, 0, &api_rep_stat ); printf("Status : rpi_cnt:%3ld entry_cnt:%7ld (Required reloads:%3ld)\r", api_rep_stat.rpi_cnt, api_rep_stat.entry_cnt, reload );



if ( api_rep_stat.entry_cnt == 0) printf("\r\nReplay finished.\r\n"); break; // check for replay overflow diff = api_rep_stat.rpi_cnt - prev_rpi_cnt; if(diff > 1) /* We reloaded the buffer to slow. A overflow occurred. */ printf("Overflow\r\n"); break; if(diff == 1) if(reload > 0) // read data from file bytes_read = fread( rep_buf, sizeof(AiUInt8), HALF_BUFF_SIZE, rep_fp ); if ( bytes_read < 1) printf("\r\n End of file reached:""%s""\r\n", replay_fname); break; api_rep_stat.size = bytes_read; // refill inactive half replay buffer ApiWriteRepData( ApiModuleHandle, 0, &api_rep_stat, rep_buf, &bytes_written ); reload--; prev_rpi_cnt++; AIM_WAIT(2000); else printf("\r\n End of file found:""%s""\r\n", replay_fname ); else printf("\r\n End of file found:""%s"" \r\n", replay_fname ); ApiCmdReplayStop( ApiModuleHandle, 0 ); printf("\r\nApiCmdReplayStop() done.\r\n"); fclose(rep_fp); else printf("\r\n Open File:""%s"" failed !!\r\n", replay_fname);



5 PROGRAM SAMPLES

Within the API/ACI1553 software package exists several sample programs which can be used

by program developers as examples for learning and developing their code. This section will

discuss the following:

a. Overview of Sample Programs

b. Description of Each Sample Program

c. Program listing for two samples:


LS_Interrupt_Sample.c

d. Matrix of all API S/W Library Calls vs. Sample Programs

All sample C/C++ source files are located in the spg program folder:

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

In order to run a sample project, please refer to the associated Getting Started Manual.

5.1 Program Samples Overview

Table 5.1-I provides a list of the sample programs included in your board support package and

a description of the function of the program. You may choose to use one or more sample

programs as a starter program to be modified if they accomplish the tasks required for your

application.



Table 5.1-I Program Samples Overview

Interrupt_Sample.c (Table 5.1.1-I and Section 5.2.2) - This sample demonstrates how to setup BC

and RT interrupts such that a defined action can be taken upon the occurrence of the interrupt.

The interrupt can be setup in various ways. In this case, the interrupt will occur upon "end of

1553 transfer" for the BC transfers, and will occur on "any transfer" for the RT interrupts

defined. Two interrupt handlers are contained in the sample one for the RT and one for the BC.

LS_BC_Acyclic_Xfers_Sample.c (Table 5.1.1-II) - This sample demonstrates how to setup the BC

for acyclic transfers, i.e. - transfers that will occur upon an external event.

LS_BC_Dynamic_Data_Dytag_Sample.c (Table 5.1.1-III) - This sample demonstrates how to

setup the BC data word transfers to include words that change dynamically based on programmer

chosen algorithms.

LS_BC_Dynamic_Data_Systag_Sample.c (Table 5.1.1-IV) - This sample demonstrates the use of

the AIM Buffer function which will generate a buffer queue of three 32-word datasets to be used

in a cyclic fashion for a BC 1553 transfer.

LS_BC_External_BC_Trigger_Sample.c (Table 5.1.1-V) - This sample demonstrates how to setup

the BC to begin transfers upon the occurrence of an external trigger.

LS_BC_Fifo_Sample.c (Table 5.1.1-VI) - This sample demonstrates how to use FIFOs (a FIFO is a

queue of 128 32-word buffers), instead of message buffers, for the data words transmitted in the

1553 BC and/or RT transfer.

LS_BC_Multibuffer_Sample.c (Table 5.1.1-VII) - This sample demonstrates how to setup the BC

to cycle through a sequential set of message buffers to be used to obtain the data words for a

cyclic 1553 transfer.

LS_BC_RT_BM_Sample.c (Table 5.1.1-VIII and Section 5.2.1) - This sample demonstrates

several device management and system functions including network connections, API self-test,

IRIG time setup and response time setup. It also demonstrates how to define BC and RT 1553

transfers and setup minor and major frame cycles. Triggers for the Bus Monitor function are

also demonstrated.

LS_BC_RT_FW_Sample.c (Table 5.1.1-IX) -This sample is the same as

LS_BC_RT_BM_Sample.c except it provides the following compiler options:

USE_BIU1 - indicating use of BIU1 (default will be BIU2)

USE_MONSTER_SETUP - indicating that the maximum number of BC Transfers will be setup

for BC to RT31 SA1.

USE_STD_FRAMING - indicating the use of the standard frame definition functions

(ApiCmdBCFrameDef and ApiCmdBCMFrameDefEx) and transfers as defined below. If

not specified, use of instruction tables for minor/major frame definitions

(ApiCmdBCInstrTblxxx) will be utilized and setup identical to the standard framing setup.

If Instruction tables are used to define the framing, then if USE_MONSTER_SETUP was not

indicated, the transfers as defined below will occur, otherwise, the maximum number of BC

transfers allowed will be included in the instruction tables, transfered once to RT31SA1, then

the BC will be halted.

USE_SET_MEM - demonstrates the use of the Memory partition functions

ApiCmdGetMemPartition and ApiCmdSetMemPartition.

LS_BM_Message_Filter_Recording_Sample.c (Table 5.1.1-X) - This sample demonstrates how to

setup the BM to capture only RT1 SA1 1553 messages traffic with additional filters providing

for the capture of only messages with certain data words.



LS_BM_Queue_Sample.c (Table 5.1.1-XI) - This sample demonstrates how to setup the BM to

queue captured 1553 message traffic into a circular queue of entries. There are no filters allowed

when recoding BM data in this mode. The BC is setup to transfer 1553 messages on both the

primary and secondary buses. Messages from both buses will be captured by the BM queuing

function.

LS_Recording_Sample.c (Table 5.1.1-XII) - This sample demonstrates the setup of the BM

required for recording data. Also, the sample demonstrates how to generate a file of captured

Bus monitor 1553 traffic. This file could then be printed by the applications program or archived

for later use.

LS_Replay_Sample.c (Table 5.1.1-XIII) - This sample demonstrates the setup of the BM required

for recording data. Also, the sample demonstrates how to generate a file of captured Bus monitor

1553 traffic. This file could then be printed by the applications program or archived for later

use.

LS_RT_Global_Con_Sample.c (Table 5.1.1-XIV) - This sample demonstrates how to setup the

multiple RTs on multiple devices using the Global RT configuration function.

1760_BC_RT_Sample.c (Table 5.1.1-XV) - This sample demonstrates enable MIL-STD-1760 mode

such that the checksum of transmitted data words from either the RT or BC can be computed.



5.1.1 Sample Programs

Tables 5.1.1-I through 5.1.1-XIV provide a description of all sample programs contained in

your BSP.

Table 5.1.1-I Interrupt_Sample.c

This sample demonstrates how to setup BC and RT interrupts such that a defined action can be

taken upon the occurrence of the interrupt. The interrupt can be setup in various ways. In this

case, the interrupt will occur upon "end of 1553 transfer" for the BC transfers, and will occur

on "any transfer" for the RT interrupts defined. Two interrupt handlers are contained in the

sample one for the RT and one for the BC.

Activity System BC RT Major/ Minor

Frame

Setup Default code setup includes

both RTs and BCs on stream

1 with MILBus coupling

mode = Externally Coupled

Sets up pointer to Interrupt

handler for BC related

events and Interrupt

handler for RT related

events. The Interrupt

Handlers (one for BC and

one for RT) are included in

the sample code.

XF1- BC-to-RT Broadcast

transfer - RTs to receive 2 data

words from BC with BC

transfer interrupt control set

to "interrupt on end of

transfer."

XF2- BC-to-RT - RT1 SA1 to

receive 4 data words from BC

with BC transfer interrupt

control set to "interrupt on

end of transfer."


transmit 5 data words to BC

with BC transfer interrupt


transfer error."

RT1 SA1 setup to receive data

RT2 SA2 setup to transmit

data with RT interrupt


any transfer"

RT31 SA1 setup to receive

data with interrupt control

set to "interrupt on transfer

error."

MinF1 = XF1,

XF2, XF3 & lasts

10 milliseconds

MajF = one

MinF1

Run After the BC and RT are

halted, the interrupt

handlers are released.

BC is started

Upon interrupt (which will

occur after each BC transfer,

as defined above), the global

interrupt counter is

incremented. The buffer

memory used for XF1 and

XF3 is then modified.

For 10 seconds, the BC/RT

interrupt count and IRIG time

is printed each second.

After 3 more seconds the BC is

halted.

Status of the BC and XFR1,

XF2, and XF3 are printed.

RTs are started.

Upon interrupt (which will

occur after each RT2 transfer,

and on RT31 transfer error as

defined above), the global

interrupt counter is

incremented. For each

interrupt, the buffer memory

used for the data word transfer

is then modified and IRIG time

is retrieved.

After 3 more seconds the RTs

are halted.

Global status of the RT's is

printed.



Table 5.1.1-II LS_BC_Acyclic_Xfers_Sample.c

This sample demonstrates how to setup the BC for acyclic transfers, i.e. - transfers that will

occur upon an external event.

Activity System BC RT Major/Minor

Frame

Setup - Sets MILBus coupling

mode = Externally

coupled

XF1 - BC-to-RT Broadcast -

RT31 to receive 2 data

words.

Message Buffer is initialized

to 0x3131.

XF2 - BC-to-RT - RT1 SA2

to receive 4 data words.


to 0xACAC.


data


data

MinF1 = XF1,

& lasts 100

milliseconds

MajF = one

MinF1

Run BC is started. After 1

seconds a request to

transfer the acyclic

transfer (XF2) is

performed. After 1 second

the BC is halted.

Status of BC is obtained.

RTs are started. After 2

seconds the RTs are halted.

Execution status of RT1 and

RT31 and the contents of

their associated message

buffer used for XF1 and

XF2 is obtained.

XF2 is inserted

into Minor

Frame 1 "on-

the-fly" i.e.

when

commanded to

do so (acyclic).



Table 5.1.1-III LS_BC_Dynamic_Data_and_1760_Sample.c

This sample demonstrates MIL-STD-1760 mode such that the checksum of transmitted data

words from either the RT or BC can be computed. The usage of the PSC-Timer is shown.


Frame

Setup - Demonstrates PSC timers by

initializing, starting, stopping and

checking the status.

- Sets MILBus coupling mode =

Externally coupled

Enable 1760 simulation mode.

For the buffers used for 1760 xfers

(i.e. buffer for XFR2, XFR4 and

buffer for XFR5) enable 1760

checksum word computation and

fill the associated buffers with test

data. Setup dynamic data generation

for the first data word in the XF4

buffer using a positive ramp

algorithm. Setup dynamic data

generation for the first two data

words in the XF2 buffer using a

negative triangle algorithm.

XF1- BC-to-RT - RT31 SA1

to receive 3 data words from

BC

XF2- RT-to-BC - RT1 SA1 to

transmit 32 data words to BC



BC

1760 Controlled Xfers:



BC



BC

RT1 SA1 setup to

receive data

RT2 SA2 setup to

transmit data

MinF1 = XF1,

XF2, XF3, XF4,

XF5

& lasts 1 second

MajF = one

MinF1

Run Start the BC.

Read the status of the BC and

RT transfers.

Halt the BC

Start the RTs.

Halt the RTs.

Table 5.1.1-IV LS_BC_Dynamic_Data_Dytag_Sample.c

This sample demonstrates how to setup the BC data word transfers to include words that

change dynamically based on programmer chosen algorithms.

Activity System BC Major/Minor Frame


mode = Externally

coupled.

XF1- BC-to-RT Broadcast transfer - RT31 SA1 to

receive 32 data words from BC

Message Buffer is initialized to 0x3131.

Setup Dynamic Data Generation to transmit

two dynamic data words within the XF1

transmit buffer. One dynamic data word is

setup for positive ramp, and one is setup for

positive triangle.

MinF1 = XF1 & lasts 100

milliseconds

MajF = one MinF1

Run Start the BC.

Wait 1 second.

Halt the BC.

Read BC status.



Table 5.1.1-V LS_BC_Dynamic_Data_Systag_Sample.c

This sample demonstrates the use of the AIM Buffer function which will generate a buffer

queue of three 32-word datasets to be used in a cyclic fashion for a BC 1553 transfer.

Activity System BC Major/Minor Frame

Setup - Sets MILBus coupling mode

= Externally Coupled

Create three 32-word buffers

using

ApiCmdRamWriteDataset

Buffer function.

Message Buffers ire initialized

to 0x5555, 0xAAAA, 0x1234.

Setup System Dynamic Data

Generation to Associate these

three buffers to the BC XF1

such that XF1 will cycle

through the three pre-defined

32 word buffer datasets for

XF1 data words.

XF1- BC-to-RT Broadcast transfer -

RT31 SA1 to receive 32 data words

from BC

Message Buffer is initialized to

0x3131.

MinF1 = XF1 & lasts 100

milliseconds

MajF = one MinF1

Run Start the BC.

Wait 1 second.

Halt the BC.

Read BC status.

Table 5.1.1-VI LS_BC_External_BC_Trigger_Sample.c

This sample demonstrates how to setup the BC to begin transfers upon the occurrence of an

external trigger.

Activity System BC Major/Minor

Frame


= Externally coupled

XF1- BC-to-RT Broadcast transfer -

RT31 SA1 to receive 2 data words

from BC


0x3131.

MinF1 = one wait

instruction (wait .5

milliseconds), XF1,

XF1

MajF = one MinF1

Run Start the BC with framing driven

by an external pulse.

Wait for the external trigger to

start the BC.

Halt the BC and read BC status.



Table 5.1.1-VII LS_BC_Fifo_Sample.c

This sample demonstrates how to use FIFOs (a FIFO is a queue of 128 32-word buffers),

instead of message buffers, for the data words transmitted in the 1553 BC and/or RT transfer.


Frame


= Externally coupled.

A pool of 32 FIFOs is

initialized for use by the

application. These FIFOs (each

FIFO is a queue of 128 32-

word buffers) can be used to

load large amounts of data to

be used for BC/RT data word

transmissions.

Each FIFO (1-6) is loaded

with data.

1st half FIFO 1 = 0x00xx

2nd half FIFO 1 = 0x11xx









1st half FIFO 6 = 0xAAxx

2nd half FIFO 6 = 0xBBxx

Where xx increments by 1.

XF1- BC-to-RT - RT31 SA6-


BC


0x3131.


receive 32 data words from BC.


0x5454.


transmit 32 data words to BC.

Message Buffer is cleared.

XF4- RT-to-RT - RT4 SA1 to

transmit 32 data words to RT3

SA1.


0x2121.

XF5- BC-to-RT Mode code

transfer - RT5 SA0 to receive

Mode code "synchronize" (17)

from BC.


0x8787.

XF6- RT-to-BC Broadcast

transfer- RT7 SA1 to transmit

32 data words to RT31 SA1


0x6464.

Data word transfers from the

BC are setup to utilize a

FIFO. i.e. - XFR1, XFR2, and

XF5 are assigned FIFO 1,2,

and 5 respectively




data.


0x7676.



RT4 SA1 setup to transmit data


0x3030.

RT5 setup to receive Mode

code 17


RT7 SA1 setup to transmit data


0x5050.

Data Word transfers from the

RT are setup to utilize a

FIFO. i.e. RT2 SA2, RT4

SA1, and RT7 SA1 are

assigned FIFO 3, 4, and 6

respectively.

MinF1 = XF1,

XF2, XF3,

XF4, XF5,

XF6 & lasts

100

milliseconds

MajF = one

MinF1

Run 2 seconds after the BC and RTs

are started, each FIFO (1-6) is

checked and reloaded with

new data into newly available,

FIFO area.

BC is started. .

After 2 seconds have elapsed

and the FIFOs reloaded, the BC

is halted.

RTs are started.

After 2 seconds have elapsed

and the FIFOs reloaded, the

RTs are halted.



Table 5.1.1-VIII LS_BC_Multibuffer_Sample.c

This sample demonstrates how to setup the BC to cycle through a sequential set of message

buffers to be used to obtain the data words for a cyclic 1553 transfer.


Frame


mode = Externally coupled

XF1 - BC-to-RT Broadcast -

RT31 SA1 to receive 16 data

words using 4 message

buffers, one for each

consecutive xfer. i.e. data

words in message buffer 1

are used for the first XFR1,

data words in message buffer

2 are used for the second

XFR1, .....data words in

message buffer 1 are used for

the fifth XF1...

Message Buffer 1 is

initialized to 0x3131.

Message Buffer 1 is


Message Buffer 1 is


Message Buffer 1 is


RT31 SA1 setup to

receive data (not

required for broadcast)

MinF1 = XF1

& lasts 100

milliseconds

MajF = one

MinF1

Run BC is started. After 1

second, the BC is halted

Status of BC is obtained and

the contents of the associated

data word buffers used by

the BC for XF1 is obtained

RT is started. After 1

second the RT is halted.

Execution status of

RT31 and the contents

of the associated data

word buffers (1-4) used

by RT31 for XF1 is

obtained. The contents

of RT31 XF1 buffer 4 is

printed.



Table 5.1.1-IX LS_BC_RT_BM_Sample.c

This sample demonstrates several device management and system functions including module

self-test, IRIG time setup and response time setup. It also demonstrates how to define BC and

RT 1553 transfers and setup minor and major frame cycles. Triggers for the Bus Monitor

function are also demonstrated.

Activity System BC RT BM

Major/

Minor

Frame

Setup - Sets User input

controlled

connection of API

device to PC where

remote application

program is running

- Performs API

Selftest

- Reads and prints

SW Version

- Sets/Reads on-

board IRIG time

encoder

- Sets Response

Timeout = 14

microseconds

- Sets MILBus

coupling mode =

Externally coupled

XF1- BC-to-RT

Broadcast - RTs to

receive 2 data words

Message Buffer is


XF2- BC-to-RT -

RT1 SA1 to receive 4

data words from BC

Message Buffer is


XF3- BC-to-RT -

RT2 SA2 to transmit

5 data words to BC

Message Buffer is

cleared.

RT1 SA1 setup to

receive data.

Message Buffer is

cleared.

RT2 SA2 setup to

transmit data

Message Buffer is

initialized to

0x2222.

RT31 SA1 setup to

receive data .

Message Buffer is

cleared.

Setup Bus Monitor mode

for "No Interrupt".

Set capture mode to

"Standard Capture

Mode" to capture bus

monitor traffic prior to

and 100 entries after the

following 2 triggers occur.

2 triggers are setup:

Static - Trigger on error

condition

Complex - Trigger on the

occurrence of a specific

command word, then

trigger on a specific data

word.

MinF1=

XF1, XF2,

XF3 & lasts

10

milliseconds

MajF = two

MinF1s

Run BC is started. After

1 second, the BC is

halted.

Status of the BC,

XF1, XF2, and XF3

is printed.

RTs are started.

After 1 second the

RTs are halted.

Status of RTs is

printed.

BM is started. After 1

second the BM is halted.

BM status of RT1 and

RT1 SA1 is printed..



Table 5.1.1-X LS_BC_RT_FW_Sample.c

This sample is the same as LS_BC_RT_BM_Sample.c except it provides the following

compiler options:

USE_MONSTER_SETUP - indicating that the maximum number of BC Transfers will be setup

for BC to RT31 SA1.

USE_STD_FRAMING - indicating the use of the standard frame definition functions

(ApiCmdBCFrameDef and ApiCmdBCMFrameDefEx) and transfers as defined

below. If not specified, use of instruction tables for minor/major frame definitions

(ApiCmdBCInstrTblxxx) will be utilized and setup identical to the standard framing

setup. If Instruction tables are used to define the framing, then if

USE_MONSTER_SETUP was not indicated, the transfers as defined below will occur,

otherwise, the maximum number of BC transfers allowed will be included in the

instruction tables, transfered once to RT31SA1, then the BC will be halted.

USE_SET_MEM - demonstrates the use of the Memory partition functions

ApiCmdGetMemPartition and ApiCmdSetMemPartition.

Activity System BC RT BM

Major/

Minor

Frame

Setup - Reads and prints

the BSP version

- Reads and prints

SW Version

- Sets/Reads on-

board IRIG time

encoder

- Sets Response

Timeout = 14

microseconds

- Sets MILBus

coupling mode =

Externally Coupled

XF1- BC-to-RT

Broadcast - RT31

SA1 to receive 2 data

words

Message Buffer


XF2- BC-to-RT -

RT1 SA1 to receive 4

data words from BC

Message Buffer


XF3- RT-to-BC -

RT2 SA2 to transmit

5 data words to BC

RT1 SA1 setup to

receive data

RT2 SA2 setup to

transmit data

Message Buffer

initialized to

0x2222.

RT4 SA1 setup to

transmit data

Message Buffer

initialized to

0x4444.

RT3 SA1 setup to

receive data

RT5 setup to

receive mode code

17

RT31 SA1 setup to

receive data

Setup Bus Monitor mode

for "No Interrupt".

Set capture mode to

"Standard Capture

Mode" to capture bus

monitor traffic prior to

and 100 entries after the

following 2 triggers occur.

2 triggers are setup:

Static - Trigger on error

condition

Complex - Trigger on the

occurrence of a specific

command word

(command for RT2,

transmit, SA2 and word

count = 5), then trigger

on a specific data word.

(4th data word = 0x2222)

MinF1=

XF1, XF2,

XF3 & lasts

10

milliseconds

MajF = two

MinF1s

Run BC is started.

The BC is halted.

RTs are started.

The RTs are halted.

BM is started.

For 10 iterations, print the

BM Status each second.

XF3 will cause the Start

Trigger Event to occur.

The BM is halted.



Table 5.1.1-XI LS_BM_Message_Filter_Recording_Sample.c

This sample demonstrates how to setup the BM to capture only RT1 SA1 1553 messages traffic

with additional filters providing for the capture of only messages with certain data words.

Activit

y System BC RT BM

Major/

Minor Frame

Setup - Sets MILBus

coupling mode

= Externally

coupled


transfer - RT31 SA1 (RTs)

to receive 32 data words

from BC

Message Buffer is


XF2- RT-to-RT - RT2

SA2 to transmit 32 data

words to RT31 SA2

Message Buffer is


XF3- RT-to-BC - RT3


words to BC

Message Buffer is


XF4- RT-to-RT - RT4


words to RT5 SA5.

Message Buffer is


XF6- BC-to-RT

Broadcast transfer- RT31


words from BC

Message Buffer is


XF7- BC-to-RT

Broadcast transfer- RT31


words from BC

Message Buffer is


RT1 SA1 setup to

receive data

Message Buffer is

initialized to

0x4321.

RT2 SA2 setup to

transmit data

Message Buffer is

initialized to

0x5432.

RT3 SA3 setup to

transmit data

Message Buffer is

initialized to

0x6543.

RT4 SA4 setup to

transmit data

Message Buffer is

initialized to

0x7654.

RT5 SA5 setup to

receive

Message Buffer is

initialized to

0x8765.

Setup to enable the BM

interrupt mode to interrupt

on BM "Monitor Buffer

Full" or BM "Half

Buffer Full"

Set capture mode to

"Message Filter

Recording mode" for

continuous capture.

1 trigger is setup:

Dynamic - Trigger on

data word = xF840 on

Primary or Secondary bus

for RT1 SA1. Eight

additional data words with

specific values and

message buffer locations

are included for BM

filtering.

MinF1 =

XF1, XF2,

XF3

& lasts 100

milliseconds

MinF2 =

XF4, XF5,

XF6

& lasts 100

milliseconds

MajF =

MinF1,

MinF2

Run Start the BC.

Halt the BC after recorded

data is printed.

Start the RTs. Start the BM.

Wait 4 seconds.

Read the recorded and

formatted BM Message

Filter data in a selectable

format.

Print recorded data.



Table 5.1.1-XII LS_BM_Queue_Sample.c

This sample demonstrates how to setup the BM to queue captured 1553 message traffic into a

circular queue of entries. There are no filters allowed when recoding BM data in this mode.

The BC is setup to transfer 1553 messages on both the primary and secondary buses. Messages

from both buses will be captured by the BM queuing function.

Activity System BC RT BM Major/

Minor Frame

Setup - Sets MILBus

coupling mode =

Externally coupled


transfer - RT31 SA1 (RTs) to

receive 32 data words from

BC on the primary bus


to 0x1234.



from BC on the primary

bus


to 0x2345.

XF3- RT-to-BC - RT2 SA2

to transmit 5 data words to

BC on the primary bus


XF4- RT-to-RT - RT3 SA3


RT4 SA4 on the secondary

bus




from BC on the secondary

bus


to 0x3456.

XF6 - BC-to-RT - RT6 SA6


from BC on secondary bus


to 0x3456.

RT1 SA1 setup to

receive data

Message Buffer is

cleared.

RT2 SA2 setup to

transmit data

Message Buffer is

initialized to

0x4321.

RT3 SA3 setup to

transmit data

Message Buffer is

initialized to

0x5432.

RT4 SA4 setup to

receive data

Message Buffer is

cleared.

RT5 SA5 setup to

receive data

RT6 SA6 setup to

receive data

Message Buffer is

cleared.

Setup to enable the BM

interrupt to interrupt on

"Monitor Buffer Full" or

"Half Buffer Full"

Setup the BM Queuing

function to capture all 1553

traffic in a circular queue

of entries.

MinF1 =

XF1, XF2,

XF3

& lasts 100

milliseconds

MinF2 =

XF4, XF5,

XF6

& lasts 100

milliseconds

MajF =

MinF1,

MinF2

Run Start the BC

Halt the BC.

Start the RTs

Halt the RTs.

Start queuing of 1553

messages from the stream of

1553 traffic.

Wait 200 milliseconds.

Read a single structure

from the head of the

message queue. If the queue

is empty, print " Queue

empty", if overflow, print

"Recording Overflow!!!".

Halt and flush the queue.



Table 5.1.1-XIII LS_Recording_Sample.c

This sample demonstrates the setup of the BM required for recording data. Also, the sample

demonstrates how to generate a file of captured Bus monitor 1553 traffic. This file could then

be printed by the applications program or archived for later use.

Activity System BC RT BM Major/Minor

Frame

Setup - Sets MILBus

coupling mode =

Externally coupled


transfer - RT31 SA6 (RTs)


from BC

Message Buffer is




from BC

Message Buffer is




BC

Message Buffer cleared.



RT3 SA1

Message Buffer is


XF5- BC-to-RT Mode code

transfer - RT5 SA0 to

receive Mode code

"synchronize" (17) from

BC

Message Buffer is


XF6- RT-to-RT Broadcast

transfer- RT7 SA1 to

transmit 32 data words to

RT31 SA1

Message Buffer is


RT1 SA1 setup to

receive data

Message Buffer

cleared.

RT2 SA2 setup to

transmit data

Message Buffer is


RT3 SA1 setup to

receive data

Message Buffer

cleared.

RT4 SA1 setup to

transmit data

Message Buffer is


RT5 setup to receive

Mode code 17

Message Buffer is

cleared.

RT7 SA1 setup to

transmit data

Message Buffer is


RT31 SA6 setup to

receive data

Message Buffer

cleared.

Setup to enable the

BM interrupt mode to

interrupt on BM

"Monitor Buffer

Full".

Set capture mode to

"Continuous

Capture" (Recording

Mode). In this mode

the Buffer Full

Interrupt is enabled so

that every time the

AIM board Bus

Monitor has captured a

certain amount of data,

an interrupt is asserted.

MinF1 =

XF1, XF2,

XF3,

XF4, XF5,

XF6 & lasts

10

milliseconds

MajF =

MinF1

Run A sample recording

file, "sam_rec.prc",

is opened after the

RT(s), BC, and BM

are started.

Using

"ApiReadRecData"

function, the recorded

BM data is copied

from the Global RAM

area of the AIM board

to an application

buffer. This buffer

data is then written to

the sample recording

file "sam_rec.prc".

Start BC.

Halt BC and read BC status.

Start RTs.

.

Start BM.



Table 5.1.1-XIV LS_Replay_Sample.c

This sample demonstrates the Replay of pre-recorded 1553 MILbus data using

"sam_rec.prc" file from LS_Recording_Sample.c..

Activity System Replay

Setup - Sets MILBus coupling mode =

Externally coupled

Initialize the Replay function to replay:

1. Based on no absolute time

2. Replay only Low Time tag

3. Assert Half Buffer Transmitted Interrupt

4. Replay entire replay file "sam_rec.prc"

.

Open "sam_rec.prc" file previously recorded.

Compute number of reloads required.

Run Start the Replay Operation.



Table 5.1.1-XV LS_RT_Global_Con_Sample.c

This sample demonstrates how to setup the RTs on using the Global RT configuration function.


Frame

Setup - Initializes three AIM

boards

- Sets MILBus

coupling mode =

Externally coupled

On BIU1:



BC



BC



RT4 SA4



from BC

Using the

ApiCmdRTGlobalCon

function:


data


and receive data


data


data


data

For BIU1:

MinF1 = XF1,

XF2, XF3, XF4

& lasts 100

milliseconds

MajF = one

MinF1

Run Start the BC

Halt the BC

Start the RTs

Wait....

Change the buffer content

for each RT transmit

buffers on BIU1 using the

ApiCmdRTGlobalCon

function

Wait....

Change the buffer content

for each RT transmit

buffers on BIU1 using the

ApiCmdRTGlobalCon

function

Halt the RTs.


Section 5 - Program Samples LS_BC_RT_BM_Sample.c

5.2 Program Sample Code

5.2.1 LS_BC_RT_BM_Sample.c

The LS_BC_RT_BM_Sample.c provides several device management and system functions

including network connections, API self-test, IRIG time setup and response time setup. It also

demonstrates how to define BC and RT 1553 transfers and setup minor and major frame

cycles. Triggers for the Bus Monitor function are also demonstrated. Please refer to Table

5.1.1-VIII for an overview of this sample program. /****************************************************************************** ******************************************************************************/ /************************************ Includes ************************************/ #include <windows.h> #include <stdio.h> #include <string.h> #include <conio.h> /* AIM Header File contains C-prototypes and structures */ #include "Api1553.h" /************************************ Some Globals ************************************/ AiUInt8 biu; AiUInt32 ApiModuleHandle; AiInt8 ApiModuleNumber; /************************************ Some Makros ************************************/ #define AIM_WAIT(x) Sleep(x) /************************************ Prototypes for sample functions ************************************/ void PerformeSomeSystemCommands(void); void Setup1553BusControllerWithSomeTransfers(void); void Setup1553RemoteTerminals(void); void Setup1553BusMonitor(void); void ReadSomeStatusReports(void); #define TITLE \ "*********************************************************************\n\ >>>>> AIM Gmbh Programming Sample for the API1553 Board <<<<<\n\ LS_BC_RT_BM_Sample.c 1553 Bus Simulator BC, RT, BM \n" /***************************************************************************** * function: main * * - Initalizes the communication to the board * - shows the programming sequence * * *****************************************************************************/



void __cdecl main(int argc, char * argv[]) TY_API_RESET_INFO api_res_info; AiInt16 boardCount; AiUInt16 retVal; AiInt32 i, in_cnt, in_ch; TY_API_BM_STATUS_DSP api_bm_status_dsp; AiUInt32 ul_MajFrameAddr; AiUInt32 aul_MinFrameAddr[64]; TY_API_OPEN x_ApiOpen; AiUChar ServerName[128]; // Select a Stream biu = API_STREAM_1; // default ApiModuleNumber = API_MODULE_1; // default sprintf(ServerName, "local"); // Default server printf("%s",TITLE); printf("\nModule Number:%d Stream:%d\n", ApiModuleNumber, biu); if( stricmp(ServerName, "local") == 0 ) // Local board access. boardCount = ApiInit(); else // remote board access (using server) printf("Connect to Server:%s\n", ServerName); retVal = ApiConnectToServer( ServerName, &boardCount); if( retVal != API_OK ) printf("\r\n ApiConnectToServerfailed !!\r\n"); return; if (boardCount != 0) printf("\r\n Now do ApiOpenEx\r\n"); x_ApiOpen.ul_Module = ApiModuleNumber; x_ApiOpen.ul_Stream = biu;

sprintf( x_ApiOpen.ac_SrvName, ServerName ); retVal = ApiOpenEx( &x_ApiOpen, &ApiModuleHandle );

// use the ApiModuleHandle for all further ApiXXX.... calls if (retVal == API_OK)

printf("\r\n ApiOpened\r\n");

/* At this point the communication to the Hardware can start */ /* Now do some Setups */ PerformeSomeSystemCommands(); Setup1553BusControllerWithSomeTransfers(); Setup1553RemoteTerminals(); Setup1553BusMonitor(); /* Now start simulation */ printf(" Now Start BM, RT and BC \r\n"); ApiCmdBMStart( ApiModuleHandle, 0 ); ApiCmdRTStart( ApiModuleHandle, 0 ); ApiCmdBCStart( ApiModuleHandle, 0, API_BC_START_IMMEDIATELY, 0 /*cyclic*/, 10/*frame time*/,0, &ul_MajFrameAddr, aul_MinFrameAddr );

Open the board if it is remote.

Open the Application interface to

the target module and get the

handle for the module.

These are the four main

functions within this sample

program. These functions will

perform setup of the system,

BC, RTs, and BM.

Open the board if it is local.

Start BM, RT, BC.

The BC start function defines the minor frame time with 10 ms and

starts the simulation in cyclic mode.



while( ! isKeyboardPressed() ) // ... allow some time here ... printf(" Wait a while \r\n\n"); ApiCmdBMStatusRead (ApiModuleHandle,0, &api_bm_status_dsp); printf(" BM Status: enabled:%d, in sync:%d, trigger:%d, MSG:%08lx ERR:%08lx\r\n",

(api_bm_status_dsp.men & 1 ), (api_bm_status_dsp.msw & 0x40, (api_bm_status_dsp.msw & 0x1, api_bm_status_dsp.glb_msg_cnt, api_bm_status_dsp.glb_err_cnt );

printf("\r\n"); /* Now stop communication */ printf("\r\n Now Stop RT and BC, and show some Results \r\n"); ApiCmdBCHalt( ApiModuleHandle, 0 ); ApiCmdRTHalt( ApiModuleHandle, 0 ); ApiCmdBMHalt( ApiModuleHandle, 0 ); /* And read some Status Results */ ReadSomeStatusReports(); // Do Reset ApiCmdReset(ApiModuleHandle, 0, API_RESET_ALL, &api_res_info); // Close Device retVal = ApiClose(ApiModuleHandle); printf("ApiClose.\r\n"); if (retVal != API_OK) printf("ApiClosefailed !!\r\n"); else printf("\r\n ApiOpen failed !!\r\n"); if (stricmp(ServerName, "local") != 0 ) // Disconnect from server retVal = ApiDisconnectFromServer( ServerName); if (retVal != API_OK) printf("ApiDisconnectFromServer failed !!\r\n"); return;

Status can be read and

printed to console.

Then BC, RTs and BM

are halted.

Finally, the data

structures and variables

are re-initialized to a

default state, and the

module is closed thus

allowing no further

communication, except

ApiOpen.

Status is printed to the

console in this function.



/***************************************************************************** * function: PerformeSomeSystemCommands * * - Initalizes the board * - Resets the Communication to the board * - Reads all version information * - Set and read the IRIG time * - Set the coupling * * *****************************************************************************/ void PerformeSomeSystemCommands(void) TY_API_INI_INFO api_ini_info; TY_API_RESET_INFO api_res_info; TY_API_IRIG_TIME api_irig_time; AiUInt8 bite_status[2]; AiUInt16 fw_id, sw_id, lca_id; AiUInt32 lca_chks; AiUInt32 ul_FirmwareVer, ul_targetver, ul_targetBuild, ul_LcaVer1, ul_LcaVer2, ul_LcaCheckSum, ul_SysDrvVer, ul_SysDrvBuild, ul_DllVer, ul_DllBuild, ul_BoardSerialNr; AiUInt8 uc_BspCompatibility; printf("\r\n Now do ApiCmdIni\r\n"); ApiCmdIni(ApiModuleHandle, API_INIT_MODE_READ, &api_ini_info); printf(" ApiCmdIni Result: bt 1 %81x \r\n",(AiInt32)api_ini_info.bt[0]); printf(" bt 2 %81x \r\n",(AiInt32)api_ini_info.bt[1]); printf(" chns %81x \r\n",(AiInt32)api_ini_info.chns); printf(" prot %81x \r\n",(AiInt32)api_ini_info.prot); printf(" emod %81x \r\n",(AiInt32)api_ini_info.emod); printf(" irg %81x \r\n",(AiInt32)api_ini_info.irg); printf(" res1 %81x \r\n",(AiInt32)api_ini_info.res1); printf(" pbi_id_biu1 %81x \r\n",(AiInt32)api_ini_info.pbi_id_biu1); printf(" asp_mon_id %81x \r\n",(AiInt32)api_ini_info.asp_mon_id); printf(" asp_bite_id %81x \r\n",(AiInt32)api_ini_info.asp_bite_id); printf(" pbi_id_biu2 %81x \r\n",(AiInt32)api_ini_info.pbi_id_biu2); printf(" res2 %81x \r\n",(AiInt32)api_ini_info.res2); printf(" glb_mem_size %81x \r\n",(AiInt32)api_ini_info.glb_mem_size); printf(" glb_mem_addr %81x \r\n",(AiInt32)api_ini_info.glb_mem_addr); printf(" loc_dram_size %81x \r\n",(AiInt32)api_ini_info.loc_dram_size); printf(" loc_dram_addr %81x \r\n",(AiInt32)api_ini_info.loc_dram_addr); printf(" shared_dram_size %81x \r\n",(AiInt32)api_ini_info.shared_dram_size); printf(" shared_dram_addr %81x \r\n",(AiInt32)api_ini_info.shared_dram_addr); printf(" flash_ram_size %81x \r\n",(AiInt32)api_ini_info.flash_ram_size); printf(" flash_ram_addr %81x \r\n",(AiInt32)api_ini_info.flash_ram_addr); printf("\r\n Now do ApiCmdReset\r\n"); ApiCmdReset(ApiModuleHandle, 0, API_RESET_ALL, &api_res_info); printf(" ApiCmdReset Result: mbufs %81x \r\n", (AiInt32)api_res_info.mbufs); printf(" sbufs %81x \r\n", (AiInt32)api_res_info.sbufs); printf(" mon_addr %81x \r\n", (AiInt32)api_res_info.mon_addr); printf(" sim_addr %81x \r\n", (AiInt32)api_res_info.sim_addr); /* Now the board is ready for work */

Initialize the module to

receive module

properties. Those

properties are then

printed to console.

The data structures and variables

are initialized to a default state



// Read all versions of the board ApiReadBSPVersion(ApiModuleHandle, &ul_FirmwareVer, &ul_targetver, &ul_targetBuild, &ul_LcaVer1, &ul_LcaVer2, &ul_LcaCheckSum, &ul_SysDrvVer, &ul_SysDrvBuild, &ul_DllVer, &ul_DllBuild, &ul_BoardSerialNr, &uc_BspCompatibility ); printf(" ApiReadBSPVersion Result: \r\n\n" ); printf(" | Fw Biu1 | Fw Biu2 | Target | LCA1 | LCA2 |\r\n"); printf(" +----------+----------+----------+----------+----------+\r\n"); printf(" | V%05lX | V%05lX | V%05lX | V%05lX | %05lX |\r\n", (ul_FirmwareVer & 0x0000ffff), ((ul_FirmwareVer >> 16) & 0x0000ffff), (ul_targetver & 0x0000ffff), (ul_LcaVer1 & 0x0000ffff), ul_LcaVer2); printf(" | | | B%05lX | | |\r\n\n", ul_targetBuild ); printf(" | SysDRV | DLL | SN |\r\n"); printf(" +----------+----------+----------+\r\n"); printf(" | V%05lX | V%05lX | %08ld |\r\n", (ul_SysDrvVer & 0x0000ffff), (ul_DllVer & 0x0000ffff), ul_BoardSerialNr); printf(" | B%05lX | B%05ld |\r\n\n", ul_SysDrvBuild, ul_DllBuild); /* Now perform Selftest */ printf("\r\n Now do ApiCmdBite (This will take some seconds...)\r\n"); ApiCmdBite(ApiModuleHandle, 0, API_BITE_ALL, bite_status); printf(" ApiCmdBite Result: major %21d \r\n", (AiInt32)bite_status[0]); printf(" minor %21d \r\n", (AiInt32)bite_status[1]); if (bite_status[0] != 0) printf(" >>> Selftest ERROR! <<<\r\n"); else printf(" >>> Selftest PASSED! <<<\r\n"); printf("\r\n Now do ApiCmdReset again Note: This is necessary after Selftest!\r\n"); printf("\r\n ---------------------------------------\r\n"); ApiCmdReset (ApiModuleHandle, 0, API_RESET_ALL, &api_res_info); /* Now we can go on */ printf("\r\n Now do ApiCmdDefRespTout\r\n"); ApiCmdDefRespTout (ApiModuleHandle, 0, 14/*BC+BM Timeout*/); printf("\r\n Now do ApiCmdReadSWVersion \r\n"); ApiCmdReadSWVersion(ApiModuleHandle, 0, &fw_id, &sw_id, &lca_id, &lca_chks); printf(" ApiCmdReadSWVersion Result: biu %8x\r\n",biu ); printf(" fw_id %8x\r\n",fw_id ); printf(" sw_id %8x\r\n",sw_id ); printf(" lca_id %8x\r\n",lca_id ); printf(" lca_chks %81x\r\n",(AiInt32)lca_chks);

This command retrieves the s/w

version for each s/w component.

The version information is then

printed.

Note: This cmd cannot be used

for modules with one biu.

Perform a self-test

of all components

on the module.

Note: ApiCmdReset is

now called

automatically after

ApiCmdBite - no need to

perform again in your

program.

Example of response

timeout being set to 14

µsec. (Default is 14

µsec)

Retrieves the version

of the firmware, driver

software and LCA

software.



printf(" Now do ApiCmdSetIrigTime \r\n"); // Set onboard IRIG time api_irig_time.day_hi = 0; api_irig_time.day_lo = 0; api_irig_time.hour = 0; api_irig_time.min = 0; api_irig_time.sec = 0; api_irig_time.sec = 0; api_irig_time.mode = API_IRIG_SET; ApiCmdSetIrigTime (ApiModuleHandle, &api_irig_time); // ... wait some seconds here .. AIM_WAIT(2000); printf(" Read the IrigTime \r\n"); 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);

// Set Coupling mode to onboard MILbus Network simulation printf(" ApiCmdCalCplCon set to onboard MILbus Network simulation \r\n"); ApiCmdCalCplCon(ApiModuleHandle,0,API_CAL_BUS_PRIMARY, API_CAL_CPL_EXTERNAL); ApiCmdCalCplCon(ApiModuleHandle,0,API_CAL_BUS_SECONDARY, API_CAL_CPL_EXTERNAL);

Sets, then reads the

IRIG time from the

onboard IRIG-B

timecode encoder.

The coupling mode for

the primary and

secondary buses are

set to "isolated".



/***************************************************************************** * function: Setup1553BusControllerWithSomeTransfers * * - Init Bus Controler * - Setup tree different transfers with data buffer and buffer header * - Setup minor frame * - Setup major frame * * *****************************************************************************/ void Setup1553BusControllerWithSomeTransfers(void) TY_API_BC_BH_INFO api_bc_bh_desc; TY_API_BC_XFER api_bc_xfer; TY_API_BC_FRAME api_bc_frame; TY_API_BC_MFRAME api_bc_mframe; AiUInt16 out_dataw[32], rid, xfer_id, buf_id, bc_hid; AiUInt32 addr, raddr; AiInt32 i; printf(" Now do Setup API1553 Bus Controller \r\n"); // Bus Controller Commands ApiCmdBCIni(ApiModuleHandle,0,0,0,0,0); // BC Broadcast Transfer XF1: C31_R_01_02 (RT31,RCV,SA01,WC2) xfer_id = 1; buf_id = 1; bc_hid = 1; 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.xmt_rt = 0; /* XMT-RT */ api_bc_xfer.rcv_rt = 31; /* RCV-RT */ api_bc_xfer.xmt_sa = 0; /* XMT-SA */ api_bc_xfer.rcv_sa = 1; /* RCV-SA */ api_bc_xfer.wcnt = 2; /* 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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); for(i=0;i<32;i++) out_dataw[i] = 0x3131; ApiCmdBufDef(ApiModuleHandle,0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,&rid,&raddr);

Initializes the BC defining #

of retries, and bus to be used

(primary or seconday). (0

indicates default which is no

retry and primary enabled)

First assign a transfer ID, Buffer ID

and a BC Header ID. Then the

structure containing the information

about the BC transfer is defined.

This information is the input to the

ApiCmdBCXferDef function below.

Associate the BC Buffer Header

with the message buffer and set

message buffer queue size to 1.

The message buffer is then

initialized with data 3131h

BC-to-RT xfer

RT31 SA1

word count = 2



// BC-RT Transfer XF2: C01_R_01_04 (RT01,RCV,SA01,WC4) 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_PRIMARY; /* 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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); for(i=0;i<32;i++) out_dataw[i] = 0x1111; /* BC transmit datawords */ ApiCmdBufDef(ApiModuleHandle,0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,&rid,&raddr); // RT-BC Transfer XF3: C02_T_02_05 (RT02,XMT,SA02,WC5) xfer_id = 3; buf_id = 3; bc_hid = 3; 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_RTBC; /* Transfer Type */ api_bc_xfer.chn = API_BC_XFER_BUS_PRIMARY; /* MILbus */ api_bc_xfer.xmt_rt = 2; /* XMT-RT */ api_bc_xfer.rcv_rt = 0; /* RCV-RT */ api_bc_xfer.xmt_sa = 2; /* XMT-SA */ api_bc_xfer.rcv_sa = 0; /* RCV-SA */ api_bc_xfer.wcnt = 5; /* 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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); for(i=0;i<32;i++) out_dataw[i] = 0x0000; /* clear BC receive buffer */ ApiCmdBufDef(ApiModuleHandle,0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,&rid,&raddr);

First assign a transfer ID, Buffer ID and a BC

Header ID. Define properties of the next xfer.




The message buffer is then initialized

with data 1111h

BC-to-RT xfer

RT1 SA1

word count = 4






.


(cleared) to 0.

RT-to-BC xfer

RT2 SA2

word count = 5



/* Minor Frame 1 MF1 Transfer sequence */ api_bc_frame.id = 1; api_bc_frame.cnt = 3; api_bc_frame.xid[0] = 1; /* XF1 */ api_bc_frame.instr[0] = API_BC_INSTR_TRANSFER; api_bc_frame.xid[1] = 2; /* XF2 */ api_bc_frame.instr[1] = API_BC_INSTR_TRANSFER; api_bc_frame.xid[2] = 3; /* XF3 */ api_bc_frame.instr[2] = API_BC_INSTR_TRANSFER; ApiCmdBCFrameDef(ApiModuleHandle,0,&api_bc_frame); /* Minor Frame sequence in Major Frame */ api_bc_mframe.cnt = 2; api_bc_mframe.fid[0] = 1; /* MF1 */ api_bc_mframe.fid[1] = 1; /* MF1 */ ApiCmdBCMFrameDefEx(ApiModuleHandle,0,&api_bc_mframe);

The minor and major frames are then

defined using the xfer IDs defined

above.

One minor fame is defined with three

transfers: XF1, XF2, and XF3 (which

were defined above).

The major frame is defined with two

minor frames: Minor frame 1 then

minor frame 1 again.

Note: The ApiCmdBCStart function

call in the main program will define

the timing of each minor frame within

the major frame.



/***************************************************************************** * function: Setup1553RemoteTerminals * * - Init all needed Remote Terminals * - Setup buffers and buffer header for RTs * - Configure RT subadresses and assign buffers to it * * *****************************************************************************/ void Setup1553RemoteTerminals(void) TY_API_RT_BH_INFO api_rt_bh_desc; AiUInt16 out_dataw[32], rt_hid, rid, buf_id; AiUInt32 raddr; AiInt32 i; printf(" Now do Setup API1553 Remote Terminals \r\n"); // Remote Terminal Commands ApiCmdRTIni(ApiModuleHandle,0, 1/*RT*/,API_RT_ENABLE_SIMULATION,0,8,0x0800); ApiCmdRTIni(ApiModuleHandle,0, 2/*RT*/,API_RT_ENABLE_SIMULATION,0,8,0x1000); ApiCmdRTIni(ApiModuleHandle,0,31/*RT*/,API_RT_ENABLE_SIMULATION,0,8,0x1800); rt_hid = 1; buf_id = 10; for(i=0;i<32;i++) out_dataw[i] = 0x0000; /* clear RT-SA receive buffer */ ApiCmdRTBHDef(ApiModuleHandle,0,rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,

&api_rt_bh_desc); ApiCmdBufDef(ApiModuleHandle,0,API_BUF_RT_MSG,0,buf_id,32,out_dataw,&rid,&raddr); 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*/); rt_hid = 2; buf_id = 11; for(i=0;i<32;i++) out_dataw[i] = 0x2222; /* RT-SA transmit datawords */ ApiCmdRTBHDef( ApiModuleHandle, 0, rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,

&api_rt_bh_desc); ApiCmdBufDef( ApiModuleHandle, 0, API_BUF_RT_MSG,0,buf_id,32,out_dataw,&rid,&raddr); ApiCmdRTSACon( ApiModuleHandle, 0, 2/*RT*/, 2/*SA*/, rt_hid/*HID*/, API_RT_TYPE_TRANSMIT_SA, API_RT_ENABLE_SA, 0/*rmod*/, API_RT_SWM_OR, 0/*swm*/); rt_hid = 3; buf_id = 12; for(i=0;i<32;i++) out_dataw[i] = 0x0000; /* clear RT-SA receive buffer */ ApiCmdRTBHDef( ApiModuleHandle, 0, rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,

&api_rt_bh_desc); ApiCmdBufDef( ApiModuleHandle, 0, API_BUF_RT_MSG,0,buf_id,32,out_dataw,&rid,&raddr); ApiCmdRTSACon( ApiModuleHandle, 0, 31/*RT*/, 1/*SA*/, rt_hid/*HID*/, API_RT_TYPE_RECEIVE_SA, API_RT_ENABLE_SA, 0/*rmod*/, API_RT_SWM_OR, 0/*swm*/);

The mode, response time and the

value of the next status word for each

simulated RT is initialized.

A Buffer ID and RT Header ID for the transfer to RT1 SA1 is assigned. The

receive message buffer is cleared.

A Buffer ID and RT Header ID for the transfer from RT2 SA2 is assigned. The

transmit message buffer is initialized with 2222h.


receive message is cleared. This RT is setup to be able to monitor the broadcast.



/***************************************************************************** * function: Setup1553BusMonitor * * - Init Bus Monitor * - Setup in standard capture mode * *****************************************************************************/ void Setup1553BusMonitor(void) TY_API_BM_CAP_SETUP api_bm_cap; TY_API_BM_TCB api_bm_tcb; printf(" Now do Setup API1553 Bus Monitor \r\n"); // Bus Monitor Commands ApiCmdBMIni(ApiModuleHandle,0); ApiCmdBMIntrMode(ApiModuleHandle,0,API_BM_MODE_NO_INT,API_BM_NO_STROBE,0); 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); // Setup Trigger // init TCB 3 for Trigger on any 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; // Trigger Reset Bits api_bm_tcb.tset = 0x3F; /*only F is valid see FTW */ // Trigger Set Bits api_bm_tcb.tsp = 0x00; // Trigger spec api_bm_tcb.next = 0xFF; // next TCB api_bm_tcb.eom = 0xFF; // next TCB End of Message control 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, 3 /*tid*/, API_ENA, &api_bm_tcb); // init TCB 7 for Sequence Trigger First Step // Trigger on a special command word 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; // Trigger Reset Bits api_bm_tcb.tset = 0x70; /* only 0 is valid see FTW */ // Trigger Set Bits api_bm_tcb.tsp = 0x31; /* Trigger on Command Word */ // Trigger spec api_bm_tcb.next = 0x09; /* next TCB in sequence */ // next TCB api_bm_tcb.eom = 0xFF; // next TCB End of Message control api_bm_tcb.tdw = 0x1445; /* Command word */ // Trigger data word api_bm_tcb.tmw = 0xFFFF; // Trigger mask word api_bm_tcb.tuli = 0xFFFF; // Trigger upper limit api_bm_tcb.tlli = 0x0000; // Trigger lower limit ApiCmdBMTCBIni(ApiModuleHandle, 0, 7 /*tid*/, API_ENA, &api_bm_tcb);

Initialize the BM. Disable the

BM interrupts and output strobes.

BM is setup to capture BM traffic

prior to and 100 entries after the

following triggers occur .

static trigger - Setup a trigger control block (TCB) to trigger on any

error condition (all bits in the trigger data word (tdw) are set). The

TCB still needs to be activated by the ApiCmdBMTIWIni function.

dynamic trigger (TCB3) - Setup a trigger control block (TCB7) to trigger on a sequence. First trigger -set TCB to

trigger if word is cmd word and = 1445h (which is RT2, T/R = T, SA = 2, Word count = 5). The TCB is setup to set the

Trigger Set Bits (70h) of the Monitor Status Trigger then process TCB 9 next. The ApiCmdBMTCBIni only sets up the

trigger control blocks - the function call to start the trigger and the trace after trigger counter, ApiCmdBMFTWIni,

and the function to tell BM to start looking at this TCB, ApiCmdBMTIWIni, has yet to be performed.



// init TCB 9 for Sequence Trigger First Step // Trigger on a special data word. If it does not occur in that Message go back to command word

Trigger 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; // Trigger Reset Bits api_bm_tcb.tset = 0x9F; /* only F is valid see FTW */ // Trigger Set Bits api_bm_tcb.tsp = 0x04; /* Data Word position */ // Trigger spec api_bm_tcb.next = 0xFF; // next TCB api_bm_tcb.eom = 0x07; /* previous TCB in sequence */// next TCB End of Message control api_bm_tcb.tdw = 0x2222; // Trigger data word api_bm_tcb.tmw = 0xFFFF; // Trigger mask word api_bm_tcb.tuli = 0x222F; // Trigger upper limit api_bm_tcb.tlli = 0x2220; // Trigger lower limit ApiCmdBMTCBIni(ApiModuleHandle, 0, 9 /*tid*/, API_ENA, &api_bm_tcb); // Set the Function Trigger Word with Mask and compare Values ApiCmdBMFTWIni(ApiModuleHandle, 0, API_BM_WRITE_ALL, 0x00 /*htm*/, 0xFF /*htc*/,

0x0F /*stm*/, 0x0F /*stc*/); // Set the Trigger Index Word with the indexes of the TCBs ApiCmdBMTIWIni(ApiModuleHandle, 0, API_BM_WRITE_ALL, API_DIS /*eti*/, 3/*aei*/,

7/*ti0*/, API_DIS/*ti1*/);

dynamic trigger (TCB9) - Second trigger - trigger if word is a data word and = 2222h and is the fourth

word in the message. The TCB is setup to set the Trigger Set Bits (9Fh) of the Monitor Status Trigger then

process TCB7 next. The ApiCmdBMTCBIni only sets up the trigger control blocks - the function call to

start the trigger and the trace after trigger counter, ApiCmdBMFTWIni, and the function to tell BM to

start looking at this TCB, ApiCmdBMTIWIni, has yet to be performed.

Setup the Function Trigger Word (FTW) to tell the BM when to begin monitoring and incrementing the

trace after trigger counter. The start trigger mask (stm) is set to 0Fh, so only the right-most nibble of the

Monitor Status Trigger word needs to be set (set by TCB9) for the BM to start. Basically in this example,

both conditions as specified by TCB7 and TCB9 must be met before the start trigger condition is met and

the trace after trigger counter is incremented. The halt trigger mask (htm) is 00h indicating it will not be

used to stop the BM trigger condition.

Setup the Trigger Index Word (TIW) to indicate which Trigger Control Blocks the BM will monitor. You

can setup 2 static and two dynamic triggers at one time.

external trigger index(eti) and any error index (aei) are static triggers

trigger index 0 (ti0) and trigger index 1 (ti1) are dynamic triggers meaning they may contain a sequence of

triggers

In this example, the external trigger index (eti) is disabled (no triggers based on external stimuli), the any

error index (aei) is set to 3, therefore, TCB3 is the only static trigger being used in this example.

One dynamic trigger is enabled, TCB7, (tio=7) which is a sequence trigger as shown above that starts with

TCB7,, then goes to TCB9 after the conditions of TCB7 have been met.



/***************************************************************************** * function: ReadSomeStatusReports * * - Read BC Status and Transfer informations * - Read RT STatus * - Read BM Activity * * *****************************************************************************/ void ReadSomeStatusReports(void) TY_API_BM_RT_ACT api_rt_cnt; TY_API_BC_XFER_DSP api_bc_xfer_dsp; TY_API_BC_STATUS_DSP api_bc_status_dsp; TY_API_RT_STATUS_DSP api_rt_status_dsp; // BC Gobal Status printf("\r\n Now Read BC Status \r\n"); ApiCmdBCStatusRead(ApiModuleHandle,0,&api_bc_status_dsp); printf(" Results: status = %81x\r\n", (AiInt32)api_bc_status_dsp.status); printf(" hxfer = %81x\r\n", (AiInt32)api_bc_status_dsp.hxfer); printf(" glb_msg_cnt = %81x\r\n",

(AiInt32)api_bc_status_dsp.glb_msg_cnt); printf(" glb_err_cnt = %81x\r\n",

(AiInt32)api_bc_status_dsp.glb_err_cnt); // BC Transfer Status printf("\r\n Now Read BC Xfer 1 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,1/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %81x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %81x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt); printf("\r\n Now Read BC Xfer 2 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,2/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %81x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %81x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt); printf("\r\n Now Read BC Xfer 3 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,3/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %81x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %81x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %81x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %81x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %81x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt);

This intermodule function demonstrates the

"Read" functions for the BC, BC Xfer, RT and

BM RT status functions. It also shows some

sample code to print the results.



// RT Gobal Status printf("\r\n Now Read RT Status \r\n"); ApiCmdRTStatusRead(ApiModuleHandle,0,&api_rt_status_dsp); printf(" Results: status = %81x\r\n", (AiInt32)api_rt_status_dsp.status); printf(" glb_msg_cnt = %81x\r\n", (AiInt32)api_rt_status_dsp.glb_msg_cnt); printf(" glb_err_cnt = %81x\r\n", (AiInt32)api_rt_status_dsp.glb_err_cnt); // BM RT Activity Counter printf("\r\n Now Read RT BM Act \r\n"); ApiCmdBMRTActRead(ApiModuleHandle,0,1,&api_rt_cnt); printf(" Results: mc = %81x\r\n", (AiInt32)api_rt_cnt.mc); printf(" ec = %81x\r\n", (AiInt32)api_rt_cnt.ec); printf(" et = %81x\r\n", (AiInt32)api_rt_cnt.et); printf("\r\n Now Read RT Sub Addr. Act \r\n"); ApiCmdBMRTSAActRead(ApiModuleHandle,0,1,1,0,&api_rt_cnt); printf(" Results: mc = %8x\r\n", (AiInt32)api_rt_cnt.mc); printf(" ec = %8x\r\n", (AiInt32)api_rt_cnt.ec); printf(" et = %8x\r\n", (AiInt32)api_rt_cnt.et);


Section 5 - Program Samples LS_Interrupt_Sample.c

5.2.2 LS_Interrupt_Sample.c

This sample demonstrates how to setup BC and RT interrupts such that a defined action can be

taken upon the occurrence of the interrupt. The interrupt can be setup in various ways. In this

example, the interrupt will occur upon "end of 1553 transfer" for the BC transfers, and will

occur on "any transfer" for the RT interrupts defined. Two interrupt handlers are contained in

the sample; one for the RT and one for the BC.

******************************************************************************/

#include <windows.h> #include <stdio.h> #include <string.h> /* AIM Header File contains C-prototypes and structures */ #include "Api1553.h" /************************************ Some Globals ************************************/ AiUInt32 ApiModuleHandle; TY_API_IRIG_TIME api_irig_time; AiUInt32 bufferAddress[20]; AiUInt32 interruptCountBC = 0; AiUInt32 interruptCountRT = 0; AiUInt8 errFlag = FALSE; /************************************ Some Makros ************************************/ #define AIM_WAIT(x) Sleep(x) /************************************ Prototypes for sample functions ************************************/ void PerformeSomeSystemCommands(void); void Setup1553BusControllerWithSomeTransfers(void); void Setup1553RemoteTerminals(void); void ReadSomeStatusReports(void); void userInterruptFunctionBCBiu(AiUInt32 ul_Module, AiUInt8 uc_HsLs, AiUInt8 uc_Type,

TY_API_INTR_LOGLIST_ENTRY x_Info ); void userInterruptFunctionRTBiu(AiUInt32 ul_Module, AiUInt8 uc_HsLs, AiUInt8 uc_Type,

TY_API_INTR_LOGLIST_ENTRY x_Info );

API1553.h header file is the

header file you should include in

your program for all constant,

structure and function definitions.



/***************************************************************************** * function: main * * - Initalizes the communication to the board * - shows the programming sequence * *****************************************************************************/ void __cdecl main(void) TY_API_RESET_INFO api_res_info; AiUInt16 boardCount, retVal; AiInt32 i; AiUInt32 maj_frame_addr, min_frame_addr[MAX_API_BC_MFRAME]; TY_API_OPEN x_ApiOpen; printf("\r\n >>>>> AIM Gmbh Programming Sample for the API1553 Board <<<<<\r\n"); printf("\r\n Interrupt_Sample.c 1553 Bus Simulator BC, RT \r\n"); // Basic Initialization boardCount = ApiInit(); if (boardCount != 0) printf("\r\n Bus Controller is running on Board %d, BIU %d\r\n" ,ApiModuleHandle , 0 ); printf("\r\n Remote Terminals are running on Board %d, BIU %d\r\n" ,ApiModuleHandle, 0 ); printf("\r\n"); printf("\r\n Now do ApiOpen\r\n"); // Open Device x_ApiOpen.ul_Module = API_MODULE_1; x_ApiOpen.ul_Stream = API_STREAM_1; sprintf(x_ApiOpen.ac_SrvName, "local"); retVal = ApiOpenEx(&x_ApiOpen, &ApiModuleHandle); // use the ApiModuleHandle for all further ApiXXX.... calls if (retVal != API_OK) printf("\r\n ApiOpen failed !!\r\n"); return; printf("\r\n ApiOpened\r\n"); /* At this point the communication to the Hardware can start */ /* Now do some Setups */ PerformeSomeSystemCommands(); /* Now init the interrupt system*/ printf("\r\n Now install the Interrupt Handler Funcitons \r\n"); ApiInstIntHandler( ApiModuleHandle, API_INT_LS, API_INT_BC, userInterruptFunctionBCBiu ); ApiInstIntHandler( ApiModuleHandle, API_INT_LS, API_INT_RT, userInterruptFunctionRTBiu ); /* Now setup the communication */ Setup1553BusControllerWithSomeTransfers(); Setup1553RemoteTerminals(); /* Now start communication */

Initialize the application interface to the

target and get the number of boards in

the system. Print information indicating

which BIU is selected for the BC and

RT.

Open the Application interface to

the target module and get the

handle for the module.

There are the three main setup functions within this sample

program.. The first one, PerformeSomeSystemCommands(); will

perform setup of the system.

There are two interrupt handlers within this sample, one for the BC

and one for the RT will handle the interrupts. The pointers to the

interrupt handler are setup with the ApiInstIntHandler function

The other two main functions

will perform setup of the

BC,and RTs.

After the systems are setup, the RTs and

BC can be started.



printf(" Now Start RT and BC \r\n"); ApiCmdRTStart(ApiModuleHandle,0); ApiCmdBCStart(ApiModuleHandle,0, API_BC_START_IMMEDIATELY,0 /*0=cyclic*/,10 /*ftime in ms*/ ,0 ,&maj_frame_addr,min_frame_addr); // ... allow some time here ... printf(" Wait a while \r\n"); for (i=0; i< 10; i++) AIM_WAIT(1000); printf(" Interrupt Counter BC-BIU %6d RT-BIU %6d", (AiInt32)interruptCountBc,

(AiInt32)interruptCountRt );

printf(" IrigTime is Day:%d, Time %02d:%02d:%02d, ms:%04d\r",(((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));

if (errFlag == TRUE) printf("\n\r ERROR occurred ! \n\r"); break; AIM_WAIT(3000); /* Now stop communication */ printf("\r\n Now Stop RT and BC, and show some Results \r\n"); ApiCmdBCHalt(ApiModuleHandle,0); ApiCmdRTHalt(ApiModuleHandle,0); /* And read some Status Results */ ReadSomeStatusReports(); // Do Reset ApiCmdReset(ApiModuleHandle, 0, API_RESET_ALL, &api_res_info); printf("\r\n Now uninstall the Interrupt Handler Functions \r\n"); ApiDelIntHandler( ApiModuleHandle, API_INT_LS, API_INT_BC ); ApiDelIntHandler( ApiModuleHandle, API_INT_LS, API_INT_RT ); // Close Device retVal = ApiClose(ApiModuleHandle); printf("ApiClose\r\n"); if (retVal != API_OK) printf("ApiClose failed !!\r\n"); return; /* end: main */

Print the interrupt counter and the time

to show interrupts are working.

Then BC, RTs and BM

are halted.

Status is printed to the

console in this function.

Finally, the data

structures and variables

are re-initialized to a

default state. TheBC and RT interrupt

handlers must be

uninstalled (pointers

removed) prior to

module close. The module is closed

thus allowing no further

communication, except

ApiOpen.



/***************************************************************************** * function: PerformeSomeSystemCommands * * - Initalizes the board * - Resets the Commnunication to the board * - Reads all version informations * - Set the coupling * * *****************************************************************************/ void PerformeSomeSystemCommands(void) TY_API_INI_INFO api_ini_info; TY_API_RESET_INFO api_res_info; ApiCmdIni(ApiModuleHandle, API_INIT_MODE_READ, &api_ini_info); ApiCmdReset(ApiModuleHandle, 0, API_RESET_ALL, &api_res_info); // Set Coupling mode for BC BIU to onboard MILbus Network simulation printf(" ApiCmdCalCplCon set to onboard MILbus Network simulation for BIU %d \r\n", 0); ApiCmdCalCplCon(ApiModuleHandle,0,API_CAL_BUS_PRIMARY, API_CAL_CPL_EXTERNAL); ApiCmdCalCplCon(ApiModuleHandle,0,API_CAL_BUS_SECONDARY,API API_CAL_CPL_EXTERNAL);

Initialize the modul to

receive module

properties.

The data structures and variables

are initialized to a default state.

The coupling mode for the

primary and secondary

buses are set to "externally

coupled".



/***************************************************************************** * function: Setup1553BusControllerWithSomeTransfers * * - Init Bus Controler * - Setup tree different transfers with data buffer and buffer header * - Setup minor frame * - Setup major frame * * *****************************************************************************/ void Setup1553BusControllerWithSomeTransfers(void) TY_API_BC_BH_INFO api_bc_bh_desc; TY_API_BC_XFER api_bc_xfer; TY_API_BC_FRAME api_bc_frame; TY_API_BC_MFRAME api_bc_mframe; AiUInt16 out_dataw[32], rid, xfer_id, buf_id, bc_hid; AiUInt32 addr; AiInt32 i; printf(" Now do Setup API1553 Bus Controller \r\n"); // Bus Controller Commands ApiCmdBCIni(ApiModuleHandle,0,0,0,0,0); // BC Broadcast Transfer XF1: C31_R_01_02 (RT31,RCV,SA01,WC2) xfer_id = 1; buf_id = 1; bc_hid = 1; 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.xmt_rt = 0; /* XMT-RT */ api_bc_xfer.rcv_rt = 31; /* RCV-RT */ api_bc_xfer.xmt_sa = 0; /* XMT-SA */ api_bc_xfer.rcv_sa = 1; /* RCV-SA */ api_bc_xfer.wcnt = 2; /* Word Count field */ api_bc_xfer.tic = API_BC_TIC_INT_ON_XFER_END; /* Interrupt control */ // 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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); for(i=0;i<32;i++) out_dataw[i] = 0x3131; ApiCmdBufDef(ApiModuleHandle,0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,

&rid,&bufferAddress[buf_id]);

Initializes the BC defining #

of retries and bus to be used

(primary or seconday). (0

indicates default which is no

retry and primary enabled)

First assign a transfer ID, Buffer ID

and a BC Header ID. Then the

structure containing the information

about the BC transfer is defined.

This information is the input to the

ApiCmdBCXferDef function below.

BC-to-RT xfer

RT31 SA1

word count = 2

Sets interrupt to

occur on end of

transfer.




The message buffer is then

initialized with data 3131h.



// BC-RT Transfer XF2: C01_R_01_04 (RT01,RCV,SA01,WC4) 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_INT_ON_XFER_END; /* Interrupt control */ // 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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); for(i=0;i<32;i++) out_dataw[i] = 0x1111; /* BC transmit datawords */ ApiCmdBufDef(ApiModuleHandle0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,

&rid,&bufferAddress[buf_id]); // RT-BC Transfer XF3: C02_T_02_05 (RT02,XMT,SA02,WC5) xfer_id = 3; buf_id = 3; bc_hid = 3; 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_RTBC; /* Transfer Type */ api_bc_xfer.chn = API_BC_XFER_BUS_PRIMARY; /* MILbus */ api_bc_xfer.xmt_rt = 2; /* XMT-RT */ api_bc_xfer.rcv_rt = 0; /* RCV-RT */ api_bc_xfer.xmt_sa = 2; /* XMT-SA */ api_bc_xfer.rcv_sa = 0; /* RCV-SA */ api_bc_xfer.wcnt = 5; /* Word Count field */ api_bc_xfer.tic = API_BC_TIC_INT_ON_XFER_ERR; /* Interrupt control */ // 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 Request Handling */ api_bc_xfer.rte = 0; /* Reserved */ api_bc_xfer.res = 0; /* Reserved */ 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 */ api_bc_xfer.err.type = API_ERR_TYPE_NO_INJECTION; /* error injection type */ api_bc_xfer.err.sync = 0; api_bc_xfer.err.contig = 0; api_bc_xfer.err.err_spec = 0; api_bc_xfer.err.err_spec |= (0 << 16); /* wpos */ api_bc_xfer.err.err_spec |= (0 << 8); /* bpos */ api_bc_xfer.err.err_spec |= (0 << 0); /* bc_bits */ 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);



BC-to-RT xfer

RT1 SA1

word count = 4

Sets interrupt to

occur on end of

transfer.





with data 1111h



RT-to-BC xfer

RT2 SA2

word count = 5

Sets interrupt to

occur on transfer

error.





(cleared) to 0.



for(i=0;i<32;i++) out_dataw[i] = 0x0000; /* clear BC receive buffer */ ApiCmdBufDef(ApiModuleHandle,0,API_BUF_BC_MSG,0,buf_id,32, out_dataw,

&rid,&bufferAddress[buf_id]); /* Minor Frame 1 MF1 Transfer sequence */ api_bc_frame.id = 1; api_bc_frame.cnt = 3; api_bc_frame.xid[0] = 1; /* XF1 */ api_bc_frame.instr[0] = API_BC_INSTR_TRANSFER; api_bc_frame.xid[1] = 2; /* XF2 */ api_bc_frame.instr[1] = API_BC_INSTR_TRANSFER; api_bc_frame.xid[2] = 3; /* XF3 */ api_bc_frame.instr[2] = API_BC_INSTR_TRANSFER; ApiCmdBCFrameDef(ApiModuleHandle,0,&api_bc_frame); /* Minor Frame sequence in Major Frame */ api_bc_mframe.cnt = 1; api_bc_mframe.fid[0] = 1; /* MF1 */ ApiCmdBCMFrameDefEx(ApiModuleHandle,0,&api_bc_mframe);

The minor and major frames are then

defined using the xfer IDs defined

above.

One minor fame is defined with three

transfers: XF1, XF2, and XF3 (which

were defined above).

The major frame is defined with one

minor frame: Minor frame 1

Note: The ApiCmdBCStart function

call in the main program will define

the timing of each minor frame within

the major frame.



/***************************************************************************** * function: Setup1553RemoteTerminals * * - Init all needed Remote Terminals * - Setup buffers and buffer header for RTs * - Configure RT subadresses and assign buffers to it * * *****************************************************************************/ void Setup1553RemoteTerminals(void) TY_API_RT_BH_INFO api_rt_bh_desc; AiUInt16 out_dataw[32], rt_hid, rid, buf_id; AiInt32 i; printf(" Now do Setup API1553 Remote Terminals \r\n"); // Remote Terminal Commands ApiCmdRTIni(ApiModuleHandle,0, 1/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x0800); ApiCmdRTIni(ApiModuleHandle,0, 2/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x1000); ApiCmdRTIni(ApiModuleHandle,0,31/*RT*/,API_RT_ENABLE_SIMULATION, 0, 8, 0x1800); rt_hid = 1; buf_id = 10; for(i=0;i<32;i++) out_dataw[i] = 0x0000; /* clear RT-SA receive buffer */ ApiCmdRTBHDef( ApiModuleHandle, 0, rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,

&api_rt_bh_desc); ApiCmdBufDef( ApiModuleHandle, 0, API_BUF_RT_MSG,0,buf_id,32,out_dataw,&rid,

&bufferAddress[buf_id]); 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*/); rt_hid = 2; buf_id = 11; for(i=0;i<32;i++) out_dataw[i] = 0x2222; /* RT-SA transmit datawords */ ApiCmdRTBHDef( ApiModuleHandle, 0, rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,


&bufferAddress[buf_id]); ApiCmdRTSACon( ApiModuleHandle, 0, 2/*RT*/ ,2/*SA*/, rt_hid/*HID*/,

API_RT_TYPE_TRANSMIT_SA, API_RT_ENABLE_SA_INT_XFER, 0/*rmod*/, API_RT_SWM_OR, 0/*swm*/); rt_hid = 3; buf_id = 12; for(i=0;i<32;i++) out_dataw[i] = 0x3333; /* RT-SA transmit datawords */ ApiCmdRTBHDef( ApiModuleHandle, 0, rt_hid,buf_id,0,0,API_QUEUE_SIZE_1,0,0,0,0,0,


&bufferAddress[buf_id]); ApiCmdRTSACon( ApiModuleHandle, 0, 31/*RT*/, 1/*SA*/, rt_hid/*HID*/,

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

The mode, response time and the

value of the next status word for each

simulated RT is initialized.


receive message buffer is cleared.

A Buffer ID and RT Header ID for the transfer from RT2 SA2 is assigned. The

transmit message buffer is initialized with 2222h.


receive message is cleared. This RT is setup to be able to monitor the broadcast.

The RT processor is the only RT setup for transmit

so it is setup here to interrupt on end of transfer.

The RT processor is setup here to interrupt on

any transfer error.



/***************************************************************************** * function: ReadSomeStatusReports * * - Read BC Status and Transfer informations * - Read RT STatus * - Read BM Activity *****************************************************************************/ void ReadSomeStatusReports(void) TY_API_BC_XFER_DSP api_bc_xfer_dsp; TY_API_BC_STATUS_DSP api_bc_status_dsp; TY_API_RT_STATUS_DSP api_rt_status_dsp; // BC Gobal Status printf("\r\n Now Read BC Status \r\n"); ApiCmdBCStatusRead(ApiModuleHandle,0,&api_bc_status_dsp); printf(" Results: status = %8x\r\n", (AiInt32)api_bc_status_dsp.status); printf(" hxfer = %8x\r\n", (AiInt32)api_bc_status_dsp.hxfer); printf(" glb_msg_cnt = %8x\r\n", (AiInt32)api_bc_status_dsp.glb_msg_cnt); printf(" glb_err_cnt = %8x\r\n", (AiInt32)api_bc_status_dsp.glb_err_cnt); // BC Transfer Status printf("\r\n Now Read BC Xfer 1 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,1/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %8x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %8x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt); printf("\r\n Now Read BC Xfer 2 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,2/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %8x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %8x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt); printf("\r\n Now Read BC Xfer 3 \r\n"); ApiCmdBCXferReadEx(ApiModuleHandle,0,3/*xfer_id*/,0,&api_bc_xfer_dsp); printf(" Results: cw1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw1); printf(" st1 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st1); printf(" cw2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.cw2); printf(" st2 = %8x\r\n", (AiInt32)api_bc_xfer_dsp.st2); printf(" bid = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bid); printf(" brw = %8x\r\n", (AiInt32)api_bc_xfer_dsp.brw); printf(" bufp = %8x\r\n", (AiInt32)api_bc_xfer_dsp.bufp); printf(" ttag = %8x\r\n", (AiInt32)api_bc_xfer_dsp.ttag); printf(" msg_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.msg_cnt); printf(" err_cnt = %8x\r\n", (AiInt32)api_bc_xfer_dsp.err_cnt); // RT Gobal Status printf("\r\n Now Read RT Status \r\n"); ApiCmdRTStatusRead(ApiModuleHandle,0,&api_rt_status_dsp); printf(" Results: status = %8x\r\n", (AiInt32)api_rt_status_dsp.status); printf(" glb_msg_cnt = %8x\r\n", (AiInt32)api_rt_status_dsp.glb_msg_cnt); printf(" glb_err_cnt = %8x\r\n", (AiInt32)api_rt_status_dsp.glb_err_cnt);

This intermodule function demonstrates the

"Read" functions for the BC, BC Xfer, RT and

BM RT status functions. It also shows some

sample code to print the results.



/******************************************************************************* * Function : userInterruptFunctionBCBiu Author : Rolf Heitzmann *------------------------------------------------------------------------------ * Create : 18.01.00 last Update : 28.12.00 Status: [i][t][ ] *------------------------------------------------------------------------------ * Descriptions * ------------ * User Interrupt Function to do some Buffer modifications from interrupt. * This Function is used for BC-BIU Interrupt * * Inputs : ul_Module - board which has produced the interrupt * uc_LsHs - On 1553 always Api_INT_LS * uc_Type - interrupt Type (BC/RT/BM...) * x_Info - Information in structure TY_API_INTR_LOGLIST_ENTRY * * Outputs : - * * Return : - * ******************************************************************************/ void userInterruptFunctionBCBiu(AiUInt32 ul_Module, AiUInt8 uc_LsHs, AiUInt8 uc_Type,

TY_API_INTR_LOGLIST_ENTRY x_Info ) AiUInt32 buffAddr; AiUInt32 tempVar; AiUInt16 out_dataw[32]; AiUInt16 i; AiUInt32 bytesWritten; /* ATTENTION! printf outputs in a Interrupt routine may result in problems on high interrupt load. So this is only for Test */ /* printf("\n\n User Interrupt occured!"); printf("\n Board %d, BIU %d, Type %d !", uc_Module, uc_Biu, uc_Type); printf("\n LoLi: lla = %08x, llb = %08x, llc = %08x, lld = %08x\n\n", x_Info.ul_Lla, x_Info.ul_Llb, x_Info.ul_Llc, x_Info.ul_Lld); */ interruptCountBC++; if (x_Info.ul_Lld == 1) buffAddr = bufferAddress[x_Info.ul_Lld]; ApiReadMemData(ul_Module, API_MEMTYPE_GLOBAL, buffAddr, sizeof(AiUInt32),

(void*)&tempVar); tempVar++; for(i=0;i<32;i++) out_dataw[i] = (AiUInt16)tempVar; ApiWriteBlockMemData(ul_Module, API_MEMTYPE_GLOBAL, buffAddr, sizeof(AiUInt16), (void*)out_dataw, 64, &bytesWritten); if (x_Info.ul_Lld == 3) buffAddr = bufferAddress[x_Info.ul_Lld]; out_dataw[0] = (AiUInt16)0xFFAA; ApiWriteMemData(ul_Module, API_MEMTYPE_GLOBAL, buffAddr, sizeof(AiUInt16),

(void*)out_dataw); if ((x_Info.ul_Lla & 0x02000000) == 0x02000000) errFlag = TRUE; // END: userInterruptFunction

These print statements are commented out - but if

put back into the code, they would print everytime

the BC XFR1 and XF2 were completed and

everytime an error occurred with XFR3.

The global interrupt counter is incremented.

If BC XFR 1, then read the first 2 data words in

the buffer into tempVar, then increment tempVar.

The incremented data word will be put back

into the buffer to show that the end-of-XFR

caused an interrupt.

If BC XFR3, then the interrupt was due to error -

so write the word FFAAh back into the buffer to

show that this buffer created a Xfer error interrupt.

If the error bit was set, then indicate any xfr error

occurred by setting the global error flag to true.

This interrupt handler is needed to process the BC interupts setup in structure element

api_bc_ xfer.tic which is used in the ApiCmdBCXfrDef function.



/******************************************************************************* * Function : userInterruptFunctionRTBiu Author : Rolf Heitzmann *------------------------------------------------------------------------------ * Create : 18.01.00 last Update : 28.12.00 Status: [i][t][ ] *------------------------------------------------------------------------------ * Descriptions * ------------ * User Interrupt Function to do some Buffer modifications from interrupt. * This Function is used for RT-BIU Interrupt * * Inputs : uc_Module - board which has produced the interrupt * uc_LsHs - On 1553 always Api_INT_LS * uc_Type - interrupt Type (BC/RT/BM...) * x_Info - Information in structure TY_API_INTR_LOGLIST_ENTRY * * Outputs : - * * Return : - * ******************************************************************************/ void userInterruptFunctionRTBiu(AiUInt32 ul_Module, AiUInt8 uc_LsHs, AiUInt8 uc_Type,

TY_API_INTR_LOGLIST_ENTRY x_Info ) AiUInt32 buffAddr; AiUInt16 tempVar;

AiUInt16 out_dataw[32]; AiUInt16 i; AiUInt32 bytesWritten; /* ATTENTION! printf outputs in a Interrupt routine may result in problems on high interrupt load. So this is only for Test */ /* printf("\n\n User Interrupt occured!"); printf("\n Board %d, BIU %d, Type %d !", uc_Module, uc_Biu, uc_Type); printf("\n LoLi: lla = %08x, llb = %08x, llc = %08x, lld = %08x\n\n", x_Info.ul_Lla,

x_Info.ul_Llb, x_Info.ul_Llc, x_Info.ul_Lld); */ interruptCountRt++; if (x_Info.ul_Lld >= 10) buffAddr = bufferAddress[x_Info.ul_Lld]; ApiReadMemData(ul_Module, API_MEMTYPE_GLOBAL, buffAddr, sizeof(AiUInt16),

(void*)&tempVar); tempVar++; out_dataw[0] = (AiUInt16)tempVar; out_dataw[0] |= (AiUInt16)(tempVar << 8); for(i=1;i<32;i++) out_dataw[i] = out_dataw[0]; ApiWriteBlockMemData(ul_Module, API_MEMTYPE_GLOBAL, buffAddr, sizeof(AiUInt16), (void*)out_dataw, 32, &bytesWritten); ApiCmdGetIrigTime( ul_Module, &api_irig_time); if ((x_Info.ul_Lla & 0x02000000) == 0x02000000) errFlag = TRUE; // END: userInterruptFunctionBiu2

These print statements are commented out - but if

put back into the code, they would print everytime

the BC XFR1 and XF2 were completed and

everytime an error occurred with XFR3.

The global interrupt counter is incremented.

If RT Buf 10, then read the first 2 data words

in the buffer into tempVar, then increment

tempVar .

The incremented data word will be put back

into the buffer to show that the end-of-XFR

caused an interrupt.

If the error bit was set, then indicate any xfr error

occurred by setting the global error flag to true.

This interrupt handler is needed to process the RT interupts setup using in the

ApiCmdRTSACon function.


Section 5 - Program Samples Function Calls vs. Program Samples

5.3 API S/W Library Function Calls vs. Program Samples

Table 5.3-I provides a list of all the function calls within the API S/W Library and which

sample program contains the function call and how often is it used in the sample program.

This table is useful for searching for program examples of how a function call is used within a

program.

Table 5.3-I API S/W Library Function Calls vs. Program Samples

Inte

rru

pt_

Sa

mp

le.c

LS

_B

C_

Ac

yc

lic

_X

fers

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_a

nd

_1

76

0_

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_D

yta

g_

Sa

mp

le.c

LS

_B

C_

Dy

na

mic

_D

ata

_S

ys

tag

_S

am

ple

.c

LS

_B

C_

Ex

tern

al_

BC

_T

rig

ge

r_S

am

ple

.c

LS

_B

C_

Fif

o_

Sa

mp

le.c

LS

_B

C_

Mlt

ibu

ffe

r_S

am

ple

.c

LS

_B

C_

RT

_B

M_

Sa

mp

le.c

LS

_B

C_

RT

_F

W_

Sa

mp

le.c

LS

_B

M_

Me

ss

ag

e_

Fil

ter_

Re

co

rdin

g_

Sa

mp

le.

c

LS

_B

M_

Qu

eu

e_

Sa

mp

le.c

LS

_R

ec

ord

ing

_S

am

ple

.c

LS

_R

ep

lay

_S

am

ple

.c

LS

_R

T_

Glo

ba

l_C

on

_S

am

ple

.c

Library Administration Functions

ApiInit

ApiOpenEx

ApiClose

ApiGetTgEmul

ApiSetTgEmul

ApiGetTcomStatus

ApiGetOpenErr

ApiInstIntHandler

ApiDelIntHandler

ApiConnectToServer

ApiDisconnectFromServer

ApiPrintfOnServer

ApiGetServerInfo

ApiSetDllDbgLevel

System Functions

ApiCmdIni

ApiCmdReset

ApiCmdBite

ApiCmdDefRespTout



Inte

rru

pt_

Sa

mp

le.c

LS

_B

C_

Ac

yc

lic

_X

fers

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_a

nd

_1

76

0_

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_D

yta

g_

Sa

mp

le.c

LS

_B

C_

Dy

na

mic

_D

ata

_S

ys

tag

_S

am

ple

.c

LS

_B

C_

Ex

tern

al_

BC

_T

rig

ge

r_S

am

ple

.c

LS

_B

C_

Fif

o_

Sa

mp

le.c

LS

_B

C_

Mlt

ibu

ffe

r_S

am

ple

.c

LS

_B

C_

RT

_B

M_

Sa

mp

le.c

LS

_B

C_

RT

_F

W_

Sa

mp

le.c

LS

_B

M_

Me

ss

ag

e_

Fil

ter_

Re

co

rdin

g_

Sa

mp

le.

c

LS

_B

M_

Qu

eu

e_

Sa

mp

le.c

LS

_R

ec

ord

ing

_S

am

ple

.c

LS

_R

ep

lay

_S

am

ple

.c

LS

_R

T_

Glo

ba

l_C

on

_S

am

ple

.c

ApiCmdReadSWVersion

ApiReadBSPVersion

ApiReadBSPVersionEx

ApiCmdPSCTimerCon

ApiCmdTimerIntrCheck

ApiCmdBiuIntrCheck

ApiCmdLoadSRec

ApiCmdProgFlash

ApiCmdExecSys

ApiCmdSetIrigTime

ApiCmdGetIrigTime

ApiCmdDefMilbusProtocol

ApiReadRecData

ApiWriteRepData

ApiCmdSystagDef

ApiCmdSystagCon

ApiCmdTrackDefEx

ApiCmdTrackReadEx

ApiCmdSysSetMemPartition

ApiCmdSysGetMemPartition

ApiCmdWriteDiscretes

ApiCmdInitDiscretes

Calibration Functions

ApiCmdCalSigCon

ApiCmdCalCplCon

ApiCmdCalTransCon

ApiCmdCalXmtCon

Buffer Functions

ApiCmdBufDef

ApiCmdBufRead

ApiCmdBufWrite

ApiCmdRamWrite

ApiCmdRamRead



Inte

rru

pt_

Sa

mp

le.c

LS

_B

C_

Ac

yc

lic

_X

fers

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_a

nd

_1

76

0_

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_D

yta

g_

Sa

mp

le.c

LS

_B

C_

Dy

na

mic

_D

ata

_S

ys

tag

_S

am

ple

.c

LS

_B

C_

Ex

tern

al_

BC

_T

rig

ge

r_S

am

ple

.c

LS

_B

C_

Fif

o_

Sa

mp

le.c

LS

_B

C_

Mlt

ibu

ffe

r_S

am

ple

.c

LS

_B

C_

RT

_B

M_

Sa

mp

le.c

LS

_B

C_

RT

_F

W_

Sa

mp

le.c

LS

_B

M_

Me

ss

ag

e_

Fil

ter_

Re

co

rdin

g_

Sa

mp

le.

c

LS

_B

M_

Qu

eu

e_

Sa

mp

le.c

LS

_R

ec

ord

ing

_S

am

ple

.c

LS

_R

ep

lay

_S

am

ple

.c

LS

_R

T_

Glo

ba

l_C

on

_S

am

ple

.c

ApiCmdRamWriteLWord

ApiCmdRamWriteWord

ApiCmdRamWriteByte

ApiCmdRamReadLWord

ApiCmdRamReadWord

ApiCmdRamReadByte

ApiCmdRamWriteDataset

ApiCmdRamReadDataset

ApiReadMemData

ApiWriteMemData

ApiReadBlockMemData

ApiWriteBlockMemData

ApiCmdBufC1760Con

ApiBHModify

FIFO Functions

ApiCmdFifoIni

ApiCmdFifoWrite

ApiCmdFifoReadStatus

ApiCmdBCAssignFifo

ApiCmdRTSAAssignFifo

BC Functions

ApiCmdBCAcycPrep

ApiCmdBCAcycSend

ApiCmdBCBHDef

ApiCmdBCDytagDef

ApiCmdBCFrameDef

ApiCmdBCGetDytagDef ApiCmdBCGetMajorFrameDefinition ApiCmdBCGetMinorFrameDefinition ApiCmdBCGetXferBufferHeaderInfo

ApiCmdBCGetXferDef

ApiCmdBCHalt

ApiCmdBCIni



Inte

rru

pt_

Sa

mp

le.c

LS

_B

C_

Ac

yc

lic

_X

fers

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_a

nd

_1

76

0_

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_D

yta

g_

Sa

mp

le.c

LS

_B

C_

Dy

na

mic

_D

ata

_S

ys

tag

_S

am

ple

.c

LS

_B

C_

Ex

tern

al_

BC

_T

rig

ge

r_S

am

ple

.c

LS

_B

C_

Fif

o_

Sa

mp

le.c

LS

_B

C_

Mlt

ibu

ffe

r_S

am

ple

.c

LS

_B

C_

RT

_B

M_

Sa

mp

le.c

LS

_B

C_

RT

_F

W_

Sa

mp

le.c

LS

_B

M_

Me

ss

ag

e_

Fil

ter_

Re

co

rdin

g_

Sa

mp

le.

c

LS

_B

M_

Qu

eu

e_

Sa

mp

le.c

LS

_R

ec

ord

ing

_S

am

ple

.c

LS

_R

ep

lay

_S

am

ple

.c

LS

_R

T_

Glo

ba

l_C

on

_S

am

ple

.c

ApiCmdBCInstrTblGen

ApiCmdBCInstrTblGetAddrFomLabel

ApiCmdBCInstrTblIni

ApiCmdBCMFrameDefEx

ApiCmdBCSrvReqVecStatus

ApiCmdBCStart

ApiCmdBCStatusRead

ApiCmdBCXferCtrl

ApiCmdBCXferDef

ApiCmdBCXferReadEx

RT Functions

ApiCmdRTBHDef

ApiCmdRTBHRead

ApiCmdRTDytagDef

ApiCmdRTEnaDis

ApiCmdRTGetDytagDef

ApiCmdRTGetSABufferHeaderInfo

ApiCmdRTGetSAConErr

ApiCmdRTGetSimulationInfo

ApiCmdRTGlobalCon

ApiCmdRTHalt

ApiCmdRTIni

ApiCmdRTLCW

ApiCmdRTLSW

ApiCmdRTMsgRead

ApiCmdRTMsgReadAll

ApiCmdRTNXW

ApiCmdRTRespTime

ApiCmdRTSACon

ApiCmdRTSAConErr

ApiCmdRTSAMsgReadEx

ApiCmdRTStart

ApiCmdRTStatusRead



Inte

rru

pt_

Sa

mp

le.c

LS

_B

C_

Ac

yc

lic

_X

fers

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_a

nd

_1

76

0_

_S

am

ple

.c

LS

_B

C_

Dy

na

mic

_D

ata

_D

yta

g_

Sa

mp

le.c

LS

_B

C_

Dy

na

mic

_D

ata

_S

ys

tag

_S

am

ple

.c

LS

_B

C_

Ex

tern

al_

BC

_T

rig

ge

r_S

am

ple

.c

LS

_B

C_

Fif

o_

Sa

mp

le.c

LS

_B

C_

Mlt

ibu

ffe

r_S

am

ple

.c

LS

_B

C_

RT

_B

M_

Sa

mp

le.c

LS

_B

C_

RT

_F

W_

Sa

mp

le.c

LS

_B

M_

Me

ss

ag

e_

Fil

ter_

Re

co

rdin

g_

Sa

mp

le.

c

LS

_B

M_

Qu

eu

e_

Sa

mp

le.c

LS

_R

ec

ord

ing

_S

am

ple

.c

LS

_R

ep

lay

_S

am

ple

.c

LS

_R

T_

Glo

ba

l_C

on

_S

am

ple

.c

Bus Monitor Functions

ApiCmdBMActRead

ApiCmdBMCapMode

ApiCmdBMDytagMonDef

ApiCmdBMDytagMonRead

ApiCmdBMFilterIni

ApiCmdBMFTWIni

ApiCmdBMHalt

ApiCmdBMIllegalIni

ApiCmdBMIni

ApiCmdBMIniMsgFltRec

ApiCmdBMIntrMode


ApiCmdBMRTActRead

ApiCmdBMRTSAActRead

ApiCmdBMStackEntryFind


ApiCmdBMStackpRead

ApiCmdBMStart

ApiCmdBMStatusRead

ApiCmdBMSWXMIni

ApiCmdBMTCBIni

ApiCmdBMTCIIni

ApiCmdBMTIWIni

ApiCmdDataQueueClose

ApiCmdDataQueueControl

ApiCmdDataQueueOpen

ApiCmdDataQueueRead

ApiCmdQueueFlush

ApiCmdQueueHalt

ApiCmdQueueIni

ApiCmdQueueRead

ApiCmdQueueStart

Pro

gra

mm

er's

Guid

e fo

r PC

I 1553 W

indow

s A

pplic

atio

ns

19

7

Sectio

n 5

- Pro

gra

m S

am

ple

s

Functio

n C

alls

vs. P

rogra

m S

am

ple

s

Interrupt_Sample.c

LS_BC_Acyclic_Xfers_Sample.c

LS_BC_Dynamic_Data_and_1760__Sample.c

LS_BC_Dynamic_Data_Dytag_Sample.c

LS_BC_Dynamic_Data_Systag_Sample.c

LS_BC_External_BC_Trigger_Sample.c

LS_BC_Fifo_Sample.c

LS_BC_Mltibuffer_Sample.c


LS_BC_RT_FW_Sample.c

LS_BM_Message_Filter_Recording_Sample.c

LS_BM_Queue_Sample.c

LS_Recording_Sample.c

LS_Replay_Sample.c

LS_RT_Global_Con_Sample.c

Rep

lay F

un

ctio

ns

ApiC

mdR

epla

yIni

ApiC

mdR

epla

ySta

rt

ApiC

mdR

epla

ySto

p

ApiC

mdR

epla

ySta

tus

ApiC

mdR

epla

yRT


Section 6 – Creating a New Microsoft Visual C/C++ Application Program

6 CREATING A NEW MICROSOFT VISUAL C/C++ APPLICATION PROGRAM

Note: For information on include files and project structure see chapter 3.2.2

6.1 Steps to Create and Compile

Your new Console Win32 Application program can be created by copying a sample program

to your new workspace/project and modifying it as needed. The default location for the

sample programs is:

x:\Program Files\AIM GmbH\PCI-1553-Windows-BSP-Vxxxx\sample\msvc\win32

Once your new application has been created, there are three additional steps to configuring

the Microsoft Visual C/C++ application before compiling to insure your program executes

without error including:

a. Adding proper search paths for the API S/W Library include files

b. Adding the preprocessor definition required for the API/ACI/ANI1553

device

c. Linking the application program to the api_mil.dll via connection to

api_mil.lib

Note: api.mil.dll must be located in the same directory as the User's Application

executable(s).

Note: The api.mil.dll was compiled in _stdcall calling convention. To prevent

stack problems it is highly recommend that the user application is also compiled with

_stdcall calling convention!

Please review the following steps to accomplish the items above.

To add the proper search paths for the API S/W Library include files perform

the following steps:

1. Select Tools | Options

The Options window will pop up.

2. Select the Directories Tab

3. For Show directories for:, select Include Files

4. Add the Directory with the include files:


Vxxxx\spg

5. Select OK



To add the preprocessor definition:

1. Select Project | Settings

The project settings window will pop up.

2. Select the C/C++ tab

3. Under Preprocessor Definitions enter _AIM_WINDOWS

4. Select OK



To link the api_mil.lib to the application program perform the following

steps

1. Select your project file (in example, Project A Files)

2. Select Project | Add to Project | Files...

An "Insert Files into Project" window will pop up.

3. For Files of Type: entry, select Library Files (.lib)

4. For File Name: Look in


Vxxxx\bin\msvc\win32

5. Select api_mil.lib

api_mil.lib will be added to your project.


Section 7 - Notes

7 NOTES

7.1 Acronyms and Abbreviations

Ω ohms

µs microseconds

ACI AIM Compact PCI I-Architecture

ACK Acknowledge

addr address

ANI AIM Notebook Architecture

ANS AIM Network Server

API AIM PCI I-Architecture

App Appendix

ARINC Aeronautical Radio, Incorporated

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


Section 7 - Notes

FIFO First in/First out

FLASH Page oriented electrical erasable and programmable memory

FOFE Fiber Optic Front End

GmbH Gesellschaft für angewandte Informatik und Mikroelektronik

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

NetBIOS Network Basic Input/Output System

NOP No operation - indicates no executable code

PBA MIL-STD-1553 Databus Analyzer Software for Windows

PBI Physical Bus Interface

PC Personal Computer

PC/AT Personal Computer/Advanced Technology

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


Section 7 - Notes

UINT unsigned integer

VME Versa Module Eurocard

VxD Virtual Device Driver

VXI Vmebus Extensions for Instrumentation

WDM Windows Driver Model

wpos word position

xid transfer identifier


Section 7 - Notes

7.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


Section 7 - 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

Trigger pattern

8 bits in the Monitor Status Word that reflect the results of the Monitor

Trigger Block execution of the BIU Processor.

Monitor Status

Word

reflects the current status of Bus Monitor operation

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

Value

The maximum time the Bus Controller will wait for a Status word

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

(BC)

an area of memory assigned by the target s/w to store status of the 1553

transfer

Transfer Descriptor

(RT)

an area of memory assigned by the target s/w to store status of the 1553

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.


Section 7 - Notes



Index

API S/W LIBRARY INDEX

ApiBHModify 28, 62, 96, 194

ApiClose 26, 46, 53, 192

ApiCmdBCAcycPrep 30, 54, 84, 85, 87,

194

ApiCmdBCAcycSend 30, 84

ApiCmdBCAcycySend 194

ApiCmdBCAssignFifo 29, 67, 194

ApiCmdBCBHDef 30, 61, 66, 67, 99, 194

ApiCmdBCDytagDef 30, 67, 194

ApiCmdBCFrameDef 30, 54, 73, 74, 79,

84, 85, 87, 152, 161, 194

ApiCmdBCGetDytagDef 30, 194

ApiCmdBCGetMajorFrameDefinition 30,

194

ApiCmdBCGetMinorFrameDefinition 30,

194

ApiCmdBCGetXferBufferHeaderInfo 30,

194

ApiCmdBCGetXferDef 30, 194

ApiCmdBCHalt 30, 194

ApiCmdBCIni 30, 60, 61, 89, 118, 194

ApiCmdBCInstrTblGen 30, 54, 75, 79, 80,

83, 85, 87, 195

ApiCmdBCInstrTblGetAddrFomLabel 30,

195

ApiCmdBCInstrTblIni 30, 75, 195

ApiCmdBCMFrameDefEx 30, 73, 74, 152,

161, 195

ApiCmdBcModeCtrl 30

ApiCmdBCSrvReqVecCon 30

ApiCmdBCSrvReqVecStatus 30, 90, 195

ApiCmdBCStart 30, 54, 73, 77, 79, 83, 85,

195

ApiCmdBCStatusRead 30, 195

ApiCmdBCXferCtrl 30, 195

ApiCmdBCXferDef 30, 54, 60, 61, 62, 67,

77, 85, 86, 87, 88, 89, 90, 91, 195

ApiCmdBCXferReadEx 30, 195

ApiCmdBite 27, 47, 192

ApiCmdBiuIntrCheck 27, 193

ApiCmdBMActRead 32, 196

ApiCmdBMCapMode 32, 113, 117, 118,

120, 141, 142, 143, 196

ApiCmdBMDytagMonDef 32, 144, 196

ApiCmdBMDytagMonRead 32, 145, 196

ApiCmdBMFilterIni 32, 114, 118, 144,

196

ApiCmdBMFTWIni 32, 113, 117, 121,

132, 141, 142, 144, 196

ApiCmdBMHalt 32, 117, 196

ApiCmdBMIllegalIni 32, 118, 196

ApiCmdBMIni 32, 113, 117, 124, 139,

141, 142, 143, 144, 196

ApiCmdBMIniMsgFltRec 32, 117, 120,

144, 196

ApiCmdBMIntrMode 32, 54, 113, 117,

118, 120, 135, 141, 142, 143, 196

ApiCmdBMReadMsgFltRec 32, 117, 120,

144, 196

ApiCmdBMRTActRead 32, 196

ApiCmdBMRTSAActRead 32, 196

ApiCmdBMStackEntryFind 32, 196

ApiCmdBMStackEntryRead 32, 115, 117,

141, 196

ApiCmdBMStackpRead 32, 115, 117, 141,

196

ApiCmdBMStart 32, 117, 136, 143, 144,

196

ApiCmdBMStatusRead 32, 169, 196

ApiCmdBMSWXMIni 32, 118, 124, 139,

196

ApiCmdBMTCBIni 32, 54, 113, 117, 121,

122, 123, 127, 136, 141, 142, 144, 196

ApiCmdBMTCIIni 32, 196

ApiCmdBMTIWIni 32, 114, 117, 121,

134, 135, 141, 142, 144, 196

ApiCmdBufC1760Con 28, 194

ApiCmdBufDef 28, 67, 71, 99, 101, 102,

193

ApiCmdBufRead 28, 193

ApiCmdBufWrite 28, 67, 102, 193

ApiCmdCalCplCon 28, 48, 50, 193


Index

ApiCmdCalSigCon 28, 50, 193

ApiCmdCalTransCon 28, 193

ApiCmdCalXmtCon 28, 48, 49, 50, 193

ApiCmdDataQueueClose 196

ApiCmdDataQueueControl 196

ApiCmdDataQueueOpen 196

ApiCmdDataQueueRead 196

ApiCmdDefMilbusProtocol 27, 47, 50, 64,

88, 193

ApiCmdDefRespTout 27, 51, 192

ApiCmdExecSys 27, 193

ApiCmdFifoIni 29, 67, 102, 194

ApiCmdFifoReadStatus 29, 67, 102, 194

ApiCmdFifoWrite 29, 67, 102, 194

ApiCmdGetIrigTime 27, 51, 193

ApiCmdIni 27, 45, 192

ApiCmdInitDiscretes 27, 58, 193

ApiCmdLoadSRec 27, 193

ApiCmdProgFlash 27, 193

ApiCmdPSCTimerCon 27, 193

ApiCmdQueueFlush 32, 196

ApiCmdQueueHalt 32, 196

ApiCmdQueueIni 32, 113, 117, 143, 196

ApiCmdQueueRead 32, 116, 117, 143, 196

ApiCmdQueueStart 32, 117, 136, 143, 196

ApiCmdRamRead 28, 193

ApiCmdRamReadByte 28, 194

ApiCmdRamReadDataset 28, 194

ApiCmdRamReadLWord 28, 194

ApiCmdRamReadWord 28, 194

ApiCmdRamWrite 28, 193

ApiCmdRamWriteByte 28, 194

ApiCmdRamWriteDataset 28, 67, 102,

157, 194

ApiCmdRamWriteLWord 28, 194

ApiCmdRamWriteWord 28, 194

ApiCmdReadDiscretes 27

ApiCmdReadDiscretes 58

ApiCmdReadSWVersion 27, 47, 193

ApiCmdReplayIni 33, 54, 146, 197

ApiCmdReplayRT 33, 147, 197

ApiCmdReplayStart 33, 147, 197

ApiCmdReplayStatus 33, 148, 197

ApiCmdReplayStop 33, 197

ApiCmdReset 27, 46, 47, 50, 51, 192

ApiCmdRTBHDef 31, 95, 97, 98, 99, 102,

107, 195

ApiCmdRTBHRead 31

ApiCmdRTBHRead 195

ApiCmdRTDytagDef 31, 99, 102, 195

ApiCmdRTEnaDis 31, 195

ApiCmdRTGetDytagDef 31, 195

ApiCmdRTGetSABufferHeaderInfo 31,

195

ApiCmdRTGetSAConErr 31, 195

ApiCmdRTGetSimulationInfo 31, 195

ApiCmdRTGlobalCon 31, 110, 166, 195

ApiCmdRTHalt 31, 195

ApiCmdRTIni 31, 94, 97, 98, 106, 108,

110, 195

ApiCmdRTLCW 31, 106, 195

ApiCmdRTLSW 31, 195

ApiCmdRtModeCtrl 31

ApiCmdRTMsgRead 31, 195

ApiCmdRTMsgReadAll 31, 195

ApiCmdRTNXW 31, 106, 195

ApiCmdRTRespTime 31, 94, 195

ApiCmdRTSAAssignFifo 29, 102, 194

ApiCmdRTSACon 31, 54, 97, 98, 102,

103, 105, 106, 107, 108, 109, 110, 111,

195

ApiCmdRTSAConErr 31, 106, 107, 195

ApiCmdRTSAMsgRead 195

ApiCmdRTSAMsgReadEx 31

ApiCmdRTStart 31, 109, 195

ApiCmdRTStatusRead 31, 195

ApiCmdSetIrigTime 27, 51, 193

ApiCmdSyncCounterGet 27

ApiCmdSyncCounterSet 27

ApiCmdSysGetMemPartition 27, 193

ApiCmdSysMemLayout 75

ApiCmdSysSetMemPartition 27, 193

ApiCmdSystagCon 27, 193

ApiCmdSystagDef 27, 67, 102, 193

ApiCmdTimerIntrCheck 27, 193

ApiCmdTrackDefEx 27, 91, 110, 111,

112, 193

ApiCmdTrackPreAlloc 27

ApiCmdTrackReadEx 27, 92, 112, 193

ApiCmdTrackScan 27

ApiCmdWriteDiscretes 27, 58, 193

ApiConnectToServer 26, 44, 45, 192

ApiDelIntHandler 26, 53, 192

ApiDisconnectFromServer 26, 46, 47, 192


Index

ApiGetBoardInfo 26

ApiGetLibraryInfo 26

ApiGetOpenErr 26, 192

ApiGetServerInfo 26, 47, 192

ApiGetTcomStatus 26, 47, 192

ApiGetTgEmul 26, 192

ApiInit 26, 44, 45, 192

ApiInstIntHandler 26, 52, 53, 85, 109, 136,

192

ApiOpenEx 26, 44, 45, 46, 192

ApiPrintfOnServer 26, 192

ApiReadBlockMemData 28, 77, 115, 117,

141, 194

ApiReadBSPVersion 193

ApiReadBSPVersionEx 27, 47, 193

ApiReadMemData 28, 194

ApiReadRecData 27, 115, 117, 143, 164,

193

ApiSetDllDbgLevel 26, 57, 192

ApiSetTgEmul 26, 192

ApiWriteBlockMemData 28, 194

ApiWriteMemData 28, 194

ApiWriteRepData 27, 146, 147, 193


Index
