This Technical Note (TN for short) illustrates the concept behind a custom product developed by DAVE Embedded Systems for a customer operating in the professional lighting market. This project is a useful use case for showing some interesting technologies that can address effectively common requirements in the world of embedded systems for industrial applications.

[[File:DMX-RDM-controller-bd.png|center|thumb|885x885px]] Basically, the product is a dual-role device: it can operate either as a '''controller''' or as a '''recorder'''.  When working as a controller, it feeds slave devices (stage lighting dimmers, special effects machines, etc.) with DMX streams. DMX data can be generated programmatically on the fly or can be retrieved from previously recorded streams.  When working as a recorder, the product "sniffs" and stores DMX data traffic traveling on the connected buses. Each DMX frame is stored onto a permanent storage device — an e.MMC or a microSD card, for instance — with an '''associated timestamp'''. Thus, the data streams can be played at a later time with the '''same timings of the original ones'''.  As shownin the block diagram, the product features a rich set of I/O's ranging from the [https://en.wikipedia.org/wiki/DMX512 DMX/RDM] channels to network interfaces. With regard to the network Graphical User Interface, two displays are supported: an HDMI monitor and a local LVDS display. It is worth remembering that they can work simultaneously, for example in mirror mode. The core of the system is the [[ORCA SOM|Orca SoM]], which in turn is built around the [https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS i.MX8M Plus] system-on-chip by NXP. == Heterogeneous asymmetric multiprocessing ==From the computational standpoint, there are two domains running '''two different operating systems'''. In this regard, the resulting architecture is an example of [https://en.wikipedia.org/wiki/Heterogeneous_computing heterogeneous] [https://en.wikipedia.org/wiki/Asymmetric_multiprocessing asymmetric multiprocessing] as it is based on different types of cores, namely the ARM Cortex-A53 and the ARM Cortex-M7. The system architect chose this implementation because it is convenient to satisfy the diversified product's requirements. In particular, the DMX/RDM subsystem must meet '''real-time requirements''' in order to be compliant with the DMX/RDM standards. The DMX/RDM subsystem consists of an ARM Cortex-M7 core working in tandem with an FPGA. The M7 and the FPGA are connected with an I²S bus. Even though this bus is conceived for digital audio streams, it fits very well for conveying the data to/from the DMX/RDM channels. The A53-centred domain runs a Yocto Linux distribution. The product's main application is executed in this domain. In particular, this application integrates the business logic and implements the GUI. Also, it deals with all the peripherals and interfacesnot having real-time constraints such as the temperature sensor, the gyroscope, the Ethernet ports, etc. The Linux domain is widely scalable in terms of computational power as multiple versions of the SoC are available featuring a different number of A53 cores (1, 2, or 4). These versions are ballout compatible, thus '''the same hardware platform fits them all'''.  == Real-timeness ==As stated previously, the ARM Cortex-M7 core and the FPGA are the building blocks of the DMX/RDM domain.

A real-time operating system (FreeRTOS) runs on the M7 core. The core application executed on top of the systems is RTOS communicates with the [[ORCA SOM|Orca SoM]]Linux domain through RPMsg-Lite, which in turn is built around a ''lightweight implementation of the Remote Processor Messaging (RPMsg) protocol'' according to [https://www.nxpgithub.com/productsNXPmicro/processorsrpmsg-lite NXP documentation]. Basically, the M7 acts as a bridge between the Linux domain and the FPGA, which is responsible for transmitting and-microcontrollersreceiving the DMX/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS i.MX8M Plus] system-RDM frames on-chip by NXPthe buses at physical level.

== Heterogeneous asymmetric multi-processing ==From the computational standpoint, there are two domains running two different operating systems. In this regarda logical point of view, the resulting architecture is an example of heterogeneous asymmetric multi-processing whole transmitting/receiving chain looks like as it is based on different types of cores, namely the ARM Cortex-A53 and shown in the ARM Cortex-M7following picture.

The system architect chose this implementation because it is convenient to satisfy the diversified product's requirements. In particular, the [[File:DMX/RDM subsystem must meet real-time requirements in order to be compliant with the DMX/RDM standards. The DMX/RDM subsystem consists of the ARM Cortex-M7 core working in tandem with an FPGAstack. On the M7 core, a real-time operating system (FreeRTOS) runs. The application executed on top of the RTOS communicates with the Linux domain through RPMsg-Lite, a "lightweight implementation of the Remote Processor Messaging (RPMsg) protocol" according to [https://github.com/NXPmicro/rpmsg-lite NXP documentationpng|center|thumb|450x450px]]. On the other side, the M7 core is connected to an FPGA through an I2S bus. Even though this bus is conceived for digital audio streams, it fits very well for conveying the data to/from the DMX/RDM channels.

Such requirements would be hard == IoT and security ==The product is an example of edge computing platform as well. It connects to fulfill the customer's cloud to upload data retrieved on the field and to manage OTA software updates. In order to use secure connections, the product is equipped with two secure elements: * NXP EdgeLock SE050 * Microchip ATECC608A. The first one is part of the [[ORCA SOM|Orca SoM]], while the second is optionally populated at the carrier board level. These components allow to implement several schemes to address security-related issues. From the software perspective, they are supported by the LinuxBSP so that the user space applications can access them through high-only implementationlevel API's. The Linux BSP is derived from the release L5.4.70 by NXP.