Feed aggregator

Multicore processing boosts performance and energy efficiency in many coding situations. Bare-metal algorithms further enhance these benefits.

Many embedded firmware engineers have seemingly not yet tried multicore processing. Using processors with more than one core can actually make your architecture and coding easier. And the part you may find surprising is that setting up and using multicores processors is very easy to do.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Typically, multicore programs are used in systems with an OS, but if you’re like me, my projects are typically bare-metal. I have long used multicore under an RTOS but have historically avoided multicore on bare-metal systems. But ever since I discovered how easy it was to use multicore on bare-metal, it has become part of my go-to design architecture.

Let’s look at how this is accomplished. The examples and discussions that follow are based on using an RP2040 two-core microcontroller with code developed on an Arduino IDE. RP2040 development boards can be found for around $5 USD. Also, although I will discuss a two-core setup, expanding to larger core count processors will use the same concepts.

So why didn’t I use multicore designs sooner? I had some concerns that there were difficulties that I wasn’t ready to take on. Some of these were:

• How to keep each core’s code separate
• How to start multiple cores
• How the cores talk to each other (i.e., how to transfer data among cores)
• What peripherals each core can use; do they need to be checked out or registered, for example

It turns out that all these issues are actually very easy to deal with. Let’s look at them one at a time.

First, how do you separate the code for each core? In a single-core Arduino C program there are two major sections: the setup section (which begins like this: void setup()) and the loop section (which begins like this: void loop()). If you are using two cores, the first core, core 0, will use these sections just as used in a single-core design.

The code for the second core, core 1, will have a function defining its main loop. Let’s name it core1_main. Then in the core 0’s setup section, enter the line multicore_launch_core1(core1_main);. That line will start the function, called core1_main, running on the second core. (Note: I find it much cleaner to put the core 1 code in a separate tab in the Arduino IDE.) Unlike the main loop in an Arduino C program, you will need to wrap the code in core 1 in a while(1); loop. Another item to include is the line #include "pico/multicore.h" at the top of the code.

Be aware that there are other approaches for setting up code in the second core. They include methods that allow core 1 to use its own setup function. Use your favorite AI or other research tool to discover other methods of setting up code and executing code on the second core.

Here’s a very simple example having each core blinking its own LED:

#include #include "pico/multicore.h" // ----------------------------- // Core 1 code // ----------------------------- void core1_main() { pinMode(14, OUTPUT); while (1) { digitalWrite(14, HIGH); delay(500); digitalWrite(14, LOW); delay(500); } } // ----------------------------- // Core 0 code // ----------------------------- void setup() { pinMode(15, OUTPUT); // Start core 1 multicore_launch_core1(core1_main); } void loop() { digitalWrite(15, HIGH); delay(300); digitalWrite(15, LOW); delay(300); }

This example gives you an idea of how to get the two cores executing their own tasks. Typically, though, you would want to have some sort of communication between the cores. This can be achieved very simply by using a variable that each core can see and modify. It turns out that the entire memory space of the microcontroller can be seen and modified by either core. So, if you define a global variable at the top of the code (just below the #include statements), it can be used to transfer data between cores.

Make sure that the variable is tagged as volatile as it can change at any time. Also remember that the RP2040 is a 32-bit microcontroller and reading and writing 64-bit values is not atomic, so care must be taken to not read a transferred 64-bit value before both halves have been transferred. A simple flag can help here. This simple method of using shared memory to transfer data is easy but can be dangerous if you’re not careful—similar to global variables—but bare-metal developers typically like this tight control over resources.

This method of transferring data is good for simple tasks, but you may want to use FIFOs to handle more data and to remove some syncing issues. These are not difficult to write, and you’ll also find pre-written packages online. For more sophisticated programs, you can investigate mailboxes, semaphores, flags, etc. from various sources…but now we’re getting into RTOS functions.

Now let’s look at sharing peripherals between cores. In our bare-metal architecture, the best explanation is that any core can use any peripheral at any time. This situation is both good and bad. Good because there are no flags to set, no checkouts that need to happen, and no negotiations to be made: just use the peripheral. Bad in the sense that without some form of coordination the two cores can attempt to set up the same peripheral at the same time, in different configurations.

What I have found useful in my designs is that I have typically separated the code in the two cores such that each core always uses peripherals that are not used by the other core. If that not the case in your designs, you may want to implement a resource lock method using flags. Related is the interesting fact that both cores can use the serial port (only configured by one core) without any necessary handshaking or flags. Do note, though, that the serial communications will be interleaved. That said, I find this very handy since I can Serial.print() from either core during debugging.

Let’s answer one last question: why do I want to use more than one core? The first reason is the obvious one: you get more computing power. But more than that, by separating tasks from each other you may find coding easier and cleaner. That’s because there are no concerns about the multiple tasks fighting for cycles, especially for time-sensitive tasks. Also, if you are using multiple interrupts, separating these tasks between cores can remove the complexity of interrupts occurring at the same time and thereby holding off one or the other. Another benefit is that you may have faster response to events happening as you can essentially monitor and respond to twice as many events.

Here’s another code example using some of the concepts discussed earlier. This code uses core 1 to monitor the serial port looking for a G or an R. If it sees a G, it sets the shared variable led_color to 1. Core 0 continuously monitors led_color and turns on the green LED if the led_color is 1. Similarly, if core 1 sees a R it changes led_color to 0 and core 0 then then turns on the red LED:

#include #include "pico/multicore.h" // ---------------------------- // LED pin assignments // ---------------------------- #define RED_LED_PIN 14 #define GREEN_LED_PIN 15 // ---------------------------- // Shared variable between cores // 0 = RED, 1 = GREEN // ---------------------------- volatile int led_color = 0; // ====================================================== // Core 1: Serial monitor // ====================================================== void core1_entry() { while (!Serial) { delay(10); } while (1) { if (Serial.available() > 0) { char c = Serial.read(); if (c == 'G' || c == 'g') { led_color = 1; Serial.println("Set LED = GREEN"); } else if (c == 'R' || c == 'r') { led_color = 0; Serial.println("Set LED = RED"); } } delay(2); } } // ====================================================== // Core 0 setup // ====================================================== void setup() { Serial.begin(115200); pinMode(RED_LED_PIN, OUTPUT); pinMode(GREEN_LED_PIN, OUTPUT); // Launch Core 1 multicore_launch_core1(core1_entry); } // ====================================================== // Core 0 loop — LED logic now lives here // ====================================================== void loop() { if (led_color == 1) { digitalWrite(GREEN_LED_PIN, HIGH); digitalWrite(RED_LED_PIN, LOW); } else { digitalWrite(RED_LED_PIN, HIGH); digitalWrite(GREEN_LED_PIN, LOW); } delay(5); }

It may now be becoming clearer to you where the benefits lie in using more than one core. Think of something more complex, say, a program that monitors the serial port for modifications to settings, along with a high-speed ADC being read with a tight tolerance on jitter. Having the serial port code running on one core and the ADC code in another core would make this combination much easier to get working cleanly.

Give multicore code design a try! It’s easy, I think you’ll find lots of uses for it, and you’ll also find it makes coding easier and more organized.

p.s. Both pieces of code shown in this article were initially written by CoPilot per author instructions. The author subsequently only made minor modifications.

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

Related Content

• The next RISC-V processor frontier: AI
• Partitioning to optimize AI inference for multi-core platforms
• Multicore architectures, Part 1 – Key drivers
• Multicore architectures, Part 2 – Multicore characteristics
• Multicore architectures, Part 3 – Communications and memory
• Multicore architectures, Part 4 – Application specificity

The post Give bare-metal multicore processing a try appeared first on EDN.

Sivers Semiconductors AB of Kista, Sweden (which supplies RF beam-former ICs and lasers for AI data-center, SATCOM, defense and telecom applications) says that its high-performance distributed feedback (DFB) lasers are to be used by global engineering, supply chain and manufacturing solutions provider Jabil Inc to develop a 1.6T linear receive optical (LRO) transceiver module. The new pluggable module will provide highly energy-efficient optical interconnect speeds to accelerate deployment for next-generation hyperscale AI data centers...

In first-quarter 2026, Sweden-based semiconductor equipment maker AlixLabs AB (which was spun off from Lund University in 2019, specializing in atomic layer epitaxy) closed its Series A funding round following a strategic investment from Stephen Industries, a Finnish investment company with a track record in scaling advanced technology ventures...

To advance the production of its APS (Atomic Pitch Splitting) equipment, Sweden-based semiconductor equipment maker AlixLabs AB (which was spun off from Lund University in 2019, specializing in atomic layer epitaxy) has signed a memorandum of understanding (MoU) with VDL ETG Projects (part of VDL Groep of Eindhoven, The Netherlands)...

Науково-випробувальному центру "Надійність" – 30 років Інформація КП ср, 04/15/2026 - 12:00

Стало відомо про загибель випускника КПІ Павла Мунтяна kpi ср, 04/15/2026 - 11:49

Silanna UV of Brisbane, Australia – which provides far-UVC light sources for water quality sensors, gas sensors, disinfection, and HPLC (high-performance liquid chromatography) applications – has released an additional package type: a TO-39 flat-window package for its high-performance SF1 series (Far-UVC 235nm) and SN3 series (Deep-UVC 255nm) LEDs. This latest development expands the firm’s comprehensive metal can UVC LED portfolio, delivering greater optical flexibility, compact integration, and proven reliability for advanced sensing applications...

A rare kot of vintage military-grade circuit boards originating from Cold War-era radar infrastructure, consistent with systems such as PAVE PAWS. These boards represent a time when electronics were engineered for absolute reliability under mission-critical conditions. Each unit features meticulously arranged multi-channel circuitry, shielded modules, precision-tuned components, and electromechanical relays — all indicative of early high-performance signal processing design. The construction alone tells the story: hand-calibrated elements, gold-edge connectors, and robust analog architecture built to operate continuously in high-stakes environments. This is not consumer hardware. It is a preserved fragment of early warning defense technology — a physical artifact from an era defined by vigilance and engineering excellence. Ideal for: • Advanced collectors of military or Cold War technology • Display in studios, offices, or curated spaces • Engineers and historians of early electronic systems Condition: Untested. Original vintage condition with visible signs of age consistent with long-term storage. Available Serious only submitted by /u/Negative_Alfalfa_069 [link] [comments]

Pictured is the offender, my custom 84V 480A brushed DC motor driver. While testing, I had to make some adjustments to the rev1 routing, since apparently I forgot to run DRC before sending it to the fab. Tried to change the logic power supply to the FET drivers from 12V to 5V, forgot to cut one trace, and ended up bridging 5V to 12V. I used a lead acid battery instead of a current limited power supply for testing, connected it to my laptop without a USB isolator, and... well, I no longer have a laptop. I wonder how I'll explain to my professors why I won't be able to submit my paper draft that is due tonight. submitted by /u/feoranis26 [link] [comments]

Нові можливості для майбутніх інженерів-теплоенергетиків Інформація КП вт, 04/14/2026 - 20:00

The Wireless Broadband Alliance (WBA) has released guidelines to strengthen security, privacy, and trust across Wi-Fi networks. These guidelines help organizations reduce exposure to common Wi-Fi threats, improve user trust, and simplify interoperability across networks and partners.

The guidelines also address the growing need for carrier-grade security that aligns with user expectations.

1. Prevent connections to rogue and fake networks

Wi-Fi devices must validate network certificates before sharing credentials by using 802.1X and Extensible Authentication Protocol (EAP). That ensures users connect only to legitimate networks, significantly reducing the risk of evil-twin and rogue access point (AP) attacks.

2. Protect data over the air

Data traffic confidentiality and integrity can be ensured by enforcing WPA2/WPA3-Enterprise with Advanced Encryption Standard (AES) and Protected Management Frames (PMF). That prevents passive sniffing, de-authentication attacks, and many man-in-the-middle techniques, bringing Wi-Fi security closer to cellular-grade protection.

3. Preserve user identity privacy without breaking compliance

Balance privacy and traceability by using anonymous identities, encrypted inner identities, pseudonyms, and chargeable-user-identity (CUI). That protects personally identifiable information during authentication while still enabling lawful intercept, billing, and incident handling when required.

4. Secure credentials end-to-end

Credentials are protected throughout their lifecycle, from device to network to backend systems. Secure OS key stores on devices and hardened credential storage in identity provider systems. So, tamper-resistant SIMs and USIMs for mobile credentials reduce the risk of large-scale credential theft.

5. Harden the entire access network

Security extends beyond the radio link. Physical security of access points and controllers, encrypted AP-to-controller links, secure backhaul design, and local breakout architectures ensure that data traffic remains protected across the full network path.

6. Secure AAA and roaming signaling

This guideline recognizes that the control plane is often overlooked; so, it strongly recommends RADIUS over TLS or DTLS for all AAA and roaming exchanges. That protects authentication and accounting traffic from interception or manipulation, aligning with OpenRoaming and WRIX requirements.

7. Add layer-2 protections against lateral attacks

Layer-2 traffic inspection, client isolation, proxy ARP, and multicast and broadcast controls are employed to limit damage even if a malicious device connects and thus reduce client-to-client attacks such as ARP spoofing and broadcast abuse.

8. Enforce security through federation and governance

Security is reinforced not only technically but operationally through OpenRoaming and the WRIX legal framework. As a result, security requirements, responsibilities, and privacy obligations can be consistently enforced across operators, identity providers, and hubs.

Related Content

• Securing a wireless network–The basics
• How to achieve better IoT security in Wi-Fi modules
• How to make 802.11 systems combine security with affordability
• 10 things to consider when securing an embedded 802.11 Wi-Fi device

The post 8 Wi-Fi security guidelines issued by Wireless Broadband Alliance appeared first on EDN.

The UK Semiconductor Centre (UKSC) has launched a new HQ at the Institute of Physics (IOP) in King’s Cross, London, marking a significant step in its mission to ensure that the UK capitalizes on rapid expansion in the global semiconductor industry...

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — has introduced the EPC9186HC2 and EPC9186HC3 evaluation boards, two high-performance 3-phase BLDC motor drive inverter platforms designed for applications including robotics, industrial automation, light electric vehicles (EVs), electric scooters, forklifts, agricultural machinery, battery-powered mobility systems, and high-power drones. Supporting motor drive systems up to 5kW, the boards enable engineers to evaluate compact, high-efficiency inverter architectures based on 100V EPC2361 eGaN FET technology...

Tracking down rodentia (or otherwise)-caused cable cuts, and differentiating them from normal open circuits, is critical. Evolving the circuit design for expanded functionality makes it even more valuable.

It’s just part of the job.  Every design engineer learns early (if not so happily) about the inevitable necessity of detecting, confronting, and swatting “bugs” in circuitry.

Wow the engineering world with your unique design: Design Ideas Submission Guide

In a recent Design Idea, frequent contributor Jayapal Ramalingam extends this art of circuit defect detection and deletion from dealing with mere insects to coping with something much more formidable: rats!

With so many rodents and creatures around the plant, a cable cut can happen at any time

The cables being subjected to those toothy threats transport signals from field contacts monitoring pressure, temperature, valve position, limit switches, manual operator inputs, etc., to process control systems. The possible consequences of mistaking an undetected cable break for an open contact range from the merely inconvenient to the catastrophic. An example of the latter might be a critical valve that’s actually open but erroneously read as closed—viz., Three Mile Island?

Mr. Ramalingam’s clever solution to the problem of undetected cable cuts is a current transmitter design that adds a third current level to the two that are inherent to an ON/OFF contact.  Thusly.

20mA = contact closed, cable intact
4mA = contact open, cable intact
0mA = cable cut, contact state unknown

It therefore explicitly verifies cable continuity, preventing the mistaking of an open circuit for an open contact. See his article for details.

Mr. Ramalingam’s circuit works, is proven, and has nothing significantly wrong with it.  Its utility, however, is limited to that single function.  It might be significantly more convenient and thrifty if its role could be combined with another in a multipurpose design, provided, of course, that said design would be of no greater cost or complexity than the single-purpose transmitter.  Figure 1 and Figure 2 show such a circuit adapted from an earlier article.

Figure 1  0/20mA to 4/20mA current loop converter.

Figure 2 Field contact OFF/ON to 4/20mA current loop converter.

Note that the circuits are identical, so that only one design needs to be fabricated, documented, and stocked.

Calibration in this new role is quick and simple and completed in a single pass:

1. Open contact.
2. Tweak 4mA adj for 4mA output.
3. Close contact.
4. Tweak 20mA adj for 20mA output.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content 

• Is your PLC/DCS reading the field contacts reliably?
• Silly simple precision 0/20mA to 4/20mA converter

The post Double-duty current loop transmitter appeared first on EDN.

Photonic integration firm Photon Bridge of Eindhoven, The Netherlands and PhiX B.V. of Enschede, The Netherlands have partnered to advance Photon Bridge’s high-performance DWDM external laser source transmit optical sub-assembly (TOSA), targeting co-packaged optics (CPO) and high-density optical interconnects for AI data-center infrastructure...

Gallium nitride (GaN) power IC and silicon carbide (SiC) technology firm Navitas Semiconductor Corp of Torrance, CA, USA has appointed semiconductor veteran Gregory M. Fischer to its board, serving on the Compensation and Executive Steering committees. He will stand for reelection in 2027 as a Class III director...

Громнадська Марина. Біотехнологи КПІ задля реалізації цілей сталого розвитку Інформація КП вт, 04/14/2026 - 11:30

Володимиру Володимировичу Пілінському – 85! Інформація КП вт, 04/14/2026 - 11:20

Flagship consumer electronic device launches are among the most operationally complex events in modern engineering. They require years of coordination across hardware, silicon, RF, software, operations, supply chain, and manufacturing. Yet, despite mature processes and experienced teams, flagship programs remain vulnerable to schedule volatility.

The root cause is rarely inadequate engineering talent. More often, it’s structural. Manufacturing realities are integrated too late into architectural decision-making. System-level validation, when deployed early and continuously, functions not as a downstream quality checkpoint, but as an organizational mechanism for compressing schedule risk before capital and timeline commitments are locked.

Financial exposure at flagship scale

At flagship scale, schedule slip is not simply an engineering inconvenience. It’s a material financial event.

Apple’s fiscal year 2025 results reported approximately $416 billion in annual revenue, with iPhone revenue representing roughly half of total sales. Samsung’s Mobile Experience division reported approximately $26 billion in quarterly revenue during. For programs operating at this scale, a one-month delay during a peak launch cycle can defer revenue comparable to the annual revenue of many mid-sized technology firms.

Even outside tier-one OEMs, launch timing directly impacts channel readiness, carrier alignment, ecosystem momentum, and competitive positioning. In high-volume hardware, schedule is strategy.

The challenge is that many launch delays are not caused by unforeseen global disruptions, but by late-stage design changes triggered during production ramp. Industry analyses consistently show that a significant portion of late engineering change orders originate from integration and manufacturability issues that were technically detectable earlier in the development cycle.

When these issues surface during ramp, optionality has already collapsed. Tooling is frozen, suppliers are capacity-allocated, and marketing calendars are committed. At that stage, validation confirms risk rather than preventing it.

Why component-level validation fails at scale

Traditional validation strategies are optimized for component correctness. Subsystems are tested against modular specifications, and readiness decisions are based on aggregated subsystem pass rates. This approach ensures that parts function independently; however, it does not guarantee that the system functions reliably under real-world, high-volume conditions.

Many failure modes emerge only during full-system interaction. Digital signal interference, RF coexistence conflicts, thermal coupling between tightly integrated subsystems, and parasitic effects often cannot be fully replicated in isolated bench testing.

For example, a high-speed display flex cable may pass standalone signal integrity validation. During system-level engineering verification testing (EVT) under real RF load, that same cable can radiate broadband noise that desensitizes the primary cellular receiver. The result is a coexistence failure that frequently forces late-stage shielding changes or mechanical redesign.

Similarly, assembly processes introduce stress, tolerance stack-up, and handling variability that are absent in early prototypes. Component-level validation ensures parts are defect-free. It does not predict how those parts behave when integrated and manufactured at scale. The consequence is predictable: issues emerge when yield sensitivity tightens during ramp.

A defect observed in 1 out of 100 early validation units translates into 10,000 defective devices at a one-million-unit scale. At millions of units, small deltas compound rapidly.

The design–manufacturing impedance mismatch

A recurring root cause of late-stage validation failures is misalignment between design optimization and manufacturing constraints. Design teams optimize for performance, power efficiency, compact form factor, and cost targets. Manufacturing teams optimize for yield stability, throughput, repeatability, and process capability. Both are correct within their domains.

Failure occurs when manufacturing sensitivity is not structurally integrated into architectural trade-off decisions. In cross-functional reviews, performance metrics are often presented without quantified yield sensitivity analysis. Design freeze decisions may proceed based on functional validation, while manufacturing risk remains probabilistic rather than modeled. Schedule pressure can incentivize accepting integration risk with the assumption that ramp will resolve residual issues.

System-level validation acts as the translation layer between these domains. When embedded early, it exposes divergence between design intent and production feasibility while design changes remain affordable. The cost-of-change curve, widely cited in engineering economics literature, demonstrates that defects discovered during mass production can cost orders of magnitude more to correct than those identified during early design phases. Whether the multiplier is 10x or 100x depends on context, but the direction is consistent: late discovery amplifies cost and schedule exposure.

System-level validation as risk compression

Reframing system-level validation as a schedule-risk compression mechanism changes how engineering organizations deploy it. Risk compression means reducing the variance between projected and actual ramp performance before high-volume commitments are made. It means narrowing the gap between modeled yield and early ramp yield while architectural flexibility still exists.

Consider a ten-million-unit program targeting 97% yield but only achieving 94% during early ramp. A 3% delta produces 300,000 additional defective units. At a $500 bill-of-materials cost, that equates to $150 million in direct exposure: before accounting for logistics, containment actions, rework, warranty impact, and brand degradation.

When system-level validation is embedded earlier in the development cycle, integration uncertainty is resolved before tooling freeze and capacity allocation. Manufacturing sensitivity becomes an architectural input, not a downstream constraint. Validation shifts from reactive confirmation to proactive risk reduction.

Governance implications for senior managers

For senior engineering and manufacturing managers, the implication is structural. System-level validation must be positioned upstream of design freeze, not solely before ramp. In practice, this requires:

• Upstream integration: Embedding manufacturing engineering into early architecture discussions.
• Quantified sensitivity: Requiring quantified yield sensitivity data before design freeze.
• Strategic alignment: Aligning validation milestones with major financial commitments.
• Holistic ownership: Elevating system-level risk ownership to program leadership rather than distributing it across siloed subsystem teams.

Organizations that treat system-level validation as a downstream quality function implicitly accept schedule volatility as a cost of doing business. Organizations that embed it as a bridge between design architecture and manufacturing execution create structural advantage. They stabilize flagship launch timelines, reduce ramp inefficiency, and preserve optionality when trade-offs are still affordable.

Ayokunle Oni is a system engineering program manager at Apple, where he helps coordinate the iPhone hardware design and engineering process across cross-functional teams. He specializes in system integration and validation and has led complex engineering programs from concept through production, working closely with global manufacturing and vendor partners.

Related Content

• Basics of Bench Silicon Validation – PCB Passives
• Early verification and validation using model-based design
• Design Constraint Verification and Validation: A New Paradigm
• Design-Stage Analysis, Verification, and Optimization for Every Designer
• Hardware Verification: What AI Gets Right When It Generates Your Testbench — and What It Misses

The post How system-level validation compresses schedule risk in device design appeared first on EDN.