TE Module Guide

TTEthernet Family Guide

Overview

The TE family is NAI’s line of deterministic Ethernet modules, built on TTTech’s certifiable TTEthernet® End System. The defining idea of TTEthernet is that one physical Ethernet interface carries three traffic classes at the same time:

• IEEE 802.3 — ordinary best-effort Ethernet. Ubiquitous and flexible, but with no delivery or ordering guarantee.
• ARINC 664 Part 7 (AFDX®) — rate-constrained, asynchronous traffic on profiled virtual links, delivered with bounded latency and jitter (millisecond precision) when policed by a compliant switch.
• SAE AS6802 (Time-Triggered Ethernet, TTE) — time-triggered, synchronous traffic scheduled to fire at precise instants on a network-wide clock (microsecond precision), with the highest priority on the wire.

Because all three share the same module, a program already running standard 802.3 can adopt AFDX or AS6802 determinism later without changing hardware. Every TE module is tri-redundant — the interface runs over three independent network planes — which is what makes it suitable for safety- and mission-critical avionics (the End System is DO-178/DO-254 certifiable).

This is NAI’s Ethernet / deterministic-networking member among the communication families. Unlike the bus-oriented families, a TTEthernet network is switched — traffic is policed and (for AS6802) scheduled by a TTE/AFDX switch, not arbitrated on a shared bus. (NAI’s other communication / data-bus families: the FT family for MIL-STD-1553/1760, the AR family for ARINC 429/575, the CB family for CANbus, and the SC family for freeform serial (RS-232/422/485).)

Important

The TE2 is not a typical NAI smart function module. It has no naibrd_* register API, no SSK sample apps, and no ESP2 panel. It is configured offline with TTTech’s TTE-Plan / TTE-Build tools and driven at runtime through TTTech’s tte_es_* End System API over the PCIe driver. The rest of this guide is written around that model — see Software.

TE modules at a glance

The family currently has one member, the TE2 (more may follow). Every TE module is a single-channel, tri-redundant TTEthernet End System:

	TE2
Function	Tri-redundant deterministic Ethernet (TTEthernet)
Traffic classes	IEEE 802.3, ARINC 664 P7 (AFDX®), SAE AS6802 (TTE) — concurrent
Channel / ports	1 logical channel over 3 redundant Ethernet planes
Line rate	10 / 100 / 1000BASE-T
Host interface	PCIe Gen II (5.0 Gbps) endpoint
Core	TTTech TTEthernet End System IP (Zynq UltraScale+), DO-178/DO-254 certifiable

Platform support is constrained — unlike the naibrd families (which run identically across every OS), TTEthernet support is tied to specific SBC + RTOS combinations:

• 67PPC2 & 68PPC2 (PowerPC T2080) with Wind River® VxWorks® 653 3.x or DDC-I Deos™
• 68G5P for 3rd-party SBC boards — contact factory for support

If your target isn’t on that list, treat it as a factory conversation before designing it in.

The three traffic classes — how they relate

TTEthernet’s whole point is that these three classes coexist on the same wire, each serving a different need; this is not a “pick one” decision. They differ mainly in who controls timing and what guarantees you get:

	IEEE 802.3	ARINC 664 P7 (AFDX®)	SAE AS6802 (TTE)
Timing model	Best-effort, unscheduled	Asynchronous, rate-constrained	Synchronous, time-triggered
Determinism	None (no delivery/order guarantee)	Bounded latency & jitter	Precisely scheduled on a global clock
Jitter	Unbounded	up to ~2 ms	~1 µs
Typical latency	Unbounded	1–10 ms	< 12.5 µs / switch
Unit of traffic	Standard Ethernet frames	Virtual Links (VLs) with policed bandwidth	Scheduled frames on a TT clock
What polices it	Nothing	AFDX/TTE switch enforces each VL’s profile	TTE switch enforces the schedule + sync
Use it for	Maintenance, logging, non-critical data	Bounded-latency critical data without global sync	Hard-real-time, tightly synchronized data

The short version: 802.3 is the familiar baseline, AFDX adds bounded delivery without a shared clock, and AS6802 adds a scheduled delivery on a network-wide clock. A single TE2 can carry all three at once — which is why it’s positioned as an upgrade path: start on 802.3, layer in AFDX or AS6802 determinism as the program needs it, on the same module. Both deterministic classes depend on a policing switch to enforce their guarantees (see Physical setup).

Physical setup

A TE2 presents one logical TTEthernet channel carried over three redundant Ethernet planes — that’s what “single-port, tri-redundant” means. The same traffic is sent on all three planes; redundancy is resolved (and deterministic traffic is policed) at the switch, not on the module. On the connector the three planes appear as ETH1, ETH2, and ETH3, each a full 1000BASE-T link with four twisted pairs (TP0–TP3, +/−) — see the pin map in the TE2 Manual (Appendix B: Pin-Out Details).

Two things drive the wiring:

• A TTEthernet/AFDX switch is required for the deterministic classes. AFDX bounds latency/jitter and AS6802 schedules frames because a policing switch enforces each virtual link’s profile and the network schedule. The module is an End System (an endpoint), not a switch — plain 802.3 will run point-to-point, but AFDX and AS6802 guarantees only exist through a compliant switch. Full redundancy means three independent network planes (three switches / switch ports), one per ETH plane.
• The ports come out through DATAIO. As with any NAI module, the channel’s signals appear at the motherboard breakout as generic DATIO# pins; the TE2 Manual pinout maps each DATIO# to a specific TTE-ETHn-TPx± line for the 44- and 50-pin I/O connectors. The exact pins depend on your slot, so confirm them against your motherboard’s operational manual.

The wiring pattern, then, is:

1. Identify the TE2’s slot on your NAI motherboard or system.
2. Bring the channel’s signals out through the breakout board, where the slot’s pins appear as DATIO# numbers.
3. Map DATIO# pins to ETH1 / ETH2 / ETH3 (TP0–TP3 pairs) using the TE2 Manual pinout or the module’s overlay card.
4. Cable each plane to its TTEthernet/AFDX switch (all three for full tri-redundancy), with the network designed and policed per your TTE-Plan configuration (Software).

Software

This is where TE2 departs hardest from the rest of the catalog. There is no naibrd_* open/init/free lifecycle, no SSK 1.x/2.x split, no sample apps, and no ESP2 panel. A TTEthernet End System is configured, not register-poked, and the configuration is designed off the target before your application ever runs. The flow has three stages:

1. Design the network offline — TTE-Plan / TTE-Build. Using TTTech’s tools you describe the network: the virtual links, their bandwidth/rate profiles (AFDX), and the time-triggered schedule (AS6802), across every End System and switch. TTE-Build compiles that design into a configuration image. The module’s network parameters (FPGA revision, IP core version, frame memory size — entered in bytes, device target) are part of this step; see the Network Description in the TE2 Manual.
2. Load the configuration onto the End System. The compiled config is loaded to the module (as IP/firmware configuration). Once initialized and configured, traffic for each class is routed automatically per its protocol — your application doesn’t schedule frames by hand; it reads and writes the ports the configuration defined.
3. Run your application against the tte_es_* API. With the End System configured, your code opens the input/output ports from the config and moves data through them. These calls are TTTech’s End System API, supplied with the TTTech stack — not part of NAI’s SSK. The Features section below lists them in full.

On the PCIe side the module exposes two BARs, which matters when you bring a board up:

• BAR0 — used by the TTTech / DDC-I driver (the End System stack).
• BAR1 — the NAI interface: a small set of registers for board-level checks (Test Register, FPGA Revision, FPGA Timestamp). These are the only directly accessible registers, and they’re for verification, not operation — see Confirm communication.

Where to find what you need:

• The TTEthernet stack, TTE-Plan/TTE-Build, and the tte_es_* API come from TTTech with the certifiable End System product. NAI supports the TE2 on VxWorks 653 3.x and DDC-I Deos (67PPC2/68PPC2), and on the 68G5P for 3rd-party SBCs — contact factory for the driver, tooling, and integration package for your platform.
• Bringing your board up — power, network, terminal, and file transfer — is covered in Connecting to Boards.
• The board-level interface and pinout for the TE2 itself is in the TE2 Manual.

Confirm communication

TTEthernet has no two-channel loopback self-test like the bus families — proving an End System means confirming it in stages, from “the host sees the card” up to “the End System is configured and synchronized to the network”:

1. The card enumerates on PCIe. The TE2 is a PCIe endpoint, class NET_CNTLR, vendor ID 0x1c7e, device ID 0x012a, with two memory BARs (BAR0 for the TTTech/DDC-I driver, BAR1 for the NAI interface). On VxWorks the PCI header dump (see the TE2 Manual enumeration example) shows it; if the card doesn’t enumerate, nothing else will work.
2. The NAI interface responds (BAR1). Read/write the Test Register at BAR1 offset 0x04 — a R/W scratch register whose only job is to confirm the module is reachable over PCIe. Then read the read-only FPGA Revision (0x08) and FPGA Timestamp (0x14, packed build date/time) to confirm the expected build is loaded.
3. The End System is alive and configured. Through the TTTech API, tte_es_get_device_info and tte_es_get_config_status confirm the loaded configuration, and tte_es_get_bist_status returns the built-in-test result.
4. The network is synchronized (deterministic classes). For AS6802, tte_es_get_sync_status / tte_es_get_sync_stats confirm the End System has achieved synchronization with the network’s time base — until it’s synced, time-triggered traffic won’t flow on schedule.

If the card enumerates, the Test Register reads back what you wrote, the FPGA build is what you expect, BIST is clean, and (for TT traffic) the End System reports synchronized — then the board connection, the PCIe driver, the module, and your loaded configuration are all confirmed, and your tte_es_* ports are ready to carry data.

Features

Everything you do at runtime goes through TTTech’s TTEthernet End System API. Two things to keep in mind as you read this section:

• This is TTTech’s API, not NAI’s SSK. The signatures below are reproduced from the TE2 Manual; the headers, types (Tte_Es_*), and buildable reference code ship with the TTTech stack (contact factory). There is one API — no SSK 1.x/2.x split, so no version toggle.
• The configuration comes first. The virtual links, ports, and schedule were defined in TTE-Plan/TTE-Build (Software). At runtime you don’t create those — you open the ports the configuration already defined and move data through them.

The model: a configured End System is referenced by a handle (Tte_Endsystem_Hdl es); within it, an application partition is identified by an Tte_Es_Ap_Id, and each port by a Tte_Es_Port_Id. You open a port to get an input-port (Tte_Es_Iport_Hdl) or output-port (Tte_Es_Oport_Hdl) handle, then read or write through that handle. The same calls serve all three traffic classes — which class a port carries was decided in the configuration, not in code.

Ports & messaging — move data through configured ports

What it does / when: open the input/output ports defined in your configuration, send and receive message data, and inspect per-port type, status, and timing. This is the core of any TTEthernet application.

Relevant APIs:

/* Open / close ports */
Tte_Es_Iport_Hdl tte_es_open_iport(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Port_Id port_id, Tte_Es_Data_Size *size, bool_t *fresh, Tte_Es_Ret *result);
Tte_Es_Oport_Hdl tte_es_open_oport(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Port_Id port_id, Tte_Es_Data_Size msg_len, Tte_Es_Ret *result);
Tte_Es_Ret       tte_es_close_iport(Tte_Es_Iport_Hdl *iport, bool_t reset_drops);
Tte_Es_Ret       tte_es_close_oport(Tte_Es_Oport_Hdl *oport);
Tte_Es_Ret       tte_es_flush_iport(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Port_Id port_id);
 
/* Read / write message data */
Tte_Es_Ret tte_es_read_data(Tte_Es_Iport_Hdl iport, Tte_Es_Port_Data *data, Tte_Es_Data_Size length);
Tte_Es_Ret tte_es_write_data(Tte_Es_Oport_Hdl oport, Tte_Es_Port_Data *data, Tte_Es_Data_Size length);
Tte_Es_Ret tte_es_get_raw_imsg(Tte_Es_Iport_Hdl iport, Tte_Es_Port_Data **msg);
Tte_Es_Ret tte_es_get_raw_omsg(Tte_Es_Oport_Hdl oport, Tte_Es_Port_Data **msg);
 
/* Inspect a port */
Tte_Es_Ret       tte_es_query_iport(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Port_Id port_id, Tte_Es_Iport_Status *status, Tte_Es_Iport_Props *props);
Tte_Es_Ret       tte_es_query_oport(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Port_Id port_id, Tte_Es_Oport_Status *status, Tte_Es_Oport_Props *props);
Tte_Es_Ret       tte_es_get_iport_status(Tte_Es_Iport_Hdl iport, Tte_Es_Iport_Status *status);
Tte_Es_Ret       tte_es_get_oport_status(Tte_Es_Oport_Hdl oport, Tte_Es_Oport_Status *oport_status);
Tte_Es_Ret       tte_es_get_iport_type(Tte_Es_Iport_Hdl iport, Tte_Es_Iport_Type *type);
Tte_Es_Ret       tte_es_get_oport_type(Tte_Es_Oport_Hdl oport, Tte_Es_Oport_Type *type);
Tte_Es_Data_Size tte_es_get_ihdr_size(Tte_Es_Iport_Type type);
Tte_Es_Data_Size tte_es_get_ohdr_size(Tte_Es_Oport_Type type);
Tte_Es_Ret       tte_es_get_timestamp(Tte_Es_Iport_Hdl iport, Tte_Es_Iport_Timestamp *timestamp);

Frame headers / SAP addressing — build and read MAC/IP/UDP headers

What it does / when: read the addressing on received frames and stamp it on frames you send. AFDX traffic is typically carried as IP/UDP over the virtual link, so these get/set the MAC, IP, and UDP Service Access Point fields on a port (*_port) or directly in a buffer (*_buf); macraw handles a raw MAC frame.

Relevant APIs:

/* Read header fields off received data (input side) */
Tte_Es_Ret tte_es_get_hdr_macsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Iport_Mac_Sap *info);
Tte_Es_Ret tte_es_get_hdr_ipsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Iport_Ip_Sap *info);
Tte_Es_Ret tte_es_get_hdr_ipsap_port(Tte_Es_Iport_Hdl iport, Tte_Es_Iport_Ip_Sap *info);
Tte_Es_Ret tte_es_get_hdr_udpsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Iport_Udp_Sap *info);
Tte_Es_Ret tte_es_get_hdr_udpsap_port(Tte_Es_Iport_Hdl iport, Tte_Es_Iport_Udp_Sap *info);
 
/* Set header fields on outgoing data (output side) */
Tte_Es_Ret tte_es_set_hdr_macsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Oport_Mac_Sap *info);
Tte_Es_Ret tte_es_set_hdr_macraw_buf(Tte_Es_Port_Data *buf, Tte_Es_Oport_Mac_Raw *info);
Tte_Es_Ret tte_es_set_hdr_ipsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Oport_Ip_Sap *info);
Tte_Es_Ret tte_es_set_hdr_ipsap_port(Tte_Es_Oport_Hdl oport, Tte_Es_Oport_Ip_Sap *info);
Tte_Es_Ret tte_es_set_hdr_udpsap_buf(Tte_Es_Port_Data *buf, Tte_Es_Oport_Udp_Sap *info);
Tte_Es_Ret tte_es_set_hdr_udpsap_port(Tte_Es_Oport_Hdl oport, Tte_Es_Oport_Udp_Sap *info);

Timing & synchronization — the network clock

What it does / when: read the End System’s view of network time and its synchronization state. This is what makes AS6802 deterministic — every scheduled frame is timed against this clock — and it’s how you confirm the module has locked to the network’s time base.

Relevant APIs:

Tte_Es_Ret tte_es_get_time(Tte_Endsystem_Hdl es, uint64_t *time_ns);
Tte_Es_Ret tte_es_get_time_resolution(Tte_Endsystem_Hdl es, uint32_t *res_ns);
Tte_Es_Ret tte_es_get_cycle_time(Tte_Endsystem_Hdl es, uint32_t *time_ns);
Tte_Es_Ret tte_es_get_clock_corrections(Tte_Endsystem_Hdl es, Tte_Es_Clock_Corrections *corr);
Tte_Es_Ret tte_es_get_sync_status(Tte_Endsystem_Hdl es, Tte_Es_Sync_Status *status);
Tte_Es_Ret tte_es_get_sync_stats(Tte_Endsystem_Hdl es, Tte_Es_Sync_Stats *stats);

Status, statistics & BIT — monitor the End System

What it does / when: query device identity, configuration, health, and traffic statistics — for bring-up (Confirm communication), monitoring, and debugging. Covers device/config info, built-in test, per-channel and per-virtual-link statistics, error counters, and partition state.

Relevant APIs:

/* Device, configuration, and parameters */
Tte_Es_Ret tte_es_get_device_info(Tte_Endsystem_Hdl es, Tte_Es_Info *es_info);
Tte_Es_Ret tte_es_get_config_status(Tte_Endsystem_Hdl es, Tte_Es_Config_Status *status);
Tte_Es_Ret tte_es_get_com_params(Tte_Endsystem_Hdl es, Tte_Es_Dev_Params *params);
Tte_Es_Ret tte_es_get_mac_src_addr(Tte_Endsystem_Hdl es, uint8_t channel, uint8_t *adr);
Tte_Es_Ret tte_es_get_prom_mode(Tte_Endsystem_Hdl es, uint8_t channel, bool_t *enable);
 
/* Built-in test, statistics, and error status */
Tte_Es_Ret tte_es_get_bist_status(Tte_Endsystem_Hdl es, Tte_Es_Bist_Status *status);
Tte_Es_Ret tte_es_get_channel_stats(Tte_Endsystem_Hdl es, Tte_Es_Channel_Stats *stats);
Tte_Es_Ret tte_es_get_drop_stats(Tte_Endsystem_Hdl es, Tte_Es_Drop_Stats *stats);
Tte_Es_Ret tte_es_get_error_status(Tte_Endsystem_Hdl es, Tte_Es_Error_Status *status);
Tte_Es_Ret tte_es_get_ram_error_status(Tte_Endsystem_Hdl es, Tte_Es_Ram_Error_Status *status);
Tte_Es_Ret tte_es_get_rm_error_status(Tte_Endsystem_Hdl es, Tte_Es_Rm_Error_Status *status);
Tte_Es_Ret tte_es_get_no_cots_status(Tte_Endsystem_Hdl es, Tte_Es_No_Cots_Status *status);
Tte_Es_Ret tte_es_get_vl_status(Tte_Endsystem_Hdl es, uint16_t vl_tbl_idx, Tte_Es_Vl_Error_Status *status);
 
/* Partitions */
Tte_Es_Ret tte_es_get_partition_status(Tte_Endsystem_Hdl es, Tte_Es_Ap_Id ap_id, Tte_Es_Partition_Status *status);
Tte_Es_Ret tte_es_get_partition_space(Tte_Endsystem_Hdl es, uint8_t part_id, uint16_t *space, uint32_t *threshold_vect);

Try it

Once the End System is configured (Software) and confirmed (Confirm communication), a TTEthernet application is fundamentally open a port → move data → close it. The snippets below show the call order for the transmit and receive paths — they’re the conceptual sequence, not buildable programs. TTTech’s stack ships the full, buildable sample code (contact factory); these just orient you.

The same calls serve all three traffic classes — which class a port carries (802.3, AFDX, or AS6802) was decided in the configuration, so the code looks the same either way.

Try it — transmit (output port)

Open an output port the configuration defined, optionally stamp the destination addressing on the frame, and write the payload. The End System routes and (for the deterministic classes) schedules it automatically.

/* Transmit — open a configured output port and send a message */
Tte_Es_Ret       result;
Tte_Es_Oport_Hdl oport = tte_es_open_oport(es, AP_ID, OPORT_ID, MSG_LEN, &result);
 
/* (AFDX / IP-UDP traffic) stamp the destination SAP on the outgoing frame */
tte_es_set_hdr_udpsap_port(oport, &udp_dst);
 
/* Send the payload; routing/scheduling follows the port's traffic class */
tte_es_write_data(oport, data, length);
 
tte_es_close_oport(&oport);

Try it — receive (input port)

Open a configured input port, read the latest message, and optionally inspect its source addressing and arrival timestamp.

/* Receive — open a configured input port and read a message */
Tte_Es_Ret       result;
Tte_Es_Data_Size size;
bool_t           fresh;
Tte_Es_Iport_Hdl iport = tte_es_open_iport(es, AP_ID, IPORT_ID, &size, &fresh, &result);
 
/* Read the data; optionally inspect its source SAP and timestamp */
tte_es_read_data(iport, data, size);
tte_es_get_hdr_udpsap_port(iport, &udp_src);
tte_es_get_timestamp(iport, &timestamp);
 
tte_es_close_iport(&iport, FALSE);

Building and running. The snippets above are condensed for orientation. The TTTech End System product supplies the headers, types, and complete sample applications for your platform (VxWorks 653 / Deos / 68G5P) — contact factory for the integration package. For bringing the board itself up (power, network, terminal, file transfer), see Connecting to Boards.

Hardware capabilities and status monitoring

This section covers what the hardware provides and what you can monitor — for how to drive the ports, see Features and Try it above.

TTEthernet hardware (TE2):

• Tri-redundant — one logical channel carried over three independent Ethernet planes (ETH1/2/3), so a single link or switch failure doesn’t take the interface down.
• TTTech End System core on a Zynq UltraScale+ FPGA, DO-178/DO-254 certifiable, supporting all three traffic classes concurrently.
• PCIe Gen II (5.0 Gbps) endpoint, two BARs (BAR0 driver, BAR1 NAI interface).
• Frame memory is configured as part of the network build (e.g. 512 KB on IP core 1.9.2, 304 KB on 1.8.25 — see the Network Description in the TE2 Manual); the frame memory size is entered in bytes.
• Build identity is readable from BAR1: FPGA Revision (0x08) and FPGA Timestamp (0x14, packed build date/time).

Statuses you can monitor programmatically (via the TTTech API):

Status	What it tells you	Where
BIST	Built-in-test result for the End System	tte_es_get_bist_status
Sync status	Whether the End System is synchronized to the network time base (AS6802)	tte_es_get_sync_status / tte_es_get_sync_stats
Config status	Whether the loaded configuration is valid/active	tte_es_get_config_status
Network time	Current ES time, resolution, and integration cycle time	tte_es_get_time / tte_es_get_time_resolution / tte_es_get_cycle_time
Channel stats	Per-plane traffic counters	tte_es_get_channel_stats
Drop stats	Frames dropped (e.g. policing, overflow)	tte_es_get_drop_stats
VL status	Per-virtual-link error status	tte_es_get_vl_status
Error / RAM / RM status	Error counters, memory errors, redundancy-management errors	tte_es_get_error_status / tte_es_get_ram_error_status / tte_es_get_rm_error_status
Partition status / space	Per-partition state and buffer space	tte_es_get_partition_status / tte_es_get_partition_space
FPGA revision / timestamp	Loaded build identity	BAR1 0x08 / 0x14

Common pitfalls

• No policing switch → no determinism. AFDX’s bounded latency/jitter and AS6802’s scheduling exist because a compliant TTE/AFDX switch enforces them. Wire the End System point-to-point and you only have best-effort 802.3 — the deterministic guarantees require the switch.
• Configuration mismatch between End System and switch. The TTE-Plan/TTE-Build design (virtual links, rates, schedule) loaded on the module must match the network design on the switch and the other End Systems. A mismatch shows up as policed/dropped frames or traffic that never gets scheduled.
• Not synchronized, but expecting time-triggered traffic. AS6802 traffic only flows on schedule once the End System has synchronized to the network clock — check tte_es_get_sync_status before assuming the schedule is running.
• Frame memory size entered in the wrong unit. The preferred input for frame memory size is bytes — see the note in the TE2 Manual Network Description.
• Tri-redundancy needs all three planes wired. Cabling only one ETH plane works, but gives you no redundancy; full fault tolerance means all three planes to redundant switches.
• Expecting the NAI register / ESP2 / SSK model. TE2 has no naibrd_* API, no function register map, no SSK sample apps, and no ESP2 panel. Configure and drive it through TTTech’s tooling and tte_es_* API.
• Unsupported platform. TTEthernet support is tied to specific SBC + RTOS combinations (67PPC2/68PPC2 on VxWorks 653 3.x or DDC-I Deos; 68G5P for 3rd-party SBCs). Off that list, contact factory before designing it in.

Related resources

• TE2 Manual — the module manual (data sheet, network description, PCIe/BAR1 registers, full tte_es_* API list, pinout)
• TTTech TTEthernet documentation, TTE-Plan / TTE-Build, and the End System SDK — the source for the stack, tooling, and buildable sample code (contact factory for the package for your platform)
• The standards — IEEE 802.3 (Ethernet), ARINC 664 Part 7 (AFDX®), and SAE AS6802 (Time-Triggered Ethernet) define the three traffic classes
• FT Family Guide — MIL-STD-1553/1760 avionics data bus
• AR Family Guide — ARINC 429/575 avionics data bus
• CB Family Guide — CANbus (CAN 2.0 A/B, J1939, MilCAN)
• SC Family Guide — freeform serial (RS-232/422/485)
• Connecting to Boards — power, network, terminal, and file transfer to your board