Bring-up
- Clock, power and memory initialization
- Debug console and JTAG or SWD access
- Pin multiplexing checked against the schematic
- First boot on the real board
Embedded Software Development
Embedded software development
The device works on the bench, but it has to boot only trusted code, survive a failed update and pass review against a written coding standard. Agnotic Technologies builds the software that runs on the device: the platform choice, board support, drivers, bootloader and secure boot, written to MISRA C or SEI CERT C.
Bare metal, RTOS or LinuxBoard support and driversSecure bootMISRA C and CERT C
Trusted by global innovators
On-device software
What is embedded software development?
Embedded software development is the work of writing the code that runs on a device's own processor: startup code, drivers, an RTOS or embedded Linux image, the bootloader and the application. Agnotic Technologies builds this on-device software for device makers, working with your hardware team from board bring-up to the production image.
This page is about software on the device. The cloud, fleet console, device identity and over-the-air update service are covered on our IoT development page, and FDA premarket cybersecurity documents on our medical device cybersecurity page.
We do not design circuit boards or enclosures. We work from your schematics and datasheets, and with your hardware engineers when a board needs a change.
Decision table
Bare metal, RTOS or embedded Linux: which does your device need?
The platform decision sets the processor, the boot chain, the update method and the team skills for the life of the product. We make it with you before any code is written.
| Criterion | Bare metal | RTOS (Zephyr, FreeRTOS) | Embedded Linux (Yocto Project, Buildroot) |
|---|---|---|---|
| Typical processor | Small microcontroller | Microcontroller with more peripherals and connectivity | Application processor with a memory management unit |
| How work is scheduled | One main loop plus interrupts | Threads with fixed priorities and predictable timing | Processes and threads; hard real-time needs extra work |
| Memory | Small, statically allocated | Small to moderate, mostly static | Enough for a kernel, file system and several processes |
| Connectivity and interface | Minimal, written for the job | Network and Bluetooth stacks from the RTOS | Full network stack, file systems and graphical interfaces such as Qt |
| Boot and update | Simple bootloader with one image | Bootloader with two image slots, such as MCUboot | U-Boot with A and B root file systems and an update agent |
| Choose it when | The device does one job and power and cost come first | Timing guarantees and connectivity are both needed | The product needs a rich interface, complex networking or Linux software |
Many products use two: an application processor running Linux for the interface and networking, and a microcontroller running an RTOS for time-critical control.
Board support
What does board bring-up and board support include?
The code that makes a new board usable, before any product feature runs.
Drivers
- SPI, I2C, UART, CAN and USB
- Displays, touch controllers and sensors
- Radios for Wi-Fi, Bluetooth LE and cellular
- Low-power modes and wake sources
Linux board support
- Device tree for the board
- Kernel configuration and patches
- Yocto Project layer or Buildroot configuration
- Reproducible image builds in CI
Production
- Manufacturing test firmware
- Hooks for per-device provisioning
- Signed release images
- Debug access locked in production builds
Secure boot
How does a secure boot chain protect the device?
Each stage checks the signature of the next before running it, so the device only runs code you signed. If an update fails, it recovers to a known good image.
Root of trust
- Immutable boot ROM in the processor
- Public key hash stored in one-time programmable fuses
- Verifies the first bootloader stage
- Debug ports closed by fuse in production
Bootloader
- Verifies the signature of the next image
- Two image slots, active and fallback
- Anti-rollback version counter
- Falls back if the new image does not confirm
Kernel or RTOS
- Signed kernel and device tree, or a signed RTOS image
- Verified read-only root file system on Linux
- Memory protection between tasks or processes
- Watchdog started early
Application and updates
- Signed application and update packages
- Health check after each update
- Image confirmed only when checks pass
- Signing keys kept off developer machines
Coding standards
How do MISRA C and SEI CERT C apply to your code?
A coding standard is only useful when it is checked on every build and its exceptions are written down.
01
MISRA C
Example: Safety-related or long-lived C code in medical, industrial, automotive and rail products
Approach: We agree the MISRA C edition and a compliance plan, run a checker in CI and record each deviation with its reason and the person who approved it.
02
SEI CERT C
Example: Code that parses input from a network, radio, USB or file
Approach: We apply the rules for integers, arrays, strings and memory management first, and track every finding as a defect until it is fixed.
03
Static analysis
Example: Every merge request on the firmware repository
Approach: Compiler warnings are errors and static analysis runs on each change. New findings block the merge until they are fixed or justified.
04
Review evidence
Example: Products that go through customer audits or regulatory review
Approach: Checker reports, deviation records and review notes are kept with each release, so your quality team can show how the code was checked.
Failure points
Why do devices fail in the field?
Problems that are cheap to design out and expensive to fix after shipping.
Challenge
A power cut during an update leaves the device unable to boot.
Agnotic approach
Two image slots and a bootloader that falls back to the last confirmed image if the new one does not start.
Challenge
A task hangs and the device stops responding until someone unplugs it.
Agnotic approach
A hardware watchdog fed only when every critical task reports healthy, with the reset reason logged.
Challenge
An RTOS task overflows its stack and corrupts memory at random.
Agnotic approach
Stack use is measured under load, stacks are sized with margin, and memory protection guards each stack where the processor supports it.
Challenge
JTAG or a debug console is left open on shipped units.
Agnotic approach
Production builds disable debug output, and debug ports are locked as part of the factory process.
Challenge
Firmware signing keys sit on a developer laptop.
Agnotic approach
Release images are signed by a controlled signing service, and development keys never work on production devices.
Challenge
Logging wears out flash memory over the product's life.
Agnotic approach
Log volume and write patterns are planned against the flash part's endurance, with wear leveling where needed.
Who it is for
Who builds embedded software with us?
Device makers who own the hardware and need the on-device software built and kept current.
Medical and wellness device makers
Wearables, monitors and home-use devices whose firmware must support the maker's design controls and security documentation.
Industrial equipment makers
Controllers, gateways and sensors that run unattended for years on site.
Connected consumer products
Products where the device firmware, the companion app and the cloud must agree on every update.
Lab and instrument makers
Instruments with an embedded Linux interface and a microcontroller handling timing and motion.
Embedded software for startups
Hardware founders who need the platform choice, boot chain and coding rules right before the first production run.
Scope and cost
What drives the cost of embedded software development?
We do not publish prices. These are the factors we size an embedded project from on the scoping call.
Board maturity
Whether the hardware is a development kit, a first prototype or a production board with known errata.
Platform choice
Bare metal, an RTOS or embedded Linux, and whether the product uses more than one processor.
Drivers and peripherals
How many peripherals need new drivers rather than vendor or RTOS drivers.
Security features
Secure boot, encrypted storage, signed updates and the factory steps they need.
Coding standard and evidence
MISRA C or SEI CERT C compliance work and the records your quality team needs.
Regulated products
Extra documentation and test records when the device falls under medical or safety rules.
Engagement
How does an embedded engagement work?
From a board on the bench to a signed production image.
1.
Scoping and hardware review
We review schematics, datasheets and requirements, and agree the platform and the first release.
Scope2.
Bring-up and platform
Board support, drivers, the boot chain and the CI build come first, on real hardware.
Bring-up3.
Fixed-scope first release
The agreed features run on the device, with static analysis reports and test records for the release.
Build4.
Production and sustaining
Factory support, field updates and fixes as components and threats change.
SustainStandards
Standards our embedded work follows
Coding standards, firmware security guidance and the platforms we build on.
MISRA CSEI CERT CNIST SP 800-193ZephyrYocto Project
Facts and sources
Facts behind embedded software development
The coding standards, firmware security guidance and platform documentation this page relies on, each linked to its source.
MISRA C:2025 was published in March 2025 as an incremental update that supports the C11 and C18 versions of the language, and MISRA C is used across sectors including rail, aerospace, military and medical.
Source: MISRA C (MISRA)The SEI CERT C Coding Standard organizes its secure coding rules by area, including the preprocessor, integers, arrays, characters and strings, memory management, error handling and concurrency.
Source: SEI CERT C Coding Standard, Software Engineering Institute, Carnegie Mellon UniversityThe Zephyr OS is based on a small-footprint kernel designed for resource-constrained and embedded systems, and supports architectures including Arm Cortex-M, Cortex-A and Cortex-R, RISC-V and x86.
Source: Introduction, Zephyr Project documentation (Linux Foundation)The Yocto Project is not an embedded Linux distribution: it is an open source project with tools that help developers create a custom Linux-based system for their device, regardless of the hardware architecture.
Source: The Yocto Project (Linux Foundation)NIST SP 800-193 sets out platform firmware resiliency as three kinds of security mechanism: protecting firmware against unauthorized changes, detecting unauthorized changes that occur, and recovering rapidly and securely from attacks.
Source: NIST SP 800-193, Platform Firmware Resiliency Guidelines (NIST CSRC)
Frequently Asked Questions
We do not publish a price. Cost follows the board's maturity, the platform, the number of new drivers, the security features, any coding standard evidence and whether the device is regulated. You get a written proposal after the scoping call.
An RTOS suits microcontrollers that need predictable timing, low power and modest connectivity. Embedded Linux suits application processors that need a rich interface, complex networking or existing Linux software. Many products use both on two processors, and we help you decide during scoping.
No. We do not design circuit boards or enclosures. We write the software for your board, work from your schematics and datasheets, and give your hardware team clear findings when bring-up shows a board problem.
Yes. We agree the edition and a compliance plan with you, check the code with a MISRA checker in CI and record every deviation with its reason. Whether the result meets your product's requirements is assessed by your quality team or assessor.
Production signing keys never sit on developer machines. Release images are signed through a controlled signing service, development builds use separate keys that production devices reject, and the factory process locks the boot configuration.
Yes. We start by building it reproducibly, running static analysis and reviewing the boot and update path, then fix the highest risk issues before adding features.
Yes, as a separate scope. Device identity, MQTT messaging, the fleet console and the over-the-air update service are covered by our IoT development work, and the firmware is built to match them.