Hire by skill · Firmware and embedded software
Hire an RTOS Firmware Engineer
An RTOS firmware engineer decides how firmware is split into tasks and interrupts, sets priorities, sizes stacks, and proves the timing with measurements instead of hope. Bring one in when deadlines slip under load, a task hangs in the field, or a superloop has outgrown itself. Talent Badger's bench includes specialists who have shipped production firmware on Zephyr and FreeRTOS, available fractionally or per project.
What RTOS firmware work covers
- Task decomposition: what belongs in interrupts and what in tasks, how many tasks the design actually needs, and priorities set by deadline rather than by how important a feature feels.
- Synchronization that holds under load: queues and event flags for passing data, mutexes with priority inheritance for shared resources, and short interrupt handlers that defer the real work to a task.
- Memory and stacks: per-task stack sizes set from measured high-water marks plus margin, overflow detection enabled during development, and a deliberate choice between static and heap allocation.
- Timing evidence: interrupt-to-task latency and deadline margins measured under worst-case load with GPIO toggles and a logic analyzer or a trace tool, plus tickless idle so the system sleeps between events.
- Platform work: Zephyr devicetree, Kconfig and west workspaces with MCUboot, FreeRTOS configuration and ports, Eclipse ThreadX, and moving a bare-metal superloop onto an RTOS one subsystem at a time.
Signs you need an RTOS specialist
- A deadline is missed only under load, or a high-priority task stalls while a lower-priority one holds a lock.
- Units in the field hang without resetting, because the watchdog is fed from a timer or idle hook that keeps running when a task is stuck.
- The superloop has collected flags and timeouts, and adding one feature breaks the timing of another.
- You've adopted Zephyr and the team spends its days on devicetree, Kconfig and build errors instead of the product.
How to vet an RTOS engineer
- Explain priority inversion and how you've prevented it. A strong answer describes a medium-priority task starving a high-priority one that waits on a mutex held by a low-priority task, then covers priority inheritance and short critical sections, and knows a FreeRTOS binary semaphore used as a lock gets no inheritance.
- How do you size task stacks? Look for high-water marks measured on worst-case paths, including formatted printing and deep call chains, margin on top, and overflow checking left on through testing.
- What do you do inside an interrupt handler? Expect: acknowledge the hardware, capture the data, signal a task with an ISR-safe call (the FromISR functions in FreeRTOS) and return, never blocking inside the ISR.
- How would you design a watchdog that catches a hung task? A good answer has each critical task check in, and one supervisor feeds the hardware watchdog only when every task has reported within its window.
- How do you know your worst-case latency? Listen for measurement under deliberate worst-case load and an account of interrupt priorities, critical sections and blocking calls, not an average taken on a quiet bench.
Cost and engagement shape
- On Talent Badger each profile shows a rate band set by assessed level, from $95/hr at engineer level up to $245/hr at the top of the most senior band.
- Typical shapes: an RTOS architecture review of existing firmware, a timing or hang investigation, a superloop-to-RTOS migration, or a Zephyr port with MCUboot.
- Planning range, not a quote: an architecture pass that settles RTOS or bare metal, task structure and the driver stack is commonly budgeted around 60 hours. Load hands-on hours by about 1.3–1.5× for reviews, meetings and contingency.
- Investigations fit capped hourly work with a written finding at the end. Work runs under a statement of work, and IP assignment is signed before work begins.
RTOS: Zephyr, FreeRTOS, ThreadX specialists on the bench
Božidar Kresaj
Connectivity Architect
RTOS (FreeRTOS, Zephyr, ThreadX) · Embedded C/C++ · STM32 / ARM Cortex-M · Linux / Yocto / BSP
Oleksandr Gergel
Specialist
RTOS (FreeRTOS, Zephyr, ThreadX) · Embedded C/C++ · Bootloader Development · STM32 / ARM Cortex-M
Yahya Aouled Amer
Specialist
RTOS (FreeRTOS, Zephyr, ThreadX) · STM32 / ARM Cortex-M · Python · Embedded C/C++
Common questions
Mostly structure and evidence: deciding what runs in interrupts and tasks, setting priorities, sizing stacks, choosing synchronization, and measuring whether deadlines hold under worst-case load. Many engagements review or fix existing firmware, such as a field hang or a missed deadline, rather than starting a new build.