Both the High Speed (100kb) and low-speed (12.5KB) are supported.
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.
A typical configuration could be 2 transmitters and 14 receivers. The receivers would be located on channels pairs 0+1, 2+3, ... 26,27. The transmitters 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.
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-8591 (RX) and HI-8596 (TX). It is also possible to design your own driver receiver from discrete parts (op-amps, comparators). 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.
The following is and example of a receiver waveform at the input pins of the eTPU.
A transmitter's output channels would look similar.
Each receiver requires 64 bytes (60-used, 4 spare) of chanel 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 channel frame data. This does not include circular buffer space.
Each transmitter and each receiver needs its own circular buffer.
The used code space is 648 bytes total for the receiver and 668 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.
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.
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.
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.
The following receiver faults are detected:
All receive faults result in rejection of received word.
The following transmit fault sources are detected.
Each fault is reported individually, affording full observability of fault source.
The eTPU drivers are written in C and can be compiled with the ETEC compiler (best performance) or the Byte Craft Ltd. 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.
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.
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.
The delivered items can be used as certification artifacts, though you will need to do your own certification.
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.
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.
With the purchase of the initial license comes 4 hours of consulting. Additional hours can be purchased at our standard hourly consulting rate.
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.
Each license is royalty free. ASH WARE receives no per unit royalty.
Contact ASH WARE to receive an ARINC 429 evaluation package that contains everything you need to test whether this solution works for you!