While we await the arrival of the complete OpenEPT hardware, we have an opportunity to enhance the existing OpenEPT firmware to support the EEZ DIB feature and ensure hardware compatibility with the EEZ DIB chassis. Although this task may initially appear straightforward, it involves three significant sub-tasks:

1. Enhancing the OpenEPT firmware to support EEZ DIB functionality via SPI.
2. Create GUI for OpenEPT in Envox EEZ Studio and modify PSU Modular firmware to recognize and interface with our custom board.
3. Integrate OpenEPT module inside EEZ DIB Chassis and verify functionalities

Upgrade OpenEPT Firmware to support communication with EEZDIB MCU

All functionalities related to EEZ DIB are encapsulated inside EEZ DIB Software service. Complete service is written inside eez_dib.c and eez_dib.h files located on following path:

Source/ADFirmware/CM7/Core/Middlewares/Services/EezDib.

Main EEZ DIB Service task, with relevant synchronization elements with other system services, is illustrated on Figure 1.

‍

The SStream service is responsible for acquiring voltage and current samples from the AnalogIN driver, processing them, and transmitting the data to the OpenEPT GUI application running on the host side. This service supports two acquisition modes: Active and Inactive. The current acquisition state of the SStream service is critical for the operation of the EEZ DIB service. To facilitate this interaction, the SStream service has been extended to support the registration of a callback function that is invoked whenever the acquisition state changes. During service initialization, performed within the System Task, the prvSYSTEM_AcquisitionStateChanged function is registered as the callback handler. This function, implemented in system.c notifies the EEZ DIB service whenever a change in the acquisition state occurs. Within the EEZ DIB service, this state recorded within the first bit of a service-specific variable named STATUS. This acquisition state information is crucial for the EEZ DIB service to determine the appropriate timing for initiating sample collection from the SSample service.

The EEZ DIB Service Task operates in three distinct states: Initialization, Service, and Error. During the Initialization state, all relevant peripherals (such as SPI Instance 2) and internal variables are set up. The Error state handles fault recovery mechanisms if an error occurs in any of the other states. The core functionality resides in the Service state, where the main task logic is executed. In this state, the task begins by reading the queue that stores incoming request messages from EEZ DIB MCU. Once a message is retrieved, it is processed, and the appropriate action is executed, and response is sent back to the EEZ DIB MCU.

Communication between the EEZ DIB Main MCU and the OpenEPT MCU is established over a full-duplex SPI interface. In this setup, the EEZ DIB side operates as the SPI master, while the OpenEPT side functions as the SPI slave. Messages exchanged between the two MCUs are limited to a maximum of 10 bytes and can be either in ASCII or binary format. There are two message types:

• Request - Sent from the EEZ DIB MCU to the OpenEPT MCU, in ASCII format, over the MOSI line.
• Response – Sent from the OpenEPT MCU back to the EEZ DIB MCU, in binary format, over the MISO line.

When a Request message is transmitted during an SPI transaction, it is received by the OpenEPT MCU using a dedicated SPI DMA channel. Upon reception, a corresponding callback is triggered. The message is then encapsulated into a request message structure and send to the queue on which EEZ DIB Service task is blocked. Writing to this queue will unblock task, and message processing will start. As processing results, binary response is prepared it will be transmitted during the next SPI frame.

As previously mentioned, request messages are sent from the EEZ DIB MCU to the OpenEPT MCU over the MOSI line in ASCII format. Each request consists of a command string followed by the \r character, which signifies the end of the message. The current version of the OpenEPT firmware supports a single request command: "GetVC\r". Upon receiving this command, OpenEPT responds by sending a binary-formatted message within the SPI frame. This response includes the following fields:

• Voltage (2 bytes)
• Current (2 bytes)
• STATUS variable (1 byte)
• End-of-Message (EOM) marker (2 bytes)

This binary response format is illustrated in the Figure 2.

Create GUI for OpenEPT by Envox EEZ Studio and modify PSU Modular firmware

After upgrading the OpenEPT firmware to enable communication with the EEZ DIB, two key steps remained to verify the functionality:

• Designing a graphical user interface in EEZ Studio to display voltage and current readings.
• Updating the PSU firmware to extract and transmit voltage and current samples received over SPI.

Designing a graphical user interface for OpenEPT in EEZ Studio

The GUI implementation was based on the source code of the modular-psu-firmware, available in the official Envox [2] GitHub repository [1], specifically the dev_1.7.6 branch. For our project, the initial reference was the GUI configuration for the DCM224 power card, which we duplicated and renamed to create the OPENEPT project. Since our focus was on the slot_max view, we streamlined this interface to include only the essential functionalities, namely, starting and stopping data acquisition, and displaying voltage and current values. The resulting GUI layout within EEZ Studio is shown in the Figure 3.

In the main EEZ studio project, the OpenEPT project was included, and build was run to update needed files for firmware GUI drawing update as shown in Figure 4.

Updating the PSU firmware to support OpenEPT module

Like the GUI development, the starting point for upgrading the portion of the modular-psu-firmware responsible for communicating with the OpenEPT module was the source code of the DCM224 firmware. We first created an OpenEPT subdirectory within the module’s directory, into which we copied the entire source code of the DCM224 module. From there, we began adapting the code to establish proper communication with our hardware. The directory containing the OpenEPT-specific source code, along with the corresponding GUI project, is shown in Figure 5.

Several modifications were made in the openept.cpp and openept.h files, including updates to variables such as moduleType, moduleName, moduleBrand, and latestModuleRevision to reflect the identity of the OpenEPT module. These changes are essential for proper initialization and recognition of the module within the system. Some of these modifications are illustrated in Figure 6.

One of the key modifications made in the openept.cpp file is the implementation of the tick function. This function is used periodically to poll the OpenEPT module for voltage and current data. The function’s behavior is determined by the STATUS byte received over SPI from the OpenEPT module. It follows two distinct execution paths:

• If the first bit of the STATUS byte is 0, it indicates that the acquisition on the OpenEPT module has not started. In this case, both voltage and current values are set to zero.
• If the first bit is 1, it signifies that acquisition is active. The raw voltage and current bytes are then scaled to their appropriate values and displayed on the front panel.

This logic ensures accurate and real-time representation of measurement data based on the acquisition state of the OpenEPT module.

Integration results

Due to the unavailability of a fully assembled Envox EEZ DIB chassis on Mouser at the time, we obtained individual components directly from the Envox team and manually assembled the chassis on-site by following this step-by-step assembly tutorial. This unplanned effort required additional time and extended the duration of the task. However, the successful assembly of the chassis proved valuable for conducting comprehensive testing and validation.

After everything is prepared and modules is mounted, it is necessary to ensure that the correct values are written to the module’s EEPROM. Since the EEPROM is connected to the main I2C bus, only the main MCU has write access—module MCUs cannot directly access it. To accomplish this, the pre-assembled EEZ DIB chassis must first be connected to EEZ Studio. The recommended values provided by Envox are then written to the EEPROM, specifically:

• Module ID: 901
• Revision: R3B3
• Firmware version: A5A5

These values, as illustrated in Figure 7, are essential for enabling proper GUI module configuration.

After the module is installed and programmed, it is recognized by EEZ DIB and front panel content is presented on Figure 8.

As shown in the figure, the module is successfully recognized, its name and corresponding revision number are displayed in the upper-left corner. When the touchscreen is tapped, the voltage and current values are displayed, as illustrated in the Figure 9.

Since the acquisition has not yet been started, the voltage reading remains at 0, and the current is below 20 mA. To display actual measurement values, acquisition must be initiated from the OpenEPT GUI application running on the host machine. Once the acquisition is started and the discharge current is set to 90 mA, the EEZ DIB chassis front panel appears as shown in the Figure 10.

‍