The NAI ethernet interface supports block read writes. A block is a list of register addresses to be read or written in a singular operation.

The following block commands are supported:

A block definition consists of the following fields:

Block commands differ from the basic ReadRegs/WriteRegs commands because they allow for non-patterned multiple register reads or writes. The addresses can be in any order and not be defined by any particular pattern. All registers specified within a block are bound by the same flag settings. You cannot mix Onboard/Off-board addressing or 32-bit/16-bit register sizes.

The NAI Ethernet Interface also supports ZBlock reads and writes. Like a block, a ZBlock is a list of register addresses to be read or written in a single operation. Unlike regular blocks, ZBlocks may contain Onboard and Offboard addresses in a single block.

The following block commands are supported:

A ZBlock definition consists of the following fields:

ZBlock commands differ from ReadRegs/WriteRegs commands because they allow for non-patterned multiple register reads or writes. In other words, the addresses can be in any order and not be defined by a particular pattern. All registers defined in a ZBlock must be either 32-bit or 16-but in register sizes — you cannot mix 32-bit and 16-bit register commands in a single ZBlock.

TDRs (also known as Unprompted Reply Commands) execute a list of commands based on a timer event, requiring asynchronous listening for responses triggered by timers. While similar to Interrupt Driven Responses (IDR), TDRs use a timer period instead of an interrupt vector.

The following TDR commands are supported:

A TDR definition consists of the following fields:

There are a maximum of 16 definable TDRs. Each TDR can contain up to 4 commands.

TDRs use SequenceNo’s to identify the TDR to which a particular response belongs. The SequenceNo is provided by the following formula:

\$SequenceNo == 0x8000 | (uhTDRIndex << 10) | (uhCommandIndex << 6)\$

This provides the mechanism to identify the TDR for which an Unprompted Replay is associated with.

The Bit assignments for SequenceNo’s is as follows:

IDRs (also knwon as Unrpompted Reply Commands) execute a list of commands based on an interrupt, requiring asynchronous listening for responses. While similar to Timer Driven Responses (TDR), IDRs use an interrupt vector instead of a timer period.

The following IDR commands are supported:

An IDR configuration consists of the following fields:

Commands contained the command list follow the same message protocol as all other commands. Each command must contain the full Header, Payload, and Trailer fields. A maximum of 16 IDRs may be defined. Each IDR may have up to 4 commands.

IDRs use SequenceNo’s to identify the TDR to which a particular response belongs. The SequenceNo is provided by the following formula:

\$SequenceNo == 0xC000 | (uhIDRIndex << 10) | (uhComm$andIndex << 6)\$

This provides the mechanism to identify the TDR for which an Unprompted Replay is associated with.

The Bit assignments for SequenceNo’s is as follows:

The NAI Ethernet Interface also supports scripting commands. This allows the user to assemble sequences of predefined commands that are stored in the operation memory of the Motherboard Ether Listener process. These sequences are called scripts and are available fro the duration of the existing process only — they are not stored in on the Motherboard. On reset, all scripts are cleared from memory.

Up to 16 scripts can be defined. Each script is defined by its ScriptID (a number from 1 - 16).

Users can WriteScripts, ReadScripts, ExecuteScripts, and ClearScripts using the associated commands.

Each script can hold a maximum of 100 commands provided that the summation of all command bytes do not exceed the maximum allowable bytes (1500) per Ethernet Message.

When a script is executed, all commands are executed serially in the exact sequence they are defined in the script. Responses are generated for each command and are executed exactly as if the commands were sent individually.

The following scripting commands are provided:

The following commands can be scripted:

The NAI Ethernet Interface supports I2C reads and writes.

The following I2C commands are supported:

A I2C Raw Data definition consists of the following fields:

These commands are intended for Factory Test only and may not be available on all platforms.

The following System Configuration commands are supported:

System Configuration data definition consists of the following fields:

Error responses wil return the error number via the TypeCode with a value between 0x8000 to 0x8FFF. The packet also contains an ASCII encoded message field which is not null terminated. RThe size of this field can be determined by subtracting 10 from the Length field. For information about valid error codes, refer to Response Type Codes.

There are two Register Commands: ReadRegs and WriteRegs. These commands are capable of reading or writing single or multiple registers using a pattern of addressing on the motherboard or modules. Both commands use the same set of parameters as described below:

The Count parameter specifies the number of registers to read or write. The Register size is defined in the Flags parameter as either 32-bit or 16-bit. If the 16-bit flag is set, then Count represents the number of 16-bit words to read or write. If the 32-bit flag is set, Count represents the number of 32-bit words to read or write.

The Stride parameter specifies how the Register Address will be incremented while performing the Count reads or writes. The Stride parameter is always specified in bytes and only values that are a multiple of the specified register size (32-bit or 16-bit) are valid. See the notes below for specifying a valid Stride value:

In this project, we establish a communication link between an NAI motherboard and a mission computer using the Ethernet interface to monitor system health. This setup is crucial in real-world applications, such as in defense and aerospace, where maintaining optimal system performance is vital. By retrieving data like temperature and status, the mission computer can ensure that the embedded systems are operating within safe parameters, allowing for timely interventions and adjustments. This integration enhances situational awareness and contributes to the overall reliability and safety of the mission-critical operations. In particular, we want to look at the capabilities of reading directly from ethernet and reading from the registers.

Hardware Components:

Software Components:

Hardware Setup:

To get started, first assemble your hardware. We will need a NAI Generation 5 Motherboard for integration with the ethernet interface. In this example, we will be using a 75G5.

You will need an appropriate power supply for your motherboard. For the 75G5, we will need to supply 5V. Connect the ground and positive terminal of your motherboard to the corresponding terminals on your power supply like so:

Connect your ethernet cable to the back ethernet port on the motherboard like so:

Connect the other end of your ethernet cable to the breakout board, as well as connecting the ethernet cable and serial cable for your host machine to the breakout board as well.

Now, you have configured your hardware to get started with software development.

Software Setup:

To get started, we need to download the SSK1 and configure a new project for use.

First, open the terminal on your device and navigate to a folder where you want to keep the repository.

Then, type in git clone https://gitlab.naii.com/software/ssk1.git

Next, ensure that you have downloaded and properly setup Visual Studio 2022 from the following link: https://visualstudio.microsoft.com/vs/community/

Once you have everything installed, open up the folder containing your repository in Visual Studio:

Once inside, navigate into AppSrc and right click on any of the projects inside the subfolders to copy.

You now have a project to work with. If you want to change the name of the project/source file, you must change all references of this using editor tools. For now, we will leave it as is.

Open the naibrd_Appsrc.sln now in Visual Studio to build and execute the projects.

Before you begin editing your project, make sure you build the naibrd project first.

Now, we can start creating our project.

In this project, we want to do a few things:

To get started, you need to create an external client that your motherboard is communicating with. This server needs to be run at all times so your motherboard is able to access it. Here is an example of such in python:

Now, let’s see some code to send a message across ethernet and print the received data:

In our main code block, we will call this function along with a time measuring function over 4 different buffer sizes to see how long it takes. Here’s some code to perform this:

The output of this code is shown below, where we can see how long it takes to send and receive messages over ethernet, saving them in an array:

Now let’s see how long it takes to do something similar using the Gen 5 Ethernet Interface’s block capabilities. Instead of reading the response directly from ethernet, we will be saving the results to block storage and then reading from the block registers.

To do so, let’s modify our transmit function slightly to include calling the block functions:

Now, let’s create the new Block functions, starting with SetEthBlockConfig. This function calls This function calls InitBlockRegisters() to sets up the list of register addresses for the Set Block command and calls naibrd_Ether_SetBlock() to send the SetBlock command to the board for the Block ID specified, which is defined to just 1 for this example. This function will be called once in the main function.

Next, let’s create InitBlockRegisters, which configures the list of register addresses for the Set Block command.

Now let’s create the WriteEthBlockRegisters function, which sets up the data received via etherent to write to the list of registers via InitBlockRegistersData and sends the WriteBlock command to the board to write the data to the list of register addresses specified for the Block ID.

InitBlockRegistersData sets up the data to write to the list of registers for the block command by splitting up the data received by ethernet evenly to write to the block registers in order to be put back together when read later.

Finally, let’s create the ReadEthBlockRegisters function, which sends the ReadBlock command to the board to retrieve the data for the list of register addresses specified for the Block ID.

If we run the code now, we receive the following output:

In both instances, we received the same message from the server. Although it does not necessarily take less time to read information from block registers compared to reading directly from Ethernet, there are still significant advantages to using block registers. Using block registers can simplify the management of data, provide more structured access patterns, and enhance the reliability of data retrieval by reducing the potential for errors associated with direct memory access.

With this example, we have demonstrated the benefits of using block registers for reading and writing Ethernet messages. While the speed may not always be improved, the structured approach and potential for better data management make block registers a valuable tool in certain applications. This highlights the efficiency and reliability of direct register access over traditional memory allocation in the main process.