Новини світу мікро- та наноелектроніки

Siemens and Microsoft are employing generative AI to increase efficiency across the design, engineering, manufacturing, and operational lifecycle of products. The companies are integrating Siemens’ Teamcenter software for product lifecycle management (PLM) with the Microsoft Teams messaging and collaboration platform. The integration will also include the language models in Azure OpenAI Service, as well as other Azure AI capabilities.

At this month’s Hannover Messe trade fair, the companies demonstrated how generative AI can improve factory automation and operations through AI-powered software development, problem reporting, and visual quality inspection. The Teamcenter app for Microsoft Teams, anticipated later in 2023, allows engineers and frontline workers to quickly solve challenges together. Through the Azure OpenAI Service, the app can parse informal speech data and create a summarized report. With Teamcenter for Microsoft Teams, millions of workers who do not have access to PLM tools can impact the design and manufacturing process more easily.

The two companies also demonstrated how OpenAI’s ChatGPT and other Azure AI services can help software developers and automation engineers create code for programmable logic controllers (PLCs) faster and with fewer errors using natural language inputs. Additionally, with Microsoft Azure Machine Learning and Siemens’ Industrial Edge tools, images captured by cameras and videos can be analyzed by machine learning systems and used to build, deploy, run, and monitor AI vision models on the factory floor.

Siemens

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post Partners use generative AI to boost industrial productivity appeared first on EDN.

A new flash memory chip claims to offer real-time code execution for safety-critical applications serving domain and zonal controllers in semi-autonomous vehicles while exceeding the capability of today’s most advanced xSPI NOR flash devices. Domain and zone controllers, which consolidate many safety-critical functions, must process huge amounts of data in real-time; so more memory is needed to support growing code size and complexity.

Infineon Technologies also claims that its SEMPER X1 chip is the industry’s first LPDDR flash memory; the LPDDR4 interface offers the scalability and performance required for direct code execution from an external NVM device. It does that by facilitating a scalable interface in terms of bus widths and the number of channels.

Figure 1 SEMPER X1 is the world’s first LPDDR flash memory device enabling real-time code execution from external NOR flash. Source: Infineon

According to Sandeep Krishnegowda, VP of marketing and applications for flash solutions at Infineon, at advanced process nodes, automotive-qualified eNVM technologies are challenged by high cost and lack of scalability. “As a result, standard xSPI NOR flash does not meet real-time execute-in-place (XiP) performance requirements.”

Jim Handy, general director at Objective Analysis, provided a more detailed view of this issue. “What’s at issue is that NOR flash, which has served as the program storage for MCUs and ASICs since the 1980s, suddenly stopped scaling when CMOS logic processes started to use FinFETs at 14 nm,” he said. “The smallest process to support NOR is 28 nm.”

“Designers could either use a new memory technology like MRAM and ReRAM to replace the NOR, or they could use an external flash chip,” Handy added. The trouble is that the parallel and SPI interfaces for external NOR flash are orders of magnitude slower than embedded NOR.” To that end, some MCU designers have added an LPDDR interface, hoping that memory makers will offer products that can support their MCUs at a higher speed.

“SEMPER X1 is the first NOR flash I know to come with an LPDDR interface,” he said. “I expect to see similar offerings from Infineon and its competitors in coming years.” Handy is the co-author of an annual report on emerging memory technologies.

The embedded vs. external flash

When it comes to embedded flash and external flash settings, the traditional way is to execute from embedded flash. And external NOR flash can be used as a memory expansion. In what Krishnegowda calls a pivot point, design engineers can now execute from external LPDDR flash with a high-performance LPDDR interface enabling real-time code execution from external flash.

“The real-time processors in domain and zone controllers need the performance of advanced process nodes,” he added. “So, real-time processors without embedded flash need equivalent performance from an external flash.”

Figure 2 SEMPER NOR flash is targeted at automotive, industrial, datacenter, and communications applications where failure is not an option. Source: Infineon

“SEMPER X1 offers significant performance gains compared to standard xSPI NOR flash as well as standard LPDDR4 DRAM,” Krishnegowda said. With an LPDDR4 interface, it operates at 3.2 GBytes/sec throughput and features a multi-bank architecture to meet the performance and density requirements of domain and zone controllers.

Krishnegowda added that SEMPER X1 flash has been architected and designed for functional safety. It’s ISO 26262 ASIL-B compliant and offers advanced error correction and other safety features. Moreover, it supports over-the-air (OTA) firmware updates with zero downtime.

At a time when software-defined vehicles increasingly demand real-time code execution for safety-critical applications like engine control, a new memory device taking advantage of the LPDDR4 interface can bring value to the next-generation automotive domain and zone controllers running safety-critical, real-time applications. Especially, when it claims to deliver 8 times the performance of current NOR flash memories and achieve 20 times faster random read transactions for real-time applications.

SEMPER X1 is sampling now with commercial availability in 2024.

Related Content

• Inside Intel’s 65-nm NOR flash
• The Future of NOR flash memory
• Flash 101: NAND Flash vs NOR Flash
• NOR flash eyes IoT devices catering to more code, data
• Emerging memories move to replace embedded NOR flash
• How NOR flash helps overcome design challenges in wearables

The post LPDDR flash claims edge on xSPI NOR in code execution appeared first on EDN.

In addition to the expected technical expertise, engineering design is largely about managing tradeoffs within the boundaries set by unavoidable constraints. Deciding how much weight and priority to assign to each good or bad attribute to enable making these tradeoffs takes both quantitative analysis as well as judgment and experience. The list is long and covers many dimensions of performance such as power, size, weight, reliability, component availability, bill of materials (BOM) cost, and assembly cost, to cite just a few of the many issues.

Even a decision which seems simple at first glance has its tradeoffs. Consider the case of sizing the resistor used for load-current sensing, Figure 1.

Figure 1 Even the conceptually simple use of the voltage drop across a resistor to measure current flow brings tradeoffs among various technical considerations. Source: Analog Devices

A larger-value resistor provides a higher voltage via the IR drop at a given current, but that drop also reduces the rail voltage available for the load. There’s also dissipative waste, so a physically larger or thermally more rugged resistor is needed to handle that heat. Conversely, a smaller-value resistor reduces rail and dissipation losses but offers a smaller voltage drop, which is more prone to corruption by noise. Insight into these tradeoffs is one of the many functions which a good application note or blog can provide.

There are several kinds of application-focused collateral:

• Those which simply posit a specific component or approach as the solution to the problem and extol its virtues. These often lack context and presume there are no other alternatives or downsides to what they propose. I find these to have the least value due to their minimization or outright avoidance of broader context, but they nonetheless often contain useful information despite their limited perspective.
• Others go beyond the simplistic discussion explain how to get the most when using a specified component or class of components (current-feedback op amps, for example) but acknowledge where they may not be a good fit in some cases. These notes are valuable if you are not entirely sure which solution you will be choosing, and they help to minimize avoidable mistakes and headaches you’re evaluating the situation.
• Finally, there are those which focus on discussion and explanation of the tradeoffs among several approaches by clarifying the pros and cons of each. They also show how the relative weight of these attributes may change as your design scales up or down in capacity and capability.

I find this last group to be the most satisfying because the lessons they provide give longer-term insight into the issues. Further, if well written, these will help you make better decisions in future projects as well.

A very good example of this last group is a recently posted blog by Harald Parzhuber of Texas Instruments, “5 converter topologies for integrating solar energy and energy storage systems” (free but registration may be required). It begins with an overview of the various power converters that a residence with solar power might require, each producing different DC voltages and currents, Figure 2.

Figure 2 A typical solar-inverter system for residential energy generation. The associated storage-system installation shows that different units are needed for different functions in the house. Source: Texas Instruments

As the title indicates, it is not about any single topology but instead it looks at the attributes of five topologies with respect to complexity, voltage, performance, and other aspects. This brief yet interesting blog/app note starts with a nice summary table/graphic showing and classifying power topologies for half-bridge and branch equivalent, and then delves further into each one with a substantive level of detail, Figure 3.

Figure 3 Simplified power topologies for half-bridge and branch equivalent topologies. Source: Texas Instruments

This was followed by a chart listing the benefits and challenges (that’s an engineering euphemism for “difficulties,” of course) of the different topologies.

After reading this piece, I gained some useful insight into the converter options for this application and their associated technical cost/benefit tradeoff of each. It made clear, among other points, that a simpler design with fewer components can work. However, by adding additional components or using somewhat different topologies, you can overcome the inherent shortcomings of the simpler approaches, if those are unacceptable—and they may not be. It’s one of the classic engineering tradeoffs and dilemmas: keep it simple (which is generally a good thing) and accept reduced performance or elect to add complexity for some level of performance improvement. To what extent should the engineering rule that “simpler is better” apply?

This blog was a nice, brief course and guide proving insight into the issues. If I was actively doing a design this this area, I’d have much better insight into the options and tradeoffs—that’s a good engineering start to any project.

Do you recall reading a brief but insightful application note that gave you the perspectives you needed about your choices and the costs/benefits of each? Are the lessons it offered still meaningful and viable?

Bill Schweber is an EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features.

Related Content

• Energy-storage options: abundant alternatives and tricky tradeoffs
• Pulsed high-power systems are redefining weapons
• Keep solar panels clean from dust, fungus
• Series vs shunt linear voltage regulation for small solar-photovoltaic power supplies
• Teardown: The power inverter – from sunlight to power grid

The post Home solar-supply topologies illustrate tradeoff realities appeared first on EDN.

Sometimes I look at a product and think to myself, “wow, this device was genuinely developed to solve a customer problem.” Other times, I look at it and think “wow, this device exists fundamentally to extract money from customers’ wallets.” Spotify’s Car Thing, which many of you likely didn’t know was ever even a thing (show of hands, readers? Yeah…thought so…) unfortunately IMHO falls into the latter category. Which likely explains why, after first rolling out press review units in April of 2021, followed by a limited public preview that same October and a full release the following February (2022) at $89.99, by that same (last)-year late summer the company began heavily discounting remaining inventory in preparation for a full product discontinuation (although Car Things already in customers’ hands still work). The markdown pricing started at $49.99…by late October, when I bought mine, it was down to $29.99.

Truth be told, I don’t even use Spotify; Amazon Music Unlimited, Pandora and Sirius XM (along with, occasionally, Tidal) are my services of preference. And Car Thing wasn’t compatible with the free Spotify service tier, anyway; you needed to spring for a Premium account (and then spring even more for Car Thing itself…remember my earlier “money extraction from wallet” comment)? But it’s got some cool technology built into it—touchscreen, dial-and-button and voice interface options, for example, along with an OpenLinux O/S foundation and integrated Bluetooth—so I thought it’d make a cool teardown candidate.

In (faint) fairness to Spotify, the product’s lengthy gestation was no small part of the problem; had it come out sooner, when folks’ smartphone screens were tinier and the smartphones’ voice interfaces were flakier, it might have had more of an impact (the company started talking publicly about the initial prototype, which never ended up making it to market, way back in May 2019). But I’m getting ahead of myself; how does Car Thing work?

As the earlier “stock” photo shows, Car Thing has a 3.97” diagonal 800×400 pixel resolution LCD touchscreen, along with a dial in the upper right corner (which can also be pressed in to select a particular menu option) and a switch-only button below it (for “back-menu” purposes). In-between them is an embedded ambient light sensor that raises the LCD backlight intensity for daylight viewing and dims it to avoid distracting the driver at night. Along the top edge is an array of microphones along with several preset-selecting buttons. And Car Thing communicates with a separate (also required) smartphone over Bluetooth.

That’s right; Car Thing’s not even a Spotify receiver in its own right. Essentially, it’s a Spotify-only (albeit for both Android and iOS) second display with app UI control. Now see what I mean about how the large-screen smartphones that are all the rage nowadays, not to mention the multi-app-compatible Android Auto, Apple CarPlay and other UIs built into modern vehicles’ dashboards, have essentially neutered any rationale for Car Thing’s ongoing existence?

Enough background-info banter; let’s get to dissecting. As usual, I’ll begin with some outer packaging shots:

Slip off the sleeve:

Open the top, and here’s what you’ve got:

Let’s first look at what’s underneath the Car Thing:

First, a few pieces of literature:

And below that, three different mounting options—optical disc player slot, vent, and dashboard (the latter permanent sticker-only, no suction cup option), all of which magnetically mate to the Car Thing—a USB power cable, a cigarette lighter socket power adapter, and a screen cleaner:

Spotify thoughtfully supplied an adapter with dual USB power outputs, one for the Car Thing and the other presumably intended for the paired smartphone:

And here are the cigarette lighter power adapter’s specs:

Now for Car thing itself, as-usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes:

Remove the screen protector and reorient the smartphone-as-camera to minimize reflections…

As you may have already been able to tell, Car Thing is fairly svelte:

• 5” (124 mm) wide
• 3” inches (64 mm)
• 1” (20 mm) in depth and
• weighing 3 oz (90 g)

A top view reveals the five preset buttons, intermingled with four inlet holes for (presumably MEMS) microphones:

A bottom-side view is more mundane:

As are the initial glimpses of both sides:

So, let’s flip ‘er over:

Again, the top edge of the device:

is far more intriguing than either the bottom edge or either side:

The USB-C power input is a bit more interesting:

And then there’s the back-side label itself:

which atypically doesn’t list the FCC ID (2AP3D-YX5H6679, for any of you who were wondering) but provides a potential path inside. While poking at one of the corners of the sticker with a flat-head screwdriver to see if I could get it to detach, I stumbled across the impression of a seeming screw head underneath. No surprise, there ended up being one in each corner:

By alternative means of my thumbnail, I did end up getting the sticker off:

although removing the metal panel underneath didn’t get me far in the grand scheme of things; its seeming “raison d’être” is as a mate for the previously mentioned magnet mount:

So, I turned my attention to the device’s front side, specifically the aforementioned dial. The top portion popped right off when I applied a flat-head screwdriver to it:

The assemblage underneath the rubberized disc lifted right out, too, but only to a point; a flex cable presumably also connected to the main PCB inside the device hindered further progress:

See what look like two silver pins in that last shot? I assumed that they, in conjunction with some adhesive, held in place the plastic ring surrounding the assembly, and that I might therefore be able to pop the plastic ring off by careful flat-head screwdriver application (to avoid cracking the screen surrounding the ring). Unfortunately, my theory didn’t exactly pan out:

Turns out the dial and button are part of the same subassembly, which cracked and punched through the screen. And those silver pins? They were the ends of two screws; initial assembly had taken place from the other (in)side.

In this next shot, you can see the ambient light sensor, also integrated in the same subassembly, in-between the dial and button:

One upside of my inadvertent entry point into the Car Thing’s innards is that it was then straightforward to surmount the remainder of the adhesive surrounding the LCD:

Turns out the flex cable coming from the dial-and-light-sensor-and-button assembly that I showed you earlier didn’t end up directly at the system PCB, after all. Instead, it connected to an amalgam of connectors, traces and circuits glued to the backside of the display backlight, from which exited a larger flex cable which did end up at the system PCB:

Its tether point is the now-unpopulated connector at top in this photo, above the large Faraday cage on the main PCB:

Speaking of which…now for the main PCB and its heat sink to the left. First step, remove those three screws:

Next, the connector to the left of the earlier-mentioned one, whose flex cable hooks up to the five top-side preset buttons and four microphones mentioned earlier:

Here’s a closeup of the buttons-and-mics assemblage, after disconnecting the flex cable. The assemblage was securely glued in place, so I was unable to proceed further with its dissection:

So, I returned my attention to the PCB-and-heatsink smorgasbord, which lifted right out of the chassis with no fuss:

The heatsink and PCB were pressed together with thermal paste on the underside:

Both sides of heatsink standalone, for your inspection:

Since we’ve got the PCB turned upside down, let’s next clean off its Faraday Cage with some rubbing alcohol:

And then pop it off:

More thermal paste to remove; happy happy joy joy!

That large square IC is the system SoC, Amlogic’s S905:

And populating one of the other now-exposed quadrants is an Etron Technology EM6HE16EWAKG-10 4 Gbit 933 MHz DDR3L SDRAM:

Now let’s flip the PCB back over; it’s got two Faraday Cages to pop the tops off, and more thermal paste to subsequently clean off:

The large square IC in the upper right corner can be ID’d by its last two package mark lines:

THGBMNG5
D1LBAIL

The product code THGBMNG5D1LBAIL references a 4 GByte eMMC module comprised of a Toshiba (now Kioxia) 32 Gbit NAND flash memory and a media controller. Below it, in the lower right corner of the PCB, is a Cypress Semiconductor (now Infineon) CYW20706 Bluetooth (and Bluetooth LE) SoC; you can see the associated PCB-embedded antenna to its left.

As I previously mentioned, the Car Thing runs on an OpenLinux operating system foundation. Predictably, folks have tried “rooting” the device to give it additional capabilities and otherwise extend its useful life. Here are a few related Github pages I found, for your perusal:

• “Spotify Car Thing Root”, by Nolen Johnson (project coverage)
• “car-thing-reverse-engineering”, by Ivan Savelyev and team

And that just about wraps up this project, at least from my perspective; feel free to continue the discussion in the comments!

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related Content

• Freeing a three-way LED light bulb’s insides from their captivity
• Ungluing a GaN charger
• Streaming music reception: implementation differentiation
• Google’s Pixel Buds Pro earbuds dissected: Noise is (finally) actively detected

The post Spotify’s Car Thing: “Why does it exist” is the crux of the questioning appeared first on EDN.

Silicon carbide (SiC) has arrived, and it’s a big deal. It was written all over APEC 2023 show with a string attached: the cost of a SiC device is significantly higher than its silicon counterpart. Several seminars and keynotes about SiC provided first-hand details about the cost issues and what the industry is doing to address them.

At his keynote titled “Silicon Carbide Mass Commercialization and Future Trends” at APEC 2023, Victor Veliadis, executive director and CTO at Power America, outlined wafer cost, defects, scalability of the device area, reliability, and ruggedness concerns as major barriers for SiC in next-generation power electronics. Power America is a member-driven consortium of industry, universities, and national labs.

“The commercially available manufacturing processes for silicon are streamlined and high yield,” Veliadis said. “In SiC, you need processes that are SiC specific because it’s a very hard material.” That makes SiC wafers—currently moving from 150 mm to 200 mm—highly complex. “More complexity inevitably leads to higher cost,” he added.

While emphasizing the need for new fab models and a vibrant SiC manufacturing infrastructure, he proposed using old equipment manufacturing silicon devices complemented by SiC-specific tools. “Process SiC in silicon fabs while using 30-year-old equipment by adding SiC-specific tools and explore the silicon economy of scale.”

Figure 1 Victor Veliadis highlighted the need for new fab models and manufacturing infrastructure for SiC in his keynote at APEC 2023.

Narrowing down to the most crucial issue—cost—Veliadis claimed that 40% to 60% of SiC device cost relates to the substrate. “Wafer substrate complexity is the key factor in higher than silicon device cost,” he added. That explains why several major SiC players like STMicroelectronics and onsemi are proactively bolstering SiC wafer supply.

Vertical integration is back

STMicroelectronics, very prominent on this front, first acquired Sweden-based SiC wafer supplier Norstel and then deepened its cooperation with French material supplier Soitec for its SiC substrate technology. Soitec is among the early suppliers offering 200-mm SiC wafers.

Moreover, to ramp up its production of SiC devices, ST is building a new fab in Catania, Italy, which is dedicated to SiC devices. Besides its front-end fabs in Catania, Italy and Ang Mo Kio, Singapore, ST has back-end facilities for assembly and testing in Shenzhen, China and Bouskoura, Morocco. Next, ST has started small-volume 150-mm production for substrate manufacturing in Norrkoping, Sweden. Here, it’s also experimenting with 200-mm prototypes to enhance wafer quality and yield.

At APEC, while talking about ST’s focus on SiC wafer management, Gianluca Aureliano, Americas marketing manager for automotive power transistors at STMicroelectronics, acknowledged the complexity of building SiC wafers and related defect issues. “Dedicated machines for SiC fabrication can lead to extra cost,” he said. “It’s a new material, so material cost is a significant factor.”

Figure 2 Vertical integration is making a comeback in the SiC technology realm. Source: Yole

Five years after inheriting the SiC business from Fairchild Semiconductor and turning SiC into a strategic bet for automotive and industrial markets, onsemi snapped GT Advanced Technologies (GTAT), a supplier of SiC materials in New Hampshire. It’s worth mentioning here that Fairchild had bought Swedish startup TranSiC to enter the SiC market before it was acquired by onsemi in 2016.

Also, onsemi as well as Infineon had SiC wafer supply agreements with GTAT before onsemi acquired GTAT in a $415 million cash deal to bolster its supply of competitive SiC wafers. Now, onsemi plans to expand GTAT’s SiC crystal growth technology into 150-mm and 200-mm wafer realms.

Epi layer cost

Peter Friedrichs, senior director for wide bandgap at Infineon Technologies, acknowledged that wafer is a major cost point in SiC devices. However, resonating with Veliadis’ views, he noted that front-end SiC manufacturing isn’t much different from silicon-based IGBTs. “That opens the door for using silicon fabs with specialized SiC tools.”

Friedrichs also noted that the epitaxial process mainly constitutes the cost. SiC epi-wafers are produced through deposition and growth of epitaxial SiC layer on the surface of single-crystal SiC substrate.

“Epi requires demanding tools that are also expensive,” he added. Infineon has adopted a multi-source approach for SiC substrates to counter the wafer cost. Here, it’s worth noting that wafer suppliers like Resonac now offer tools that prevent the expansion of dislocation defects existing in SiC substrate into the epitaxial SiC layer.

Figure 3 Infineon has signed a multi-year SiC wafer supply deal with Resonac, formerly known as Showa Denko. Source: Infineon

Friedrichs and Veliadis agree on another key premise: high SiC devices cost can be compensated by reducing the overall cost at the system level. “Lower system cost can be achieved with the reduced amount of magnetics at higher frequency and simplified thermal management,” Veliadis said in his keynote.

Besides cost, wafer defects are a major headache in SiC device manufacturing. “The presence of defects limits the scalability of the device area,” said Veliadis. “To minimize defects, engineers must get threshold stability under control.” Thus, engineers can make larger-area devices by reducing defects.

SiC device ruggedness, another crucial issue, relates to high avalanche tolerance. “SiC circuit ruggedness is enabled by fast gate drives with protection features,” Veliadis said. That shows a way forward and that challenges will be overcome over time.

With greater focus on SiC crystal growth, epitaxial layer and robust wafer supply, the component cost of SiC is expected to come down over time. Though challenges are real, stakes are too high for the status quo to hold SiC progress hostage for long.

Related Content

• SiC and GaN: A Tale of Two Semiconductors
• The diverging worlds of SiC and GaN semiconductors
• SiC and resurgence of semiconductor vertical integration
• Silicon carbide (SiC) and the road to 800-V electric vehicles
• APEC 2023: SiC moving into mainstream, cost major barrier

The post Silicon carbide’s wafer cost conundrum and the way forward appeared first on EDN.

When someone notices that two 8-bit DACs can be bought for less than one 16-bit DAC, a classic question is often asked: Why can’t you simply take two 8-bit DACs, assign one to the MSByte, the other to the LSByte, sum their outputs in a 28:1 ratio, and get 16 bit resolution (or near) for cheap? The likewise classic (but disappointing) answer is: Well, you can try, but you probably won’t like the result. This prediction is usually true mainly because of two factors:  #1, poor differential nonlinearity (DNL), and #2, mismatch between typical 8-bit DACs.

The DNL of classic “resistor ladder” architecture DACs, typified in Figure 1, is seldom much better than the ~1/2 lsb that’s good enough to guarantee monotonicity, but only just.

Figure 1 The DNL typical of classic “resistor-ladder” DACs.

Consequently, when two such “classic” DACs are combined, very little improvement in useful resolution can happen. Fortunately, there’s an alternative. The inherent DNL of a “resistor string” type DAC is much better, as illustrated in Figure 2.

Figure 2 The DNL typical of “string” type DACs (e.g., TLV5624).

So, provided the right DAC architecture is chosen, is there hope after all for our money-saving plan?

Unfortunately, #2, the mismatch problem, remains unsolved. Two 8-bit DACs just can’t be expected to have output scale factors that match and sum to a result that’s significantly more accurate than required for 8-bit precision—clearly inadequate for our extended resolution application. However, what if both bytes of the 16-bit input could be converted by the same DAC? One DAC can reasonably be expected to accurately match itself!

A recent design idea (DI) suggests how this might be done (i.e., get one DAC to do double duty). In the earlier DI, the Shannon Decoder concept (see Figure 3), is explained. It employs (what is effectively) a 1-bit DAC to do multi-bit digital to analog conversion by the dynamic summation of successive conversions in a simple T/ln(2) RC time constant.

Figure 3 The Shannon decoder dynamic DAC.

The trick that might be useful here is this: the Shannon Decoder principle isn’t limited to working with a 1-bit DAC. If instead of a time constant of RC = T/ln(21) the constant is made to be T/ln(28), then an 8-bit DAC could be accommodated. This is done in Figure 4.

Figure 4 The Shannon decoder principle applied to extending 8-bit DAC resolution.

U1 is an 8-bit, voltage output, resistor-string type DAC (e.g., TLV5624) controlled by a standard SPI serial interface, plus a separate output bit (CNV = Convert/-Hold). 

Each conversion cycle is 2Tby = 40 µs long (for a 25kHz update rate) as illustrated in Figure 5.

Figure 5 The Shannon conversion sequence.

As the cycle begins with loading the Lsby of a 16-bit conversion value. Simultaneous assertion of Frame Sync (FS) and Convert (CNV) outputs the Lsby value and switches U2 so that R1 is connected to C1, creating a Shannon summation time constant of

R1C1 = Tby/ln(28) = 3.610 µs.

 Consequently, after the 20 µs Tby interval, the charge on C1 is

 Vc1 = (256/28)Lsby = Lsby.

While that’s happening, the Msby is loaded over the SPI interface so that when the second FS pulse occurs the Msby value is output, beginning its accumulation by the R1C1 time constant, while the previously accumulated Lsby de-accumulates. 

After the second Tby = 20 µs interval,

Vc1 = (256/28)Msby + (256/216)Lsby = Msby + Lsby/28,

 which is the final 16-bit result, and the conversion cycle is complete.

CNV now returns low, causing Vc1 to be sampled and transferred to C2 by unity-gain follower U3, where it is held until updated by subsequent conversion cycles.

Stephen Woodward’s relationship with EDN’s DI column goes back quite a ways. In all, a total of 64 submissions have been accepted since his first contribution was published in 1974.

 Related Content

• The Shannon decoder: A (much) faster alternative to the PWM DAC
• DAC (PWM) Controlled Triangle/Sawtooth Generator
• Cancel PWM DAC ripple with analog subtraction—revisited
• Cancel PWM DAC ripple with analog subtraction but no inverter

The post Squeeze extra resolution from an 8-bit DAC with Shannon decoder idea appeared first on EDN.

Embedded systems are ubiquitous in our daily lives, from medical devices to automotive systems to smart homes, yet the most popular embedded programming language poses significant safety and security risks. The MISRA C guidelines reduce such risk by providing a set of rules and directives to minimize undefined behaviors and vulnerabilities in areas such as memory allocation, pointer management, and buffer overflows.

The recent release of the MISRA C:2012 Amendment 4 (AMD4) and upcoming release of the MISRA C:2023 edition offer embedded developers the opportunity to re-evaluate how the guidelines are adopted by embedded software teams. Amendment 4 addresses concurrency features introduced in the latest versions of the C standard (ISO/IEC 9899:2011 and 2018) and MISRA C:2023 will consolidate all MISRA C versions into one document.

By expanding the guidelines to cover multithreading and atomic types, the MISRA C guidance aligns to the increasing complexity and scale of embedded systems in any industry. Embedded developers are relying more on these concurrency features and sophisticated hardware platforms to deliver on growing requirements for connected devices and feature-rich user experiences.

MISRA C:2023 compliance report from the TBvision component of the LDRA tool suite indicates 27 violations within a C file. Source: LDRA

Reducing the risk of safety issues and security breaches in these complex environments means understanding how MISRA C compliance applies to your code.

The risks of C programming for critical systems

The MISRA Working Group developed the MISRA C guidelines to establish best practices in coding, tools, and development processes to ensure the reliability, safety, and security of embedded software in critical systems. MISRA C addresses a wide range of potential coding errors in areas such as data type conversions, control flow statements, and use of the standard library functions.

Such errors arise from limitations in the C language standard itself, where the implementation and behavior of some features are not specified to give compilers, operating systems, and developers flexibility in their use.

These unspecified features can lead to behaviors at runtime that are:

• Undefined – the C standard contains no requirement for how the feature must behave.
• Unspecified – the C standard allows for two or more behaviors for a feature with no specification as to which one shall be used.
• Open to interpretation by the language implementation (compiler and operating system) to decide and document.

This flexibility allows implementers of the C standard and embedded developers to write code that meets the requirements of the language. However, it can also cause undesirable and unpredictable effects in critical systems. Below are some examples:

• Writing to a file stream opened as read-only can lead to potentially undesirable behavior.
• Using functions that call themselves recursion can lead to a potential stack overflow.
• Accessing memory outside the bounds of a data structure can lead to a threat vector exploitable by hackers.

MISRA compliance example

To help development teams test their code and prove compliance, MISRA C classifies guidelines as either rules or directives:

Rule: A source code requirement that is complete, objective, and unambiguous. Developers can use analysis tools to check compliance with rules. The guidelines further classify rules as decidable if analysis tools can conclusively verify them and undecidable if no verification guarantee is possible.

Directive: A guideline satisfied through code, processes, documentation, or functional requirements. Directives can be subject to interpretation, and analysis tools may or may not be able to assist in checking compliance.

Take this code sample that uses the C sizeof() operator in accordance with the C standard:

void foo(int32_t x)

{

size_t x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

s = sizeof(int32_t[x++]); //Non-compliant to MISRA C

}

As sizeof() does not execute expressions passed into it, but rather simply evaluates the type and size of the resulting expression at compile time, this code may result in unexpected behavior at runtime. Although such usage is legal according to the C standard, the MISRA Working Group restricts this usage in MISRA C:2012, Rule 13.6, stating that “The operand of the sizeof operator shall not contain any expression which has potential side effects.”

The guidelines classify this rule as decidable, which means that developers can use static analysis tools to identify occurrences in code where this rule is violated. Once identified, developers can correct the error with a simple adjustment:

void foo(int32_t x)

{

size_t x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

++x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

}

Benefits of MISRA compliance

Some C compilers can identify risky coding implementations, but they are by no means as comprehensive or effective as automated tools that can identify issues earlier in the lifecycle. As MISRA C lays out decidable rules to clearly restrict language use to a safe and secure subset, tools deploying static analysis can use this information to help developers identify potential issues as they write code.

MISRA C influences standards across many industries where critical software is built. MISRA C guidelines are either directly cited by or commonly practiced in projects following AUTOSAR, IEC 62304, IEC 61508, ISO 26262, and DO-178C processes. MISRA C also forms the basis of the Joint Strike Fighter C++ Coding Standard and the NASA Jet Propulsion Library C Coding Standard.

In addition to improving the security and safety of embedded systems, compliance with MISRA C has legal and financial benefits. Development teams adopting a MISRA compliance strategy can demonstrate due diligence toward reducing the risk of liabilities and the loss of confidence among consumers, investors, and industry regulators. In the event of a product recall, security breach, or similar incident, the artifacts of MISRA compliance can support investigation, remediation, and re-release efforts.

The path forward with MISRA C

MISRA C is not a coding style guide but rather a set of rules and directives to minimize or eliminate coding practices known to be hazardous. Especially relevant to the complexity of safety- and security-critical systems, AMD4 and MISRA C:2023 give developers an important tool in avoiding or eliminating potentially dangerous code.

By adapting development processes to support the effective and efficient demonstration of MISRA compliance, such as using static analysis tools to identify violations, teams can improve the reliability of their products and reduce the likelihood of vulnerabilities in their code.

Mark Pitchford is a technical specialist at LDRA.

Related Content

• MISRA C: Write safer, clearer C code
• Using MISRA C and C++ for security and reliability
• Software test tools add support for MISRA C: 2012
• MISRA C update addresses automotive software safety
• 5 ways to incorporate MISRA C:2023 into your embedded development process

The post Why MISRA C matters for embedded system developers appeared first on EDN.

When you think about your furnace, you may not immediately connect it to the health of your electronics. However, these two seemingly unrelated systems can impact one another in surprising ways. A poorly functioning furnace can cause damage to your electronics, leading to costly repairs and replacements.

In this post, we will explore the reasons why your furnace might be damaging your electronics and what you can do to prevent it.

One of the primary ways a furnace can damage your electronics is by causing temperature fluctuations. Electronics are sensitive to temperature changes, and frequent swings can lead to premature wear and tear on components.

To prevent this issue, ensure that your furnace is operating efficiently and consistently maintaining a stable indoor temperature – check out Morris Jenkins for more info about furnace repair.

A poorly functioning furnace can also lead to excess humidity in your home. High humidity levels can cause condensation to form on your electronics, which can lead to corrosion and eventual component failure.

To combat this problem, consider investing in a dehumidifier or humidifier, depending on your climate, to maintain an ideal humidity level in your home.

Your furnace filters and circulates air throughout your home. Over time, dust and debris can accumulate inside the furnace and in your air ducts, which can then be blown out into your living space. This dust can settle on your electronics, clogging vents and causing them to overheat.

Regularly replacing your furnace filter and having your air ducts professionally cleaned can help reduce the amount of dust in your home and protect your electronics.

A malfunctioning furnace can sometimes cause power surges, which can be incredibly damaging to your electronics. When a power surge occurs, it can overwhelm the electrical components of your devices, potentially frying circuits and causing irreversible damage.

To safeguard your electronics, use surge protectors on all sensitive devices and consult a professional to assess and repair your furnace if you suspect it is causing power surges.

An improperly grounded furnace can create electromagnetic interference (EMI), which can disrupt the operation of your electronics. EMI can cause erratic behavior in your devices, such as random shutdowns or data corruption.

If you suspect your furnace is not properly grounded, contact a professional to assess and resolve the issue.

If your electronics are located near your furnace or in a room that is consistently warmer than the rest of your home, they may be at risk for heat-related damage. Prolonged exposure to high temperatures can cause components to degrade and shorten the lifespan of your devices.

To avoid this, ensure that your electronics are kept in well-ventilated areas away from heat sources, such as your furnace.

To protect your electronics from furnace-related damage, follow these steps:

Keeping your furnace in good working order is crucial to preventing damage to your electronics. Schedule regular maintenance with a professional HVAC technician to ensure your furnace is running efficiently and safely.

Invest in a hygrometer to monitor the humidity levels in your home and adjust as needed with a humidifier or dehumidifier. Additionally, keep an eye on your thermostat to ensure your home’s temperature remains stable.

Protect your electronics from power surges by using surge protectors on all sensitive devices. This simple step can save you from costly repairs or replacements.

Position your electronics in well-ventilated areas, away from heat sources like your furnace. This will help prevent heat-related damage and extend the life of your devices.

A well-functioning furnace is not only essential for maintaining a comfortable living environment but also for protecting the integrity of your electronics. By understanding the potential risks posed by a poorly maintained furnace and taking proactive steps to address them, you can safeguard your electronics and avoid costly repairs or replacements. Regular maintenance, monitoring temperature and humidity levels, investing in surge protectors, and keeping electronics away from heat sources are all effective ways to ensure your devices remain in optimal condition. Stay vigilant and protect your valuable electronics from furnace-related damage.

The post Why Your Furnace Might Be Damaging Your Electronics And What To Do About It appeared first on Electronics Lovers ~ Technology We Love.