Embedded Software Engineer

We need to output HTML fragment with sections: About the Company, About the Role, Responsibilities, Qualifications (maybe Education/Experience). Also maybe other sections like Benefits, Pay, Schedule if present. The posting includes schedule info: "This role is based in Akron, OH on a hybrid schedule with at least weekly in-office presence..." That's schedule info. Also location/hybrid schedule. Should we create a Schedule section? The rule: include a section ONLY when posting has real, specific content for it. The posting does mention hybrid schedule, location, weekly in-office presence. That's schedule info. So we can create a

Schedule

with

describing hybrid schedule, location, remote considered. Also maybe Benefits? Not mentioned. Pay? Not mentioned. So omit. We need to use

for section headings. Use

• for any list of duties/requirements/benefits. For prose use

  . Must not repeat job title. Must not include Job ID etc. Must remove boilerplate like EEO etc. Remove duplicated lines. Must preserve all substantive info. We need to parse the posting and extract sections. Let's extract: About the Company: paragraph(s) about engineering connectivity etc. About the Role: paragraph describing role. Responsibilities: multiple bullet points under headings: Wi-Fi Radio Firmware Development, Debug, Test & Quality, Cross-Functional & Customer Collaboration, Documentation & Process. Each with sub-bullets. We need to output

  • for any list of duties/requirements/benefits. So each bullet becomes
  • . Should we keep subheadings inside li? Probably we can keep the heading as part of li text, maybe bold? But we cannot add extra tags not specified? We can include inside li? Not prohibited. Safer to just include the text as is. Qualifications: list of qualifications bullet points. Education/Experience: could be part of Qualifications? It's separate heading "Education/Experience". Could treat as Qualifications section? But we have Qualifications heading already. The posting has "Qualifications" then bullet list, then "Education/Experience" then bullet list. We could combine them under Qualifications or make separate sections. The rule: Prefer a few substantive sections over many thin ones. Could combine Education/Experience into Qualifications as part of same list. But we need to preserve all info. We could have Qualifications section with two sub-lists? But we need to use
    • for any list. Could have one
      with all qualification items, including education/experience items. That would be fine. Schedule: hybrid schedule info. We must not include boilerplate like "We're an equal opportunity employer..." etc. Remove that. Also remove duplicated lines: there may be duplication of "Legal authorization to work in the US is required." appears earlier? Actually appears in About the Role: "Legal authorization to work in the US is required." Also later maybe not duplicated. We'll keep once. Now craft HTML. Structure:

      About the Company

      We engineer connectivity and embedded compute solutions that power connected devices worldwide. With decades of experience, our solutions are secure by design, globally compliant and supported over long lifecycles.

      About the Role

      The Embedded Software Engineer designs, develops, and supports Wi-Fi radio firmware and driver software for Ezurio's wireless connectivity products, working closely with the RF hardware development team in the USA and Taiwan, program management, and customers to deliver reliable, innovative, and resilient embedded software. The ideal candidate is comfortable working close to the metal - register-level access, bootloaders, and drivers in a resource-constrained environment - as well as building the connectivity stacks that sit above them, and brings strong debugging and root-cause analysis skills to complex hardware/software and RF interaction issues. Deep 802.11 protocol expertise is not required; we are willing to train a strong embedded/RTOS candidate on the Wi-Fi-specific pieces. Experience developing software for network protocols (Wi-Fi, TCP/IP, or similar) is a useful plus. This role is preferably based in hybrid work arrangement in Akron, Ohio. Remote candidates will also be considered. Legal authorization to work in the US is required.

      Responsibilities

      • Wi-Fi Radio Firmware Development
        • Design, develop, and maintain firmware for Wi-Fi radio subsystems, including MAC/PHY interfacing, calibration routines, and channel/RF management.
        • Bring up Wi-Fi silicon on new hardware platforms: port and validate vendor SDKs, drivers, and radio calibration data for new designs.
        • Develop and maintain radio firmware within an RTOS environment (e.g., ThreadX or similar) and host-side Wi-Fi drivers under Linux, with real-time scheduling, interrupt handling, and register-level access to radio and host interfaces (SDIO, PCIe, USB, DMA).
        • Write clean, well-documented, testable code following Ezurio coding standards and secure development practices.
        • Support 802.11 protocol-layer behavior (association, authentication, power-save, rate adaptation) and power management/wake-on-wireless design in coordination with vendor stacks.
      • Debug, Test & Quality
        • Debug complex RF firmware issues using tools such on hardware where on-device debug access (e.g., JTAG/debug ports) is limited, using debug output, code analysis, logic analyzers, oscilloscopes, and Wi-Fi packet capture tools (e.g., Wireshark) and JTAG/SWD
        • Develop and execute unit, functional, integration, and system-level tests; work with SWQA teams to contribute to test infrastructure and CI/CD pipelines.
        • Reproduce, isolate, and resolve field and customer-reported Wi-Fi issues (throughput, roaming, association drops, coexistence) and drive issues to root cause and closure.
        • Participate in code reviews and enforce quality gates across the software development lifecycle.
      • Cross-Functional & Customer Collaboration
        • Partner with the RF hardware team (USA and Taiwan) during schematic review, antenna design, and prototype bring-up to flag firmware-relevant design considerations early.
        • Work directly with customers and program managers to clarify Wi-Fi firmware requirements, scope, and acceptance criteria for co-development programs.
        • Support manufacturing, NPI, and DVT/PVT activities with RF test tools, calibration procedures, and production-line firmware as needed.
        • Provide clear technical status updates to program managers and contribute to schedule and risk discussions.
      • Documentation & Process
        • Produce and maintain technical documentation: design specifications, API references, porting guides, and release notes.
        • Maintain source control hygiene, branching strategy, and release/versioning discipline across active programs.
        • Contribute to the continuous improvement of embedded software development practices within the Custom SOM & SBC group.
      But note: The rule says use
      • for any list of duties/requirements/benefits. It didn't forbid nested lists? Might be okay but could be considered extra. Safer to flatten: each bullet as a top-level
      • with the heading as part of text. However that would lose grouping. But we can keep nested lists; it's still
        • . Probably acceptable. Now Qualifications section: combine qualifications and education/experience. We'll create

          Qualifications

          then
          • each bullet. List items from Qualifications bullet list: - Strong proficiency in C working in embedded, memory-constrained, real-time systems. - Solid understanding of processor architecture, memory management, and real-time constraints in embedded systems and working with register access. - Proven debugging skills across the hardware/software boundary, using debug output, JTAG/SWD, oscilloscopes, logic analyzers, and ideally Wi-Fi packet capture tools. - Demonstrated persistence and rigor in debugging and driving issues to true root cause rather than applying surface-level fixes. - Ability to read schematics and datasheets, and to communicate effectively with RF hardware engineers on radio and interface details. - Strong written and verbal communication skills; comfortable presenting technical status to customers and internal stakeholders. - Effective collaborator in a fast-paced, globally distributed team environment (coordinating with the RF hardware team in the USA and Taiwan), able to manage multiple concurrent programs. - Ideally hand-on RTOS experience: task scheduling, interrupt handling, and priority management in a resource-constrained system. Note that specific RTOS experience e.g. ThreadX, Zephyr, or similar matters less than a working understanding of RTOS concepts and real hands-on time in one. - Working knowledge of Linux (kernel modules, device drivers, kernel/user-space interfaces) is a plus, since our Wi-Fi drivers run under Linux. - Experience with host interfaces such as SDIO, PCIe, or USB is most relevant; familiarity with SPI, I2C, and UART is also useful. - Exposure to 802.11 MAC-layer concepts (association, authentication, power-save, rate adaptation) is a plus; we will train a strong embedded/RTOS candidate who doesn't yet have this. - Working knowledge of version control (Git), CI/CD pipelines, and issue tracking tools such as Jira. - Chipset vendor SDK exposure is a plus: Cypress/Infineon, NXP, Qualcomm/Atheros (QCA) or similar Wi-Fi silicon vendors. - Familiarity with RF/PHY concepts (calibration, gain control, channel switching) is a plus. - Prior experience with another wireless or networking protocol stacks e.g. Bluetooth, Zigbee, Thread, Cellular is valuable even without direct Wi-Fi background. - Power management firmware experience (sleep states, wake-on-wireless) is a plus, especially for battery-powered or IoT platforms. Education/Experience bullet list: - Bachelor's degree in Computer Engineering, Computer Science, Electrical Engineering, or a related technical field. Equivalent professional experience considered in lieu of degree. - 5+ years of embedded software or firmware development experience in an electronics design and manufacturing environment. - Direct experience with Wi-Fi or other wireless radio firmware/driver bring-up is strongly preferred; we will train a strong embedded/RTOS candidate without direct Wi-Fi background. - Experience supporting customer co-development programs (NRE-based or joint development agreements) is a plus. - Experience with wireless certification, RF coexistence, or low-power design considerations is a plus. - This role is based in Akron, OH on a hybrid schedule with at least weekly in-office presence, to support close collaboration with the RF hardware and QA teams. Fully remote work will be considered on a case-by-case basis for exceptional candidates with deep Wi-Fi radio chip experience (e.g., QCA, Infineon, NXP). Note: The last bullet about hybrid schedule duplicates schedule info; we already have schedule section. Might be redundant but we can keep it in Qualifications? Better to move schedule info to Schedule section and not duplicate. However the instruction: Preserve ALL substantive information; do NOT invent or summarize away detail. So we need to keep that sentence somewhere. If we create a Schedule section, we can include that sentence there, and we can omit it from Qualifications to avoid duplication. But we must not duplicate lines. So we should not repeat it. We'll place schedule info in Schedule section and not include that bullet in Qualifications. Thus Qualifications list will exclude the schedule bullet. Now Schedule section:

            Schedule

            This role is based in Akron, OH on a hybrid schedule with at least weekly in-office presence, to support close collaboration with the RF hardware and QA teams. Fully remote work will be considered on a case-by-case basis for exceptional candidates with deep Wi-Fi radio chip experience (e.g., QCA, Infineon, NXP).

            We also need to include "Legal authorization to work in the US is required."