Збирач потоків

• Infineon’s radiation-hardened semiconductors performed flawlessly on NASA’s Artemis II Orion capsule across ten days in space.
• Since the 1970s Infineon’s radiation-hardened technology has proven reliable across hundreds of space missions.
• With the world’s first JANS-qualified internally manufactured rad-hard gallium nitride (GaN) transistor, Infineon sets the benchmark for space semiconductors.

Munich, Germany – 15 April 2026 – NASA’s Artemis II mission has successfully returned to Earth after ten days in space, having approached the Moon and reached the farthest distance from our planet ever achieved by crewed spaceflight. The four astronauts have safely returned home, delivering renewed proof that the radiation-hardened (rad-hard) semiconductor solutions of Infineon Technologies AG (FSE: IFX / OTCQX: IFNNY) perform reliably even under the most extreme conditions of deep space. From critical power supply and control systems to data communications, Infineon’s rad-hard devices from its IR HiRel (high reliability) division supported the electronic backbone at the heart of the Orion capsule.

“Space programs require technologies and partners they can rely on for decades. Infineon is a critical technology partner, and we are proud to have once again contributed to the success of a historic space mission,” said Mike Mills, Senior Vice President and General Manager of IR HiRel at Infineon. “The space industry is evolving rapidly: more missions, more data, more electrification – while facing increasing pressure on size, weight and power consumption. In this equation, semiconductors are becoming a central focus in space. The fact that our components performed flawlessly from the first to the last minute of the Artemis II mission is no coincidence. It is the result of decades of engineering expertise, state-of-the-art qualification processes and a deep understanding of what semiconductors must deliver in space.”

Artemis II marks decades of space heritage for Infineon. As far back as the 1970s, Infineon’s predecessor companies supplied the first rad-hard components for NASA and ESA space programs. Since then, Infineon IR HiRel has supported hundreds of space missions including navigation satellites, the International Space Station (ISS), and today’s Artemis program. Our rad-hard components have traveled further than any other human-made object, over 20 billion kilometers from Earth. As a technology leader, Infineon continues to invest in, develop and manufacture the best performing rad-hard semiconductors supporting the space design community on a global scale.

The demands placed on semiconductors in space are immense. Beyond Earth’s protective magnetic field, high-energy particles strike electronic components unimpeded and can permanently damage or destroy them, causing mission failure. Infineon’s rad-hard technology addresses these mechanisms not through passive shielding, but through a semiconductor architecture that is radiation-resistant by design. All products are qualified to the most stringent international space standards, including MIL-PRF-38535 Class V, MIL-PRF-19500, ESA’s ESCC standards and NASA EEE-INST-002, ensuring their reliable performance.

At Infineon, innovation is developed at the system level: semiconductor technology, rad-hard assurance, and packaging perform together. An optimized overall system influences not only electrical performance, but also thermal behavior and long-term reliability – while simultaneously reducing weight and volume. Every gram counts in space, Infineon’s rad-hard parts provide a decisive system-level advantage.

Wide-Bandgap technology: GaN takes the next step

Infineon is also advancing the use of new semiconductor materials in space applications. Gallium nitride (GaN) enables lower switching losses, higher power density and higher switching frequencies – reducing power losses and magnetic component requirements, which translates directly into further weight savings. Built on internal manufacturing capabilities and the process and quality stability that comes with it, Infineon’s award-winning rad-hard 100-V GaN transistor, qualified to JANS (Joint Army Navy Space) per MIL-PRF-19500, brings GaN from concept to proven technology for demanding space missions. Infineon’s JANS qualified device is the first and only internally manufactured rad-hard GaN transistor on the market.

Infineon offers a broad rad-hard portfolio spanning Si power MOSFETs and GaN transistors, gate drivers and solid-state relays, in addition to rad-hard memories and radio frequency (RF) devices. Backed by in-house radiation testing capabilities and guaranteed long-term product availability, Infineon positions itself not merely as a component supplier, but as a strategic technology partner for the entire space industry.

The post Mission accomplished: Infineon technology proves reliable once again in space on Artemis II appeared first on ELE Times.

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