Properties Easy-to-use, low-cost, open-source solution that includes compatible hardware and software sets of tools. This comprehensive solution is designed to fulfill the need for firmware energy profiling, as well as State of Charge (SoC) and State of Health (SoH) algorithm evaluation for real LiPo battery-powered embedded devices.

Official youtube channel

ko-fi

• Features
• Building and Running the Energy Profiler Probe Firmware
• Contributor guide
• Documentation
• Acknowledgments

The OpenEPT Energy Profiler Probe (EPP) combines high-speed energy measurement, programmable load control, hardware protection, and device configuration in a single open-source platform.

Main features include:

• Real-time voltage, current, and energy-consumption streaming
• High-speed data acquisition up to 1 MSPS
• Programmable sampling period
• Programmable load generation and custom current waveform creation
• Programmable overcurrent, undervoltage, and overvoltage protection thresholds
• Hardware-based protection detection and latching
• Programmable current-sink control
• On-board non-volatile memory for persistent device configuration
• Dedicated interface for an external battery charger board
• Ethernet interface for measurement streaming and device control
• USB/UART interface for debugging and hardware bring-up
• Dedicated test points for analog and digital signal verification
• Visual indication of power rails, protection events, acquisition state, and system status
• Graphical User Interface for acquisition, visualization, statistics, calibration, and device configuration
• Fully open-source hardware and firmware

The main connectors, controls, indicators, and test interfaces available on the Energy Profiler Probe are shown below.

OpenEPT Energy Profiler Probe

The main external connections of the Energy Profiler Probe are listed below.

Several on-board LEDs provide direct visual feedback about the operating state of the Energy Profiler Probe and its protection circuitry.

The board provides several hardware-selection jumpers that are useful during normal operation, calibration, and testing. The default position for each jumper is indicated below.

To successfully build and run the EPP firmware, STM32CubeIDE must be installed and properly configured with the required dependencies. The following steps guide you through the full setup process.

The latest version of STM32CubeIDE should be downloaded from this link.

After downloading, install STM32CubeIDE on your machine by following the standard installation instructions provided by STMicroelectronics.

There are two main methods for downloading the project from the official GitHub repository:

• Method 1: Using a Git console, such as Git Bash, to clone the repository directly via the command line.
• Method 2: Navigate to the repository's GitHub page, click the green Code button, and select Download ZIP. This will download the project files as a compressed archive.

Download project as ZIP

1. Launch STM32CubeIDE and configure the workspace path.
2. Navigate to File → Open Projects from File System (1 and 2 on the figure bellow).

Import 1

When the Import Project from File System or Archive window opens, specify the directory where the project is located (in this case, Source/ADFirmware).
To do so, click the Directory button (1 in Figure bellow).

Import 2

After clicking Directory, the Browse for Folder window appears (see Figure bellow).
Navigate to the Source/ADFirmware directory, select it (1 in FIgure bellow), and click Select Folder (2 in FIgure bellow).

Browse

If the project is successfully detected, the window (Figure bellow) will update to show the discovered project (as in Figure bellow).
To finalize the import, click the Finish button (1 in Figure bellow).

Import 3

Once the project is imported, it will be visible in the Project Explorer panel (see Figure bellow).

Project Explorer

The PROJECT_PATH variable serves as a reference for many relative include paths in the project. Instead of hardcoding absolute paths, the source files and build configurations use this variable to dynamically resolve header and source file locations, improving portability and maintainability.

To define PROJECT_PATH:

1. Right-click on the project named ADFirmware_CM7 in the Project Explorer and select Properties.
2. Navigate to C/C++ Build → Build Variables (see Figure bellow).

Properties

3. Locate the variable PROJECT_PATH. Double-click it to open the Edit Existing Build Variable dialog (1 in Figure bellow).
4. Click Browse (step 1 in Figure bellow), navigate to the Source/ADFirmware directory, select it, and click OK.

Path

After clicking OK, return to the Properties window and click Apply and Close to finalize the change.

If the path is set correctly, the include paths under ADFirmware_CM7 → Includes will update automatically.
The folder icon will change from a transparent folder with a yellow warning triangle to a solid blue folder, indicating successful path resolution.

Once the project is fully configured:

1. In the Project Explorer, right-click on ADFirmware_CM7.
2. It is recommended to perform a Clean Project first to remove any previously generated files.
3. After cleaning, right-click again and select Build Project. This will compile the project using the defined settings and paths.

If the build is successful, the binary file ADFirmware_CM7.elf will appear under ADFirmware_CM7 → Binaries.

To run and start debugging:

1. Click on the bug icon in the toolbar (step 2 in Figure 5.11).
2. This will start the first debug session, allowing you to flash the firmware onto the target board and begin testing.

Debug

To start contributing, fork the main repository to your own GitHub account:

1. Navigate to the repository you want to contribute to.
2. Click the Fork button in the upper-right corner. (This is an example for OpenEPT/FEPLib repo.) Fork
3. This will create a copy of the repository under your GitHub account.

Once the repository is forked, clone it to your local machine:

# Replace <your-username> with your GitHub username
git clone https://github.com/<your-username>/<repository-name>.git
cd <repository-name>

Before making changes, create a new branch based on the type of contribution:

• For new features, name the branch feature/<name>.
• For bug fixes, name the branch bug/<name>.

To create a branch:

# Replace <branch-name> with your branch name
# Example for a feature: feature/apard32690_lib
# Example for a bug fix: bug/fix_esp12e_lib
git checkout -b <branch-name>

Make the necessary changes to your branch. Test thoroughly to ensure your contribution does not introduce new issues.

Before any changes, please read developer Documentation

Once your changes are ready, stage and commit them:

git add .
# Write a descriptive commit message
git commit -m "Description of the changes made"

Push the changes to your forked repository:

# Push the branch to your fork
git push origin <branch-name>

1. Navigate to your forked repository on GitHub.
2. Switch to the branch you just pushed.
3. Click the Compare & pull request button. PullRequest
4. Ensure the base repository is set to the main/master repository and the base branch is `main
5. Provide a descriptive title and detailed description for your pull request.
6. Add appropriate reviewers
7. Submit the pull request.

Once the pull request is submitted:

1. Wait for project maintainers to review your changes.
2. Address any feedback provided by making additional commits to your branch.
3. Once approved, the maintainers will merge your changes.

After your changes are merged, keep your fork updated with the main repository to avoid conflicts:

git remote add upstream https://github.com/<original-owner>/<repository-name>.git
git fetch upstream
git checkout main
git merge upstream/main

For detailed developer instructions and additional materials, please see the Documentation->Software under Materials on the offical project website.

NLNet