The CM5 provides a combined function alternative which mitigates SWaP-C system integration and configuration challenges. The CM5 function essentially combines two of NAI’s popular functions on a single-slot function module:

MIL-STD-1553 Communications Interface : The CM5 smart function provides a MIL-STD-1553 interface Bus Controller (BC), Remote Terminal (RT) or Bus Monitor (BM) function (programmable per channel). The IP/Core MIL-STD-1553 firmware supports NAI software/API Assisted Mode Capability (AMC).

ARINC 429/575 Communications Interface : The CM5 smart function provides a fully programmable ARINC 429/575 communications interface. ARINC 429 (and legacy ARINC 575) is a data transfer standard for aircraft avionics. It uses a self-clocking, self-synchronizing data bus protocol. The physical connection wires are twisted pairs carrying balanced differential signaling. Data words are 32 bits in length and most messages consist of a single data word. Messages are transmitted at either 12.5 or 100 kbps to other system elements that monitor the bus messages. The transmitter constantly transmits either 32-bit data words or the NULL state. A single-wire pair is limited to one transmitter and no more than 20 receivers. The protocol allows for self-clocking at the receiver end, thus eliminating the need to transmit clocking data.

•Independent (dual-redundant) MIL-STD-1553 interface channel: Bus Controller (BC), Remote Terminal (RT), and Bus Monitor (BM) or RT/BM combined mode operation •64KB onboard memory per channel •IP-core register-compatible with DDC™ family of devices •Ability to set message retry policy •Message scheduling capability •Asynchronous message capability •Message FIFO capability

MIL-STD-1553

ARINC 429/575

General

abc

NAI’s Custom-On-Standard Architecture™ (COSA®) offers a choice of over 40 Intelligent I/O, communications, or Ethernet switch functions, providing the highest packaging density and greatest flexibility of any 3U SBC in the industry. Preexisting, fully-tested functions can be combined in an unlimited number of ways quickly and easily.

The 75PPC1 includes BSP and SDK support for Wind River® VxWorks®. In addition, software support kits are supplied, with source code and board-specific library I/O APIs, to facilitate system integration. Each I/O function has dedicated processing, unburdening the SBC from unnecessary data management overhead.

BIT continuously monitors the status of all I/O during normal operations and is totally transparent to the user. SBC resources are not consumed while executing BIT routines. This simplifies maintenance, assures operational readiness, reduces life-cycle costs and— keeps your systems mission ready.

Eliminate man-months of integration with a configured, field-proven system from NAI. Specification to deployment is a seamless experience as all design, state-of-the-art manufacturing, assembly and test are performed— by one trusted source. All facilities are in the U.S. and optimized for high-mix/low volume production runs and extended lifecycle support.

From design-in to production, and beyond, NAI’s product lifecycle management strategy ensures the long-term availability of COTS products through configuration management, technology refresh, and obsolescence component purchase and storage.

As a leading manufacturer of smart function modules, NAI offers over 100 different modules that cover a wide range of I/O, measurement and simulation, communications, Ethernet switch, and SBC functions. Our CM5 combination module offers users the functionality of two COSA® smart function modules in one physical module. Based on NAI’s FTB (MIL-STD-1553B) and AR1 modules, the CM5 provides two MIL-STD- 1553B, Notice 2 compliant interface channels, and eight channels of ARINC 429/575 I/O that are programmable for either Rx or Tx per channel. This user manual is designed to help you get the most out of our CM5 smart function module.

NAI’s CM5 module offers a wide range of features designed to suit a variety of system requirements, including: MIL-STD-1553B (FTB Module-Type) Features

The FTB function provides two dual-redundant MIL-STD-1553B interface channels. Each channel can be configured to act as a Bus Controller (BC), Remote Terminal (RT), Bus Monitor (BM), or RT/BM combined mode. This flexibility allows for versatile operation and redundancy in critical systems.

The FTB function utilizes a built-in secondary (ARM) processor dedicated to ‘assisting' the movement of 1553 messages from the 1553 device to host interface, minimizing host CPU activity (reads & writes to device), reducing application memory required on the host, and improving data transfer time between 1553 device and host interface while also reducing data transfer delays.

With a substantial 64K words of on-board memory per channel, this function offers ample storage capacity for data and messages, facilitating efficient data handling and processing.

Users familiar with the DDC™ family of devices will appreciate that the function’s IP-core registers are compatible with these devices. This compatibility ensures seamless integration into existing systems and reduces the learning curve for engineers already familiar with DDC™ products.

The FTB function provides the ability to configure and set a message retry policy, proving invaluable in ensuring data integrity and system reliability, particularly in environments where communication errors may occur.

This feature allows precise timing and coordination of messages, making it ideal for applications that require synchronized data exchange.

The FTB function supports asynchronous messaging, which is crucial for real-time systems where data needs to be transmitted and received without fixed time intervals. This feature ensures efficient communication in dynamic environments.

The inclusion of a message FIFO (First-In-First-Out) capability enhances data management and flow control. Users can optimize data handling and prioritize messages as needed, contributing to system efficiency.

The AR1 function supports the following ARINC communications:

ARINC 429 is a widely adopted data transfer standard, serving as an alternative to MIL-STD-1553. It utilizes a self-clocking, selfsynchronizing data bus protocol with separate transmit and receive ports. The physical connection consists of twisted pairs carrying balanced differential signaling. Each data word is 32 bits in length, with most messages containing a single data word. Messages are transmitted at either 12.5 or 100 kbps, allowing other system elements to monitor the bus messages. The transmitter continuously transmits 32-bit data words or the NULL state. A single-wire pair can accommodate one transmitter and up to 20 receivers. Notably, the receiver end of the protocol enables self-clocking, eliminating the need for transmitting clocking data.

In addition to ARINC 429, the AR1 function also supports ARINC 575, a data transfer protocol specifically used for the Digital Air Data System (DADS) on commercial and transport aircraft. ARINC 575 defines a digital data bus that distributes crucial air-data information to displays, autopilots, and flight control instrumentation.

While there are minor differences between the digital data bus of ARINC 575 and ARINC 429, the most significant distinction lies in the usage of bit 32. In ARINC 429, bit 32 is reserved for parity, whereas ARINC 575 can utilize bit 32 for either parity (when using BNR encoding) or data (when using BCD encoding).

Each channel of the AR1 function can be programmed to operate in either receive or transmit mode according to your specific application needs.

The AR1 function supports both 100 kHz and 12.5 kHz operation per channel, allowing you to choose the appropriate speed for your communication requirements.

Enjoy the convenience of a 255 message FIFO or scheduled transmits per channel, allowing you to efficiently manage and control the transmission of messages. Additionally, asynchronous transmits can be performed alongside scheduled transmits.

Benefit from a 255 message FIFO or mailbox buffering per channel, providing ample storage for incoming messages. This ensures reliable reception and efficient handling of data.

The AR1 function supports SDI/Label Filtering, enabling you to validate received messages based on specific criteria per channel. This feature enhances the overall data integrity and ensures only relevant information is processed.

You have the option to enable selectable hardware parity generation/checking, which adds an extra layer of data integrity verification during transmission and reception.

Gain valuable insight into message reception with the functions’s receive time stamping feature. This allows precise timing analysis and synchronization in your communication system.

The AR1 function incorporates continuous BIT functionality, providing self-diagnostics and monitoring capabilities to ensure reliable operation and easy troubleshooting.

Verify the integrity of the AR1 function by performing loop-back tests. This feature allows you to validate the communication path and confirm proper functionality.

The AR1 function’s outputs support tri-state functionality, allowing you to control the state of the outputs as needed. This enables seamless integration with other system components.

The AR1 function offers both high and low-speed slew rate outputs, providing flexibility in meeting the requirements of various communication interfaces.

The MIL-STD-1553B communications function is similar to the standard FTB communications function module (FTB may be used as a reference/guide within the context of this document)

The CM5 provides (2) channels of dual-redundant MIL-STD-1553B communication buses (FTB module-type). MIL-STD-1553 is a military standard that defines the characteristic for a Digital Time Division Command/Response Multiplexed Data Bus. The 1553 data bus is a dualredundant, bi-directional, Manchester II encoded data bus with a high bit error reliability. It is used commonly for both military and civilian applications in avionics, aircraft and spacecraft data handling.

Table 1 provides a summary of the MIL-STD-1553 characteristics.

|Terminal Types| |Bus Controller Remote Terminal Bus Monitor| |Number of Remote Terminals| |Maximum of 31| |Transmission Technique| |Half-duplex| |Operation| |Asynchronous| |Encoding| |Manchester II bi-phase leve| |Fault Tolerance| |Typically, Dual Redundant Bus, which means there are two independent bus networks (one bus is called the Primary or “A” bus and the other is the Secondary or “B” bus. 1553 messages are usually only transmitted on either the A or B bus network at a time, but it does not usually matter which bus is used for the message transfer – devices on the 1553 network are supposed to handle messages on either the A or B bus with equal priority.| |Coupling| |Transformer or direct| |Data Rate| |1 MHz| |Word Length| |20 bits| |Data Bits/Word| |16 bits| |Message Length| |Maximum of 32 Data Words| |Protocol| |Command/response| |Message Formats| |Bus Controller to Remote Terminal (BC-RT message) Remote Terminal to Bus Controller (RT-BC message) Remote Terminal to Remote Terminal (RT-RT message) Broadcast System control (Tx and Rx Mode codes)|

The MIL-STD-1553 Data Bus is defined as a twisted shielded pair transmission line consisting of the main bus and a number of stubs. There is one stub for each remote terminal connected to the bus. The main bus is terminated at each end with a resistance equal to the cable’s characteristic impedance (± 2%). This termination makes the data bus behave electrically like an infinite transmission line. Stubs, which are added to the main bus to connect the terminals, provide “local” loads and produce impedance mismatch where added. This mismatch, if not properly controlled, produces electrical reflections and degrades the performance of the main bus. Table 2 provides a summary of the MIL-STD-1553 Transmission Media characteristics.

|Cable Type| |Twisted Shielded Pair| |Capacitance| |30.0 pF/ft max, wire to wire| |Characteristic Impedance| |70.0 to 85.0 ohms at 1 MHz| |Cable Attenuation| |1.5 dB/100 ft. max, at 1 MHz| |Cable Twists| |4 Twists per ft., minimum| |Shield Coverage| |90% minimum| |Cable Termination| |Cable impedance (± 2%)| |Direct Coupled Stub Length| |Maximum of 1 foot| |XFMR Coupled Stub Length| |Maximum of 20 feet|

Each 1553 channel on the FTA-FTF module employs a Sital Technology BRM1553D core, which is based on Sital’s proven 1553 IP cores, with DDC® Enhanced Mini-Ace® compatible interface. The core may operate in Bus Controller (BC), Remote Terminal (RT), Bus Monitor (BM) or RT/BM combined mode.

The Bus Controller (BC) provides data flow control for all transmissions 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, unless the message is BC→broadcast receive message, in which case, there will be no RT response.

The Remote Terminal (RT) is a device designed to interface various subsystems with the 1553 data bus. 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.). RT characteristics include: •Up to 31 Remote Terminals can be connected to the data bus •Each Remote Terminal can have 31 Sub addresses, where SA 0 and SA 31 signify a Mode code message. In which case the data word count would be the Mode Code number. •No Remote Terminal shall speak unless spoken to first by the Bus Controller and specifically commanded to transmit.

The Bus Monitor (BM) listens to all messages on the data 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.

MIL-STD-1553 data bus system consists of a Bus Controller (BC) controlling multiple Remote Terminals (RT) all connected by a data bus providing a single data path between the Bus Controller and all the associated Remote Terminals. There may also be one or more Bus Monitors (BM); however, Bus Monitors are specifically not allowed to take part in data transfers and are only used to capture or record data for analysis.

The following transactions are allowed between the BC and a specific RT:

1.BC to RT Transfer The Bus Controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words. The selected Remote Terminal then sends a single 16-bit Status word 2.RT to BC Transfer The Bus Controller sends one transmit command word to a Remote Terminal. The Remote Terminal then sends a single Status word, immediately followed by 1 to 32 data words. 3.Mode Command Without Data Word (Transmit) The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word 4.Mode Command with Data Word (Transmit) The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word immediately followed by a single Data word 5.Mode Command with Data Word (Receive) The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command immediately followed by a single data word. The Remote Terminal responds with a Status word

The following transaction is allowed between the BC and a pair of RTs: 1.RT to RT Transfers The Bus Controller sends out one receive command word immediately followed by one transmit command word. The transmitting Remote Terminal sends a Status word to the BC, immediately followed by 1 to 32 data words to the receiving RT. The receiving Terminal then sends its Status word to the BC.

The following are broadcast transactions that are allowed between the BC and all capable RTs: 1.BC to RT(s) Transfers The Bus Controller sends one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by 0 to 32 data words. All Remote Terminals will accept the data but will not respond back to the BC

2.RT to RT(s) Transfers The Bus Controller sends out one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by one transmit command. The transmitting Remote Terminal sends a Status word immediately followed by 1 to 32 data words to all other RT(s). All Remote Terminals will accept the data but will not respond back to the BC.

3.Mode Code without Data Word (Broadcast) The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command. No Remote Terminals will respond back to the BC.

4.Mode Code with Data Word (Broadcast) The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command, immediately followed by one Data word, if it is an Rx Mode code. No Remote Terminals will respond.

The following are three components that make up the 1553 messages: •Command Word •Data Word •Status Word Each word type is 20 bits in length. The first 3 bits are used as a synchronization field, thereby allowing the decode clock to re-sync at the beginning of each new word. The next 16 bits are the information field. The last bit is the parity bit. Parity is based on odd parity for the single word.

The Command Word specifies the function that the Remote Terminal is to perform.

The RT Address field states which unique remote terminal the command is intended for (no two terminals may have the same address). Note the address of 0x00 (00000b) is a valid address, and the address 0x1F (11111b) is always reserved as a broadcast address. The maximum number of terminals the data bus can support is 31.

The Transmit/Receive bit defines the direction of information flow and is always from the point of view of the Remote Terminal. A transmit command (logic 1) indicates that the Remote Terminal is to transmit data, while a receive command (logic 0) indicates that the Remote Terminal is going to receive data

The Sub-Address/Mode Code and Word Count/Mode Code fields are defined as follows:

|Sub-Address/Mode Command Field| |Word Count/Mode Code Field| |0x00 (00000b) or 0x1F (11111b) indicates Mode Code Command| |Mode Code number to be performed| |0x01 (00001b) to 0x1E (11110b) indicates the Sub-Address 1 to Sub-Address 30| |Word Count – note 0x00 (00000b) is decoded as 32 data words|

The Data Word contains the actual information that is being transferred within a message. Data Words can be transmitted by either a Remote Terminal (Transmit command) or a Bus Controller (Receive command).

When the Remote Terminal receives a message, it will respond with a Status Word. The Status Word is used to convey to the Bus Controller whether a message was properly received or to convey the state of the Remote Terminal (i.e., service request, busy, etc.).

The RT Address in the Status Word should match the RT Address within the Command Word that the Remote Terminal received. With a RT-RT Transfer message, the RT address within either Status Word received (Rx or Tx), should match the RT address within the corresponding Command word sent (Rx or Tx).

|Status Bit| |Description| |Message Error (Bit 9)| |This bit is set by the Remote Terminal upon detection of an error in the message or upon detection of an invalid message (i.e. Illegal Command). The error may occur in any of the Data Words within the message. When the terminal detects an error and sets this bit, none of the data received within the message is used.| |Instrumentation (Bit 10)| |This bit is always set to logic “0”.| |Service Request (Bit 11)| |This bit is set to a logic “1” by the subsystem if servicing is needed. This bit is typically used when the Bus Controller is “polling” terminals to determine if they require processing.| |Broadcast Command Received (Bit 15)| |This bit indicates that the Remote Terminal received a valid broadcast command. On receiving a valid broadcast command, the Remote Terminal sets this bit to logic “1” and suppresses the transmission of its Status Word. The Bus Controller may issue a Transmit Status Word or Transmit Last Command Word Mode Code to determine if the Remote Terminal received the message properly.| |Busy (Bit 16)| |This bit indicates to the Bus Controller that the Remote Terminal is unable to move data between the Remote Terminal and the Sub-system in compliance to a command from the Bus Controller. In the earlier days of 1553, the Busy bit was required because many subsystem interfaces (analog, synchros, etc.) were much slower compared to the speed of the multiplex data bus. So instead of losing data, a terminal was able to set the Busy bit indicating to the Bus Controller to try again later. As new systems have been developed, the need for the busy bit has been reduced.| |Subsystem Flag (Bit 17)| |This bit provides “health” data regarding the subsystems to which the Remote Terminal is connected. Multiple subsystems may logically “OR” their bits together to form a composite health indicator.| |Dynamic Bus Control Acceptance Bit (Bit 19)| |This bit informs the Bus Controller that the Remote Terminal has received the Dynamic Bus Control Mode Code and has accepted control of the bus. The Remote Terminal, on transmitting its status word, becomes the Bus Controller. The Bus Controller, on receiving the status word from the Remote Terminal with this bit set, ceases to function as the Bus Controller and may become a Remote Terminal or Bus Monitor.| |Terminal Flag (Bit 20)| |This bit informs the Bus Controller of a fault or failure within the Remote Terminal. A logic “1” indicates a fault condition.|

External discrete signals are available to support “hardwired” RT Address and configuration as well as start-up modes for MIL-STD-1760A.

The 1553 modules are completely software RT Address programmable and configurable. Notice 2 of the MIL-STD-1553 standard requires that the Remote Terminal address be wire-programmable from an external I/O connector, and the Remote Terminal perform an odd parity test upon on the wired terminal address. An open circuit on an address line is detected as a logic “1” and connecting the address line to ground is detected as a logic “0”. The 1553 modules provided the ability to externally set the RT Address and Parity via discrete signals (CHx-RT-ADDR (0-4) and CHxPARITY). These discrete signals are considered additional and optional based on specific application requirements. The discrete signals are single-ended and System-GND referenced.

Because of the platform (module-thru-board) available physical pin limitations, only one set of discrete signals are provided for a channel (CH) pair (channel pair 1 = CH1, CH2 and channel pair 2 = CH3, CH4). The discrete pins are provided for the odd-numbered channel, which will use these signals directly. The even channel of the channel pair will use these same pins, but the RT addressing for the even channel will be set as a “hard +1” offset from the odd-channel discrete pattern.

For example: If the CH1 external pins are either grounded or left open to yield: CH1-RT-ADDR0-4 pins + Parity pin = 01101 + 0 =0xD (13d)

|DISCRETE SIGNAL PIN| |DESCRIPTION| |CHx-RT-ADDR0 thru CHx-RT-ADDR4| |Five (5) External RT address signal pins, binary bit-weighted (ADDR0=LSB); for applying a “hardwire” RT address (special applications only)| |CHx-PARIT| |Used in conjunction with external RT address signal pins. A single bit that complements the parity of CHx-RT-ADDR wire to odd parity. If the wrong parity is detected by core, only Broadcast commands would be valid for the core. If not masked, an interrupt will be generated in the event of wrong parity.|

In addition to supporting external RT Addressing, the 1553 modules provide discrete signals (CHx-STANDARD and CHx-MODE0) to support MILSTD-1760 auto start-up modes.

|DISCRETE SIGNAL PIN| |DESCRIPTION| |CHx-STANDARD| |‘1' – Support for MIL-STD-1760. Will power up as RT with Busy bit set. ‘0' – Powers up as inactive BC or Idle.| |CHx-MODE0| |‘1' – Support for MIL-STD-1760. Will power up as RT with Busy bit set. ‘0' – Powers up as inactive BC or Idle.|

The FTA-FTF 1553 modules have been improved to include the “Assisted Mode (AM)” feature. In the legacy FT1-FT6 modules, the 1553 messages are fetched from the 1553 device by accessing device registers directly from the host application as shown in Figure 1. The dotted lines indicate read/write access over the bus interface. The bus interface in some cases may be relatively “slow” (ex. Ethernet interface). In this design, four bus accesses are required from the host to fetch one new 1553 message. The number of accesses increases proportionately with the number of 1553 messages to fetch from the 1553 device.

The FTA-FTF 1553 modules utilize the secondary (ARM) processor built into the module that is dedicated for the purpose of “assisting” the movement of 1553 messages from the 1553 device to the host interface. This is made possible through a system of FIFOs that carry command and response messages to and from the host CPU to a bare metal application running on the secondary processor (refer to Diagram B in Figure 2). In addition, these modules have the option of funneling all 1553 messages (per channel) to a 4k byte Message FIFO (refer to Diagram A in Figure 2) that is accessible from the host.

In Figure 2, the dotted lines indicate slower bus read/write accesses (PCI, Ethernet) whereas the solid lines indicate fast bus accesses. When the Message FIFO is utilized (Diagram A), the Message FIFO is filled as new 1553 messages arrive. Moving the 1553 messages from the Message FIFO to the Host Processor requires 2 “slower” bus accesses to fetch all the new 1553 messages that are in the Message FIFO.

If the Message FIFO is not utilized (Diagram B only), for example to fully support DDC API compatibility, 2 writes and at least 2 reads via the “slower” bus is required to fetch one new 1553 message. The write access to the Command FIFO initiates the transfer of 1553 messages from the device to the Response FIFO and when the transfer is complete, the host can read the Response FIFO. In DDC API compatibility mode, the benefits of the “assisted” design provide significantly improved response times compared to the legacy FT module(s), especially with bulk 1553 transfers.

Figure 3 and Table 3 depict the latent time (time required for 1553 message(s) transfer from 1553 device to host memory when initiated by the host CPU) as a function of the number of 1553 messages being transferred. The three candidates for comparison are (1) Assisted Module running in Message FIFO Mode, (2) Assisted Module running in Standard Mode and (3) the Non-Assisted (Legacy) FT Module.

The benefits of this approach include: 1. Reduced number of host CPU reads and writes to the device. 2. Reduced host memory footprint (less application memory required on the host). 3. Lower latency from 1553 bus to host memory.

The FTB function of the combination module provide registers that indicate faults or events. Refer to “Status and Interrupts Module Manual” for the Principle of Operation description.

The FTB function of the combination module includes module common registers that provide access to module-level bare metal/FPGA revisions and compile times, unique serial number information, and temperature/voltage/current monitoring. Refer to “Module Common Registers Module Manual” for detailed information.

The Assisted Mode registers are comprised of registers that support the AM Command and AM 1553 Message FIFOs.

The registers associated with the AM Commands are divided into the following:

The Message FIFO Management registers consists of the FIFO Buffer, FIFO Count, FIFO Clear command, and the FIFO Threshold which specify threshold associated with for the “1553 Message FIFO Almost Full” status bits in the Channel Status register.

Refer to “Module Common Registers Module Manual” for the register descriptions.

The registers listed are associated with data that is received on the AR1 channels. Two modes of message storage are supported: Receive FIFO and Receive Mailbox

The Receive FIFO Mode Registers contain information about ARINC messages that are received via the Receive FIFO buffer on the AR1 channel. The registers associated with this feature are:

The Receive Mailbox Mode Registers contain information about ARINC messages that are received via mailboxes on the AR1 channel. The registers associated with this feature are: - Receive FIFO SDI/Label Buffer - Receive FIFO SDI/Label Count - Receive FIFO Almost Full Threshold - Receive FIFO Size - Mailbox Status Data - Mailbox Message Data - Mailbox Timestamp Data

If message validation (filtering) is enabled, the module compares the SDI/Label of incoming ARINC messages to a list of desired SDI/Labels in validation (match) memory and only stores messages with an SDI/Label in the list.

The registers listed are associated with data that is to be transmitted from the AR1 channels. Two modes of message storage are supported: Transmit FIFO and Transmit Scheduling.

The Transmit FIFO Mode Registers contain information about ARINC messages that are to be transmitted via the Transmit FIFO buffer on the AR1 channel. The registers associated with this feature are: - Transmit FIFO Message Buffer - Transmit FIFO Message Count - Transmit FIFO Almost Empty Threshold - Transmit FIFO Rate

The Transmit Scheduling Registers are utilized when the channel is set up to run a Transmit Schedule. The memories/registers associated with this feature are: - Transmit Schedule RAM - Transmit Message RAM - Async Transmit Data Register

Control of the transmission of ARINC messages includes the ability to start/resume, pause and stop the transmission of the message.

The AR1 control registers provide the ability to reset all the channels in the AR1 module and configuring and controlling individual AR1 channels.

The AR1 module provides the ability to run an initiated test (IBIT). Writing a 1 to the bit associated with the channel in the Test Enabled register.

The Background BIT Threshold register provides the ability to specify the minimum time before the BIT fault is reported in the BIT Status registers. The Reset BIT register provides the ability to reset the BIT counter used in CBIT.

Refer to “Module Common Registers Module Manual” for the register descriptions.

The AR1 Module provides status registers for BIT and Channel.

There are four registers associated with the Channel Status: Dynamic, Latched, Interrupt Enable, and Set Edge/Level Interrupt. Use this register to read current or real-time status. The Built-In-Test Error bit is latched and will stay set once an error is detected. It can be cleared by reading the BIT Status register. The Schedule Interrupt bit can be cleared by reading the Interrupt Status register when enabled or it can be cleared via the Channel Control register. See specific registers for function description and programming. The Rx Data Available bit is set when the receive FIFO is not empty. The Rx FIFO Overflow bit will set whenever the receiver must discard data because the receive FIFO was full and new data was received. The Async Data Available bit in Channel Status also gets cleared by a Stop Cmd in a schedule or if a Transmit Stop command is issued from the Transmit Stop register. The Tx Run bit is set whenever the transmitter is executing a schedule or actively transmitting the contents of the transmit FIFO. The Tx Pause bit is set whenever the transmitter has been paused in schedule mode. Some events are NOT latched. They are dynamic.

Key: ==Bold Italic = Configuration/Control

*When an event is detected, the bit associated with the event is set in this register and will remain set until the user clears the event bit. Clearing the bit requires writing a 1 back to the specific bit that was set when read (i.e., write-1-to-clear, writing a “1” to a bit set to “1” will set the bit to “0).

Refer to “Module Common Registers Module Manual” for the Module Common Registers Function Register Map.

BIT Status

Summary Status

Channel Status