Embedded Firmware Built for Production
C/C++ firmware from board bring-up to production release. Driver development, hardware abstraction, and protocol integration across 8 chip vendors for EV chargers, gateways, and industrial systems.
Embedded Engineering Deliverables
Embedded Project Scenarios
Four common starting points. Each follows the same engineering process: requirements, architecture, TDD, integration, production release.
Built for Firmware That Has To Work in Production
Clemios firmware development uses Ceedling TDD and MISRA C as default engineering practices. The goal is firmware that is verifiable at each stage, portable across vendors, and maintainable over the hardware lifecycle.
Test-Driven Development for Embedded C
Ceedling is the core unit testing framework for embedded C projects at Clemios. Every firmware module is developed using TDD: write the test first, then write the code that passes it. This catches defects at the earliest possible stage and produces firmware that is inherently testable.
MISRA C Compliance
All Clemios firmware projects follow MISRA C coding standards. MISRA C eliminates undefined behaviour, improves portability, and enforces disciplined coding practices required by safety-critical and automotive-grade embedded systems.
Hardware Validation and Integration Boundaries
Firmware is validated on target hardware before release. Integration boundaries between embedded firmware and backend systems (CSMS, cloud, MQTT brokers) are defined early and tested at each interface. Production test discipline includes on-device regression, protocol conformance checks, and field-deployment verification.
8 Chip Vendors Supported
| Vendor | Platforms / Families |
|---|---|
| ESP32 | ESP-IDF, WiFi/BLE-enabled embedded applications |
| Infineon | AURIX, PSoC, XMC series |
| Microchip | PIC, SAM, dsPIC families |
| NXP | i.MX, LPC, Kinetis |
| Renesas | RA, RX, RL78 families |
| STMicroelectronics | STM32 (F, G, H, L series), STM8 |
| Texas Instruments | MSP430, Tiva C, CC series |
| Hilscher | netX 90 (industrial communication) |
Engineering Tooling Stack
| Category | Tools |
|---|---|
| Languages | C, C++, Python |
| Operating Systems | FreeRTOS, Linux (Yocto, Buildroot), Bare Metal |
| Coding Standards | MISRA C |
| Unit Testing | Ceedling (core differentiator), GoogleTest |
| Static Analysis | Linters, SonarQube, CodeRabbit |
| Hardware Design | Altium Designer, Fusion 360 |
| Debugging | Segger J-Link, Saleae Logic Analyzer, STLink V2, PCAN USB |
| Version Control | GitHub, GitLab, Azure DevOps, SVN |
| Documentation | Doxygen |
| Interfaces | Ethernet, WiFi, Bluetooth Low Energy, USB |
| Protocols | OCPP (EV charging, actively implemented), MQTT, SPI, QSPI, I2C, CAN, UART, LIN, TCP/IP, Cellular, Modbus TCP/RTU |
Delivered Across Industries
All projects listed are NDA-protected. Client names withheld by policy.
Frequently Asked Questions
Clemios supports 8 chip vendors: ESP32, Infineon, Microchip, NXP, Renesas, STMicroelectronics, Texas Instruments, and Hilscher netX 90. Coverage includes bare metal, FreeRTOS, and embedded Linux targets.
Clemios provides hardware-adjacent engineering including PCB design using Altium Designer and Fusion 360, plus hardware abstraction layers and board support packages. The focus is firmware that runs on custom hardware. Hardware manufacturing itself is not in scope.
Ceedling is a test-driven development framework for embedded C. It enables unit testing of firmware modules before they run on hardware. Clemios uses Ceedling on every firmware project as a core engineering practice, testing each module before integration.
Yes. All firmware projects follow MISRA C coding standards. This ensures safety, portability, and compliance with automotive and industrial requirements.
Yes. Clemios regularly integrates into existing firmware projects for refactoring, protocol additions, driver development, and test coverage improvement. Engineers adapt to the existing toolchain, version control, and coding standards.
OCPP 2.0.1 is the actively implemented charger-to-backend protocol for EV charging projects. It serves as the primary proof point for protocol-level firmware integration.
MQTT, Modbus TCP and RTU, CAN, SPI, I2C, UART, LIN, and TCP/IP cover the broader industrial and embedded integration scope. Connectivity layers include Ethernet, WiFi, BLE, and Cellular. Protocol selection depends on the target hardware, system architecture, and connectivity requirements.
Need Embedded Software Engineers?
From bare metal C to Linux application layers, from Ceedling TDD to MISRA C compliance: Clemios embedded engineers build firmware that works in production.