An explainer of how the STM32 Microcontroller family is organized, what the underlying Arm Cortex-M cores actually give you, and how the development ecosystem works.

STM32 Microcontroller: Cores, Peripherals & Tools

<h2 id="isPasted"> </h2>Sensor-driven embedded systems spend a disproportionate share of their engineering budget on tasks that look mundane - ADC plumbing, offset calibration, ISR state machines, zero-crossing logic, fixed-point math, and reading the right paragraph of a 2,000-page datasheet at the right moment. This article compares how these sensor-level tasks play out with and without the Microchip MPLAB AI Coding Assistant, using a reference-design-class development platform as the benchmark: a bidirectional totem-pole Power Factor Correction (PFC) stage built around a dsPIC33CH dual-core digital signal controller. The result is not that the assistant replaces the embedded engineer - it is that it reliably removes a large share of the manual drudgery around the sensor chain, letting the engineer spend that time on the parts that actually require engineering judgement.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1786657073214-1786657073214.png" class="fr-fic fr-dib" alt="AI Meets Embedded Development with Microchip's MPLAB® AI Coding Assistant" />AI Meets Embedded Development with Microchip's MPLAB® AI Coding Assistant<h2>1. The Benchmark Design</h2>The benchmark platform used for this comparison is a bridgeless totem-pole PFC demonstration design with isolated AC-voltage acquisition, current-sense signals sampled by the dsPIC33CH ADC, and a software zero-cross detector. In the three-channel control framework shown in the reference material, those signals feed three 2p2z current loops at 100 kHz and one voltage loop at 300 Hz. From a firmware perspective, this is a sensor-heavy system:<ul><li>The isolated voltage-acquisition board transfers V_AC data to the main power board over SPI on a 100 kHz acquisition/control cadence, with an ADC offset-calibration state machine that runs before the online state.</li><li>A software zero-crossing detector with symmetric hysteresis runs every switching period and drives the half-bridge gate remap.</li><li>Three current-sensing channels are fed into 2p2z compensators whose coefficients come out of Microchip's Digital Compensator Design Tool (DCDT).</li><li>A DC-bus monitor provides V_BUS over-voltage checking and the adaptive step-response fast path.</li></ul>Each of these is a textbook sensor-subsystem task. Each was implemented twice - once using the traditional toolchain (datasheet, MCC/Melody, hand-coded state machines) and once using the Microchip MPLAB AI Coding Assistant on top of the same toolchain. The numbers below are indicative effort for an engineer who is already fluent with dsPIC33CH and MPLAB X.<h2>2. Task A - Isolated V_AC Acquisition Board: ADC + SPI + Offset Calibration</h2>Without the assistant. The engineer opens MCC, configures the ADC channels and the SPI slave peripheral, exports the code, then hand-writes the offset-measurement state machine, the per-channel averaging, the checksum, and the STATE_OFFSET_MEAS → STATE_ONLINE transition. The hardest part is not writing it; the hardest part is getting the trigger-to-SPI-to-control timing aligned with the 100 kHz control cadence: the acquisition is triggered at the beginning of the cycle, SPI starts a few microseconds later, the primary-core V_AC monitor completes before the data is passed to the secondary core, and the secondary-core ISR uses that data on the next 20 µs boundary shown in the timing slide. Typical time budget: ~1 working day, including one or two scope sessions.With the Microchip MPLAB AI Coding Assistant. The engineer prompts:"Generate a state machine for an isolated acquisition board running on a PIC with three ADC channels plus SPI slave output. States: OFFSET_MEAS (average a configurable number of samples per channel, verify tolerance, transmit offsets over SPI, then switch to ONLINE), ONLINE (on external trigger: sample 3 channels, subtract per-channel offset, compute a checksum, transmit 4×16-bit words over SPI). Target: 100 kHz acquisition cadence."The assistant returns a compilable skeleton aligned with the documented flow, including the tolerance check, the checksum path, and the STATE_OFFSET_MEAS to STATE_ONLINE transition. A follow-up prompt can add missed-trigger protection around the same 100 kHz trigger cadence. Time budget: ~2 hours, most of it spent on scope verification, not typing.<h2>3. Task B - Zero-Cross Detection at 100 kHz</h2>Without the assistant. Zero-cross sounds easy until you implement it. The naïve comparator-against-zero approach chatters because of noise and THD; the textbook solution is a two-threshold hysteretic detector combined with a slope sign. Getting the four states (entering/exiting region × positive/negative slope) right usually takes a whiteboard, a notebook, and half a day of bench debug to discover the single edge case that only appears near very low line voltages.With the assistant. Prompt:"Write a C function called every 10 µs that takes a signed 16-bit AC-voltage sample and produces: (a) polarity flag, (b) in-zero-cross-region flag with ±V_ZC_TH hysteresis, (c) an `soft_start_armed` flag that arms once per half-cycle when leaving the ZC band. Must be branchless where possible for deterministic ISR latency."The generated code passes review; the only human change is tuning V_ZC_TH to the actual transformer and gating the logic with the V_AC OK conditions used by the monitor: V_AC not under- or over-voltage, line frequency between 45 Hz and 65 Hz, and stability for 10 AC line cycles. Time budget: ~30 minutes vs. half a day.<h2>4. Task C - 2p2z Compensator from DCDT Coefficients</h2>Without the assistant. DCDT produces B₀/B₁/B₂/A₁/A₂ coefficients and a reference implementation. The engineer must then integrate them into the secondary-core ISR, add the adaptive gain branch that scales the B-terms below a load threshold, add the duty-ratio feed-forward term D = (V_OUT − V_IN)/V_OUT, and make sure the current-loop work fits inside the 10 µs ADC ISR. The reference material quotes roughly 660 ns execution time for one optimized 2p2z compensator, so the remaining ISR tasks still have to be budgeted carefully. Typical time: ~1 day plus oscilloscope and THD-analyzer bench time.With the assistant. Prompt:"Integrate the attached DCDT coefficients into a 2p2z current compensator. Add: (1) adaptive gain that uses the voltage-loop output as a load proxy and scales the B-coefficients when V_loop_out &lt; 16000, clamped at 3276; (2) duty-ratio feed-forward using V_BUS and V_AC; (3) output saturation at min/max duty; (4) dsPIC33CH-optimized fixed-point arithmetic. Provide a small test harness and an execution-time check for the ISR path."The assistant emits the compensator structure, the #define ADAPTIVE_GAIN_ENABLED guard, and a timing check that can be used during bench validation. On the bench data shown for the reference design, THDᵢ measured at a 40 W electronic load was 3.25 % with duty-ratio feed-forward vs. 4.25 % without, which is the target behaviour the generated integration has to preserve. Time budget: ~3 hours.<h2>5. Task D - Datasheet and Reference Design Lookup</h2>An often-ignored category. Across the three tasks above, the engineer referenced the dsPIC33CH datasheet and reference material for ADC timing, PWM trigger sources, SPI timing, core-to-core handoff, fixed-point arithmetic, and the errata. Without the assistant, this is classical PDF navigation — probably 30–45 minutes of cumulative reading per task.With the assistant connected to Microchip's internal documentation services (datasheets, EVK user guides, compiler manual, MUSL standard-C-library guide, release notes), those lookups return as short, citable answers inside the chat, and are threaded directly into the generated code as comments. Cumulative reading time: under 10 minutes per task.<h2>6. What Still Belongs to the Engineer</h2>The comparison is favourable to the assistant, but the picture is not "AI writes the firmware." Three classes of decisions must still come from the human:<ol><li>Safety-Critical and Regulatory Logic: Over-voltage trip thresholds, soft-start sequencing, and the AC_OK validation window are derived from specifications that the assistant cannot own.</li><li>Bench validation: THD, reverse-recovery losses, and EMC margins are measured, not generated. The assistant accelerates the path to the bench, not the bench itself.</li><li>System-Level Architecture: Choosing a dual-core dsPIC33CH rather than a single-core device, putting the sensing on an isolated board, or serialising data digitally rather than analog — these are the design decisions that set the performance ceiling, and they remain firmly with the engineer.</li></ol><h2>7. Takeaway</h2>In a sensor-heavy embedded design, the engineer's calendar typically looks like: 20% architecture, 60% peripheral plumbing and calibration code, 20% bench verification. The Microchip AI Coding Assistant compresses the middle block without inflating the ends. On the totem-pole PFC reference-design platform, the sensor-subsystem implementation work above shrank from roughly three working days of manual implementation and lookup effort to about one working day with the assistant, while the design targets and bench reference points remained the same: 98.5% efficiency as a key specification, 3.25% THDᵢ with duty-ratio feed-forward in the 40 W measurement shown, and IEC/EN 61000-3-2 compliance in the reference measurement.For teams building the next generation of sensor-driven converters, chargers and inverters, that is not a marginal improvement. It is the difference between shipping the sensor subsystem on schedule and watching it eat the schedule.<hr />Franziska Kofler holds a B.Eng. in Electrical and Information Engineering and an M.Eng. in AI for Autonomous Systems. After working in embedded software development, she joined Microchip as a Field Applications Engineer (FAE), where she supports customers in developing innovative embedded and AI-based solutions. In her free time, she is active in a local shooting club and regularly works out at the gym.

Artificial Intelligence Driven Coding Assistant for Modern Software Development

See how MPLAB AI Coding Assistant accelerates sensor-driven embedded design, from ADC setup to real-time control firmware.

With vs. Without: An AI Coding Assistant on a Real Sensor-Driven Embedded Design

Robotics is expanding across manufacturing, automotive production, aerospace, healthcare, logistics, and industrial automation. Despite their different uses in various industries, all modern robots share the same procedural requirements: sensing conditions, processing data, making decisions, and acting in the physical world.<a href="https://wevlv.co/ew_na_lp" id="isPasted">embedded world North America</a> will take place from September 22nd to the 24th, 2026, at the Anaheim Convention Center in Anaheim, CA, US. It provides a focused platform for the embedded technology community across the United States, Canada, and Mexico. Organisers expect more than 5,000 visitors, over 250 exhibitors, more than 60 technical sessions, and 100,000 square feet of exhibition space.[1]The Robotics Lab is a hands-on show-floor feature connecting embedded systems, AI, human-machine interaction, and practical applications. It shifts attention from robots as finished machines to the technology stack behind them.<h2>Why Robotics Belongs at an Embedded Systems Event</h2><h3>Embedded Systems as the Foundation of Robotics</h3>Robots depend on microcontrollers, systems-on-chip, sensors, real-time operating systems, connectivity, and embedded software. Sensors collect data, processors interpret it, and software turns it into movement. Timing is critical because delays can affect accuracy and safety.AI cannot compensate for weak sensing, limited processing, high energy use, or unreliable control. The wider embedded world platform encompasses the components, modules, operating systems, communication systems, and design tools that underpin this foundation.[2]<h3>Robotics as a Clear Use Case for Embedded Innovation</h3>Robotics combines hardware, firmware, software, AI, and connectivity. A mobile robot may process urgent tasks locally while sending selected data to an edge or cloud platform.This makes technical choices visible. Processing delays affect movement, sensor errors affect decisions, and network loss can interrupt remote functions. Robotics therefore matters to engineers, developers, integrators, product managers, and research leaders. It also provides a practical way to examine productivity, safety, automation, and industrial change. [3]<h2>The Robotics Lab Visitor Journey</h2><h3>A Structured Four-Zone Experience</h3>The approximately 800-square-foot Robotics Lab is planned as a journey through four connected zones: Embedded Intelligence, AI and Autonomy Engine, Human-Machine Interaction, and Industry Applications and Future Robotics.The route moves from control components to decision-making, interaction with people, and final industry use. It shows that autonomy depends on the embedded platform, data, software, AI models, interfaces, and operating environment.<h3>From Embedded Intelligence to Industry Application</h3>Embedded systems provide sensing, processing, and control. AI adds perception, learning, and autonomy. Human-machine interaction connects robots with operators, while industry applications place the complete system in environments with specific safety, performance, and reliability needs.Following this sequence helps visitors see how decisions at one level affect those at other levels. A strong AI model may still fail on limited hardware, while a capable robot may remain difficult to use if its interface is unclear.<h2>The Four Robotics Lab Zones</h2><h3>Zone 1: Embedded Intelligence</h3>This zone covers microcontrollers, SoCs, sensors, RTOS platforms, and connectivity. Together, they manage robotic control, collect operational data, support predictable timing, and connect robots with other systems.The main point is simple: every intelligent robot begins with an embedded platform designed for its task.<h3>Zone 2: AI and Autonomy Engine</h3>Machine learning supports pattern recognition and adaptive behaviour, while computer vision enables inspection, object detection, and navigation. Simulation allows teams to test and improve systems before physical deployment.AI processing may run on the robot, at the edge, or in the cloud. On-device and edge processing can reduce latency, while cloud systems can support training, storage, and coordination. Research on edge robotics identifies reduced latency, mobility, location awareness, and real-time processing as key benefits. [4]<h3>Zone 3: Human-Machine Interaction</h3>This zone includes cobots, control displays, AR and VR, voice and gesture control, and safety systems. These tools can support training, monitoring, programming, and maintenance.Robots working near people need clear status information, predictable movement, accessible emergency controls, and defined limits. Augmented and mixed reality can support robot control, training, monitoring, and clearer communication between people and machines. [5] Human-Centered design should make robotic behaviour easier to understand without hiding uncertainty or risk.<h3>Zone 4: Industry Applications and Future Robotics</h3>The final zone connects robotics with automotive manufacturing, aerospace, healthcare, logistics, industrial automation, smart factories, and emerging fields.Requirements differ by sector. Factory robots may work in controlled cells, warehouse robots must handle changing routes and people, and healthcare systems require close attention to safety, privacy, hygiene, and reliability.Displays should explain not only what a robot does, but also the sensors, processing systems, safety controls, and operating conditions behind it.<h2>Hands-On Experiences and Technical Programming</h2><h3>Interactive Show-Floor Elements</h3>The lab can include live robotics demonstrations, AI inference examples, cobots, sensor walls, simulation tools, AR and VR interfaces, gesture control, and industry-specific application pods. These displays can show how sensor input becomes an AI result and then a physical action.embedded world North America offers a hands-on technical setting where companies can demonstrate technologies directly to engineers and other technical visitors.[3] Demonstrations should also state whether processing is remote, routes are pre-mapped, or models are trained for selected objects.<h3>Engagement Through Learning Formats</h3>Ten-minute technical sessions, expert-led tours, and workshops can cover robotics programming, sensing, simulation, and AI model tuning.Tours can connect the four zones, while workshops let visitors examine trade-offs involving processing, memory, power, and deployment. These formats can serve embedded engineers, robotics and AI developers, product leaders, and technical executives.<h2>Value for Attendees, Exhibitors, and Sponsors</h2><h3>Attendee </h3>For attendees, the lab shows how robotic systems move from individual components to deployment. It brings together embedded systems, AI, HMI, and industry applications, and connects robotics trends with practical challenges in sensing, integration, connectivity, safety, and reliability.Compared with a standard booth display, live and interactive exhibits offer a more active way to understand how robotic technologies operate in real applications.<h3>Exhibitor and Sponsor</h3>For exhibitors and sponsors, the lab can offer zone-level sponsorship, ownership of selected demonstrations, branded robotics experiences, and participation in technical sessions, tours, and workshops.Direct engagement with engineers and decision-makers can support lead generation and provide a clearer way to show real-world technology impact. The official exhibitor information also presents live demonstrations, technical discussions, brand visibility, and lead generation as key reasons for participation. [3]Sensor companies can demonstrate data collection, processor suppliers can show performance under timing and power limits, and software providers can present tools for simulation, control, or deployment.Sponsored activities should be clearly identified, while technical content should discuss limits and compatibility rather than present products as universal solutions.<h1>Conclusion</h1>Robotics is one of the clearest examples of embedded systems becoming intelligent physical machines. The Robotics Lab can present the complete embedded-to-AI pipeline by connecting embedded intelligence, autonomy, human interaction, and industry applications.As robotics adoption grows across U.S. industries, hands-on demonstrations, technical sessions, tours, and workshops can help engineers and decision-makers understand both the opportunities and practical requirements of deployment.The lab’s value lies not only in displaying robots but in explaining the technologies, operating conditions, and design choices behind them.For more info about <a href="https://wevlv.co/ew_na_lp" target="_blank" rel="noopener noreferrer">embedded world North America, check out their event page</a>.<hr /><h3>References</h3><ol><li><a href="https://embedded-world-na.com/?utm_source">embedded world North America official event page</a> </li><li><a href="https://embedded-world-na.com/exhibit/?utm_source">embedded world North America exhibitor information page</a> </li><li><a href="https://www.embedded-world.de/en?utm_source">embedded world global exhibition and conference page</a> </li><li><a href="https://arxiv.org/abs/2507.00523?utm_source">Edge Computing and Its Application in Robotics: A Survey</a> </li><li><a href="https://arxiv.org/abs/2203.03254?utm_source">Augmented Reality and Robotics: A Survey and Taxonomy for AR-enhanced Human-Robot Interaction and Robotic Interfaces</a></li></ol>

How Embedded Systems, AI, and Human-Centered Design Are Driving the Future of Robotics

Robotics Lab at embedded world North America

Medical device development has long been organized around hardware stability and infrequent software change. With minimal connectivity, compliance was handled at the end of the cycle through documentation, validation, and submission preparation. That sequencing aligned with the constraints of those systems.As medical device connectivity has expanded, regulatory expectations extend across the full software lifecycle. <a href="https://www.iar.com/industry/medical-technology?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">IEC 62304 governs development</a>, maintenance, and change management. FDA cybersecurity guidance requires documented threat modeling, secure update mechanisms, and post-market monitoring. For connected devices operating across hospital networks, IEC 62443 adds network-level cybersecurity requirements that sit alongside these obligations. The EU Cyber Resilience Act (CRA) mandates early warning notifications within 24 hours of an actively exploited vulnerability and full reporting within 72 hours. All apply throughout the active life of the device.Medical devices increasingly operate as connected, software-defined systems. Over-the-Air (OTA) update capability, network interfaces, and cloud connectivity introduce continuous exposure. Each update cycle becomes a compliance event where the software must be validated, the build reproducible, and the evidence organized. Fragmented toolchains and disconnected workflows introduce gaps in traceability, validation, and response readiness, increasing both cost and operational risk.<h2>From Stable Devices to Continuous Obligations</h2>Certification as a terminal event does not support connected device development. Devices that receive software updates after deployment require each update to pass through a documented development, validation, and release process. Patches issued in response to vulnerabilities must meet the same traceability and quality requirements as the original release and must be delivered within defined regulatory timelines.Lifecycle responsibility extends beyond initial certification. Medical devices commonly remain in active use for 10 to 15 years, and software support obligations persist across that period. Software updates, patches, and security fixes must be delivered and validated repeatedly under controlled conditions. Compliance now includes response time, not only validation.CRA reporting timelines illustrate the operational pressure this creates. A 24-hour early warning window for an actively exploited vulnerability requires immediate identification of the affected software component, including its specific version and associated SBOM entry, supported by traceability and an operational response workflow. Teams that assemble compliance evidence manually across fragmented systems cannot meet this requirement consistently, as evidence must be reconstructed across multiple tools under strict time constraints.<h2>The Cost of Fragmented Development in MedTech</h2>Fragmentation in MedTech development accumulates across toolchain configuration, evidence collection, and workflow integration. The resulting costs scale with both system complexity and regulatory pressure.Most teams rely on separate tools for compilation, static analysis, testing, and security assessment. Each tool introduces its own configuration, versioning model, and output format. Manual integration between these systems creates ambiguity around which tool version produced a result, under which configuration, and against which source state. Traceability becomes difficult to establish during audits.Each toolchain component in a regulated environment requires validation. Teams must demonstrate that tools behave correctly under defined conditions of use. When tools are sourced and integrated independently, this validation effort increases with the number of components and must be repeated across product lines and releases.As software complexity grows, test coverage expands, analysis scope increases, and the number of configurations requiring validation rises. Safety and security workflows often operate in parallel without integration, producing separate evidence trails that must be reconciled during submissions. This accumulates as software lifecycle debt, where each release inherits unresolved complexity from previous development cycles. The impact becomes visible during audits, security incidents, and post-market updates.The business consequences are direct. Delayed regulatory submissions affect revenue timelines. Rework driven by late-cycle defect discovery reduces engineering capacity. Compliance gaps identified during audits extend validation cycles and introduce additional remediation effort at the portfolio level.<h2>What a Compliance-Ready Development Model Looks Like</h2>MedTech teams adapting to current regulatory requirements are aligning their development systems around three operational shifts that integrate validation, execution, and compliance into daily development.<h3>Shift 1: Verification Moves into Daily Development</h3>Static analysis, traceability, and risk assessment are integrated into the developer workflow. Coding standards including MISRA C/C++, CERT C/C++, and CWE guidelines are enforced at commit level, ensuring that issues are identified in context and addressed immediately. Early detection reduces downstream validation effort and limits the propagation of defects into later stages of development. Compliance evidence is generated continuously as part of normal development activity.<h3>Shift 2: Reproducible, Deterministic Pipelines</h3>Containerized build environments define a consistent execution context across developer machines and CI infrastructure. Toolchains, dependencies, and configurations are versioned and controlled. Build, test, and analysis outputs are linked to specific source states and stored as structured artifacts. Each pipeline execution produces repeatable results that can be audited directly from recorded artifacts. <a href="https://www.wevolver.com/article/the-hidden-cost-of-manual-builds-why-teams-in-regulated-sectors-must-embrace-cicd">CI/CD infrastructure</a> enforces repeatability across environments and over time.<h3>Shift 3: Toolchains Become Part of the Compliance Case</h3>Tool qualification contributes directly to the compliance framework. Certified toolchains reduce the need for internal validation of tool behavior and limit the scope of audit effort. A pre-qualified toolchain defines a stable boundary for build, analysis, and validation. Unified development platforms that support multiple architectures reduce the number of separate qualification cases required across product lines. Integrated toolchains also enable automated component inventory generation, capturing provenance at build time rather than during incident response. Development tooling becomes part of the compliance evidence rather than an additional validation burden. <h2>Long-Term Lifecycle Reality: Why Reproducibility Must Extend Beyond Release</h2>The requirements that apply at certification continue throughout the operational life of the device. A security patch issued years after deployment must be built within a controlled environment consistent with the original release, validated against the same standards, and supported by traceable evidence.When toolchain configurations are not preserved, updates require reconstruction of environments that may no longer exist in a controlled form. This introduces uncertainty into validation and increases the cost of maintenance over time.Long-term support strategies treat toolchain configuration as part of the product definition. Frozen toolchain versions maintained across the device lifecycle ensure that builds remain consistent across time. Development infrastructure becomes a controlled component of the system, supporting both maintenance and regulatory compliance.<h2>Enabling Compliance-Ready Development with IAR</h2>Development systems that support continuous validation and reproducibility require toolchains that are designed for integration, traceability, and long-term stability. In practice, this places constraints on how build environments, analysis tools, and security workflows are structured and maintained.<a href="https://www.iar.com/embedded-development-tools?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">IAR’s embedded development platform</a> is built to operate within these constraints. Its toolchains are <a href="https://www.iar.com/embedded-development-tools/functional-safety?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">TÜV-certified</a> against IEC 62304, contributing directly to the tool qualification component of a medical device compliance case. A unified platform supports Arm, RISC-V, Renesas, and TI MSP430 architectures, reducing the number of separately qualified toolchains across product lines.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1779365442277-image1.png" style="width:100%px" class="fr-fic fr-dib" />A Modern CI/CD Workflow. Credit: IAR <a href="https://www.iar.com/embedded-development-tools/embedded-ci-cd?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">IAR Build Tools</a> are headless and integrate with CI platforms such as GitHub Actions, GitLab CI, and Jenkins. Static analysis through C-STAT enforces MISRA C/C++, CERT C/C++, and CWE guidelines against each build within the CI/CD pipeline, and runtime verification through C-RUN extends coverage into test execution via dynamic instrumentation that detects memory access violations, arithmetic errors, and undefined behavior, enabling continuous validation without manual intervention. Together, <a href="https://www.iar.com/embedded-development-tools/code-quality-and-compliance?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">C-STAT and C-RUN</a> provide analysis coverage that maps directly to IEC 62304 software verification requirements.Security capabilities, including firmware signing, encryption, and secure boot through IAR’s <a href="https://www.iar.com/embedded-development-tools/embedded-security?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">Embedded Trust</a>, are integrated into the same workflow, aligning with FDA cybersecurity guidance and CRA requirements.<a href="https://www.iar.com/embedded-development-tools/long-term-assurance-services?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">Long-Term Support</a> versions provide frozen toolchain configurations maintained across extended periods — covering the full operational life of a medical device, commonly 10 to 15 years in active use. Builds produced under a specific configuration can be reproduced years later, with validated service packs and structured issue reporting supporting long-term device maintenance and regulatory requirements. These capabilities align with the structural requirements outlined earlier, where compliance depends on controlled, reproducible development systems rather than isolated validation activities.<h2>From Fragmentation to Lifecycle Control</h2><a href="https://www.iar.com/industry/medical-technology?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">MedTech development</a> now depends on control of the software lifecycle across its full duration. Fragmented development environments introduce gaps in traceability, increase validation effort, and limit the ability to respond to security events within regulatory timelines.Continuous, deterministic development processes provide a stable foundation for meeting these requirements. Systems that integrate validation, execution, and compliance into daily workflows reduce lifecycle debt and improve operational predictability. Meeting the 24-hour CRA notification window, maintaining IEC 62304 traceability across a 10–15 year device lifecycle, and delivering validated OTA patches without schedule risk all depend on one thing: compliance evidence that exists before it is needed, not reconstructed under pressure when it is. In MedTech, reproducibility defines the boundary between controlled development and regulatory risk.

This article explores why fragmented development models are no longer sustainable in MedTech, as connected devices, continuous software updates, and evolving regulations demand reproducible, compliance-ready development workflows across the entire device lifecycle.

Why MedTech Teams Can No Longer Afford Fragmented Development

In mid-April 2026, Nordic Semiconductor released the <a href="https://www.nordicsemi.com/Products/nRF9151/Download?#A9BA541CDE7C49A1A7B28D0099AC3E24" target="_blank">v1.0.0 NTN modem firmware</a> for their latest chipset, the nRF9151. A "1.0" tag is supposed to mean “ready for production”. But is it, really? And at what cost?Let's put the latest NTN developments to the test and find out if the standard is actually ready for production.<h2>Non-Terrestrial Networks Explained</h2>Non-Terrestrial Networks (NTN) are the 3GPP's response to a continuous demand for connecting the largest part of the planet that no cell tower will ever reach. It opens up a long list of use cases: connecting large farmlands, monitoring energy infrastructure, tracking global logistics, overseeing mining equipment, just to name a few. The standard, defined by the 3GPP in <a href="https://www.3gpp.org/specifications-technologies/releases/release-17" target="_blank">Release 17</a> (frozen in June 2022), <a href="https://www.3gpp.org/technologies/ntn-overview" target="_blank">extends existing cellular protocols</a> (LTE-M and NB-IoT) to work over satellites.The promise is that none of this requires significant changes to the IoT devices. The same modem should support both terrestrial and non-terrestrial networks. The same antenna should work, to some extend. And more and more connectivity providers now let you use the same SIM for both kinds of networks.In essence, the satellite acts as a cell tower deployed in space. Once a data packet is picked up, it's forwarded to the provider's mobile core, which routes it to the right endpoint on the application side. To the application layer, an NTN link looks like a regular cellular session, supporting both uplink and downlink traffic, just with higher latency and a tighter link budget.<h2>Requirements</h2>To deploy an TN (Terrestrial Networks) + NTN solution, four pieces have to line up:<ol><li>A modem that supports both TN+NTN and 3GPP Release 17. Several vendors have shipped NTN-capable chipsets, including the <a target="_self" href="https://www.nordicsemi.com/Products/nRF9151/">Nordic nRF9151</a>, <a target="_self" href="https://www.murata.com/products/connectivitymodule/lpwa/overview/lineup/type-1sc">Murata Type 1SC</a>, <a target="_self" href="https://www.quectel.com/product/bg770a-sn-satellite-communication-module/">Quectel BG770A-SN</a>, <a target="_self" href="https://www.quectel.com/product/bg95-s5-satellite-communication-module/">Quectel BG95-S5</a>, <a target="_self" href="https://www.telit.com/devices/me310m1-series/">Telit ME310M1</a> (Skylo Certification in progress), and <a target="_self" href="https://www.sierrawireless.com/iot-modules/lpwa-modules/hl7812/">Semtech HL7812</a>.</li><li>Access to a satellite network. Nordic currently supports <a target="_self" href="https://www.skylo.tech/">Skylo</a> (Geostationary Earth Orbit, or GEO) and <a target="_self" href="https://sateliot.space/">Sateliot</a> (Low Earth Orbit, or LEO). You can work directly with these satellite operators, but several connectivity providers have already integrated Skylo’s satellite networks into their platforms, enabling a single SIM and a single platform to cover both ground and space. Skylo’s GEO-based network means the satellite is always overhead and data can be sent at will.</li><li>An antenna that handles the NTN frequency bands used in Mobile Satellite Services (MSS) spectrum. The antenna must support Band 255 (Global), Band 23 (N. America) and/or Band 256 (Europe). </li><li>A UDP server on the receiving side. NTN today is NB-IoT only, which means UDP traffic only. You need an endpoint that can receive it.</li></ol>Arguably, the biggest benefit of 3GPP NTN is the minimal rearchitecting required for existing IoT deployments. The same modem, SIM, and application logic can operate across both TN and NTN. Partners like Monogoto make this tangible with a single SIM that seamlessly falls back to satellite connectivity when terrestrial coverage drops, much like an MVNO roaming across multiple MNO networks.On paper, tons of businesses should be lining up to implement satellite connectivity into their use cases. But do they?<h2>Putting NTN to the Test</h2>Beyond the press releases, we wanted to see what an honest end-to-end NTN deployment looks like in 2026. So we built one ourselves. Every part is off-the-shelf, and the test can be replicated by anyone willing to do the work.Our setup contains:<ul><li>Nordic Semiconductor's<a href="https://www.nordicsemi.com/Products/nRF9151" target="_blank"> nRF9151 SiP</a> running the latest v1.0.0 NTN modem firmware.</li><li><a href="https://www.actinius.com/" target="_blank">Actinius Icarus</a> (pre-released) development kit built around the nRF9151 with onboard temperature sensor and accelerometer.</li><li><a href="https://www.kyocera-avx.com/" target="_blank">Kyocera AVX</a> NTN antenna, tuned for the satellite’s L-band frequencies</li><li><a href="https://monogoto.io/" target="_blank">Monogoto</a> SIM with native<a href="https://www.skylo.tech/" target="_blank"> Skylo</a> NTN integration</li><li><a href="https://tago.io/" target="_blank">TagoIO</a> IoT platform, with an integrated UDP server to store and process data.</li><li><a href="https://www.qoitech.com/" target="_blank">Qoitech Otii</a> power profiler, measuring the device’s energy consumption during the process of connecting to a satellite, sending and receiving data.</li></ul> <img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzc5MzU2ODc4MjQxLUlNR18yNzgzLkpQRyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6OTUwLCJmaXQiOiJjb3ZlciJ9fX0=" style="width:100%px" class="fr-fic fr-dib" />The NTN setup with an active GNSS antenna, Actinius Icarus development kit with the nRF9151, and the Kyocera AVX’s L-band antenna.The sanity check is built around three questions:<ol><li>Does it work?</li><li>At what price?</li><li>At what power budget?</li></ol><h3>Does it work?</h3>We started from Nordic's open-source <a href="https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase" target="_blank">Asset Tracker Template</a>, which already ships an NTN use-case branch. The only modifications needed were a light adapter to TagoIO's UDP endpoint and a reformat to match their lightweight telemetry format, <a href="https://tago.io/tip" target="_blank">TagoTIP</a>.Connecting to Monogoto required no separate provisioning step apart from enabling the Monogoto overlay at build time. The device booted, registered on Skylo, and started reporting in. From there, the Monogoto hub gave us live feedback on attach status, signal quality, and data flow.Power it up, and data showed up in the TagoIO dashboard. The verdict: yes, NTN works, with off-the-shelf parts and openly accessible firmware. <img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzc5MzU2ODE0NTIyLU1vbm9nb3RvIERhc2hib2FyZC5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width:100%px" class="fr-fic fr-dib" />Monogoto hub showing the live NTN connection<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzc5MzU2ODMwMTAwLVRhZ29JTy1kYXNoYm9hcmQucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width:100%px" class="fr-fic fr-dib" />you TagoIO dashboard, visualizing the location and temperature data<h3>At what price?</h3>Monogoto's NTN pricing to access Skylo's network is $0.30 per KB, billed in 50-byte increments (<a href="https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/" target="_blank">source</a>).During the test, the following payload was sent, which (including its overhead) contains a total of 152 bytes.<pre>&lt;code&gt;PUSH|&lt;token&gt;|&lt;device_id&gt;|[temp:=14.00#C@=52.089895,4.313049{device=*2519};x:=0.1532#m/s2;y:=0.0383#m/s2;z:=9.4611#m/s2]&lt;/code&gt;</pre>The sensor payload of 152 bytes rounds up to 200 bytes, which works out to roughly 6 cents per message. Send one every fifteen minutes for a month and you're looking at around $173 per device. Clearly this is not economically feasible and therefore NTN IoT device behavior should be treated differently than TN IoT device behavior.Compared head-to-head with terrestrial cellular, often under $0.01 per MB, NTN looks expensive, but that's the wrong comparison. NTN exists precisely where terrestrial coverage doesn't. When a device detects it has attached to an NTN network, it should shift behavior: reduce transmission frequency to the minimum operationally acceptable interval and strip payloads down to only the data that matters most. Most modern modem SDKs, including Nordic’s, expose the network access technology in use, so detecting the switch and triggering a different transmission policy can be accomplished. The real question isn't whether it's cheap in absolute terms, it's whether you can make the economics of your specific IoT business case work.<h3>At what power budget?</h3>One key question remains, does it work out with the available power budget of battery-driven devices? We challenged Qoitech to conduct an in-depth analysis of an IoT device sending data over satellite networks, and the outcomes are more interesting than expected, and we'll walk through it live. This and more will be shared in the upcoming webinar, happening on June 2!<h2>Join the live demo!</h2>Let's move past another article promising "ubiquitous connectivity" and show how the technology works in reality, giving real data about the pricing and power budget.We’re warmly inviting you to join the <a href="https://app.livestorm.co/iot-stars/the-non-terrestrial-networks-sanity-check?utm_source=iotstars&amp;utm_medium=wevolver" target="_blank" rel="noopener noreferrer">live webinar</a> on June 2, 4pm CEST / 7am PST. We'll send a message from a device to a non-terrestrial network, show the power trace as it happens, and put real numbers next to the cost and energy questions every NTN evaluation eventually runs into.On the agenda:<ul><li>A live, end-to-end NTN demo</li><li>Technical notes from Maor Efrati, CTO at Monogoto</li><li>Power analysis findings from Björn Rosqvist CPO at Qoitech</li><li>NTN antenna insights from Carmen Redondo, Director Global Marketing at Kyocera AVX</li><li>Open Q&amp;A</li></ul>See it for yourself and decide whether NTN has a place in your next IoT deployment.<a href="https://app.livestorm.co/iot-stars/the-non-terrestrial-networks-sanity-check?utm_source=iotstars&amp;utm_medium=wevolver" target="_blank" rel="noopener noreferrer">JOIN WEBINAR</a><hr />by<a href="https://www.linkedin.com/in/laurensslats/" target="_blank"> Laurens Slats</a> <a target="_blank">laurens@iotstars.com</a> Further reading:<ul><li>3GPPs NTN overview <a href="https://www.3gpp.org/technologies/ntn-overview" target="_blank">https://www.3gpp.org/technologies/ntn-overview</a></li><li>Monogoto NTN pricing:  <a href="https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/" target="_blank">https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/</a></li><li>Antenna performance:  <a href="https://www.everythingrf.com/community/from-earth-to-orbit-the-important-role-of-antennas-in-ntn" target="_blank">https://www.everythingrf.com/community/from-earth-to-orbit-the-important-role-of-antennas-in-ntn</a></li><li>Skylo’s coverage map:  <a href="https://www.skylo.tech/resources/geographical-coverage" target="_blank">https://www.skylo.tech/resources/geographical-coverage</a></li><li>Asset Tracker Template for NTN use cases:  <a href="https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase" target="_blank">https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase</a></li></ul>

NTN modems are "ready for production." But is it, really? And at what cost?

The Satellite IoT Sanity Check

In medical devices, automotive systems, and industrial automation, software is a regulated component of the product itself. That changes what "good enough" means for a build process. A binary you cannot reproduce is a binary you cannot validate, and a build environment you cannot audit is a liability in every certification cycle you run.Despite this, many embedded teams still operate with manual or loosely controlled build processes: toolchains installed directly on developer machines, no enforced versioning, and test and analysis steps that run inconsistently, if at all. The problems this creates are well understood in theory but chronically underestimated in practice. Build reproducibility directly affects validation scope, certification timelines, and release predictability.CI/CD pipelines provide a structured path out of this. Automated builds, integrated analysis, and containerized environments together standardize execution, generate compliance evidence continuously, and reduce the audit burden at release time. Adoption does not require a dedicated DevOps team or a full infrastructure overhaul. Teams can start with automated builds alone and extend the pipeline incrementally from there.<h2>The Real Price of "Good Enough" Build Processes</h2>The most immediate problem with uncontrolled build environments is variability. When each developer maintains their own toolchain configuration, subtle differences accumulate, from compiler versions to library paths, optimization flags, and environment variables. Two developers building the same commit may produce different binaries. In most software contexts, this is inconvenient; in regulated development, it is a compliance failure waiting to materialize.Unqualified or non-certified toolchains compound this. During audits, teams must self-justify tool behavior, documenting that a given compiler version produces correct output under the conditions used. This is significant validation work that certified toolchains eliminate by shifting that burden to a qualified third party.The downstream effects are predictable. When defects are found late, as they inevitably are when analysis and testing run manually or infrequently, debugging requires first reconstructing the environment the defect occurred in. That reconstruction may not be possible if the environment state was never captured. Troubleshooting build and pipeline failures alone can consume up to <a href="https://www.iar.com/blog/enabling-consistent-workflows-with-cloud-enabled-solutions">40% of development time</a>, time that should be going toward innovation, testing, and actual feature work.Audit preparation in these environments is largely manual. Engineers assemble evidence from disparate sources: build logs from one system, test results from another, and analysis outputs from a third. Certification timelines extend unpredictably not because the product is unsafe but because the documentation trail is incomplete or inconsistent. Engineering effort shifts toward rework and environment management rather than toward the product.<h2>Anatomy of an Embedded CI/CD Pipeline</h2>A well-structured embedded CI/CD pipeline follows a 5-stage, fixed sequence: Code → Build → Analyze → Test → DeployCode commit triggers build, which feeds into static analysis, which gates automated testing, which then produces validated artifacts for deployment. Each stage is automated, version-controlled, and produces structured outputs.<a href="https://www.iar.com/embedded-development-tools/embedded-ci-cd?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver" target="_blank" rel="noopener noreferrer"><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1777030324914-image1.png" style="width:100%px" class="fr-fic fr-dib" />A Modern CI/CD Workflow. Credit: IAR</a>The value of this goes beyond speed. The pipeline becomes a system of record. Build logs, analysis reports, and test results are generated automatically on every run, linked to the specific commit that produced them. The path from source code to deployed binary is fully traceable and reproducible. When a regulator asks for evidence that a given artifact was built from a known state and tested against defined criteria, that evidence exists and is organized.Continuous validation through static analysis and runtime checks, integrated directly into the pipeline, shifts defect detection to the earliest possible point. A coding standard violation found at commit time costs minutes to address. The same violation found during integration testing can cost days.<h2>Containerization: The Foundation for Consistency</h2>Reproducibility requires that the build environment itself is controlled and versioned. <a href="https://www.iar.com/blog/a-new-chapter-for-our-docker-support-introducing-the-iar-cloud-ready-containers-repository?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">Containers</a> solve this directly. Packaging the toolchain, compiler flags, analysis tools, and all dependencies into a versioned container image means every pipeline run, whether on a developer's workstation, a cloud runner, or an on-premises CI server, executes in an identical environment.This has a direct compliance benefit. Qualification effort can be focused on the container image rather than each developer's local setup. Once the toolchain configuration inside a container is qualified, that same configuration runs identically everywhere, eliminating the risk that a local toolchain update silently changes the environment under assessment. When <a href="https://www.iar.com/embedded-development-tools/functional-safety?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">TÜV-certified</a> toolchains are packaged inside containers, the certified boundary is clear and fixed. The container image itself becomes auditable: its contents are known, its version is tracked, and its behavior is consistent across infrastructure.Isolated container environments also provide a security boundary. Dependencies cannot drift silently, and there is no ambiguity about which version of a tool was used for a given build.<h2>Performance and Quality Gains You Can Measure</h2>The shift to automated, containerized pipelines produces concrete gains.<a href="https://www.iar.com/embedded-development-tools/embedded-ci-cd?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver"> IAR Build Tools</a> on Ubuntu deliver build times roughly twice as fast as equivalent Windows-based workflows, and <a href="https://www.iar.com/embedded-development-tools/code-quality-and-compliance?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">C-STAT</a> static analysis runs approximately 3.5 times faster. Across build and debugging effort combined, automated analysis with pre-qualified toolchains reduces total time by 50 to 80 percent.C-STAT enforces MISRA C/C++, CERT C/C++, and CWE coding standards across every pipeline execution. At that speed advantage, comprehensive standards coverage stops being a bottleneck and becomes a continuous, low-friction part of the build process. Quality metrics follow a similar pattern. Continuous enforcement of coding standards on every commit, rather than periodic manual review, produces roughly a <a href="https://www.iar.com/embedded-development-tools/code-quality-and-compliance">41% reduction in defect injection rates</a>. Defects caught earlier in the pipeline require significantly less effort to fix, and downstream testing loads decrease as a result.These are not marginal improvements. For teams operating under release pressure in regulated markets, halving build and debug time while reducing late-cycle defects directly affects both certification timelines and product quality.<h2>Starting Small: Incremental Adoption</h2>CI/CD adoption in embedded development does not require a dedicated DevOps team or a large infrastructure investment. The risk of incremental adoption is low: starting with automated builds does not disrupt existing workflows or trigger re-validation requirements.The practical entry sequence is to automate builds first, capturing the toolchain configuration and making builds reproducible. Then, introduce static analysis as a pipeline gate. Afterwards, you add automated testing. At each step, containerized environments simplify setup and make the expanded pipeline portable. Teams retain ownership of their pipelines throughout. The incremental approach also means compliance evidence accumulates progressively rather than requiring a large documentation effort at the end of a release cycle.<h2>Enabling Embedded CI/CD with IAR </h2>IAR's toolchains are built for automation-first workflows. IAR Build Tools are headless, scriptable, and integrate with standard CI platforms including GitHub Actions, GitLab CI, and Jenkins. Static analysis through C-STAT and runtime verification through C-RUN run inside pipelines without manual intervention. Toolchains pre-certified to IEC 61508 (industrial automation), ISO 26262 (automotive), and IEC 62304 (medical devices) reduce the validation work teams must do themselves during certification.Cloud-based licensing removes the constraint of node-locked licenses tied to specific machines, enabling consistent workflows across local development, cloud runners, and on-premises systems. Support for over 20 processor architectures means teams working across device families can standardize on a single toolchain ecosystem without being forced into architecture-specific tool fragmentation.IAR Embedded Trust extends pipeline automation to firmware security. Automated signing and encryption within the pipeline integrates security requirements from CRA and UN R155/R156 directly into the build process rather than treating them as post-build steps.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1777030409990-image2.png" style="width:100%px" class="fr-fic fr-dib" />Credit: IAR<h2 id="isPasted">Conclusion</h2>Build reproducibility in modern embedded development is the foundation that compliance work depends on. Automated workflows, built on certified toolchains, ensure consistent execution, validation, and traceability from commit to deployed artifact. An environment that cannot consistently reproduce a binary cannot validate, certify, or maintain it.Regulatory expectations around software development processes are continuing to formalize across medical, automotive, and industrial sectors. Teams that establish reproducible pipelines now gain direct control over their development timelines and compliance readiness, rather than discovering gaps under deadline pressure during certification. The cost of manual builds is always higher than it appears, and it compounds with each release cycle.

This article explores how automated CI/CD pipelines replace fragile manual build processes with reproducible, auditable workflows that improve compliance, reduce defects, and accelerate development in regulated embedded systems

embedded development

ORGANIZATIONS. SHAPING THE INDUSTRY.

Latest Posts

STM32 Microcontroller: Cores, Peripherals & Tools

With vs. Without: An AI Coding Assistant on a Real Sensor-Driven Embedded Design

Robotics Lab at embedded world North America

Why MedTech Teams Can No Longer Afford Fragmented Development

The Satellite IoT Sanity Check

The Hidden Cost of Manual Builds: Why Teams in Regulated Sectors Must Embrace CI/CD