NAI Documentation

SC Module Guide

8 min read

SC Family Guide

Overview

The SC family is NAI’s line of programmable serial-communications smart function modules. Each module provides multiple independent, full-duplex serial channels, and every channel is software-configurable for RS-232 (single-ended), RS-422/485 (differential), and RS-423 (pending) — in asynchronous or synchronous modes, at programmable baud rate, parity, data bits, and stop bits, with on-chip transmit/receive FIFOs.

This page is the starting point for any SC module. Use it to understand the family, pick the member that fits your channel count and isolation needs, wire a serial link, and confirm you can talk to the module with a loopback. It’s aimed at engineers integrating serial devices — GPS/INS units, radios, sensors, displays, telemetry, and legacy avionics serial buses — into an NAI board or system.

In a real system, an SC module is how your processor talks to the serial devices around it. On a rugged platform that usually means a GPS receiver or inertial navigation unit streaming position data, a radio or datalink terminal, engine/environmental sensors, cockpit displays, or older avionics boxes that only speak a serial protocol. The interface you choose follows the link: RS-232 for short, point-to-point connections to a single nearby device; RS-422/485 for longer, noisier cable runs and multi-drop buses where several devices share one line. NAI also builds these same modules into larger serial subsystems — the FACE-certified Serial IOSS and the Remote Data Concentrators (RDC) — that switch and concentrate many serial lines in aerospace and defense systems.

SC modules at a glance

ModuleChannelsIsolationWhat makes it differentManual
SC14Non-isolatedBaseline programmable serial (RS-232/422/485)SC1-2-7 Manual
SC24IsolatedSC1 with isolated outputsSC1-2-7 Manual
SC74Non-isolatedSC1 with the CTS flow-control pins reallocated as 4 GPIOSC1-2-7 Manual
SC38Iso or non-isoHighest channel count; 8 async or 4 sync channelsSC3 Manual
SC54IsolatedIndividually isolated; async/sync; SYNC clock or GPOSC5 Manual
SC64Non-isolatedSC5’s non-isolated twin; async/sync; SYNC clock or GPOSC6 Manual

Choosing a member:

  • Most channels in one slot — SC3 (8 channels; run as 8 async or 4 sync).
  • Galvanic isolation — SC2 or SC5 (SC5 is individually isolated per channel).
  • Non-isolated, standard serial — SC1 or SC6.
  • Extra GPIO alongside serial — SC7 (its CTS flow-control pins become 4 GPIO).
  • Synchronous (clocked) operation, or a SYNC clock / GPO — SC3, SC5, or SC6.

Physical setup

Serial wiring depends on the protocol you program and on the per-module pinout, so the exact TX/RX pins always come from that module’s manual. The setup pattern is the same for every SC module:

  1. Seat the module in a slot on your NAI motherboard or system.
  2. Bring the channel signals out through the breakout board, where the slot’s pins appear as generic IO# numbers.
  3. Map IO# pins to the channel’s serial signals — by the pinout in the module’s manual or the module’s overlay card.
  4. Wire your serial device to the mapped TX/RX pins.

Two ideas cover every SC wiring job:

  1. Choose the electrical interface in software, then wire to match it. RS-232 is single-ended — each signal is a single wire measured against a shared ground. RS-422/485 are differential — each signal is a balanced pair of wires (a + and a −), which rejects noise and reaches much farther. Set the interface with naibrd_SER_SetInterface; the wiring you run has to match that choice.
  2. Always cross transmit and receive. The module’s TX (what it sends) goes to the device’s RX (what it listens on), and the module’s RX comes from the device’s TX.

Two worked examples — your module’s manual or overlay card gives the actual pin numbers:

RS-232 to a nearby device (e.g. a GPS receiver) — 3 wires:

Module pin→Device pin
TX→RX
RX←TX
GND↔GND

Then set baud, parity, data bits, and stop bits to match the device (e.g. 9600 8N1).

RS-422 over a longer or noisier run — 2 pairs (4 signal wires):

Module pins→Device pins
TX+ / TX− (one pair)→RX+ / RX−
RX+ / RX− (one pair)←TX+ / TX−

Each direction is its own balanced pair, so it tolerates long cables and electrical noise far better than RS-232.

Two module-specific notes: isolated variants (SC2, SC5) keep channels galvanically separated, so reference signals to the isolated ground, not system/chassis ground. And in synchronous mode a clock rides on the companion channel; in async mode those pins are free to act as a GPO (SC5/SC6) or GPIO (SC7).

Software

There’s nothing SC-specific about which software you run. The NAI SSK (naibrd library) is identical across every OS and architecture — PetaLinux, VxWorks, DEOS, Windows. What OS you’re on is determined by your motherboard/SBC, not by the SC module. The only family-specific part is which API functions you call — and note the prefix is naibrd_SER_* (serial), not naibrd_SC_*.

Where to find what you need:

  • Which functions/registers to call — the specific module’s manual (e.g. SC3 Manual) documents the SER registers (protocol, interface level, baud, parity, FIFOs).
  • Building and deploying on your platform — Connecting to Boards covers the toolchain, deployment, and terminal access for PetaLinux/ARM Linux, VxWorks, DEOS, and Windows.
  • Launching the app on the board itself — Running Applications from the Target walks through loading and launching your executable on the target.

Example — a 68ARM2 SBC with an SC3 module: pull the naibrd_SER_* calls from the SC3 Manual, set up the ARM Linux toolchain per Connecting to Boards, then load and launch a serial sample on the target per Running Applications from the Target.

Confirm communication

Before wiring anything to a real device, prove the whole chain — board connection, SSK, and the module — works.

Internal loopback (no wiring). Every SC channel can wrap its own transmitter back to its receiver internally. The loopback sample does exactly this: it configures a channel for async, writes data to the TX FIFO, loops it back through the module’s internal path, and verifies the bytes read back match — with no external cabling. Run SER Async Loopback (SSK 2.x) (or SER ASync LOOPBACK (SSK 1.x)); if it passes, you’re talking to the module.

External TX→RX (also proves your wiring). As a step up, jumper one channel’s transmit to another channel’s receive (matching the interface level you program — e.g. an RS-422 pair to an RS-422 pair), transmit on the first channel, and read the bytes on the second. This validates the physical pins and your cabling on top of the module itself. The transmit/receive sample pair SER Async Xmit and SER Async Recv demonstrates the two-channel flow.

Try it out

Serial channels are configured the same way regardless of which sample you run. Every NAI sample starts with the standard connection flow — naiapp_RunBoardMenu() opens or loads a board connection, then naiapp_query_CardIndex() and naiapp_query_ModuleNumber() pick the board and module slot (opened under the hood by naibrd_OpenDevice()), giving you the cardIndex / module / channel coordinates every naibrd_SER_* call takes. When you write your own program, you do the same — see Opening a Software Handle to Your Board.

Configuring a channel for 9600 8N1 async on an RS-422 interface looks like this (straight from the SER sample apps):

naibrd_SER_ChannelReset(cardIndex, module, channel);
naibrd_SER_ClearRxFifo(cardIndex, module, channel);
naibrd_SER_ClearTxFifo(cardIndex, module, channel);
 
naibrd_SER_SetCommProtocol(cardIndex, module, channel, NAIBRD_SER_PROTOCOL_ASYNC);
naibrd_SER_SetInterface(cardIndex, module, channel, NAIBRD_SER_INTF_RS422);
naibrd_SER_SetParityType(cardIndex, module, channel, NAIBRD_SER_PARITY_NONE);
naibrd_SER_SetNumDataBits(cardIndex, module, channel, NAIBRD_SER_DATA_BITS_8);
naibrd_SER_SetNumStopBits(cardIndex, module, channel, NAIBRD_SER_STOP_BITS_1);
naibrd_SER_SetBaudrate(cardIndex, module, channel, 9600);
 
/* On a receive channel, also enable the receiver: */
naibrd_SER_SetReceiverEnable(cardIndex, module, channel, TRUE);

From there, naibrd_SER_TransmitBuffer() sends bytes and naibrd_SER_GetRxBufferCnt() / naibrd_SER_ReceiveBuffer32() read them back.

Browse the serial samples: Async Transmit · Async Receive · Async Loopback · Async + GPIO · Built-In Test (SSK 2.x); SSK 1.x equivalents include SER_ASync_Tx, SER_ASync_Rx, and SER_ASync_LOOPBACK.

Common pitfalls

  • Interface level doesn’t match the wiring. Programming a channel as RS-232 while it’s wired differentially (or vice versa) yields garbage or silence. Set naibrd_SER_SetInterface to match how the channel is physically wired.
  • Both ends must agree on baud, parity, data bits, and stop bits. A mismatch (e.g. 9600 8N1 vs 115200 8E1) produces framing errors or gibberish — configure both sides identically.
  • No data received? The receiver may not be enabled. Transmit-only channels don’t need it, but a receive channel requires naibrd_SER_SetReceiverEnable(..., TRUE).
  • TX and RX not crossed. The module’s TX must reach the device’s RX and vice versa; wiring TX→TX is a common mistake.
  • Sync vs async confusion. Synchronous mode expects a clock on the companion channel; for plain UART-style serial use async (NAIBRD_SER_PROTOCOL_ASYNC).
  • Isolated-module grounding. On SC2/SC5, channels are galvanically isolated — reference signals to the isolated ground, not chassis/system ground.
NAI Docs Assistant
Was this document helpful?