Firmware Engineer — Microcontrollers İş İlanı

We are looking for a senior Firmware Engineer to own the microcontroller layer of the Q12. Beneath the Linux compute layers, a constellation of MCUs runs the aircraft: supervisors that sequence power and decide what happens when a subsystem stops answering at altitude, peripheral controllers for everything from audio and lighting to power boards, and flight-adjacent subsystems like the radar altimeter. It is the layer nobody sees until it matters, and then it is the only thing that matters. This is a role with real ownership rather than a specification to implement — and you will inherit a working portfolio, not a blank page. You will take ownership of the existing microcontroller firmware projects across the aircraft, carry them forward, and build out the firmware layer around them properly — consolidated onto a common structure and toolchain. The thread that runs through all of it is field update: every MCU on the aircraft should be updatable in the field, and the bootloaders that make that true are yours to integrate and keep healthy across the estate. About SiFly Aviation

At SiFly, we’re building a new category of aircraft: vertical-takeoff, long-endurance drones that deliver helicopter-level performance at drone economics. After thousands of flight tests and years of engineering, our NDAA-compliant platform flies more than 2 hours in hover or 3 hours in forward flight on a single charge — matching the capability of traditional helicopters at a fraction of their cost and operational burden. We merge aerial robotics, perception, and onboard intelligence to cut complexity and minimize human intervention, and our unique approach to communications and networking unlocks remote operations from day one. It’s an ambitious mission, and we’re a small team that moves fast. The role

You will own the microcontroller firmware across the aircraft, in all its variety: the supervisory MCUs and their failsafe logic, peripheral firmware from audio and LED control to power boards, the Bluetooth radio behind device onboarding and field diagnostics, the radar altimeter, the command and telemetry interfaces between the MCUs and our Linux compute layers, and power-on self-test and run-time diagnostics. The thread that runs through every board you touch is safe in-field update — bootloaders you integrate and maintain, and the standard over-the-air path reaching every MCU. Much of this firmware already exists; you will inherit it, consolidate it, and own it end to end. You will report into our Embedded Platform lead and work closely with the two Embedded Linux Engineers on either side of the MCU boundary, the flight-software team on the other end of the supervisory interface, the firmware-and-security engineer who owns Remote ID, the ADS-B + Remote ID board, secure boot for our STM32-based MCUs, and the common crypto co-processor API, the firmware contributors whose subsystems you will take over, and our hardware engineers in Santa Clara — with boards travelling between Turkey and California as bring-up campaigns ramp up. What you’ll do

Own the supervisory firmware. Power sequencing and rail supervision, board health and thermal monitoring, fault detection and containment, arbitration between the flight controller and the Linux compute layers, and the failsafe behaviour that governs what happens when a subsystem goes quiet mid-flight. Own peripheral firmware. Audio and LED control, the Bluetooth radio behind device onboarding and field diagnostics, power-board firmware, and the smaller MCUs scattered around the aircraft — whatever the peripheral, the firmware is yours: absorb it, document it, and consolidate it onto a common structure and toolchain. Bring up new boards with the hardware team. Review schematics before they are built, then take new boards from first power-on: verify rails, clocks, and reset behaviour, write the first drivers from the reference manual, and debug across the hardware/firmware boundary with a scope, a logic analyzer, and SWD. Own the MCU-to-Linux boundary. Define and implement the command and telemetry protocols between the MCUs and the Linux platform over UART, I²C, SPI, and CAN — versioned, documented, and debuggable, so the platform and applications teams can build against them without reading your firmware. Own field update. Integrate and maintain the MCU bootloaders the update path rides on, and keep every microcontroller on the aircraft updatable through the standard over-the-air path: dual-bank or A/B layouts, integrity and signature checks, rollback, and recovery when an update fails on a board nobody can reach with a programmer. Own diagnostics. Power-on self-test and run-time diagnostics across boards, with structured fault reporting into the platform logs, so a failure seen in the field is diagnosable from data rather than by taking an aircraft apart. Own the flight-adjacent subsystems. Radar-altimeter firmware, plus the firmware-side integration for gimbal and ESC subsystems — giving each one a real owner and a real test story. Support manufacturing. Functional test firmware, factory provisioning and programming flows, and board-level test support, so production can bring up and verify a board without an engineer on the call. Make it survivable. This layer needs a genuine, lasting owner — so leave behind documentation, code review, firmware CI, and automated or hardware-in-the-loop tests good enough that the next engineer, and your own holiday, are not a risk to the programme. Required experience

Minimum 5+ years of professional experience writing production embedded firmware on ARM Cortex-M or comparable microcontrollers. A bachelor’s degree or higher in a related program — Electrical Engineering, Computer Engineering, Computer Science, or similar. MCU firmware depth. Strong C, and modern C++ where it earns its place, across microcontroller families — our current boards lean on STM32, including the H7 family, but an unfamiliar MCU should not slow you down. Comfortable both bare-metal and on an RTOS (FreeRTOS, Zephyr, or similar), with interrupt- and DMA-driven designs, startup code, linker scripts, and peripheral drivers written from the reference manual rather than a vendor example. Peripheral breadth. You have driven a wide range of peripherals in production — sensors, radios, audio, lighting, motors, power stages, whatever the product needed — and the journey from datasheet to working, tested driver is routine for you. Board bring-up. You have read schematics, powered on a board that had never booted, and found out why. Fluent with oscilloscopes, logic analyzers, and SWD/JTAG debugging, and comfortable working alongside hardware engineers on their side of the boundary. Buses and interfaces. UART, I²C, SPI, CAN or CAN-FD, and USB — not just using them, but defining the protocols that run over them between processors and keeping those protocols stable as both sides change. Robustness and failure behaviour. Watchdogs, brown-out and reset handling, fault handlers, error containment, and degraded-mode operation. You have written firmware for something that could not simply be power-cycled by hand when it misbehaved. Bootloaders and field update. You have worked deep in MCU bootloaders — creating, maintaining, or integrating them rather than only using a vendor’s — and shipped firmware updates to devices already in the field: dual-bank or A/B schemes, signed images, verification, and rollback. Debugging and workflow. Disciplined about Git, code review, and CI, with real experience testing firmware automatically — unit tests, hardware-in-the-loop rigs, or both — rather than relying on manual bench checks. Advanced English language skills and strong written and verbal communication — able to coordinate clearly across a distributed team in Turkey and Santa Clara. Nice to have

Zephyr RTOS · nRF52 or nRF53 and BLE stack integration · BLDC motor control or ESC firmware · power electronics, power sequencing, and battery management systems · safety-relevant development process exposure — DO-178C, DO-254, ISO 26262, or IEC 61508 · PX4 or ArduPilot internals, MAVLink, or uORB · GNSS receivers and RTK integration · radar-altimeter and time-of-flight sensor work · manufacturing test firmware and factory provisioning flows · static analysis, MISRA C, or coding-standard enforcement in CI · enough Linux and Yocto familiarity to meet the platform team halfway · UAV, aerospace, automotive, or medical-device firmware experience. What success looks like

The inherited firmware projects are shipped, and every microcontroller on the aircraft has a clear, full-time owner. Power sequencing, fault handling, and failsafe behaviour are specified and documented rather than discovered in flight test. Every MCU on the aircraft can be updated in the field through the standard OTA path, safely and repeatedly, including recovery from a failed update. Peripheral firmware is consolidated under one owner, on a common toolchain, and is no longer a single point of failure. Radar-altimeter, gimbal, and ESC firmware each have an owner, a test story, and a release history. Manufacturing can program, bring up, and functionally test a board without pulling an engineer in — and field failures are diagnosable from diagnostic output. Compensation & logistics

Job type: Remote contract-based employment. Location: On-site position in Ankara, Turkey — working closely with our Santa Clara team.