10.2 Azure RTOS Middleware Support

Azure RTOS is an embedded development suite consisting of ThreadX® as core and extended functionalities using different components like GUIX, FileX, USBX, and NetX Duo.

Figure 10-1 depicts Azure RTOS middleware components and their interaction with application and hardware.

Figure 10-1 Azure RTOS Components

10.2.1 Azure RTOS ThreadX

Azure RTOS ThreadX is a high-performance RTOS kernel designed specifically for resource constrained embedded systems and applications. Azure RTOS ThreadX has picokernel architecture.

Azure RTOS ThreadX provides services like advanced preemption-threshold scheduling facilities, message passing, communication, synchronization, timer, memory management, and interrupt management, event-chaining, execution profiling, performance metrics, and system event tracing, etc.

Figure 10-2 shows different services and APIs offered by Azure RTOS ThreadX and their interaction with different components in the system.

Figure 10-2 ThreadX Services

For more API details and usage, refer to the Azure RTOS ThreadX User Guide.

Azure RTOS NetX Duo is an embedded TCP/IP stack tailored specifically for resource constrained embedded real-time and IOT environments. Along with the core network protocols such as TCP, UDP, ICMP, and IP (version 4 and version 6), NetX Duo supports a large number of additional higher layer protocols (such as HTTP(S), MQTT, FTP, etc.) as add-ons. Additionally, NetX Duo provides a set of add on protocols to enable secure communications. These implement Transport Layer Security protocols (SSL/TLS/DTLS) and IPsec.

Figure 10-3 is a high-level representation of different components in the network stack of the Alif Semiconductor RTSS SDK. Note that NetX Duo depends on functionalities provided by the Azure RTOS ThreadX and assumes its existence. For clarity, ThreadX is not shown in the figure.

As shown in Figure 10-3, NetX Duo depends on a network driver to carry out different functions (these include Ethernet hardware and physical link initialization, packet transmission, packet reception, status and control of the Ethernet interface, etc.). The Alif Semiconductor's NetX Duo network driver interacts with the Ethernet MAC and PHY hardware components to service different requests generated by NetX Duo. Apart from handling various requests generated by NetX Duo, the network driver is also responsible for detection and handling asynchronous events that happen in the physical media. These include packet reception, packet transmission complete events and link status/mode changes, etc. The Alif Semiconductor network driver supports the following performance-centric features:

• Zero-copy transmission and reception: The driver avoids copying the packet data between the buffers used by NetX Duo and the buffers used by the Ethernet DMA hardware. This saves CPU cycles and improves performance considerably.
• Scatter/Gather packet buffers: The driver is capable of programming the Ethernet DMA hardware to assemble packet payload from multiple discontinuous memory regions in both the TX and RX paths. This enables the application developers to choose and configure the packet sizes in the NetX Duo packet pools as per their need and without worrying about the MTU of the physical media and the size of the received packets. Note that this feature depends on the NetX Duo packet chaining support.

For more details on NetX Duo APIs and usage, refer to the NetX Duo documentation.

10.2.3 FileX

Azure RTOS FileX is file management system for embedded application. Azure RTOS FileX supports most physical media, including RAM disk, USB, SD card. Azure RTOS FileX supports all of Microsoft’s file formats, including FAT12, FAT16, FAT32, and exFAT.

Various services provided by FileX and interaction with other components are shown in Figure 10-4.

Figure 10-4 FileX Services

For more information about FileX and its services, refer to the FileX User Guide.

10.2.4 GUIX

Azure RTOS GUIX is used for GUI implementation on embedded boards. GUIX is GUI software which can be used for real-time applications. GUIX is an event driven framework and works on events pushed into the GUIX event queue. These events are processed in GUIX thread (same as ThreadX thread).

Input drivers such as touch screen would require additional GUIX threads. The touch input driver sends touch information into the GUIX thread by sending events into the GUIX event queue.

The framework does require hardware-specific input drivers and hardware-specific graphics drivers.

Figure 10-5 shows the Azure RTOS GUIX interaction with different system components.

Figure 10-5 GUIX

10.2.4.1 Azure RTOS GUIX Studio

Azure RTOS GUIX Studio is UI development environment for the GUIX runtime library. It can be run on Windows Host machine to design display screens for a project. With GUIX Studio, WYSIWYG screen can be designed for GUIX runtime environment. GUIX Studio generates C code that contains all the necessary UI information and code.

10.2.4.1.1 GUIX Studio Requirements

Minimum requirements for GUIX Studio:

• Windows XP (or above)
• 200MB of free RAM
• 2GB of available hard-disk space
• Display of 1024p × 768p with 256 colors

10.2.4.1.2 GUIX Studio Constraints

The GUIX Studio UI design tool has several constraints, as follows:

• A maximum of 4 displays per project
• A maximum of 100,000 widgets per GUIX Studio project
• A maximum of 100,000 distinct resources, for example colors, fonts, pixelmaps, strings, etc.

For more details about GUIX studio, refer to the GUIX User Guide.

10.2.5 USBX

USBX is a high-performance USB stack designed for resource constraint real-time embedded environment. USBX provides support for both Host and Device which includes device-class support such as mass storage, CDC-ACM, CDC-ECM, registration of different callbacks related to class defined in application, and host requests related to setup and configuration. USBX supports Open Host Controller Interface (OHCI) and Enhanced Host Controller Interface (EHCI).

10.2.5.1 USBX Stack Layout

USBX Stack comprises of three major components: Application, USBX Stack, and Dual-Role controller driver as shown in Figure 10-6.

Figure 10-6 USBX

• Application: Initialization routines for memory, resource, and USB device-class are part of the application. Callbacks related to device class registers in application. Application utilizes device framework and pass it on USBX Stack. Device framework is divided in the following three categories:
  • Descriptors: Device, Configuration, Interface and Endpoint descriptors. These descriptors hold device specific information such as class, configurations, interface, and endpoints supported by the device.
  • String: String descriptor. This descriptor holds the manufacturer, product and serial number of the USB device.
  • Language: Language descriptor holds language supported by the device.

• USBX Stack: USBX Stack is responsible for USB Host and Device-class implementation, memory resourcing, stack initialization, callbacks, data transfer routines, descriptor parsing, buffer management and returning data transfer requests to controller driver. This layer interacts with application, as well as controller driver. The requests made by USB Host such as GET_DESCRIPTOR, GET_CONFIGURATION, SET_CONFIGURATION, SET_ADDRESS for device information and configuration is parsed, data stored in buffer and finally passed by USBX Stack to driver layer for further processing like DMA transactions.

• Dual-Role controller driver: Driver handles the access to hardware registers, endpoint configurations, interrupt handling, DMA transfers and FIFO maintenance. Setup/Data requests by USB host to slave device are handled by driver. Depending upon type of interrupt (type of request) driver takes decision and interacts with framework. In response framework provides data to driver and driver initiates DMA transactions. Following are few events and interrupts handled by the controller driver:
  • XferNotReady
  • XferComplete
  • XferDataStage
  • XferStatusStage.

10.2.5.2 USBX Support for Ensemble DevKit

Figure 10-7 shows a simplified diagram of the USBX.

Figure 10-7 USBX Description

Alif Semiconductor DevKit USBX provides support for:

• CDC-ACM device class, which handles communication class requests on interface 0 using Control/Interrupt Endpoint and CDC-ACM data requests on interface 1 using bulk endpoint.
• CDC-ACM class initialization, memory resourcing, device framework parsing and availing data buffer to driver.
• TRB creation, DMA transaction initiation, Device and Endpoint interrupt handling.

10.2.5.3 USBX Working in Device/Host Mode

In Device mode, USB class registration and stack initialization routines followed by device controller initialization routine are called. Device controller is ready to accept interrupts (SETUP from Host) after configurations related to endpoints and device specific registers. Controller driver gets request from Host and it passes the request to USBX Stack. USBX Stack parses the information and return back data to driver. Driver initiates DMA transaction on specific endpoint.

In Host mode, Setup packets are created by Host and sent on Control Endpoint 0 OUT/IN once the device controller is ready to accept Setup. Host continues with more requests and enumerates the device if all the information is passed correctly (see Figure 10-8).

Figure 10-8 USBX Flow Diagram