Supported Bit Rates

Both the High Speed (100kb) and low-speed (12.5KB) are supported.

Channel Usage

Each eTPU has 32-channels, and two eTPU channels are required per transmitter. Two eTPU channels are also required per receiver. These channel pairs must occupy adjacently numbered channels as follows. The channel number (e.g. channel '4') must be paired with channel '5'. Specifically, the channel numbers can only differ by the least significant bit. For instance, channels 4 could be paired with channel 5 could be used, but channels 5 and 6 could not be paired.

Typical Configuration

A typical configuration could be 2 transmitters and 14 receivers. The transmitters would be located on channels pairs 0+1, 2+3, ... 26,27. The receivers would be located on channel pairs 28+29, 30+31. All Receivers would be set to medium priority and all transmitters would be set to high priority. This is just an example configuration as many other configurations are possible.

Hardware Interface

A device external to the microcontroller is required to perform the conversion to/from digital as shown below. A number of commercially available devices are available including Holt Integrated Circuits, Inc.'s HI 3282. It is also possible to design your own driver receiver from discrete parts (op-amps, comparators) and an example design is available upon request. An important aspect of the design is hysteresis on the receiver such that there is no glitch on the receiver. Such a glitch can cause reception errors.

Receiver Waveforms

The following is and example of a receiver waveform at the input pins of the eTPU.

eTPU Memory Usage

Each receiver requires 64 bytes (60-used, 4 spare) of function frame data. This does not include circular buffer space or label filter table space.  Each unique label filter table requries 32 bytes of data space.

Each transmitter requires 64 bytes (52-used, 12 spare) of function frame data. This does not include circular buffer space.

Each transmitter and each receiver needs its own circular buffer.

The used code space is 604 bytes total for the receiver and 704 bytes total for the transmitter which includes both code and event vector (entry) tables. No spare space is inlcuding in these code space requirement numbers.?

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

Receiver Worst Case Thread Length

The receiver's worst case thread length is 22 instructions not including data access collisions and 6-system clock time slot transition time. Under normal operation of High-Speed, this would occur once every 10 micro-seconds. See below.

Receiver Latency Requirement

The system must be designed such that the receiver function is serviced once every 10 microseconds. In other words, the net latency imposed by a combination of all functions, on all channels, worst case latencies, priorities, and thread activation rates must be such that the receiver is serviced at this worst case rate.

The system must be designed that the transmit function is serviced twice every 10 microseconds.?

Transmitter Worst Case Thread Length

The Transmitter's worst case thread length is 18 instructions not including data access collisions and 6-system clock time slot transition time. This worst case thread will only occur once every 10 Microseconds. A second worst case situation is that there can be two sequential threads every 10 microseconds. These sequential threads are the slave's threads "DataBits31_24" and the slave's "GenerateTrailingEdges" which are 18 instructions, and 7 instructions, respectively.

Transmitter Latency Requirement

The system must be designed such that the transmitter function is executed twice every 10 micro-seconds. Specifically, the "DataBits31_24" and the slave's "GenerateTrailingEdges" threads need to be serviced this often.

Compatibility with other eTPU functions

The eTPU drivers are written in C and can be compiled with the ETEC compiler (best performance) or the Byte Craft Limited 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.

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

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

Testing

Testing includes 100 % code coverage, 100% jump coverage, and 100% entry coverage. All features described in the User Manual have been tested.

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 Manual
• 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 acheive 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 Freescale files that describe the eTPU and MPC5554 (files config.h, etpu_struct.h, etpu_util.c, etpu_util.h, mpc5554.h, mpc5554_vars.h, and typedefs.h) miscellanous source files for building the GNU example (crt0.S, isrLib.c, isrLib.h, and vector.S) miscelaneous 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 are billed at an hourly rate of $180 USD.

Licensing

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

A Licensing Agreement must be in place prior to delivery.

Royalties

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