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

Author: STMicroelectronics

The STM32 Developer Zone and the STM32 Finder represent a great starting point for new and experienced developers. See how they can help reduce your time to market.

Where do you start when you are unfamiliar and potentially intimidated by such a large and rich development world as the STM32Cube ecosystem? The answer is, “Here!” Many of our partners and customers have expressed the desire to see more products use the STM32Cube environment. It’s for this exact reason that we have moved devices like the BlueNRG-LPS and S2-LP over to STM32 microcontrollers (for more information, see our blog post on the STM32WB0 and STM32WL3). Developers enjoy the graphical user interface and ease of use of tools like STM32CubeMX, the free STM32CubeIDE, and the many software packages, drivers, and middleware that help them release a product to market faster.

However, we also know that many are trying an STM32 device for the first time. Whether because they got their hands on a Discovery Kit or Nucleo boards, or simply because more and more companies are choosing to adopt our devices, there are an increasing number of engineers taking their first steps in our ecosystem. Hence, to make this experience with an STM32 more accessible, and lower the barrier to entry, we have developed tools like the STM32 Developer Zone and the STM32 Finder. Let’s explore how they can assist teams in their journey, even be a positive contributor to seasoned experts, and how they bring the STM32 ecosystem together.

The STM32 Developer Zone New approaches to development

Increasingly, new markets are adopting embedded systems, and engineers must familiarize themselves with complex concepts. For instance, developers may need to quickly learn how to take advantage of AI on a microcontroller, write a low-power wireless application designed for harsh environments, or implement strong security safeguards to meet new regulatory requirements. It was thus important for ST to help teams make the right choices for their products faster. The STM32 MCU Developer Zone is already playing a significant role in our community and is ranked as the number one page on ST.com in customer satisfaction. It was thus normal to use this platform to serve STM32 developers better.

STM32 MCU Developer Zone

While keeping the original spirit that made the Developer Zone successful, we felt it would help our community further by providing a new STM32 MPU Developer Zone. Additionally, we worked on a new application-based approach to complement the existing product or software selectors for tools like STM32CubeIDE. We also have a “Solutions” tab with sections on GUIs, motor controls, USB-C Power Delivery, and more, while “Developer Resources” will guide newcomers and experts alike by pointing them to relevant technical documentation. The website thus remains a quick way to find the right development board and software tools while guiding new engineers as they take their first steps.

The solutions in the STM32 Developer Zone (MCU version) Localization in Chinese and Japanese

In our effort to reach more STM32 developers, we are thrilled to have launched the Chinese and Japanese versions of the STM32 MCU and MPU Developer Zone. The sites provide feature parity with the English site, thus offering a strong platform for our communities in Asia. Indeed, beyond simply translating the landing pages, we are making technical documentation available in those languages, such as our white paper on security. In a nutshell, the localized versions of the Developer Zone are another testament to our desire to reach engineers where they are and work with regions by providing solutions tailored to their needs and markets.

• STM32 MCU Developer Zone in Chinese
• STM32 MPU Developer Zone in Chinese
• STM32 MCU Developer Zone in Japanese
• STM32 MPU Developer Zone in Japanese

Operating systems and an official Visual Studio Code extension

The STM32 Developer Zone will continue to receive frequent updates. For instance, we are working on releasing other solutions for the STM32U5 besides AzureRTOS in STM32CubeU5. Similarly, the STM32 Developer Zone will also promote an official Visual Studio Code extension. Developers will be able to flash their devices, track variables, and get error messages within their environment, thus vastly simplifying their workflow. Finally, the STM32 Developer Zone will also receive updates featuring software for the newly announced STM32H5 and for the new STLINK-V3PWR, which both launched at this year’s STM32 Innovation Live.

The STM32Cube Ecosystem What is the STM32Cube Ecosystem?

Launched in mid-2014, the STM32Cube brand designates our solutions to help developers

The STM32Cube Ecosystem

design products and applications. The software ecosystem relies on two pillars: embedded packages and software tools. There are two types of STM32Cube Packages: MCU Packages and Expansion Packages. The MCU Packages (STM32CubeF4, for instance) contain drivers, low-level APIs, and demos or example codes for Nucleo and Discovery boards. The STM32Cube Expansion Packages complement the device packages by offering additional middleware or drivers, as we recently saw with X-CUBE-AI, the first package in the industry to enable the conversion of a neural network into the optimized code for STM32 MCUs.

The STM32Cube software tools for PCs assist in the design of applications. It is common to hear partners say they rely on utilities like STM32CubeMX or STM32CubeProgrammer for their projects. And many of our tutorials use them to make our technologies more accessible. However, there are many other STM32Cube software tools. For instance, STM32CubeMonUCPD is a monitoring tool that works with all our USB-C PD interfaces and libraries to facilitate testing and implementation operations. And STM32CubeProgrammer is a programming tool that makes STM32 MCUs more accessible and efficient.

How tools in the STM32Cube ecosystem work together?

As time passes, tools and packages within the STM32Cube ecosystem have come to work together. For instance, STM32CubeMX is baked into STM32CubeIDE. Put simply, over the years, developers have experienced how the ST toolchain has become more cohesive. Obviously, we will also continue to release standalone versions of our STM32Cube tools for the developers who use other toolchains, ensuring that anyone can easily benefit from our STM32Cube ecosystem. However, ST engineers and researchers will continue to commit to dogfooding our tools, such as using STM32CubeIDE, because we want to be truly invested in our ecosystem and closer to our community.

How software packages in the STM32Cube Ecosystem work together?

Up to now, developers who wanted to use an STM32Cube expansion package had to find the right one, download it, and unpack it. That meant adding source files to an IDE or even exploring its source code. Additionally, porting it from one MCU to the next isn’t always straightforward if an application uses specific pins or IPs. It may also be imperative to install drivers, libraries, or middleware. Until now, ST offered documentation and tutorials to help developers. When there were only a few expansion packages, things were much more straightforward. Now that the STM32Cube ecosystem is so large, frictions can significantly increase.

The solution comes from the integration of STM32Cube expansion packages within STM32CubeMX. In a nutshell, developers can select an X-CUBE package straight from the MCU configuration tool. It required that we update existing packages, and a list of compatible solutions is available. We will also continue to ensure that most upcoming STM32 expansion packages from ST support this feature. By integrating these software packs within STM32CubeMX, users select the package, generate the files, and simply start coding. As a result, it lowers the barrier to entry for developers less familiar with our ecosystem.

How can ST Authorized Partners bring their software packages to the STM32Cube ecosystem?

Another issue that developers may encounter pertains to the ability to share their custom solutions. It is common for a company with specific needs to create a custom expansion package. Partners may then want to offer solutions to the community. For instance, we talked about embOS from SEGGER and Unison RTOS from Rowebots on the blog, but there are many others. These solutions, found under the I-CUBE initiative, help engineers add features and experiment with various technologies. However, sharing a custom package within a company or the community is not always obvious or easy. Hence, we wanted to help partners more easily create highly sharable packages.

To remedy this particular point of friction, ST is opening STM32CubeMX to I-CUBE packages. Put simply, the same integration we bring to our STM32 expansions (X-CUBE) is now available to all developers. Anyone can now build a package using STM32CubePackCreator to create a solution that can appear within STM32CubeMX. However, we’ll curate what’s visible by default within the MCU configurator tool. We offer documentation to guide developers in this process to ensure uniformity and compatibility within the STM32Cube Ecosystem. We are also offering STM32PackCreator. The utility, found within STM32CubeMX, facilitates the creation of a software package from scratch.

An expansion software follows CMSIS-Pack (Cortex Microcontroller Software Interface Standard). Many will also be configurable within STM32CubeMX’s GUI. To abide by the CMSIS-Pack specifications, developers must include a PDSC (Pack Description) file. Such a document uses XML and demands detailed information on all the pack’s content. Similarly, to make the X-CUBE or I-CUBE configurable within STM32CubeMX, STM32PackCreator uses a dedicated UI. It opens the door to a system that puts a wealth of options at a user’s fingertips, ensuring developers no longer have to configure everything manually by writing code. STM32PackCreator thus removes friction by automatically generating the PDSC file. It also ensures the software components are configurable within STM32CubeMX.

STM32 Finder What is STM32 Finder?

Not everyone working with STM32 necessarily writes code or designs a PCB. For instance, a

STM32 Finder

manager may plan for a project, or a decision-maker may want to know a component’s specifications. In such a situation, having to download STM32CubeIDE or STM32CubeMX would be cumbersome. As a result, we created STM32 Finder, ST’s mobile application for smartphones and tablets. The tool includes an extensive search feature to find a device or a related development board rapidly. Users also get to download various documentation or rapidly access social media channels and community forums.

How did ST optimize its search engine?

To improve the user experience, ST made STM32 Finder faster and added features for power users. The former came from overhauling the mobile version. By optimizing its code, we increased response times significantly. We are also adopting a responsive design to allow users to compare many devices at once, regardless of the display size. ST also changed the app’s update system to only download changes to the database rather than an entirely new one. Hence, updates are more frequent and take far less time to install to ensure searches are up to date. The latest version also includes new links to various online outlets to find partners, ask questions, or learn what’s new.

ST also reworked the search feature to make it vastly more customizable. For instance, users can now distinguish between packages. As a result, they can see how various models may influence thermal performance or prices, among other things. The application can also group categories of specifications. For example, users can search for a device by grouping UART, LPUART, and USART together. Hence, finding a device’s total number of peripherals can help answer specific questions without digging into the datasheet. Developers could also use the new grouping system to search for devices with SPI and USART since the latter also serves as an SPI.

• Check out STM32 Finder
• Surf the STM32 MCU Developer Zone
• Explore the STM32 MPU Developer Zone
• Learn more about the STM32Cube ecosystem
• On-demand webinar: STM32Cube expansion packs, or how to boost your STM32 design

The post STM32 Developer Zone, STM32 Finder 3.0: Some of the best STM32 journeys start here! Hubs for beginners and experts alike appeared first on ELE Times.

75 years ago, one of the biggest electronics firms of the century got its start in a Palo Alto, California, garage—and it did so with the help of Mickey Mouse.

submitted by /u/roaddog1977 [link] [comments]

Editor’s Note: See Part 1 here

In the last installment we looked at the ultrasonic hardware used in the development of a software designed ultrasonic data transmission system we are calling the SDU-X. 

In this second, and last, installment we will discuss the firmware that enables the system to send and receive data using software defined modulation schemes.

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

The SDU-X firmware

(The Arduino source code can be downloaded in the link at the bottom of this article.)

It needs to be mentioned that an Arduino Nano will have a number of constraints when creating the SDU-X firmware. These range from low clock speed, a small amount of RAM, a large tolerance on the resonator frequency, and the lack of a hardware floating point. So long as we’re aware of the constraints we can work around them.

So, knowing the constraints, let’s figure out a sample rate for the 40 kHz carrier. Nyquist would say it needs to be greater than 80 kilo-samples per second (ksps) but typical practice is to be at least 5 times the 40 kHz. For various reasons, and much testing, I settled for 8 times the carrier, or 320 ksps. For a baud rate, and again after much testing, I decided on 250 baud. Yes, it’s slow but sufficient for sending data back and forth from solar panels or for experimenting. (For those that remember, early PCs communicated at 300 baud over phone lines.)

Sending bytes to the DAC, for transmission, 320k times per second means we will have time to execute less than 50 instructions between bytes. Obviously, we cannot calculate sine values for the transmitted waveform on the fly, so we need to precalculate these. But again, we are constrained by the amount of RAM we have to store this data. A symbol would require 320000/250 = 1280 bytes, and we would need one array for a “0” symbol and another for a “1” symbol. That’s 2560 bytes—that’s 2k more than the Nano has.

(Let me stop for a second to make the point that even on the larger SDR system I worked on, even though there was a lot of RAM and speed, these were still constraints that needed to be worked around. The point is that developing on the Nano is a good proxy for the development on larger SDR systems.)

So, the trick for this scarcity of memory issue I came up with was to break symbols (carrier modulated by “0”s and “1”s) into subsymbols which are ¼ of the symbol time. At transmission time, the subsymbol will be repeated 4 times to make a full symbol. Subsymbols now only require 320 bytes each for “0” and “1”. Note that the subsymbols need to connect together without a discontinuity in the sine wave, whether it is connecting to a “1” or a “0”. This was part of the reason the sample rate and baud rate numbers, above, were chosen.

There is one piece of firmware, and it is shared by both the Requester and the Responder. You can compile it for use in the Requester, or compile it for use in the Responder by changing one “#define” statement in the code. To compile code for the Requester, the line towards the top of the main code that reads “#define REQUESTER” should be active, not commented out. To compile code for the Responder that same line should be commented out.

Starting in the main “loop”, there is a section to select a modulation scheme we would like to use. There are several types to choose from but only four are fully implemented: On-Off Keying (OOK), Binary Phase Shift Keying (BPSK), NONE, and Noise. By uncommenting the OOK line alone and compiling the code, we will be communicating using OOK as the modulation. Selecting BPSK by uncommenting that line alone will allow communications using BPSK. Selecting NONE will transmit short bursts of unmodulated 40 kHz sine waves. Selecting Noise transmits short bursts of somewhat random noise.

Now, let’s look at the Requester compiled code that is surrounded with “#ifdef REQESTER” and “#endif” which tells the compiler to include this code in the Requester compile but not in the Responder compile. The main pieces of Requester code in this block are:

• Get the packet to send
• Preprocess the packet
• Create the modulated symbols
• Break the packet into modulated symbols
• Transmit the packet
• Receive the packet sent from the Responder
• Print received info to the serial port

First, we get some data to send. Currently this is a call to a routine that sets some hardcoded data bytes to send, and a fixed length. But the intention is for the user to modify this to send what they want such as something from the serial port, I2C port, or a timed command for a task like periodic data logging. In the Requester, the first, and sometimes the second, byte is currently used to identify the data it wants the Responder to send or the command it wants executed.

Packet structure

Following this is a call to preprocess the data packet (Figure 5). This first moves a preamble to the packet to be transmitted. This preamble is based on the modulation selected. The preamble is useful for finding a signal amplitude, which aids in slicing. The preamble also contains a bit pattern to assist in syncing to the start of a symbol (bit). It also has a bit sequence to signal the start of the actual data (this is known as the “start-of-packet delimiter”). For OOK modulation, this routine also inserts some pilot bits into the data packet to break up long strings of “1”s or “0”s, which can inhibit symbol sync in the receiver. Lastly, the preprocessor routine creates a 16-bit CRC and appends it to the end of all its bytes of the packet (preamble, data, pilot bits, and now CRC).

Figure 5 The packet structure SDU-X packet structure with the preamble, data bytes, pilot bits, and CRC.

After that we execute one of the tricks used to save us cycles—we create the modulated subsymbols by predetermining parts of the carrier wave that we will transmit. Using a trig function during transmission would reduce execution to a crawl, so we do it in advance. There is a set of routines to do the calculations for a few modulation types and a couple of test types.

To save time in the transmit routine, we next breakdown all the packet bytes to be sent into an array of bits. This is wasteful in memory but saves significant time when we start transmitting the bits at 320k bps.

Transmitting the packet

We are now ready to transmit the packet. After some initialization, we enter a loop controlled by a timer set to the bit time. The code polls the timer until it sees the timer’s timeout bit set, and if it is, it is time to send the next byte to the DAC. The byte is grabbed, in sequence, from the correct precalculated array. This means if the next symbol is a “1”, the byte is taken from the precalculated array built for transmission of a “1” modulated symbol. If it is a “0”, then the byte is drawn from the recalculated array for the “0” modulated symbol. After the 320 subsymbol bytes are sent, they are repeated three more times to complete a full symbol. After this, the next bit to be sent is used to select the correct, precalculated array. This process continues until all bytes in the packet are sent.

During this time that the Requester was transmitting, the Responder was receiving the transmission. To sample the 40 kHz received signal the sampling routine would need to sample at something faster than 80 ksps to satisfy the Nyquist criterion. The maximum speed of the Nano’s ADC is around 9 ksps for 10-bit resolution so, for both OOK and BPSK, the input signal is actually downsampled (taken at less than Nyquist criteria). This means the 40 kHz modulated signal will appear in a new, lower, frequency.

To do the sampling in the Responder a timer is again initialized and then polled in the receiving loop to obtain samples at the correct time. Samples are read from the Nano’s ADC which is connected to the receiver amplifier. OOK and BPSK start to diverge from here, so I’ll just break each down the major steps for each.

OOK: The sample is taken at 4800 sps. The absolute value of the sample is taken and filtered to get a signal that goes up and down with the transmitted “1”s and “0”s. It then finds the mid-value of the two levels so it can slice the stream to capture the bits, but it can’t slice until it syncs to the timing of the filtered symbol stream. This is done by noticing transitions of the filtered stream rising or falling past the mid-value. We also count samples so we can keep synced when there are no transitions such as “000000” or “111”. Now that we have a sync we can wait for the time-center of the symbol and then slice (above mid-value is a “1”, below is a “0”).

While the code is gathering bits by slicing, it is also comparing the last 16 bits received to the defined start-of-packet delimiter. If they compare, then the next bit received is the first data bit.

Bits are collected until the known number of bits in a complete packet have been received. Then a CRC is calculated from the collected bits and compared to the CRC received in the data packet. If they agree, it is marked as a good packet and the receive routine returns to the main code, otherwise the process is reinitialized and the system starts receiving again.

BPSK: This is similar to OOK in that it is downsampled, but is sampled at a more controlled 4500 sps (and the timer is hand calibrated). Due to aliasing, the 40 kHz phase modulated signal will now appear at 500 Hz. The samples are now run through a correlator which is simply a multiplication of the current sample with a sample exactly one symbol time previously, and run through an averager of a length equal to the number of samples in a symbol. The correlator output is now a rising and falling signal and a mid-value is calculated, which will be used for slicing. But slicing is different than OOK. When the correlator output is above the mid-value, it signals that the symbol has not changed from the last symbol. If the correlator output is below the mid-value, it signals that the symbol has changed from the last symbol. So, we are actually using differential BPSK (DBPSK). Again, we need to sync the symbol timing first. A sync occurs as the correlator output passes the midpoint and will occur at every 4 ms after that (4ms is 1/Baud). Slicing is then executed at each sync time.

Similar to OOK, we also search for the 16 bits of the start-of-packet delimiter but with a twist. Because this is differential detection, we don’t know if we will get the bits as defined or the complement of the bits. This is because we did not know if we should have started from a “1” or a ”0”. Therefore, the start-of-packet delimiter code does a compare of both and, if it compares to the complement, it complements the last bit to get differential bit tracking corrected.

Along the way of receiving both OOK and BPSK the signal level and noise level are computed so it can later be output to the user.

It’s interesting to note that, even though OOK is considered a simpler modulation scheme, the OOK receiver code takes more time to execute than the BPSK code. It takes about 170 µs, worst case, to process an OOK symbol and a BPSK symbol takes about 100 µs. Correlation in BPSK is a much more elegant and efficient detection method than energy detection as used in OOK.

One point to remember—transmit code is always easier to write than receiver code. This is mostly due to the fact that receiver code has to deal with variable receive amplitudes and also needs to find and track symbol edges for syncing. It also must scan for the preamble. Transmit code also executes faster than the receiver code as everything it needs is prepared in advance. That’s why we can use much higher sample rates on the transmitter, which is necessary to create the modulated signal.

Now, let’s take a look at the Responder code that is surrounded with “#ifdef RESPONDER” and “#endif” which tells the compiler to include this code in the Responder compile but not in the Requester compile. The main pieces of the Responder code are executed very much like the Requester but the “Receive the packet” is the first thing called. The receiver code is executed until a valid packet is found. After a valid packet is found, the Responder code returns to the main code and calls a routine to execute the command that it received. Inside this routine, the data to send back to the Requester is also set up. The Responder then executes the steps to send the packet, as described above.

Examples

Included with the code are some debug code snippets (located in the tab labeled “Debug”). These can be used while experimenting with the code to view some parameters and look at timing in the code, or checking to see if certain parts of the code are executed.

For example, to view a value of a variable I sometimes send the value to the DAC and watch the DAC output with a scope probe on TP2.This is useful for looking at things like the correlator values but must be scaled for the 8-bit DAC output. You will find an example of this code commented out in the BPSK code.

An example of checking timing is placing code to set TP11 high and then low around the lines of code you want to time (then subtract 3.6 µs for digitalWrite execution time). Setting TP11 high can be done with the line “digitalWrite(TP11, ON)” and setting TP11 low can be done with the line “digitalWrite(TP11, OFF)”. Setting TP11 high and then low is also useful to see things like when the sync is found. You will also find an example of this code commented out in the BPSK code.

That’s the code.

Wrap Up

If you’re interested in the SDU-X you can download all the info such as:

• Source code
• PCB design
  • Schematic
  • PCB design and artwork (KiCad format)
  • Bill of materials
• Design notes
• STL files for 3D printing the parabolic transmit/receive tower

Find them at: https://www.thingiverse.com/thing:6268613

There are many other modulation schemes to explore such as FSK, QPSK, QAM, etc. It may also be an interesting exercise to add error correcting to the packet and explore improvements in packet errors versus S/N. Adding an address to the packet may also be interesting in exploring systems with multiple Requesters and Responders. A couple of the more advanced areas to explore are using the power of I/Q data and the beauty of negative frequencies.

After you experiment with the SDU-X for a while you may want to explore other uses for the hardware. Since it is flexible, you can create code to make the hardware perform different functions. Some ideas are measuring distance or speed of an object, or measuring windspeed and direction, or downsampling the receiver stream and listening for sound in the 40 kHz band.

I hope the SDU-X is useful to those that want to learn more about SDR or are teaching others the basics of SDR.

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

• Exploring software-defined radio (without the annoying RF) – Part 1
• Obtaining a patent in a corporate environment
• Simple GPS Disciplined 10MHz Reference uses Dual PWMs
• Time for a second 3D printer in the lab

The post Exploring software-defined radio (without the annoying RF)—Part 2 appeared first on EDN.

TSMC, while reaffirming its commitment to launch the 1-nm fabrication process in due time, is confident it will overcome technological and financial challenges all the way to 2030. The Hsinchu, Taiwan-based foundry showcased its technology roadmap for 2 nm, 1.4 nm, and 1 nm process nodes at the recent IEDM conference.

It’s worth mentioning that EUV lithography tool supplier ASML expects to reach 1-nm process technology in 2028. On TSMC’s part, it has opened a research and development center in Hsinchu, Taiwan, where 7,000 researchers are working on novel materials and transistor structures for 1-nm chips.

Figure 1 TSMC’s R&D center is working on 1-nm process technologies and below. Source: Reuters

Concurrent to work on a 1-nm process node for monolithic chips, TSMC is also focusing on advancements in packaging technologies to produce multi-chiplet solutions capable of packing more than a trillion transistors by 2030. TSMC plans to put a trillion chips on a package using multiple 3D-stacked chiplets.

Intel catching up

Like TSMC, Intel is also concurrently focusing on cutting-edge process nodes as well as chiplets and advanced packaging technologies to put a trillion transistors on a package. However, while TSMC plans to ride the 2-nm train by 2025, Intel claims that it will leapfrog Taiwan’s mage-fab by launching its 2-nm process node called A20 in 2024. Yet, as we enter 2024, it’s still to be seen if Intel can meet its 2-nm deadline. Intel has announced the production of a 20A-based CPU called Arrow Lake in 2024.

Likewise, the Santa Clara, California-based chip giant plans to advance to a 1.8-nm process node—or Intel 18A—in 2025. Next, by 2028, Intel plans to develop a 1.4-nm process node it calls A14; on the other hand, while TSMC earlier claimed to complete the 1.4-nm process node development by 2026, it’s now hinting about a 1.4-nm node to be ready by 2028.

Figure 2 Intel’s launch of the Arrow Lake processor built around 2 nm will show the company’s hold on its nanometer roadmap.

Samsung, another archrival of TSMC, is also confident that its 1.4-nm process technology will come into its own in 2027. Still, the company more visible in the 1-nm fray besides TSMC is based in Japan, Rapidus, a Japanese government-funded startup fab.

Rapidus joins the fray

Rapidus, which previously engaged with IBM and Belgium’s imec for the design of a 2-nm fabrication process, has now joined hands with the University of Tokyo and French research institute CEA Leti to develop a 1 nm node in the 2030s. The collaboration first aims to produce a 1.4-nm process by 2027.

Here, Leti will focus on exploring novel transistor structures while Rapidus and other Japanese partners, including Riken Research Institute, will contribute through staff exchanges, fundamental research sharing, and the assessment and testing of prototypes.

Leti’s role regarding new transistor structures will be crucial because industry observers anticipate that vertically stacked complementary field effect transistors (CFETs) may replace gate-all-around (GAA) FET technology at 1.4 nm and 1 nm nodes.

Rapidus’ tie-up with IBM and imec is expected to lead to 2-nm pilot chip production in 2025 and high-volume production in 2027. Rapidus entry in the manometer race with a labyrinth of partnerships and alliances shows that while TSMC has become an undisputed leader in chip fabrication, the field is gradually getting crowded. And that’s good for chip vendors and the semiconductor industry at large.

Related Content

• TSMC’s 3-nm Push Faces Tool Struggles
• TSMC Expansion in Arizona to Target 3-nm Node
• Samsung Seen Stumbling at Silicon’s Leading Edge
• TSMC approaching 1 nm with 2D materials breakthrough
• 4 technologies that sum up imec’s sub-1 nm silicon roadmap

The post TSMC reaffirms path to 1-nm node by 2030 on track appeared first on EDN.

Looking back on the year, here’s a review of the most popular News articles on All About Circuits.

submitted by /u/jellzey [link] [comments]

200 mf at 16vdc. Something went very wrong. Big bang, lots of smoke but it's working again (not the capacitor!) with a parts bin replacement cap. submitted by /u/APLJaKaT [link] [comments]

submitted by /u/External_Asparagus10 [link] [comments]

submitted by /u/AutoModerator
[link] [comments]

submitted by /u/Geoff_PR
[link] [comments]

I was just messing around with Sparkfun’s alphanumeric display. Took a bit of fiddling but it’s coming out great. Just need to 3D print a case for it. Since I can only attach 1 photo or video to the post, I’ll link a video of a failed case that I made and the text scrolling. submitted by /u/Bizarre_Bread [link] [comments]

Some really old history tells an instructive tale.

When I worked at Bertan High Voltage through the 1980s we used 100 K, ½ W carbon composition resistors as part of the RC high voltage filters in various modules delivering up through 7500 V (Figure 1). Then one day in the mid-1980s, those high voltage filters started to fail.

Figure 1 The 100K carbon composition resistors used as part of RC high voltage filters in modules delivering up to 7500 V.

Examination revealed that we had gone from using resistors once obtained from Allen-Bradley to other resistors then being made by IRC. It turned out that the Allen-Bradley parts were of true carbon composition structure with their resistive elements made as cylindrical cores of material while the IRC parts were actually film resistors that were acceptable per the published carbon resistor specification sheets, but troublesome for our own purposes.

Both vendor’s parts were sold as being compliant to the military specifications for RC07 resistors and indeed they were both compliant to that. However, the RC07 requirement only called for a voltage withstanding capability to 250 V and our application required those resistors to withstand impulses up into the multi-kilovolt range.

The Allen-Bradley parts could do it and there was even an article on the subject which Allen Bradley had once published, but the IRC film resistors could not do that.

Unfortunately, as we next found out, Allen-Bradley had discontinued their product line. Our purchasing department had therefore gone ahead to IRC in the belief that the two vendors’ parts were equivalent. Unfortunately, for our purposes, they weren’t.

I asked a sales rep why this had happened. His explanation was that Allen-Bradley could no longer obtain sufficient quantities of raw materials to make the cylindrical cores. The core materials had in large part been composed of slag left over from steel mill production and the steel industry was then in a severe economic slump. They weren’t making enough steel and generating enough slag to satisfy Allen Bradley’s resistor production requirements.

Was that a folk tale? I never confirmed the story independently, but that’s what I was told.

Also, it turned out that Allen-Bradley had been at the time the only resistor manufacturer still using the cylindrical core configuration and there was nobody else to turn to. We had to change from using carbon composition resistors to specially designed resistors, then made by Airco-Speer if my memory serves, which were actually rated for high voltage service.

Leaving the 1980s behind, this article in Figure 2 came along from Stackpole in EDN in 2004.

Figure 2 “Carbon-comp resistor takes you forward into the past” article by author Bill Schweber published back in 2004. 

By then, I was working at a different company, so I never re-examined the high voltage issue, but just the other day, strictly on a whim, I took another look at Stackpole and found article in Figure 3.

Figure 3 Recent viewing of Stackpole showing the carbon composition resistor series as discontinued. 

I guess the era really has ended.

John Dunn is an electronics consultant, and a graduate of The Polytechnic Institute of Brooklyn (BSEE) and of New York University (MSEE).

 Related Content

• Resistors: Know how they drift
• Selecting resistors for preamp, amplifier and other high-end audio applications
• Resistors aren’t resistors
• 7% solution

The post Carbon composition resistors appeared first on EDN.

Learn how an inductively-loaded common-emitter stage can function as a power amplifier.

submitted by /u/Legend_of_the_Wind [link] [comments]

Hey, here’s my project log of making my first real PCB for a product im trying to design. Plz don’t roast me too hard, I’m not an electrical engineer. submitted by /u/noam_aiz [link] [comments]

On the 120th anniversary of the first powered, controlled flight by a heavier-than-air aircraft, we reflect on Curtiss-Wright's legacy as an aviation pioneer.