Embedded AI moved from concept to working prototype at the first-ever embedded world North America Hackathon, where student teams were challenged to turn real-world problems into functional Edge AI solutions.The competition brought together 52 students across 12 teams, who had two days to develop solutions across four challenges: industrial automation, sensing, sustainability and robotics. Each team worked with an Arduino UNO Q, while the hackathon was powered by Arduino, Qualcomm, Quilter and ASUS.[1]<h2>Two Days of Learning, Building and Problem-Solving</h2>Rather than simply proposing concepts, participants had to develop working solutions within a tightly constrained timeframe. Teams had to learn unfamiliar tools, build hardware and software systems, train or integrate AI models, troubleshoot problems and demonstrate their results.That intensity was reflected in comments from Giovanni Salinas, Technical Advisor and Judge from Supplyframe, who said the challenges required students to learn new skills before they could even begin developing their solutions. He praised their drive, positive energy and problem-solving approach throughout the two-day event.Ben Jordan, Judge from Quilter, highlighted another dimension of the competition. He noted that although the solutions were creative and technology-driven, the results showed the continuing importance of human judgement in deciding what should be built and how technology should address practical problems.<h1><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928144-1791997928143.jpeg" width="602" height="401" class="fr-fic fr-dii" />Team 10. Source: Supplyframe.</h1><h2>Sustainability: ZOT ROT or NOT</h2>Team 10, ZOT ROT or NOT, won the Sustainability Challenge with a camera-powered conveyor designed to distinguish recyclable material, organic waste, and trash. [1]The team's Hackaday.io project describes a system in which a camera captures objects moving along a conveyor while the Arduino UNO Q processes the images locally. The system classifies items into the three categories and communicates the result to an OLED display, LEDs, and the sorting mechanism. [2]The team also documented its Edge Impulse object-detection model. Its initial unoptimised model achieved 89.6% validation accuracy, with an estimated on-device latency of 5 milliseconds. [3]<a href="https://hackaday.io/project/206767-zot-rot-or-not" target="_blank" rel="noopener noreferrer">Explore ZOT ROT or NOT on Hackaday.io</a>The project demonstrated a practical application of local computer vision: instead of relying on remote processing, the classification pipeline operates directly on the embedded system.<h1><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928150-1791997928150.jpeg" width="602" height="401" class="fr-fic fr-dii" />Team 5. Source: Supplyframe.</h1><h2>Robotics: EmbedX</h2>Team 5, EmbedX, won the Robotics Challenge with an on-device AI system for robotic motion and navigation.[1]The project combined machine vision with robotic control, demonstrating how an embedded platform can connect perception with physical movement. The challenge highlighted an important characteristic of Edge AI: intelligence becomes more valuable when it can respond directly to information collected from the surrounding environment.Rather than treating AI as a separate software function, the project connected sensing, computation, and physical action into a single system.<a href="https://hackaday.io/project/206753-team-embedx-robotics" target="_blank" rel="noopener noreferrer">Explore the EmbedX Robotics project on Hackaday.io</a><h1><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928156-1791997928156.jpeg" width="602" height="401" class="fr-fic fr-dii" />Team 3. Source: Supplyframe.</h1><h2>Industrial Automation: CRATE</h2>Team 3's CRATE — Chironomy Recognition As A Touchless Experience won the Industrial Automation Challenge.[1]The project uses an Arduino UNO Q, a camera, and a gesture-recognition model to identify hand gestures and translate them into commands. The team's Hackaday documentation states that it used a YOLOv5-based classifier and a dataset containing more than 450 images captured during the hackathon. [4]The final system reportedly achieved an average inference time of about 175 milliseconds and a 0.94 mAP@50 score, while displaying recognised gestures through the Arduino's LED matrix. [5]CRATE demonstrated how computer vision can be used to create alternative human-machine interfaces, particularly in environments where touch-based interaction may not always be convenient.<a href="https://hackaday.io/project/206741-crate-ewna-hackathon-team-3" target="_blank" rel="noopener noreferrer">Explore CRATE on Hackaday.io</a><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928162-1791997928162.jpeg" width="602" height="401" class="fr-fic fr-dii" />Team 8. Source: Supplyframe.<h2>Sensing: Zotduino</h2>Team 8, Zotduino, won the Sensing Challenge with a sound-event classification system designed around the needs of an elderly person living alone. [1]The concept focused on recognising potentially important household sounds, including events such as falls, broken glass and fire alarms, while maintaining privacy. According to the team's project documentation, sound classification was performed locally on the Arduino UNO Q, meaning audio did not need to be sent away from the device for processing. [6]The team explained that its design deliberately avoided cameras and cloud-based audio processing. A local classifier analyses the sound, while the system can provide a visual indication through an LED matrix.[6]This approach demonstrated one of the practical benefits of Edge AI: intelligent sensing can happen close to the data source while reducing the need to transmit sensitive information elsewhere.<a href="https://hackaday.io/project/206738-ewna-hackathon-team-8" target="_blank" rel="noopener noreferrer">Explore Zotduino on Hackaday.io</a><h2>Making Embedded AI More Accessible</h2>Across the four winning projects, a common theme emerged: AI was not treated as an isolated software capability. Each team connected machine learning with physical hardware, sensors and real-world actions.Rajan Mistry, a judge from Quilter, described the experience as an opportunity for students to learn new technologies, overcome engineering challenges and turn ideas into reality. He also pointed to platforms such as the Arduino UNO Q as making innovation more accessible.The projects reflected that accessibility in different ways. ZOT ROT or NOT applied computer vision to waste sorting; CRATE used vision for touchless interaction; Zotduino explored privacy-conscious sound classification; and EmbedX connected AI with robotics.<h1><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928168-1791997928168.jpeg" width="602" height="401" class="fr-fic fr-dii" />2026 embedded world North America Hackathon. Source: Supplyframe.</h1><h2>From Ideas to Working Systems</h2>The 2026 hackathon demonstrated the growing practicality of Edge AI in embedded development. Students took a problem, selected appropriate sensing and computing tools, integrated AI, and built a working prototype in just two days. [1]Perhaps the most important takeaway was not any single project, but the workflow shared by all four teams: understand a practical problem, experiment with available technology, iterate quickly, and connect intelligence to the physical world.As embedded AI continues to develop, that ability to move quickly from an idea to a functioning system could become increasingly important. The hackathon clearly demonstrated that the next generation of embedded engineers is already experimenting with that approach.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1791997928173-1791997928173.jpeg" width="602" height="401" class="fr-fic fr-dii" />2026 embedded world North America Hackathon Sponsors. Source: Supplyframe.<hr /><h3>References</h3><ol><li>Hackaday. Post-event announcement for the first-ever embedded world North America Hackathon. LinkedIn, 2026.<a href="https://www.linkedin.com/company/hackaday/"> https://www.linkedin.com/company/hackaday/</a></li><li>Hackaday.io, “ZOT ROT or NOT.” Project description and system overview for the camera-powered waste-sorting conveyor using Arduino UNO Q. https://hackaday.io/project/206767-zot-rot-or-not </li><li>Hackaday.io, “Object Detection Model ZOT ROT or NOT.” Model accuracy, dataset and on-device latency details. https://hackaday.io/project/206767-zot-rot-or-not/log/251074-object-detection-model </li><li>Hackaday.io, “CRATE: EWNA Hackathon Team 3 — Files.” Dataset and YOLOv5 model information. https://hackaday.io/project/206741-crate-ewna-hackathon-team-3</li><li>Hackaday.io, “CRATE: EWNA Hackathon Team 3  Final log.” Inference performance, model score and system details. https://hackaday.io/project/206741-crate-ewna-hackathon-team-3/log/251101-final-log</li><li>Hackaday.io, “EWNA Hackathon Team 8 — How we came up with the idea.” Privacy-focused sound classification concept and local processing approach. https://hackaday.io/project/206738-ewna-hackathon-team-8/log/251059-how-we-came-up-with-the-idea</li></ol>

Highlights from the 2026 embedded world North America Hackathon

Edge AI in Action

Most engineering organizations ship something they would rather a competitor never saw. In cloud software, that code stays on a server the company controls. In embedded products, however, it does not, because the software that defines the product gets compiled, flashed, and handed to whoever buys the device.That gap carries a real price. The Institute for Employment Research (IAB) puts the economic damage from industrial and economic espionage at roughly $400 billion a year in the United States, about 2.1 percent of GDP, and around €200 billion in Germany. Its 2025 survey also found that 22 percent of German firms conducting research and development confirmed an espionage attack in the previous five years, compared with 8.3 percent of those without an R&amp;D function [1]. Innovation, in other words, attracts attention.Automotive is a particularly clear case. A single electronic control unit (ECU) can hold years of calibration work, a proprietary control algorithm, and cryptographic keys, all within one binary. This article looks at why that binary is exposed by default, what modern tooling can pull out of it, and how <a href="https://emproof.com/en/solution">Emproof's Nyx</a> hardens it in place.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790776375099-Emproof_Binary-Protection_Automotive.jpg" style="width:100%px" class="fr-fic fr-dib" />Emproof Binary Protection for Automotive. Source: emproof<h2>The Binary Is the Real Attack Surface</h2>Firmware leaves the building through more doors than most teams count. Most microcontrollers expose a debug or readout interface, and over-the-air update packages can often be downloaded and unpacked [2]. Diagnostic interfaces sit on the vehicle bus. In automotive programs specifically, binaries also move routinely between Tier 1 suppliers and OEMs as a normal part of integration work.Once someone has the file, the tooling is free. Ghidra, the reverse engineering suite released by the US National Security Agency, disassembles the image, reconstructs control-flow graphs, and decompiles machine code into C-like pseudocode. Signature databases identify known library functions, while constant-finder plugins locate cryptographic routines by their lookup tables [2].In practice, an analyst can therefore find the function that validates a license, read the conditions gating a paid feature, or locate a hardcoded key by pattern rather than by luck. None of this requires access to the original source code.<h3>Why Readout Protection Is Not Enough</h3>Readout protection is a single barrier, and a hardware one at that. Fault injection, which glitches supply voltage or clock timing at precisely the right instant, can skip the check outright, while bootloader logic bugs and side-channel methods offer other ways in [2].It also guards only one path, doing nothing about an image pulled from an update server or shared with an integration partner. Meanwhile, the code underneath stays fragile, since roughly 70 percent of severe vulnerabilities at major technology companies trace back to memory-safety issues, and about 80 percent of embedded systems will continue to rely on C and C++ over the next decade.<h2>Large Language Models Lowered the Skill Barrier</h2>Decompilation was never the real bottleneck. Interpreting the output was always the slower and more expensive half of the job.Ghidra hands back pseudocode full of names such as FUN_0800a1c4 and undefined4 uVar7, and turning that into a working understanding of the code has traditionally required an experienced engineer and a considerable number of hours. That step is now largely automated. When decompiler output is fed to a capable large language model (LLM), the model will describe a function's purpose in plain English, propose meaningful variable names, annotate the control flow, and flag branches that resemble a licensing or safety check.The shift is economic rather than technical. Analysis that once cost expert-days now costs minutes, so an attacker can review far more binaries, and someone without deep reverse engineering experience can still obtain useful results. Complexity was never security, although it did reliably buy time, and that time is now shrinking.<h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790702404656-1790702404656.jpeg" width="624" height="367" class="fr-fic fr-dii" />Close-up of an electronic board with components. Source: AdobeStock. </h2><h2>What Emproof Nyx Does to the Compiled Binary</h2><a href="https://emproof.com/en/home">Emproof</a> is a German embedded security company, and Nyx is its binary transformation tool. It runs after compilation, directly on the binary, with no source code requirement and no hardware change. As a result, it can also be applied to third-party, legacy, and already-deployed firmware.<a href="https://emproof.com/en/nyx-microcontroller">Nyx Microcontroller</a> applies several layers of protection in a single pass:<ul><li>Control-flow obfuscation restructures the code layout so that decompiler output no longer mirrors the original program structure.</li><li>Secret hiding conceals keys and sensitive data held inside the image.</li><li>Anti-tamper checks the deployed image against a verified reference at startup, then triggers a response defined by the manufacturer, such as entering a safe state.</li><li>Anti-debug and anti-emulation techniques frustrate dynamic analysis on a live device.</li><li>Exploit mitigation adds stack canaries and control-flow integrity (CFI) to defend against memory-corruption attacks.</li></ul>Because these transformations rewrite the binary, correctness matters as much as protection. Emproof therefore preserves program semantics and uses formal methods, including translation validation, to prove that the transformed code behaves as the original did [3].<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790776477002-Emproof_Code-Hardening+Kopie.jpg" style="width:100%px" class="fr-fic fr-dib" />Source: emproof<h3>Overhead and Toolchain Integration</h3>Weight and runtime are the reasons embedded code so often ships unprotected. Emproof puts typical memory overhead for Nyx at 10 to 15 percent, and that figure is tunable. Engineering teams can protect the full image or scope transformations to specific modules, optimize each one for size or for speed, and exclude sections with hard real-time deadlines [3].For integration, the tool ships as a Docker container that drops into pipelines such as Jenkins, GitLab CI, GitHub Actions, and Azure DevOps, through a command-line interface (CLI) or a REST API. Analysis and transformation run entirely inside the customer's own infrastructure, and reproducible builds and delta testing keep the tool compatible with existing verification workflows.<h2>Why This Lands Hardest in Automotive</h2>Nyx Microcontroller covers the architectures that dominate automotive design, including Infineon AURIX (TriCore), Arm Cortex-M and Cortex-R, and Renesas RH850 [4]. The requirements tighten further in safety. A compromised braking or steering ECU is not only an intellectual property (IP) problem; it is a functional safety one. The enterprise edition of Nyx therefore carries ISO 26262 ASIL-D certification, the highest Automotive Safety Integrity Level, assessed by TÜV Nord, and it generates audit artifacts for safety documentation [4, 5]. One of the world's largest Tier 1 suppliers is a reference customer.Regulation pushes in the same direction. UNECE WP.29 R155 ties vehicle type approval to a certified cybersecurity management system [6], ISO/SAE 21434 defines the engineering process behind it [7], and the EU Cyber Resilience Act extends secure-by-design obligations to connected products more generally [8].<h2>Protection at the Binary Level Becomes the Baseline</h2>Firmware IP protection is shifting from a differentiator to an expectation. The binary was always readable, but what has changed is that reading it now takes hours instead of weeks, and regulators have started asking manufacturers what they did about it.Working at the binary level is what makes the answer practical, since it doesn't require rewriting, silicon changes, or recompiling of code a supplier may not even own, at an overhead small enough for devices that previously had no room for security at all. Emproof offers browser-based demos for engineers who want to see what the transformed output looks like.<hr /><h3>References</h3>[1] A. Glitz, S. Kohaut, and I. Möller, "Nine percent of businesses fall victim to espionage," IAB Short Policy Report, no. 2/2025, Institute for Employment Research, Nuremberg, Germany, May 2025. [Online]. Available: https://doku.iab.de/kurzber/2025/kb2025-02_en.pdf [2] Emproof, "Defend against the threat of reverse engineering with Emproof Nyx." [Online]. Available: https://emproof.com/en/reverse-engineering. [Accessed: Aug. 2, 2026].[3] Emproof, "Solution: Emproof Nyx." [Online]. Available: https://emproof.com/en/solution. [Accessed: Aug. 2, 2026].[4] Emproof, "Nyx Microcontroller." [Online]. Available: https://emproof.com/en/nyx-microcontroller. [Accessed: Aug. 2, 2026].[5] Emproof, "Emproof Nyx awarded ISO 26262 certification for functional safety in automotive components." [Online]. Available: https://emproof.com/news-posts/emproof-nyx-awarded-iso-26262-certification-for-functional-safety-in-automotive-components/. [Accessed: Aug. 3, 2026].[6] United Nations Economic Commission for Europe, UN Regulation No. 155 — Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system, Geneva, Switzerland, 2021.[7] ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering, International Organization for Standardization, Geneva, Switzerland, 2021.[8] European Parliament and Council of the European Union, Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Oct. 2024.

A modern vehicle's competitive advantage lies in compiled firmware. Binary-level protection secures that code without source access, hardware changes, or a heavy memory budget.

The Growing Cost of Embedded IP Theft and How Firmware Hardening Helps

<h2 id="isPasted">The AI Moment in Embedded Software</h2>There is a gap between the industry narrative of what AI can achieve and the actual constraints of what engineers realistically face. Leaders and the media describe models that can reason, plan, and act with almost total autonomy, while engineers face serious real-world engineering challenges such as code certification, legacy code, and trustworthy AI analysis. This is where most of the authentic conversation about AI in embedded systems happens.The current development of AI solutions in embedded software is following two distinct paths. The first path is how AI is being applied when embedded software is built, for example through code generation assistants, static analysis tools, or test generation. AI is already performing well in this domain, because the constraints are the same ones that have governed software tooling for decades. AI is good at maintaining accuracy, traceability, and compliance. TASKING has decades of <a href="https://www.tasking.com/products/#compiler-toolsets">compiler and IDE development</a> focused on driving correct, efficient code, which is a natural foundation for AI-assisted tooling.At the same time, stakeholders and industry marketers promote a vision that is heavily focused on on-device deployment, such as running complex AI models directly on embedded targets. However, on-device AI in safety-critical systems remains in its early stages. Not every microcontroller requires a neural network or an LLM; in fact, much of what is labeled "AI-enabled" in production today is classic signal processing or a well-tuned control loop under a modern marketing label. While on-device inference is progressing, tools, verification workflows, and AI-assisted development productivity are advancing far more rapidly.<h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790615447989-1790615447989.png" width="624" height="416" class="fr-fic fr-dii" />IC7 Mini on the desk. Source: TASKING.Understanding the Engineering Tradeoffs Nobody Can Skip</h2>Embedded engineers have always worked inside the following dimensions: performance, power, memory, and cost. AI adds a fifth dimension that doesn’t sit neatly alongside the other four. Every gain in model capability tends to cost latency, power, or memory, and sometimes all three.Deploying neural networks on embedded targets requires adapting models to run efficiently within kilobytes of RAM and flash memory. Standard techniques like model pruning and quantization reduce execution precision to lower footprint, but achieving real-time performance on accelerators like vector DSPs depends on toolchain-level optimizations. TASKING’s compiler and tooling ecosystem support this deployment pathway through advanced compiler scheduling, vectorization libraries, efficient memory tiling with DMA transfers, and hardware tracing tools like the <a href="https://www.tasking.com/products/bluebox/ic7pro-bluebox/" target="_blank" rel="noopener noreferrer">iC7 pro</a>—enabling up to a ~70x inference speedup on specialized architectures like the Infineon® AURIX™ TC4x.Consider a vibration-monitoring node for predictive maintenance. A float32 network works well in a cloud prototype, but the deployed device has a small RAM budget and must run for years on a battery. An int8 model with fewer layers, fed by conventional feature extraction, may score slightly lower on benchmarks and still be the better system: predictable timing, lower power, simpler validation, and a viable bill of materials.Safety requirements add another layer. For a fixed model graph, inference time is usually quite predictable. More difficultly, outputs are statistical rather than derived from a requirement, which complicates verification, and that timing can still vary with memory contention on multicore devices. Automotive and industrial projects under <a href="https://www.iso.org/standard/68383.html">ISO 26262</a> and <a href="https://webstore.iec.ch/en/publication/5515">IEC 61508</a> still need bounded execution time, bounded memory, controlled failure modes, and auditable evidence. Moreover, <a href="https://webstore.ansi.org/standards/iso/isopas88002024">ISO/PAS 8800:2024</a> addresses AI in road vehicles more specifically.In this landscape, the toolchain matters here for a concrete reason. Model converters and inference libraries emit C or C++ that a compiler turns into the final binary. Optimization quality, code-size control, debug visibility, and timing analysis then decide whether the model fits and meets its deadlines. As models shrink to fit hardware, this stage matters as much as the model architecture. TASKING's qualified compilers and libraries are built for it.TASKING’s toolchain provides compelling value propositions for embedded software engineers. The company offers a strong safety and security ecosystem, which includes certified code-generation tools and libraries. At the same time, TASKING’s broader offerings span debug, trace, test, static analysis, automated testing, structural coverage, and requirements traceability.<a href="https://www.tasking.com/products/smartcode-aurix-tc4x/" target="_blank" rel="noopener noreferrer"><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790615447996-1790615447996.png" width="458" height="308" class="fr-fic fr-dii" />SmartCode, Software development environment of certified compiler toolsets for Infineon AURIXTM TC4x microcontrollers.  Source: TASKING.</a><h2>AI in Embedded Software Through TASKING's Lens</h2>Everyone involved in the embedded software industry is working through what AI means for their products, and TASKING is no exception. Across their portfolio, that work shows up as exploration into smarter static analysis, AI-assisted development workflows, and tooling built to handle embedded AI targets. These tools are ongoing work, rather than a finished product line. What stays consistent for TASKING is the underlying discipline. TASKING's compiler, debugger, and test &amp; verification tools exist to produce code that is efficient, traceable, and certifiable, and any AI capability layered onto that portfolio must serve those same goals. Smarter static analysis that catches defects earlier is valuable because it strengthens the certification case, not because it makes the tooling sound more advanced.AI won't replace deterministic engineering disciplines in embedded systems, and no credible toolchain vendor should suggest otherwise. But what AI will do is change the workflows engineers use to write, verify, and optimize code. TASKING is working to provide engineers with the skill set embedded teams need to keep up. TASKING is a partner for embedded teams navigating the transition, not another voice adding to the hype of idealized, unrealistic AI solutions.AI is changing how embedded software has traditionally been developed, and a trusted, integrated toolchain is what makes the actual difference within this shift. Explore <a href="https://www.tasking.com/compile-debug-test/">TASKING's integrated toolchain for AI-ready embedded development</a> to see what that looks like in practice.

AI-ready tools for embedded development evolve how engineers address real-world challenges.

Beyond the Hype: What AI Actually Changes for Embedded Software Engineers

Physical AI is one of the fastest-moving fields in engineering today, and it presents significant design challenges for engineers. Whether in robots, driver assistance systems, or factory equipment, Physical AI platforms need sufficient compute to sense the physical world, process data, and make decisions in real time. Physical AI combines both AI inference with real-world interaction and closed-loop control. The systems must act locally and make decisions immediately in order to perform the required actions. The challenge is that designers usually source processor IP from one vendor and manufacture it with another. When neither supplier is accountable for the combined result, teams can end up with over-provisioned or unoptimized chips that leave performance, efficiency, and cost on the table.In August 2025, GlobalFoundries completed its acquisition of MIPS, giving MIPS unique access to a foundry and setting it apart from the rest of the IP market. As the #2 IP provider overall and the leader in RISC-V IP, <a href="https://www.wevolver.com/article/how-mips-is-powering-physical-ai-with-risc-v-and-software-to-silicon-development" target="_blank" rel="noopener noreferrer">MIPS goes beyond licensing processor IP alone</a>—delivering software tools, custom solutions, and complete platforms alongside GlobalFoundries' differentiated process technologies and manufacturing capabilities. Now, chip design teams can leverage that combination to develop Physical AI designs from concept through production.<h2>Silicon Challenges for Physical AI</h2><h3>Timing Constraints</h3>When <a href="https://mips.com/markets/physical-ai/">designing Physical AI systems</a>, one challenge is achieving fast and consistent response. In the real world, a delayed result can mean the difference between life and death, making timing a first-order design constraint. For example, a braking controller or robotic arm can't tolerate variable interrupt latency because the control loop depends on predictable timing, and the silicon must consistently meet those timing requirements. But improving latency isn’t as simple as using an accelerator, as designers do in data centers.  AI accelerators tend to optimize average throughput above all else and leave worst-case response time unbounded. In data centers, that trade-off is acceptable because an occasional slow result only means a user waits slightly longer. In Physical AI systems, however, response consistency matters more than average speed. Consider a warehouse robot detecting a worker in its path: if its processor meets the deadline 99 times but misses it once, the robot may collide or injure a human. Engineers therefore need deterministic compute that responds at a defined interval on every cycle, not just on average.<h3>Power and Thermals</h3>Beyond timing, designers are limited by power constraints in edge systems. First, the portable nature of many Physical AI systems means they often rely on battery power, limiting the energy available for computation. Meanwhile, many real-world systems require fully sealed enclosures, where passive cooling may be the only practical option. Designers must therefore balance minimal power consumption with limited thermal headroom while supporting demanding on-device AI workloads.<h3>Certification and Longevity Requirements</h3>In highly regulated industries such as automotive, aerospace, and industrial, customers need functional-safety evidence that extends down to the device’s processor architecture and its development process. To this end, the processor IP needs to come with the documentation, evidence, and safety capabilities required to support the system-level safety case. Meanwhile, these stringent markets can also entail extremely long product lifecycles. OEMs in these markets expect products and components to remain available for over a decade on average. When a processor changes mid-life, engineers often need to repeat qualification and safety certification, adding significant cost and schedule risk.<h3>Mixed Workloads</h3>The final challenge in designing Physical AI systems is handling the mixed workloads inherent to such applications. Systems like humanoid robotics rely on both real-time control and AI inference in the same system. However, these workloads have different architectural requirements: control logic depends on predictable latency, while AI inference depends heavily on raw throughput.For example, to keep a humanoid robot balanced, engineers typically program its joint controllers to update motor commands at fixed intervals, often thousands of times per second. A late update, even by a fraction of a millisecond, can destabilize the robot’s gait. Meanwhile, the robot’s vision model must process camera frames to recognize objects, where overall throughput matters more than the timing of any single operation.In that context, optimizing a core for one workload can compromise the requirements of the other.<h2>From IP Vendor to Foundry</h2>Design teams need to decide on an instruction set architecture (ISA) and an IP vendor early, then choose a foundry later. These decisions significantly impact the final chip's power, performance, and area (PPA). Yet teams often make them before anyone can evaluate the processor IP’s behavior on the specific manufacturing process ultimately selected.Foundries are typically manufacturing providers, entering the conversation only after the architecture is fixed. Unfortunately, that split creates a gap in accountability because no single supplier is accountable for the combined result if the IP reaches silicon and underperforms. The IP vendor may point to the process, while the foundry may point to the microarchitecture, leaving the design team to absorb the resulting cost and schedule impact.Meanwhile, licensing terms further narrow the options. Teams licensing a proprietary ISA end up paying more with less flexibility to customize the underlying microarchitecture, making it harder to tune the core against a specific PPA target. To correct a PPA shortfall after tapeout, teams can order a silicon respin that takes up significant time at a point in the program where schedule pressure is already highest.<h2>Platform-Level Silicon Partners</h2>Chip designers can avoid these issues if they can work with one supplier that brings processor IP and manufacturing capabilities together. By owning both processor IP and process technology, suppliers can tune PPA holistically, treating the core and the process as a single optimization target rather than two fixed inputs. Design teams can then predict a core’s behavior on specific processes earlier in the design cycle, moving the PPA question out of post-tapeout measurement and into the architecture phase.One accountable supplier can also help design teams meet power or die-area requirements. When a design comes in over budget on either, the team has one partner that can evaluate changes to the microarchitecture, process technology, or both, instead of two vendors negotiating around a shared problem.<h3>Providing an Extensive Processor IP Portfolio</h3>When selecting a supplier, another factor to consider is their ISA.For instance, a supplier using an open ISA such as RISC-V can give design teams greater architectural flexibility without requiring them to license a proprietary ISA. Open ISAs also attract a community of vendors, universities, and independent tool developers, giving design teams access to expertise beyond the IP supplier's own support engineers. The same community supplies a growing foundation of tools, reducing dependence on a single vendor's roadmap for compilers, debuggers, and verification collateral.For Physical AI designs, an open ISA’s architectural flexibility helps teams address several of the challenges outlined earlier. Vendors can layer optional extensions, such as vector and matrix instructions, on top of a shared base instruction set. As a result, engineers can build deterministic control cores and AI inference engines on the same ISA foundation. Teams can also add custom instructions to accelerate specific control or AI functions, trimming the power and die area a general-purpose core would waste. That independence from a single vendor’s roadmap also matters for longevity, letting teams better sustain their software investment across the decade-plus lifecycles of automotive and industrial products.<h2>Pre-Silicon Workload Modeling</h2>Finally, portfolio breadth and flexibility help only if a team can easily evaluate its options. In practice, engineers need tools that can model real software on candidate hardware configurations before tapeout because it’s far less costly to identify a bottleneck in simulation than in tapeout, when addressing it may require a silicon respin. By working with suppliers that offer accurate simulation and modeling tools, teams can properly tailor a core to their workloads without wasted power or die area. In turn, they can reach the foundry with greater confidence and less design risk. <img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370357999-1790370357999.png" width="624" height="156" class="fr-fic fr-dii" /> <h2>The Case for GlobalFoundries</h2>Following GlobalFoundries acquisition of MIPS in August 2025, the combined company became the ideal supplier for chip designers. Now offering both manufacturing and processor IP, as well as software tools, custom solutions, and complete platforms, GlobalFoundries can deliver differentiated solutions for energy-efficient edge computing.With access to both halves of the design equation, GlobalFoundries engineers can uniquely optimize PPA earlier in the design cycle, before register-transfer level (RTL) code freezes. And because GlobalFoundries already serves automotive, IoT, and communications infrastructure – the same segments MIPS cores target - the process technology and the core portfolio point at the same customers. For example, an automotive tier-one supplier asking for a safety-certifiable core on a qualified automotive process can now get both specified by the same engineering team.<h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370358004-1790370358004.png" width="624" height="113" class="fr-fic fr-dii" /></h2> <h2>The MIPS Atlas RISC-V Portfolio</h2>On the portfolio side, MIPS built its Atlas compute subsystems primarily around the open RISC-V ISA. This approach gives design teams the flexibility to develop differentiated compute platforms without purchasing a proprietary architecture license. With ARC processors now part of the portfolio, Atlas encompasses a broad range of embedded processors, application processors, neural processing units (NPUs), and digital signal processors (DSPs).MIPS organizes its Atlas subsystems around four roles within a Physical AI platform: Sense, Think, Act, and Communicate. This framework reflects the distinct compute requirements involved in enabling real-time intelligence at the edge.<ul><li>Sense covers capturing and moving data from cameras, radar, lidar, and other sensors. This step demands high-bandwidth data handling and signal processing, often through DSPs.</li><li>Think covers AI inference and decision-making, where designers deploy NPUs and vector-capable cores to interpret sensor data, perceive the environment, and plan the next action.</li><li>Act covers real-time control of motors, actuators, and batteries, where embedded processors must execute control loops deterministically and often meet functional-safety requirements.</li><li>Communicate extends the platform to connectivity and communication workloads, such as in-vehicle and industrial networking, helping complete the closed-loop architecture required by Physical AI systems.</li></ul>Within the Act role, the Atlas portfolio now spans multiple safety-capable processors for automotive and industrial designs, including safety-certified cores from the ARC family. For example, MIPS’ M8500 provides event-driven, low-latency control-loop processing for robotic movement. The subsystem also provides certifiable functional safety that meets automotive and industrial requirements. Customers are already designing these processors into vehicles. For instance, <a href="https://mips.com/press-releases/mips-drives-real-time-intelligence-into-physical-ai-platforms/">MIPS expects a customer automotive platform based on the M8500 to enter production in 2027.</a>Even though GlobalFoundries offers both manufacturing and IP, customers can still keep fab commitment separate from the IP decision. As a standalone business inside GlobalFoundries, MIPS maintains its own licensing model, allowing design teams to license a MIPS core without committing to a GlobalFoundries fab. Mobileye, for example, is a MIPS customer fabricating at TSMC.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370357912-1790370357912.jpeg" width="624" height="351" class="fr-fic fr-dii" />Atlas Explorer. Source: MIPS<h2>Atlas Explorer</h2>MIPS supports its portfolio with powerful, accurate modeling tools for pre-silicon validation. <a href="https://mips.com/products/mips-atlas-explorer/">Atlas Explorer</a> is a Visual Studio Code extension that provides a virtual platform for evaluating MIPS RISC-V IP before fabrication. With it, engineers can profile branch behavior and memory access patterns against a candidate configuration and read ALU utilization and execution flow. And, for parallel development efforts, the platform also lets software teams optimize models on the virtual platform while that silicon is still in development.<h2>Powering the Future of Physical AI</h2>Intelligence is moving from the data center into the physical world. To deliver optimal designs with minimal risk, chip designers need partners that combine processor IP, software tools, and manufacturing capabilities. By merging, GlobalFoundries and MIPS can now be that solution, giving designers the resources they need to deliver the future of Physical AI.

Does your Physical AI platform have sufficient compute to sense, think, act, and communicate all in real time?

Bringing AI-Native Compute to Mission-Critical, Real-Time Platforms

A Nucleo board with an expansion shield during bench testing

A practical selection guide to the STM32 Nucleo family: the three form factors, what the order code tells you, what the on-board ST-LINK actually does, and how Nucleo compares to Discovery kits and to Blue Pill and Black Pill boards.

STM32 Nucleo Boards: How to Choose the Right One

TASKING Conference brings together automotive, aerospace &amp; defense, industrial, and robotics engineers for a full day of technical sessions, live demos, and customer insights focused on building next-generation safety- and security-critical embedded systems.On 29 October 2026, attendees will gather at Design Offices München Macherei in Munich for practical, engineering-first guidance on the toolchain and workflow challenges shaping modern embedded development from heterogeneous SoCs and multi-core timing behavior to shift-left validation and safety qualification.Join speakers from TASKING, Infineon Technologies, Cadence Design Systems, deltaVision, and DeepDrive to explore how compile, debug, test, workflows are evolving together for today's safety-critical systems.<a href="https://www.tasking.com/tasking-conference-germany/?utm_source=wevolver&amp;utm_medium=referral&amp;utm_campaign=tasking_conference_2026" target="_blank" rel="noopener noreferrer" class="button-main-action">REGISTER NOW</a><h2>Event Details</h2><ul><li>Date: 29 October 2026</li><li>Location: Design Offices München Macherei, Weihenstephaner Str. 12, 81673 München, Germany</li><li>Format: Full-day in-person conference with technical sessions, live demos, and a panel discussion</li></ul><h2>Learn More</h2>TASKING Conference Germany is built for engineers working across automotive ECUs, aerospace &amp; defense systems, industrial control platforms, and robotics applications. Sessions are designed to translate today's hardest embedded engineering problems - heterogeneous SoC architectures, multi-core timing analysis, and shift-left validation - into practical workflows engineers can apply directly.Attendees will also get direct access to TASKING's product and engineering teams to discuss roadmap direction and industry-specific requirements, alongside customer case studies from organizations already applying these workflows in production.Product &amp; Roadmap<ul><li>Latest updates and roadmap direction from TASKING</li><li>Insights on modern ECU architecture across automotive, A&amp;D, industrial, and robotics domains</li></ul>Development Workflows<ul><li>Compile, debug, and test productivity gains on heterogeneous SoCs</li><li>Shift-left validation - from virtual ECUs to real silicon - ahead of hardware availability</li><li>Build, debug, test, and trace workflows integrated into CI/CD, DevOps, and AI-assisted engineering pipelines</li></ul>Timing &amp; Functional Safety<ul><li>Timing analysis across software tracing and on-chip hardware trace, for multi-core and multi-SoC systems</li><li>Certified tools and qualification packages supporting ISO 26262 (automotive), IEC 61508 (industrial/robotics), and DO-178C (aerospace)</li></ul>Customer Insights<ul><li>Key outcomes and lessons learned from organizations deploying these workflows in production</li></ul><a href="https://www.tasking.com/tasking-conference-germany/?utm_source=wevolver&amp;utm_medium=referral&amp;utm_campaign=tasking_conference_2026" target="_blank" rel="noopener noreferrer" class="button-main-action">REGISTER NOW</a><h2> </h2><h2>Who Should Attend</h2>TASKING Conference is for engineers and technical decision-makers building safety- and security-critical embedded systems, including:Automotive<ul><li>ECU software developers</li><li>Functional safety engineers targeting ISO 26262</li></ul>Aerospace &amp; Defense<ul><li>Embedded software engineers targeting DO-178C</li><li>Verification and validation teams</li></ul>Industrial &amp; Robotics<ul><li>Control platform developers</li><li>Engineers targeting IEC 61508 compliance</li></ul>Toolchain &amp; DevOps<ul><li>Engineers integrating build, debug, test, and trace into CI/CD and DevOps pipelines</li><li>Teams evaluating AI-assisted development workflows</li></ul><h2>Registration</h2>This is an exclusive event for TASKING customers and invited prospects and partners. A few things to know before registering:<ul><li>Register using a company email address. Gmail, Google, and other personal email providers are not accepted.</li><li>Registration is subject to confirmation; a separate confirmation email with agenda, venue, and logistics details will follow.</li><li>Attendance requires official confirmation.</li></ul>For more information, visit the<a href="https://www.tasking.com/tasking-conference-germany/?utm_source=wevolver&amp;utm_medium=referral&amp;utm_campaign=tasking_conference_2026" target="_blank" rel="noopener noreferrer"> TASKING Conference Germany</a> official event page.

Certified for Safe & Secure Systems

TASKING Conference 2026 - Munich, Germany

<h2 id="isPasted">The Pressure on Modern Embedded Engineering</h2>Today’s embedded systems engineering teams face an unprecedented challenge: software complexity is steadily escalating while development windows continue to shrink. With the rapid integration of advanced multicore architectures and stricter safety standards, traditional debugging workflows are no longer sufficient.When complex, non-deterministic bugs arise late in the development cycle, engineering teams often waste critical weeks hunting for root causes. These delays directly threaten time-to-market goals and inflate project budgets.To overcome these hurdles, relying on a unified, highly capable toolset is no longer a luxury—it is a technical necessity. This article explores how a holistic, end-to-end approach to debugging transforms these complex system challenges into a proactive engineering advantage.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzg5NzYzMzE1Mjk2LTE3ODk3NjMzMTUyOTYucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" width="602" height="316" class="fr-fic fr-dii" />UDE® Universal Debug Engine - Debug, Trace &amp; Test Tool for Microcontrollers and Embedded Processors. Source: PLS.<h2>PLS UDE – A Unified Environment for Embedded Tooling</h2>To address these development pressures, <a href="https://www.pls-mc.com/">PLS Development Tools</a> offers its <a href="https://www.pls-mc.com/products/ude-universal-debug-engine-debug-trace-test-tool-for-microcontrollers-and-embedded-processors/">UDE®  Universal Debug Engine</a>, a robust, cross-platform software environment engineered specifically for debugging, tracing, and testing deep embedded systems. Rather than forcing engineering teams to fragment their workflows across multiple utilities, UDE consolidates critical task management, high-level language support, and low-level system visibility into a singular, highly cohesive workspace.This unified architecture provides software engineers with an intuitive interface capable of managing complex multicore architectures without adding operational friction. Key platform capabilities include expansive multi-core debugging, deep hardware trace analysis, and specialized validation functions for timing-critical applications.By centralizing these complex tasks, PLS UDE minimizes tool-switching overhead and serves as a highly adaptable foundation that scales seamlessly across the entire product development lifecycle, ensuring critical system behaviors remain completely transparent.<h2>Full Lifecycle Coverage – From Pre-Silicon to Production</h2>The true utility of PLS UDE lies in its ability to support embedded software teams continuously throughout every phase of the development lifecycle. During the early pre-silicon stages, developers can begin building and verifying software using virtual prototyping environments.Because UDE interfaces with these virtual models using the exact same user interface and control scripts as physical hardware, engineers can seamlessly transition to real-silicon targets once physical microcontrollers arrive. This elimination of tool-switching reduces training overhead and ensures that hardware bring-up does not stall software validation.As projects progress into the test automation and continuous integration (CI) phases, UDE provides a highly flexible automation interface. Engineering teams can utilize virtually any scripting language to integrate advanced debugging, precise hardware tracing, and automated regression testing into their existing CI pipelines. While Python stands out as the most popular choice for modern orchestration due to its extensive library ecosystem, UDE’s open architecture ensures compatibility with existing legacy scripts and custom frameworks.Finally, the platform extends its utility directly into production environments. By providing dedicated, highly reliable capabilities for electronic control unit (ECU) flashing directly on the manufacturing floor, UDE bridges the gap between software development and final deployment. This end-to-end lifecycle integration guarantees that the very same tool environment used to write and debug the initial code remains vital up to the point the finished product rolls off the assembly line. <img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzg5NzYzMzE1Mzk0LTE3ODk3NjMzMTUzOTQucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" width="499" height="375" class="fr-fic fr-dii" />UAD2next. Source: PLS.<h2>Ecosystem Synergy - Broad MCU Support and Semiconductor Partnerships</h2>A major strength of PLS lies in its extensive ecosystem synergy, built upon long-standing, strategic collaborations with global semiconductor leaders. UDE provides robust, native support for advanced microcontrollers from industry pioneers, including Infineon, STMicroelectronics, NXP, Renesas, and TI, among others. Rather than treating silicon architectures as generic targets, PLS works closely with these chipmakers during early design phases. This deep integration ensures that UDE can fully exploit specialized on-chip debug and trace hardware features as soon as they hit the market. For development teams, this translates into reliable tool stability, predictable behavior, and immediate access to complex peripheral insights.Furthermore, PLS backs this platform with expert-level customer support deeply rooted in semiconductor architecture. This combined expertise allows engineering teams to quickly resolve intricate, low-level hardware-software interaction issues that generic, open-source or low-cost debugging tools simply cannot address.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzg5NzYzMzE1NTE2LTE3ODk3NjMzMTU1MTYucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" width="602" height="401" class="fr-fic fr-dii" />UAD3+ Aurora Aurix. Source: PLS.<h2>Technical Previews – Booth Demos at Embedded World North America</h2>To demonstrate these capabilities in action, PLS will feature two distinct, interactive hardware demonstrations at Embedded World North America. The first setup focuses on the Infineon AURIX™  TC4x, showcasing advanced multi-core debugging alongside trace-based runtime observation. This demo highlights how engineers can perform deep profiling and operating system behavior analysis to accurately identify and resolve system performance bottlenecks.The second showcase centers on the NXP S32K5, focusing on efficiency and debug automation. This preview demonstrates real-time debugging and test automation driven entirely by flexible Python scripts, proving how teams can orchestrate complex testing sequences without manual intervention. Together, these practical previews illustrate how UDE handles sophisticated, real-world silicon challenges, giving attendees a clear look at how to optimize their own development pipelines.<h2>Check Out the UDE in Person at Embedded World North America 2026</h2>Choosing a robust toolset transforms debugging from a time-consuming hurdle into a proactive engineering advantage. Visit PLS at <a href="https://www.wevolver.com/article/robotics-lab-at-embedded-world-north-america" target="_blank" rel="noopener noreferrer">embedded world North America</a> from September 22–24 at booth #6507 to see UDE in action, explore these live demonstrations, and consult with their technical experts to resolve your specific embedded development and automation challenges.

How PLS UDE®  Accelerates Multicore Debugging and Testing

Streamlining the Embedded Lifecycle

An STM32F103C8T6 Blue Pill wired into a prototype.

A working reference for the STM32F103 line: the four density classes and what each gives you, why USB and CAN can't run together, the LQFP48 pin functions, how the Blue Pill is wired, and how to spot the clones on cheap boards.

STM32F103: Density, Packages, and the Blue Pill

<h2 id="isPasted">embedded world North America 2026</h2>From September 22–24, <a href="https://embedded-world-na.com/" target="_blank" rel="noopener noreferrer">embedded world North America</a> brings together design engineers, systems architects, firmware developers, and product leaders at the Anaheim Convention Center for three days dedicated to the future of embedded innovation.<h2><a href="https://www.prereg.net/2026/ewna/" target="_blank" rel="noopener noreferrer">Register Now</a></h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1787147241216-1787147241214.png" width="624" height="69" class="fr-fic fr-dii" /><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1788213282343-embedded+world+North+America+2026+images.png" width="624" height="350.9896845230088" class="fr-fic fr-dii" />Copyright: NürnbergMesse North America<h3>What to Expect</h3>With 150+ exhibitors, 100+ technical sessions, and 100,000 square feet of exhibition space, embedded world North America brings the full embedded ecosystem into one venue. From agentic AI and autonomous systems to open hardware platforms, this event is built to give you both big-picture context and takeaways you can apply directly to your own work.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1787147038128-1787147038128.jpeg" width="624" height="468" class="fr-fic fr-dii" /><h3>Hear from the People Who Are Building What's Next</h3>Keynote speakers this year include Deepu Talla, VP of Robotics and Edge AI at NVIDIA, presenting on an open platform for autonomous, agentic systems, and Fabio Violante, VP and GM of Arduino at Qualcomm, on powering AI in the physical world.<a href="https://embedded-world-na.com/conference-program/" target="_blank" rel="noopener noreferrer">See the full conference program.</a><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1787147275006-embedded+world+North+America+2026+images+%281%29.jpg" style="width:100%px" class="fr-fic fr-dib" />Copyright: NürnbergMesse North America<h3>A Show Floor Built Around Real Engineering Challenges</h3>The technical conference is led by the developers and innovators doing the work. Breakout sessions are organized around real development challenges, current trends, and emerging applications, not vendor pitches.On the show floor, 150+ exhibitors give you direct access to the components, tools, and platforms shaping embedded design today. The Hackathon and Robotics Lab add a hands-on layer, letting you test ideas as working demos rather than just hear about them from a stage.In between sessions, there's room to step back, keep conversations going, and connect with others solving similar problems. <h3>Join the Conversation</h3>More than anything, embedded world North America is about bringing the embedded community together in one place. It's a chance to learn, compare notes, and see how others are approaching the same problems you are.<a href="https://www.prereg.net/2026/ewna/" target="_blank" rel="noopener noreferrer" id="isPasted">Register for your tickets now online</a>, and join us September 22-24 in Anaheim, California.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1787147642928-1787147642928.jpeg" width="624" height="327" class="fr-fic fr-dii" />

embedded world North America is the premier trade show and conference dedicated to the community of innovators and developers in the embedded tech ecosystem.

embedded world North America 2026 - Anaheim, CA

A machine-learning model running successfully in a software environment is simply the first hurdle. The real challenge is taking that model and turning it into a working embedded system by managing sensors, resources, latency, power, and physical hardware under considerable time constraints.The inaugural <a href="https://embedded-world-na.com/activations/" target="_blank" rel="noopener noreferrer">Edge AI Hackathon at embedded world North America</a> (Anaheim, September 22–24, 2026) will see university students tackle that engineering challenge live on the show floor. Nearly 50 students will form teams of four to five people to participate in a two-day embedded hardware hackathon. Professional mentors will support the teams as they move from initial concept to working demonstration.<h2>Building AI That Can Sense, Decide, and Act Locally</h2>The central challenge is to create AI systems that operate at the edge. Instead of relying entirely on remote cloud infrastructure, teams will use sponsor-provided computing and embedded hardware to run AI workloads locally.Processing information on or close to the device can reduce latency and dependence on network connectivity, allowing systems to respond to their surroundings in real time. It also forces teams to think beyond the AI model itself. Their concepts must account for hardware integration, sensor inputs, software constraints, and the physical action or output produced by the system.The hackathon will include four challenge tracks covering practical applications of edge AI, including autonomous systems, robotics, smart infrastructure, and human-machine interfaces.Potential projects could include a robotic arm that identifies and sorts objects, a mobile system that uses computer vision to avoid obstacles, predictive motor control that responds to anomalies, or multiple devices coordinating around a shared inference process.Each challenge asks students to turn an AI concept into something that works outside a controlled software environment.<h2>Engineering at the Event Live</h2>Unlike an overnight hackathon held behind closed doors, these builds will take place during conference hours and remain visible to attendees.Visitors will be able to follow the teams’ progress, see their systems take shape, and observe the practical decisions involved in developing an edge AI application. Live commentary and project updates are also planned throughout the event.The limited build time will require teams to divide responsibilities, assemble and integrate their hardware, develop and test software, troubleshoot problems, and prepare a working demonstration.The hackathon will conclude with final demonstrations and an awards ceremony. Four winning teams will each receive a $1,000 cash prize, along with hardware and gear from event sponsors.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1788799954594-260713_ewn_social_cards_persona_serie_engineer_product_procurement_v02_222250980.png" style="width:100%px" class="fr-fic fr-dib" /><h2> </h2><h2> </h2><h2> </h2><h2>Connecting Students with the Embedded Industry</h2>Arduino and Qualcomm are the title sponsors of the hackathon. Quilter is supporting the robotics challenge, while ASUS is supporting the sustainability challenge.Through the hardware, tools, and mentorship available during the event, students will gain practical experience with the technologies and engineering workflows involved in embedded AI development.The event also allows participants to work alongside students from other universities, learn from professional engineers, and connect with companies active in embedded computing.<h2>Extending the Work Beyond the Event</h2>The hackathon is designed to produce more than temporary show-floor demonstrations. Teams will document their progress and project outcomes, helping other engineers understand how they approached the problem, what solutions they attempted, and what they learned.Wevolver will share coverage of the event and the projects developed by the participating teams, creating a wider record of the ideas and engineering work produced during the hackathon.<a href="https://www.prereg.net/2026/ewna/">Learn more about the Edge AI Hackathon and register for embedded world North America here.</a>

A 2-day show-floor hackathon in Anaheim will bring together nearly 50 university students to build and demonstrate on-device AI systems with support from industry mentors.

Student Teams Put Edge AI to Work, Live at embedded world North America

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>

embedded development

ORGANIZATIONS. SHAPING THE INDUSTRY.

Latest Posts