Why embedded?
Embedded systems are everywhere — from industrial controllers via medical devices and smart energy meters to IoT gateways in the field. Industry 4.0, smart metering, eHealth and connected mobility keep raising the demands on reliability, security and longevity.
Unlike pure software projects, embedded work demands a parallel grasp of hardware, operating system, network stack and application logic. Real-time requirements, energy budgets, tight memory and security and functional-safety standards (BSI IT-Grundschutz, IEC 62443, IEC 61508, ISO 26262) shape development from day one.
We accompany projects across the full lifecycle: requirements analysis, risk assessment, hardware and platform selection, BSP and kernel work, driver development, field-update concepts and preparation for industry-specific certifications.
Determinism
Direct hardware control, guaranteed response times, predictable behaviour — decisive for control and safety applications.
Lifecycle
Embedded devices often run 10–20 years in the field. Maintainability, updateability and long-term component availability are central.
Economics
BOM cost and energy demand feed straight into the business case — hardware choice is a commercial decision.
Standards
BSI, IEC 62443, IEC 61508, ISO 26262, FDA — mandatory in many sectors, with implications for architecture, processes and documentation.
Hardware platforms
We know the common hardware families from real project experience and pick — or assess — the right platform against concrete requirements on performance, energy, interfaces and lead time.
Application processors (Linux)
ARM Cortex-A · x86 embedded · RISC-VHigher-end SoCs for IoT gateways, industrial controllers, media and HMI devices. Representatives include NXP i.MX, Rockchip, Allwinner, NXP Layerscape and Raspberry Pi Compute Modules. RISC-V (e.g. Allwinner D1, SiFive) is increasingly an open alternative.
Typical use
Linux-based devices with displays or complex network/application stacks; edge-compute nodes; platforms requiring a Yocto- or Buildroot-based software stack.
Microcontrollers (bare-metal / RTOS)
ARM Cortex-M · ESP32 · Nordic NRFEnergy-efficient microcontrollers for sensor-near control, wireless nodes and battery-powered devices. In use: STM32, NXP Kinetis, ESP32, Nordic NRF — typically with FreeRTOS, Zephyr or directly bare-metal.
Typical use
Sensors, actuators, wireless nodes (BLE, LoRa, Zigbee), battery-powered devices with multi-year lifetime; real-time requirements under ten microseconds.
FPGAs and SoCs with hardware logic
Xilinx Zynq · Intel CycloneWhen parallel data processing, deterministic latencies or configurable hardware logic are needed, FPGAs come into play — typically as hybrid SoCs with an ARM core and programmable logic on the same die (Xilinx Zynq, Intel Cyclone).
Typical use
Image processing, high-speed interfaces (industrial Ethernet, EtherCAT), signal processing, safety-critical control with hardware redundancy.
Focus areas
Four distinct workstreams that we run individually or in combination depending on the project.
System architecture and feasibility
The concept phase of an embedded project — informed decisions before money flows into hardware.
- Analysis and assessment of product requirements
- Risk assessments and feasibility studies
- Selection of hardware and platform against functional and commercial criteria
- Definition of a Linux- or RTOS-based system architecture
- Assessment of open-source components — licence, community, long-term maintenance
- Update and maintenance strategies for field operation
BSP, drivers and kernel
Bring-up of new hardware and adaptation of the software platform to specific devices.
- Development and maintenance of Board Support Packages
- Linux kernel adaptations, device-tree maintenance, kernel patches
- Driver development in kernel and user space
- Bootloader adaptations (U-Boot, Barebox)
- Build automation with Yocto, Buildroot or OpenEmbedded
- Continuous integration for firmware pipelines
Reverse engineering of hardware
Analysis, revival and migration of existing or undocumented hardware components.
- Analysis of undocumented or obsolete hardware platforms
- Reconstruction of proprietary protocols (UART, SPI, I²C, CAN, vendor-specific buses)
- Building new drivers for legacy devices without vendor support
- Migration from end-of-life platforms to modern, long-term available alternatives
- Lab setup with logic analyser, oscilloscope and JTAG/SWD debugger
Security, safety and certification
Hardening, functional safety and preparation for industry-specific approvals.
- Secure boot, signed updates, encrypted data storage
- Hardening of Linux distributions — BSI IT-Grundschutz, IEC 62443
- Functional safety per IEC 61508 or ISO 26262
- Preparation for certifications — PTB (metrology), BSI (critical infrastructure), FDA (medical)
- Support for CE declarations of conformity and the corresponding technical documentation
Experience and AI-augmented development
In the Tenvias core team and at our development partners, embedded experience reaches back to the early 2000s — from bare-metal programming in assembly and C through classic 8/16-bit microcontrollers, the rise of embedded Linux and ARM Cortex architectures to today's IoT platforms with Yocto, Zephyr and container-based edge computing.
That depth shows where things get uncomfortable: undocumented hardware, missing data sheets, bring-up on a fresh PCB, bus problems only visible on the oscilloscope. Functional safety and IT security hardening also need experience beyond tutorials — we help to set up architecture and processes so the eventual certification actually goes through.
We apply AI-augmented development tooling in embedded projects too — particularly where tasks are standardised: driver boilerplate, test and mock generation, migrations between kernel versions or Yocto layers, generating interface stubs from data sheets. In those areas we see speed gains of 30 to 50 percent.
Hardware bring-up, reverse engineering and lab work, however, remain human-driven — AI replaces neither the logic analyser nor the experience of recognising when a pull-up resistor is missing. Responsibility for architecture, security and certification readiness stays with the engineer; AI-generated code goes through code reviews, tests and the CI pipeline like any handwritten code.
