Advanced Mode UART Interface

Introduction

This document introduces both the transmitter and receiver UART advanced mode interface. Through a high-speed UART interface, the Ginseng, Saffron, Sage, and Nadja SiPs implement a set of APIs that allow a Licensee MCU (LMCU) to query and control the behaviour of a SKAA audio system. In addition to reading and writing SKAA APIs, the LMCU may subscribe to updates from APIs of interest, eliminating polling and facilitating asynchronous design.

Terminology

UART Interface Description

The specification for the UART interface is as follows:

Baud Rate 115200
Data Bits 8
Parity Bits None
Stop Bits 1

API Types

APIs differ depending on where they are used within the SKAA system. The following table summarizes the API types, their naming prefix and where and how they are used in the SKAA system:

API Type Prefix Description
Host h Affects the host device which is connected to the transmitter
Global g Affects the transmitter which can affect the global SKAA system
Bay b Affects all receivers in an entire bay
Master m Affects the master receiver node
Node n Affects any single receiver node (both master and slave receiver nodes)

Bay and Node APIs require an additional "Bay/Node Address" field since there can be multiple Bays and Nodes. In contrast there is only one master in a cluster, one host, and one transmitter so they don't require an address. Additionally, when connected to a Receiver's UART Interface the Bay/Node Address is ignored and only the local bay or node's value is set or returned.

UART Protocol Description

The SKAA UART protocol is built around a simple request-response scheme. The LMCU issues requests to the local device. The local device ACKs valid requests, and NACKs invalid requests. Requested data, if any, is sent by the local device to the LMCU in a response packet.

An API packet is structured with a Packet Type

Packet Type

There are five packet types that determine the role of the packet in the SKAA system.

Packet Type Code Description
Read 0x50 Requests API data from the SKAA system
Write 0x51 Sets API data in the SKAA system
Response 0x52 Contains returned data from a Read
ACK 0x53 Sent to LMCU to acknowledge the receipt of a Read or Write packet
NACK 0x54 Notifies the LMCU a received packet was corrupted or invalid

The format of the payload for the various Packet Types is summarized below.

Packet Type Addressing Byte 1 Byte 2 Byte 3 Remaining bytes
ReadUnaddressed0x50API
Addressed0x50APIBay/Node Address
WriteUnaddressed0x51APIAPI Data (0-8 Bytes)
Addressed0x51APIBay/Node AddressAPI Data (0-8 Bytes)
ResponseUnaddressed0x52APIAPI Data (0-8 Bytes)
Addressed0x52APIBay/Node AddressAPI Data (0-8 Bytes)
ACK0x53API
NACK0x54
Examples
Packet Type API Byte 1 Byte 2 Byte 3 Byte 4
ReadhVOL0x500x02
bVTR0x500x800xFF
WritehVOL0x510x020x500x50
bVTR0x510x800xFF0x50
ResponsehVOL0x520x020x500x50
bVTR0x520x800xFF0x50
ACKhVOL0x530x02
bVTR0x530x80
NACK0x54

Subscribing to API Updates

The LMCU can optionally subscribe to update notifications for up to 8 APIs. When one of these APIs changes value, the local device will send a request response packet containing the new value of the API. This can be useful for subscribing to volume updates, for example.

If the local device is a transmitter, API subscriptions are managed with the gIRQ and gIRE APIs as shown below.

WritegIRQAPI #1API #2API #3API #4API #5API #6API #7API #8
bVTRbMUThVOLnRAUgBTSEmptyEmptyEmpty
0x510x0C0x800x810x020x540x2C0x000x000x00
WritegIREBit Mask Enable
0x510x0D0x1F

If the local device is a receiver, API subscriptions are manged with the nIRQ and nIRE APIs.

WritenIRQBay/Node AddressAPI #1API #2API #3API #4API #5API #6API #7API #8
bVTRbMUThVOLnRAUnPSTgBTSEmptyEmpty
0x510x5A0xFF0x800x810x020x540x5F0x2C0x000x00
WritenIREBay/Node AddressBit Mask Enable
0x510x5B0xFF0x3F