Full-stack embedded fluency across MCU firmware, FPGA integration,
and the software-hardware interface , combined with the ability to
communicate clearly across all three disciplines. The ability to stand at
the boundary between a hardware schematic, an FPGA bitstream, and
a software API and make them function as a unified system.
This is the embedded authority role for the organisation. The incumbent defines the embedded
strategy across all current and future Qore products, covering MCU selection, peripheral architecture,
FPGA integration, real-time operating system decisions, and the interface contract between
embedded and software layers. This role does not execute someone else's embedded vision. It
defines it. Software engineers, hardware engineers, and firmware developers will all rely on this
individual as their first point of reference for any question that crosses the embedded boundary. Every
embedded architecture decision , interface selection, power domain design, timing requirements ,
carries this role's ownership. The scope includes the drone platform today and the automotive and
industrial products on the product roadmap. The person in this role is building the embedded
foundation on which those future products depend.
- Embedded architecture authority: owning the technical architecture for all embedded
subsystems, including MCU selection, peripheral allocation, RTOS versus bare-metal
decisions, and power domain design.
- CAN and UART architecture oversight: setting interface standards, reviewing all CAN and
UART implementations across product lines, and ensuring consistency with automotive
migration requirements.
- FPGA integration: defining the interface contract between FPGA fabric and the application
processor; overseeing HDL development and system bring-up in collaboration with the
hardware team.
- Software-embedded interface ownership: defining and enforcing clean API boundaries
between the firmware layer and the software stack, ensuring the software team is never
blocked by ambiguous or undocumented embedded behaviour.
- Hardware collaboration: participating in schematic and PCB layout reviews with a firmware
and signal-integrity perspective; identifying hardware issues before they become firmware
workarounds.
- Cross-layer failure investigation: owning root cause analysis when a failure does not present
clearly within a single layer , firmware, hardware, or software.
- Team technical development: serving as the primary technical resource and architecture
reviewer for all embedded engineers in the organisation.
- Automotive and industrial readiness: maintaining a clear roadmap for how current embedded
architecture evolves toward ISO 26262, CAN FD, AUTOSAR, and applicable functional safety
standards.
