WARE

A transmitter's output channels would look similar.

Circular Buffers

The driver and receiver use circular buffers to hold the received/transmitted data. The buffer has no size limitation, except that the total amount of buffering cannot exceed the total amount of DATA MEMORY on the eTPU.

The access coherency routine uses one of the circular buffer locations as a scratch-pad, and it is effectively not available for storage.

The driver continues to transmit at its programmed rate until the buffer is empty.

The receiver continues to receive until the buffer is full. Once the buffer is full, overflowed received words are rejected. Note that a double-buffering assures that faulty words, or words causing overflow do not cause corrupted words. Instead, the overflowing or corrupted word is rejected.

Buffer Update Requirements

The size of the circular buffers are set at initialization and once set, cannot be resized. Each receiver and each transmitter must have its own buffer. The driver/receivers share the same total memory space as global variables, and the function frame. Assume that a system has 3072 bytes of DATA memory and contains 10 ARINC429 receivers. Each receiver's function frame contains 16 (32-bit) words for a total function frame usage of 10 (receivers) * 4 (bytes/word) * 16 (words/receiver) = 640 bytes of function frame. No global variables are used by the receiver function. The leftover PRAM available for the circular buffers is therefore 3072 (total available bytes) - 640 (bytes for function frames) = 2432 bytes. That means that each receiver channel's circular buffer could be 243 bytes or could contain 60 (32-bit) locations, and the access coherency limitation effectively reduces the buffer size to 59 locations. A word can arrive or be transmitted once every 360 microseconds. This means that an entire buffers worth of words can be received or transmitted in 21 milliseconds.

Parity Calculation

With the advent of version 2.0 of the drivers, the eTPU Transmitter driver code can now optionally perform parity generation. Otherwise, Transmitter parity must be generated on the portion of the driver located in the host, before writing the data into the eTPU circular buffer. Also with 2.0, the Receiver may have parity checking enabled in the eTPU.  Parity enable/disable and odd/even setting is runtime configurable and independent per channel with 2.1 and newer.  Otherwise, parity should be checked on the host side of the driver.

Fault Detection

The following receiver faults are detected:

• Buffer Overflow Fault

• Too Many Bits in Word Fault

• Line Went Idle Fault (too few bits)

• Invalid State Fault (detection of an unknown internal software fault)

• Parity Fault (version 2.0 and newer, if enabled)

All receive faults result in rejection of received word.

The following transmit fault sources are detected.

• Buffer Overflow Fault (detected in host interface)

• Invalid State Fault (detection of an unknown internal software fault)

Each fault is reported individually, affording full observability of fault source.

Compatibility with other eTPU functions

The eTPU drivers are written in C and can be compiled with the ETEC compiler. The ARINC eTPU driver functions may be combined with other eTPU functions assuming the servicing requirements are met. Note that these drivers are well behaved in that they can coexist with other drivers.

It is the user's responsibility to verify that worst case latency requirements are met for a the customer's set of eTPU functions running on channels and priority levels.

Receiver Address Filtering

Release 2.0 of the drivers provides an option for enabling message/label filtering in the eTPU.  This can greatly reduce host CPU processing if only select labels need to be received.  Through the use of a bit table, all 256 possible labels can be individually configured for acceptance or discard.  With the 2.1 release, SDI bit filtering has been added.  Filtering can be independently enabled and configured on a per RX channel basis.

If address filtering is not enabled in the Receiver eTPU driver, it can be incorporated into the host-side drivers.

Interrupts

The host interface can be programmed to interrupt on a programmable number of received or transmitted words. Alternatively, the driver can be polled. The polling rate depends on the size of the programmable circular buffer, the bit rate, and the activity rate.

DO178B/C

The delivered items can be used as certification artifacts, though you will need to do your own certification.

Testing

Simulator testing includes 100 % code coverage, 100% jump coverage, and 100% entry coverage. All features described in the User Manual have been tested.  The package includes the simulator test suite.

Guarantees

All requirements derived from the User Manual are guaranteed to be met. No other guarantees are made or implied. Specifically, determination of suitability for a particular application is the responsibility of the purchaser. If not fully satisfied, delete and return all materials within 60 days of purchase for a full refund.

Deliverables

• User Manuals

• ARINC429 Receiver and Transmitter eTPU source code files; Arinc429Receive.c and Arinc429Transmit.c that implement the ARINC429 functionality in the eTPU.

• All other files required to build a stand-alone executable. These include header files ETpuC.H, ETpuC_Common.h, ETpuC_AshWare.h (for Byte Craft builds), and files All.c and Tester.C. Note that these files follow the standard eTPU format and can be mixed and matched with Freescale and other third party eTPU code.

• ETPU C Compiler-generated header files, etpu_Arinc429Receive_auto.h and etpu_Arinc429Transmit_auto.h which describe the interface to the transmitter and receiver functions. These files are used by the host-side compiler.

• Test cases that verify that all requirements have been met and that achieve 100% instruction, jump, and entry table coverage.

• Example host-side "C" drivers (files cpu_arinc429_receive.c, cpu_arinc429_receive.h, cpu_arinc429_transmit.c, and cpu_arinc429_transmit.h) that conform to the Freescale eTPU driver API. Note that this host-side example has not been fully tested, and is provided "as-is."

• Example host-side application file arinc429_example_mpc5500.c.

• All other files required to build the host-side application with a GNU "C" compiler. This includes NXP files that describe the eTPU and MPC5xxx (files config.h, etpu_struct.h, etpu_util.c, etpu_util.h, mpc5xxx.h, mpc5xxx_vars.h, and typedefs.h) miscellaneous source files for building the GNU example (crt0.S, isrLib.c, isrLib.h, and vector.S) miscellaneous GNU build files (Mk.bat, makefile.gnu, and link_sys_sim.ld) and miscellaneous files for running the example in the ASH WARE eTPU2/CPU System Simulator Environment (files eTPUInit.ETpuCommand, RcvOneChanYesDrive.Vector, RunScript.Cpu32Command, StartupScript.Cpu32Command, and SystemTest.ETpuSysSimProject)

Consulting

With the purchase of the initial license comes 4 hours of consulting. Additional hours can be purchased at our standard hourly consulting rate.

Licensing

Various licensing options are available.  The standard model is a per-program/product license.  Purchase of a license entitles the purchaser to use the eTPU drivers on a single product. If the driver were to be used on another product, a second license would need to be purchased. ASH WARE receives no per-unit royalties.  Another option is a site, or one-time license.

A Licensing Agreement must be in place prior to delivery.

Royalties

Each license is royalty free. ASH WARE receives no per unit royalty.

Evaluation Package

Contact ASH WARE to receive an ARINC 429 evaluation package that contains everything you need to test whether this solution works for you!

​