Product development · Firmware and embedded
Firmware and embedded software development for products
Conceptech develops firmware and embedded software for electronic products: drivers, RTOS, communications, bootloaders and automated tests, for a new board or for existing code. For startups and companies in Israel and abroad.
Remote collaboration with product teams abroad, in English, alongside our work in Israel
- For
- Product teams and startups that need new firmware, fixes to existing code or a project takeover
- You get
- Documented source code, a firmware image, automated tests and a description of how it's built
- First step
- A call with an engineer about your board, your microcontroller and what the firmware must do
What firmware is
What is firmware, and how is it different from software?
Firmware is the software that runs directly on the microcontroller inside a product. It drives the hardware: sensors, motors, communications and power, and it is updated far less often than ordinary software.
The difference from ordinary software is the environment. Firmware runs with no screen and no full operating system, or with a small real-time one, on limited memory and processing power. It often has to respond within a fixed time and keep running for years without a break. A firmware bug can stop a product in the field, so design, testing and a safe update process matter more than usual.
More complex products also have a processor running embedded Linux alongside the microcontroller. We work at both levels and decide with you what runs where.
Firmware is one part of our product development work. All hardware product development services
Scope
What do we develop?
These are the parts a product's firmware is built from. Sometimes we develop all of them, sometimes only what your team is missing.
Bare-metal and RTOS firmware
Code that runs directly on the microcontroller, or on FreeRTOS when several tasks must run in parallel with defined timing.
Output: Firmware architecture and task scheduling
Drivers and peripherals
Drivers for sensors, memories, motors, displays and converters, and a layer that separates the hardware from the rest of the code, so a part can be swapped.
Output: Documented drivers for every part on the board
Communications and protocols
CAN bus and FDCAN, RS-485, RS-232, Modbus and EtherCAT, including the message definitions, error handling and tools to test the link.
Output: Protocol implementation and a message specification
Bootloader and firmware updates
Loading a new version over the product's own interface, with an integrity check and a fallback to the previous version if the update fails.
Output: A bootloader and a documented update process
Power management
Sleep modes, wake-on-event and orderly shutdown of components, for products that run on a battery or within a power budget.
Output: Defined power modes and consumption measurements
Embedded and real-time Linux
When the product needs more than a microcontroller: software on a processor running embedded Linux, and the link between it and the controllers on the board.
Output: Services and drivers on embedded Linux
Wireless and OTA updates
Firmware for BLE and Wi-Fi, and over-the-air updates through a resilient bootloader: if an update fails, the product falls back to the previous version.
Output: Wireless comms and an over-the-air update process
User interface and actuation
Display GUIs with physical buttons and indicator LEDs, and control of DC motors, stepper motors and heating elements.
Output: Operator interface and actuation control in firmware
Testing
Testable firmware: automated tests and HIL
Firmware that is only tested by hand breaks quietly. So we build it to be tested automatically, on a PC and on the hardware, on every code change.
We test at three levels, depending on what the product needs:
- Unit tests that run on a PC, with no hardware, for logic, calculations and protocols
- Tests on the board itself, running the real firmware against its interfaces
- A HIL rig, where the real controller runs against a simulation of its environment, including fault injection
When the tests are connected to CI, every code change is built, flashed and tested, and the result goes back to the developer before merge.
HIL test benches for controllers and firmware
When the product moves to production, the same firmware is also tested at a test station, unit by unit. Automated test stations for production
Existing code
Firmware for a product that already exists
Not every project starts from scratch. Often there's a product in the field, code that has grown over the years, and a developer who is no longer on the team.
What we do with existing firmware:
- Code review: structure, risks, hardware dependencies and technical debt, with a findings report and prioritised recommendations
- Hard bug hunts: faults that only happen in the field, unexplained resets, timing and communication problems
- Taking over from a developer who left: we learn the code, document it, set up a build environment and carry on developing
- Porting to a new board or a replaced component, for example when a part goes end-of-life
We usually start by reviewing the code and the build environment, so we know where things stand before committing to changes.
When you need a firmware engineer working inside your team and tools: A hardware and firmware engineer for your project
From our projects
What does our firmware look like on a real project?
Electronic puzzles for escape rooms
A programmable cube with an IMU and LED lighting, solved by tilting it in the right order and directions.
Controllers and tools
Which controllers, tools and protocols do we work with?
These are the controllers, tools and protocols we actually work with. If your product uses something else, we check it on the first call.
Controllers and operating systems
- ARM
- AVR
- FreeRTOS
- Embedded Linux
- Real-time Linux
- STM32
- ESP32
- nRF
- Infineon
- Texas Instruments
- Microchip
- TriCore
Communications
- CAN bus
- FDCAN
- RS-485
- RS-232
- Modbus
- EtherCAT
- BLE
- Wi-Fi
- OTA
Languages, testing and safety
- C/C++
- Python
- HIL
- CI/CD
- MISRA C
- SIL
- ASIL
- FMECA
Firmware development: FAQ
Which microcontrollers do you work with?
We have experience with STM32, ESP32, nRF, Infineon, Texas Instruments and Microchip microcontrollers, and we work with any AVR- or ARM-based MCU, on FreeRTOS or embedded Linux. We also have experience with TriCore and with safety-certified MCUs.
On a new project we choose the controller for what the product needs: peripherals, power consumption, memory, long-term availability and the toolchain your team knows.
When the controller is already chosen or the board already exists, we work with what's there. If we see a problem with the choice, we say so at the start.
Who owns the source code?
Ownership of the source code, the build tools and the tests is agreed in the contract for each project, before work starts. We can work directly in your code repository, so the code stays with you throughout the project.
We sign an NDA on request when the project calls for it.
What documentation comes with the firmware?
Documentation that lets any other engineer pick up where we left off. Usually: an architecture document, build and flashing instructions, a description of the interfaces and messages, comments in the code where it isn't self-explanatory, and test results for every version.
We agree the level of documentation at the start of the project, based on what your team and your product's certification need.
Do you have safety-critical software experience?
Yes. When the product requires it, we follow MISRA C or SIL / ASIL guidelines and derive the design from an FMECA.
In earlier roles, our lead engineer did performance analysis for safety-critical automotive software and built automated HIL test pipelines in CI, and we develop firmware with the same discipline: written requirements, code review, automated tests and documentation.
If your product must meet a functional-safety standard, tell us on the first call. The process, the documentation and who signs it off are defined in the scope of work before we start.
Can we work with you remotely, from abroad?
Yes. Most firmware work suits remote collaboration: the code lives in a shared repository, the tests run in CI, and the boards are either shipped to us or stay with you with remote access to the test bench.
We work with companies and startups abroad as well as in Israel: remote collaboration, English-speaking engineering, and partnerships welcome.
What drives the cost of firmware development?
The scope of the firmware and the state it's in, so there's no single figure. You get a written proposal after a first call, and for existing code after we've reviewed it. The main cost drivers:
- The number of interfaces and protocols, and any real-time requirements
- RTOS or embedded Linux, a bootloader and updates
- Wireless links and OTA updates
- The scope of automated testing, and whether you need a HIL rig
- Safety, certification and documentation requirements
- The state of the existing code, if there is any
Tell us what the firmware must do, and we'll suggest a first step
Tell us about the board and the microcontroller, the interfaces and the state of the code today, if there is any. A short product description is enough to start. We work remotely too.
Usually a reply within 3 working hours, by email or phone