This blog post comprehensively introduces the OpenEPT system, comprising an Acquisition device unit and a host machine unit connected through Ethernet communication. The meticulously designed Acquisition device firmware prioritizes high ADC hardware sampling rates, minimal processing latency, and effective handling of streaming and control messages. The firmware architecture, organized into layers and leveraging FreeRTOS, promotes modularity and efficiency. Transitioning to the GUI application, developed with the QT framework, it serves to visualize and process streaming messages, provide insights into the Acquisition device's status, and allow control. The dual deployment of the GUI application, both as a standalone solution and an EEZ Studio plugin, exemplifies flexibility. The blog aims to offer transparency in tracking system development, acknowledging potential minor adjustments to functionalities during the ongoing project

Overall system working principle

The OpenEPT is comprised of two different processing units: the Acquisition device unit and the host machine Unit. The acquisition device will be implemented on the STM32H755ZI microcontroller platform while the host platform presents any regular PC machine. These units will be connected through an Ethernet communication interface through which will establish several parallel communication interfaces based on TCP and UDP communication. Through these interfaces will be exchanged two message types: stream messages and control messages. Stream messages will encapsulate data sampled from the ADC while control messages should be used to exchange control and status messages between processing units. The overall system functionalities are presented on following figure:System working principle

Acquisition device firmware

The firmware for the Acquisition device unit needs to be crafted to maintain the highest possible ADC hardware sampling rate and introduce minimal processing latency during active data streaming. Functionally, it should be adept at fetching data samples from the ADC, bundling them into a streaming message, and firing them off via UDP to the host machine. Considering UDP's speed advantage over TCP, it's advisable to add a simple header above the ADC samples to enhance reliability. This header facilitates the host side in detecting any packet losses. In addition to handling streaming data, the Acquisition device firmware should be capable to manage and respond to control and status messages. For smooth handling of parallel processing requirements,the complete firmware should be based on RTOS. For our project we select FreeRTOS because it is up to date solution that provides best compromise between complexity and real time performances.

Architecture of the firmware that should be developed is presented on following figure:

Acquisition device firmware

The presented architecture comprises multiple layers, each composed of various functional blocks. The primary architecture layers include:

• Device drivers layer

• Platform drivers layer

• Third parties libraries layer

• Services layer

• Application layer

The standard STM32H7 device HAL drivers are wrapped within the device driver layer.

The introduction of the platform drivers layer ensures that the STM32H7 device driver is thread-safe. From a higher perspective, the drivers within this layer act as wrappers around standard device drivers, enhancing the portability of our solution across various platforms.

Platform driver layer and higher software layers utilize different mechanism from third parties libraries such as FreeRTOS and LWIP library. FreeRTOS library

Within the Middleware layer, we have implemented a collection of unique functionalities, carefully divided into individual RTOS tasks. These tasks are designed to harness the capabilities of specific lower software layers, creating a well-organized structure that enhances the modularity and efficiency of our system architecture. This approach not only promotes clarity and maintainability but also allows for seamless integration and scaling of functionalities within the overall system framework.

The Application layer serves as the embodiment of the main firmware logic, taking on the responsibility of initializing all lower layers and initiating the RTOS scheduler. This layer acts as the orchestrator, setting the stage for the seamless interaction and collaboration of the various components within the system. By encapsulating the core functionality, it establishes a cohesive framework that ensures the proper execution and synchronization of tasks throughout the entire system.

GUI application architecture

The role of the host application is to:

• to facilitate the storage, visualization and processing of incoming streaming messages

• to offer insights into the execution status of the Acquisition device, while also providing control capabilities for the Acquisition device.

• to be compatible with Linux and Windows OS

To optimally meet these requirements, the host application is ideally designed as a GUI application which overall architecture is following:

GUI Application Architecture

Upon initiation and the establishment of a connection with the Acquisition device side, the host application initiates a handshaking process. This handshake is crucial for initializing the Acquisition device and configuring the corresponding GUI fields.

Once the connection is established and the handshaking completed, the host application is primed to process incoming streaming messages received over UDP. It dynamically handles and interprets these messages, allowing for the visualization and plotting of the received ADC sample values. This responsive and interactive GUI application thus plays a pivotal role in providing a user-friendly interface for monitoring, controlling, and gaining insights into the Acquisition device's operation.

The upcoming GUI application is slated for development with the robust QT framework, ensuring a sophisticated and user-friendly interface. This application is designed to serve users in two distinctive ways: firstly, as a standalone solution providing autonomous functionality, and secondly, as an integrated plugin seamlessly compatible with the EEZ Studio platform. This dual deployment approach offers users the flexibility to choose between the standalone version for independent use or the plugin version for a seamlessly integrated experience within the EEZ Studio environment. This versatility underscores our commitment to providing diverse options to cater to the unique preferences and requirements of our users.

Tracking the Dynamic Progress of OpenEPT System Development

We delve into the fundamental aspects of the overall system's functionality, as well as the architectures of both the firmware and GUI applications, constructed based on the previously published work "High Performance Software Architectures for Remote High-Speed Data Acquisition". The primary objective of these presented architectures is to facilitate the tracking of the entire system's development for interested users. While the project is in the development phase, minor adjustments to the showcased functionalities may occur. The overarching goal is to provide transparency and ease for users keen on following the project's progression, ensuring that any potential modifications to the presented functionalities during the development process are communicated effectively. Project code and documentation is available on official project repo