Sienda Time Sensitive Network Stack - Programming Guide

_{^{Updated March 2023. Content subject to change. Copyright (c) 2023 Sienda Multimedia Ltd. All rights reserved.}}

🢀 Back to main documentation page

Introduction

Developing software or firmware to implement an AVB endpoint (or bridge) is not trivial. AVB devices are complex real-time systems, and many different parts of the system must co-exist and interact, often on a single CPU or SoC, to form a reliable product.

The first step in starting your development is to choose a hardware platform. Selecting a SoC, MCU/CPU family or Operating System that is not up to the job will result in an AVB device that simply doesn’t work. Or even worse, it may work most of the time, but occasionally fail. The Architecture Guide details the hardware requirements for an AVB endpoint. This guide details the OS and software requirements, and offers in depth information as to the programming of an AVB endpoint.

This guide assumes that the Sienda TSN Stack will be used to provide the core AVB functionality of your product.

Programming Guide Sections

• Choosing an Operating System
• System and Stack Initialisation, and Stack Configuration
• Audio Processing and Clock Recovery
• Memory Objects and Firmware Updates

Miscellaneous Notes

Ethernet Packet Buffers

The library expects (and delivers) all ethernet packets (frames) stripped of any preamble and CRC, but with all layer 2 headers intact. For the majority of embedded systems and raw ethernet drivers this is how the packet/frame will be delivered/expected by the driver layer.

Debug console output

The library will report error messages and useful status messages to the debug console. The library uses the standard library function printf for all console output. In an embedded environment the application may redirect stdout to a serial console (UART or similar) by overriding the standard library function _write().

Timer funcionality

The library requires the use of a system timer, preferably a high resolution hardware timer. The application provides a callback function AVBStackSetTimerFunction which the library will use to set the absolute (system) time that it requests to be called at. When the system timer fires, the application should call the library’s timerElapsed() function. The library works at nanosecond precision, and so all timestamps are in nanoseconds, and are thus of type uint64_t. The datum for the system time is not important. Nanoseconds from system boot is commonly used.

Callback Functions

The library requires several callback functions to be implemented for correct operation. Not all the callbacks are required for correct operation. Each callback function has an associated context variable that is application defined. If no application context is required when the callbacks are called, then the context variables may be set null.

Plase check modStackCallbacks File Reference to see the prototypes.

Domains

The library can work with different domains so the device will be seen as multiple entities. Each network interface on the device will be mapped to a domain. The stack uses the following terminology to differentiate between physical external ethernet interface and logical ports on a domain:

• interfaceNdx: the index of the physical ethernet interface
• domainNdx: the index of the domain. Each domain is a separate network instance. In Milan devices there are typically two domains representing the two redundant networks. Domain 0 is the primary Milan network, and domain 1 is the secondary Milan network
• portNdx or portNb: the index of the logical port on a domain.

So we could have a device with 5 interfaces in:

• Normal mode: where all the interfaces belong to the same domain:

Interface	Domain	Port
0	0	0
1	0	1
2	0	2
3	0	3
4	0	4

• Redundant mode. Where odd interfaces belong to one domain and even interfaces belong to a different domain:

Interface	Domain	Port
0	0	0
1	1	0
2	0	1
3	1	1
4	0	2
5	1	2

🢀 Back to main documentation page