At DMC, we see these challenges firsthand through our work with a wide range of manufacturers in different industries. Our team designs custom test solutions that meet demanding performance requirements while remaining practical, cost-effective, and scalable. By focusing on adaptability and reliability, we help operators build test systems that support the needs of today while looking forward to tomorrow.

Why Testing Matters More Than Ever

A well-designed PCB and PCBA test strategy does more than test products at the end of the line. It supports quality, throughput, and futureproofs manufacturing operations as they continue to scale and evolve:

• Quality Assurance: Catch defects early to avoid costly downstream failures.
• Throughput Optimization: Keep your line moving without sacrificing accuracy.
• Compliance & Traceability: Meet industry standards and maintain audit-ready records.
• Lifecycle Adaptability: Design systems that adapt as your product mix evolves.

There are many reasons today for manufacturers to take a flexible approach when building a test system. Flexibility allows manufacturers to balance precision with speed, validating each unit without bottlenecking production. Automated test solutions also enable constant measurement, surfacing issues before they impact final assembly or the field. This approach not only improves first-pass yield, it also shortens feedback loops.

It’s equally important that modern test platforms are built for change. As products evolve and regulations shift, operators need test systems that can scale easily, integrate new test points, and support expanded data collection without a full redesign every time. Flexible, software-driven architectures make it easier to maintain compliance and protect your testing investment.

DMC’s Approach: Expertise + Flexibility

What sets DMC apart? Deep in-house expertise, industry certifications, and best practices, combined with strategic partnerships. We’ve built relationships with leading fixture manufacturers, instrumentation vendors, and automation specialists. This allows us to deliver end-to-end solutions tailored to your requirements, or any specific pieces of the system you need:

• Fixturing Options: From full bed-of-nails (BoN) systems for high-volume lines, to cost-effective connector-based fixturing solutions for smaller runs.
• Instrumentation: Modular, serviceable, and upgradeable DAQ and rack-based instruments sourced from trusted partners, and selected based on your needs and requirements.
• Software: Several customizable platforms ready to deploy and meet your current and future needs.
• Peripheral Systems: From simple barcode scanners, printers, & PLC automation interfaces to add-on services like MES integration and analytics platform design and delivery.

Fixturing: The Foundation of Reliable Testing

Whether your Device Under Test (DUT) is a bare PCB, a PCB assembly, or a fully enclosed PCB, your connection strategy drives cost, reliability, and timing. DMC can offer consulting and execution for:

• Complete Bed-of-Nails Fixtures: High-reliability, low-cost, or well-balanced systems can be sourced from multiple DMC partners.
• Cost-Sensitive Alternatives: DMC can offer in-house-designed and built fixturing or pogo-pin connector-based systems to reduce your spend.
• Automation Options: Robotic or auto-loading systems for high-throughput environments.
• Flexibility for Low-Volume, High-Mix Assembly: Quick-change fixtures and adaptable test sequences.

Test System Architecture: Built for Your Needs

Every system we design can be tailored to your application and include the components needed to support reliable, efficient testing, including:

• DUT Connections & Fixturing: Based on your project needs.
• Instrumentation: High-power, high-current, and high-voltage measurements are our specialty.
• Overall System Integration: Turn-key workbenches and/or racks with integrated fixtures and peripherals, to cost-saving, simple enclosure-based systems to add to your workbench.
• Software: Modular, intuitive GUIs that make operation simple, and test-engineering-friendly test sequence and parameter modification.
• Peripheral Integration: Barcode scanners, printers, databases, MES, analytics, and more.

For low-volume, high-mix operations, we can often recommend a single flexible test system that supports easy fixture changeovers and multiple DUT configurations, a real cost saver.

Advanced Capabilities

• Multiplexing: Reduce instrumentation costs and/or support multi-DUT setups with smart switching topologies.
• Microcontroller Programming: Need PCBA flashing station capability in your test system? We’ve got you covered.
• Scalable Design: If needed, DMC’s flexible designs let you start small and expand as your needs grow.
• Non-Standard Measurements: From magnetic and optical sensing to RF and high-power applications, we take on complex PCBA test challenges others may avoid.

Software That Works for You

DMC software solutions are not one-size-fits-all; they’re built to deliver speed, flexibility, and futureproofing in one package. With ready-to-deploy base designs and a wide range of platform tools at our experts’ fingertips, we can get your custom application up and running quickly, reducing downtime and fortifying your system for the future. All of our platforms and tools are designed with future flexibility and integration in mind, helping to ensure system effectiveness as demand and technologies change:

• Ready-to-Deploy: Base designs and a wide range of platform tools allow us to get your test software up and running quickly.
• Customizable: DMC can quickly add the software features you need now, while our modular platform tools allow you to grow as your requirements evolve.
• Future-Proof: All of our software platforms and tools are designed with your future flexibility and integration needs in mind.

We can also walk through GUI examples and provide live software demonstrations to show how powerful and intuitive our systems are. For a deeper look at one of our platforms, see The Hidden Cost of One-Off Test Systems.

Why Choose DMC for Test and Measurement Solutions?

DMC has a proven track record with major US manufacturers, supporting their complex test and measurement challenges and shifting technology needs. With multiple regional offices across the country, DMC is able to provide coast-to-coast support wherever our clients operate.

In addition to deep test and measurement expertise, our team also specializes in non-standard measurements and challenging test scenarios, partnering with leading instrumentation vendors to deliver reliable results.

Whether our clients are looking for a complete, turnkey system or modular components that fit within an existing strategy, DMC adapts every approach to meet business goals and project needs.

The post Adapting Manufacturing Operations? Flexible PCB and PCBA Testing Is Key to Success  appeared first on DMC, Inc..

Embedded projects can be very simple and small, with not much going on, but often have a large number of events all looking to happen. To handle all these events, engineers will want to add a Real Time Operating System (RTOS) to their system’s architecture. The purpose of an RTOS is to ensure specific tasks occur within a set time frame. This is very important in embedded devices, as many different tasks must occur for the device to function.

Once an RTOS is needed, the next question is which RTOS to use. Some common RTOS options are FreeRTOS, Mbed, ThreadX, and Zephyr. Many have great uses across various systems, though the highlight of this article is Zephyr, as it uses a different methodology for how it works and how it is used. If you’re reading this article, you may be facing the struggles of Zephyr’s learning curve, but hopefully, by the end, you will gain a greater appreciation for Zephyr.

Understanding Zephyr’s Learning Curve

All things in life need to be learned and dealt with to get the most out of them. Zephyr is the same way, but with a much steeper learning curve for users familiar with other RTOSs. Nearly all users of Zephyr have struggled with it for a reason: the hardware agnosticism, feature set, and continued growth of the RTOS. Most engineers are familiar with how to set up a new project: choose an MCU, define the required features, write drivers, and then test.

On Zephyr, the steps are more akin to establishing needed features, writing drivers, and then testing on a long list of possible MCUs. This flip can be hard for many engineers who are familiar with a certain schema, though once one has sipped from the fountain of the future, they may not want to go back. Talk is only so much, though, so now we’ll get into some actual tips and tricks to hopefully help you become a functional Zephyr user!

Core Zephyr Concepts: Usage, Kconfigs, and Device Trees

Zephyr is primarily used via the CLI and a program called “west” to handle nearly everything, including building, flashing, debugging, repo management, and much more. The Zephyr Foundation has documentation on how to install things and is quite helpful for starting out. Once install is done, Zephyr’s greatest hurdles appear on the horizon:

1. Configuration Files
2. Device Tree
3. Overlay

All three are outlined in greater detail below:

Configuration Files

Zephyr is hardware-agnostic, which means the user must say what they want included in the project. There are two files to edit: `kconfig` and `prj.conf`. Kconfig files may be familiar to those who frequent Linux, as Zephyr is a kernel; these are the “kernel configs”.  That said, in most cases, not much should need to be changed here, as the stock file created will serve most users just fine. The prj.conf file is the main location where one would define the software’s capabilities, such as the inclusion of logging, UART, ADCs, or SPI.

The Zephyr project includes the full list of variables that can be added to the prj.conf file to configure a project. This is the part that confuses most people, as they either don’t know what to set or would rather set them in the codebase itself, so they feel more like local variables or #defines. This schema enables Zephyr’s hardware-agnostic nature, since the settings are held outside the driver. To help with the volume of config variables, Zephyr includes a GUI that lets you select settings based on your needs; this helps alleviate the issue of not knowing your options. I wish I had known about this when I was configuring my first project in Zephyr.

Zephyr configuration can be done using either a graphical interface or a terminal-based menu, both exposing the same Kconfig options:

Device Tree

Where prj.conf files define the software, the device tree defines the hardware. There are three main files in play here:

• .dts. This is an MCU-specific configuration.
• .dtsi. It is more general hardware info that can apply to a MCU family or brand of MCUs, potentially

.Overlay

While the first two are often left alone as is, since they define the capabilities of the MCU, which don’t change. User intervention is needed within the .overlay file. This is where the peripherals are set up, along with the pins used to control them. An example of the overlay structure can be found here at the bottom of the section; the example shown is for an SPI and I2C setup. The .overlay will need to be curated for each hardware-related function of the setup. These created peripherals will later be used in the main code.

Moving Forward with Zephyr

In my experience and others’ sentiments, the ability to grasp the purpose and schema of the files above is the biggest hurdle in Zephyr. Once those are understood, the rest of Zephyr is quite similar to other RTOS or general embedded methodologies. It’s highly recommended to follow a guide when setting up a sample project before starting your own, as guidance can be very beneficial when starting out with Zephyr.

Practical Considerations

Currently, it is hard to avoid AI. For a case like Zephyr, it can be quite useful for understanding what to add to one’s prj.conf and .overlay files. Be aware that these config variables may change over time, and new ones may be unfamiliar to the AI model. It’s best to consult official sources if things are not working/building correctly.

Additional Resources

Here are a few reference materials to help get you on the right path in your Zephyr journey:

• Zephyr Project Home
• Mastering Zephyr Webinar

The post Zephyr RTOS Explained: Overcoming the Fear of Change appeared first on DMC, Inc..

What Is a Power Profiler?

A power profiler precisely measures the power a device consumes over a given period of time. Often, a graph is generated with the data so one can examine consistency and anomalies. Typically, the power profiler supplies power to the device, so all power flows through the profiler, enabling better measurement. In contrast, one would need to place a digital multimeter (DMM) in line with the device to measure current, and have the voltage measured with a separate instrument. An engineer would then use this data to observe how changes in hardware and software are affecting the device’s power consumption.

Devices Used

We typically use two main power profilers when working on low-power Embedded systems:

• Nordic Power Profiler Kit II. It is usually referred to as PPK2 (Power Profiler Kit 2) and is a USB device that plugs into a computer and uses Nordic’s software to view the power characteristics of the device in question.
• Qoitech Otii Ace Pro. The Otii does the same thing as the PPK2, though with a more comprehensive feature set. It offers a wider range of voltage and current, better read resolutions, and other features. It is worth noting that this tool is more expensive.

Lower Power Techniques

It is one thing to know a device’s power draw; it’s another to know how to lower its average draw. In the simplest terms, the best way to reduce power draw is to turn off as many things as possible. LEDs, Integrated Circuits (ICs), and the microcontroller (MCU) can all be powered on, off, or put to sleep via smart decisions made in hardware and software. Adding a Metal-Oxide-Semiconductor Field-Effect Transistor (MOSFET) or specialized power switches allows subsystems to be turned on and off as needed. Most MCUs support various sleep modes, which can reduce average power by orders of magnitude.

As an example, the ESP32, a popular MCU, provides a table in its datasheet that shows various sleep modes and their power consumption in those modes. Looking at these tables (see Figures 1 and 2 below), it’s seen that a maximum of 240 mA can be reduced to 5 µA by changing the power mode, a ~48,000-fold difference.

Examples

Out of simplicity, I will provide some data and examples using the Arduino Nano R4. This is Arduino’s smallest microcontroller development kit board and can be used for simple projects, including low-power applications. I’ll recreate the same setup in two different ways, both of which will result in a simple blinky program.

For hardware, a Nano R4 will be plugged into a breadboard along with an LED and a resistor. The LED will blink at 2Hz in both software setups, though the second will include power-saving logic. Figures 3 and 4 below show a large drop in power when the CPU is put to sleep with nothing happening. In normal operation, the MCU idles and consumes power doing nothing, whereas in the sleep code, it can sleep and consume much less power.

Figure 3 shows an average power draw of 24.3 mA in the 20s window, while the low-power version shown in Figure 4 has an average draw of 13.4 mA, nearly half the current used. These numbers can mean very little without some context. If the system were powered by a single CR2032 3V coin cell battery with a capacity of 225 mAh, the runtime would range from 225 mAh / 24.3 mA = 9.25 h to 16.8 h.

This is roughly double the runtime under ideal situations. The true benefits of low power come from using a device with ultra-low-power saving modes, as seen in Figure 1 for the ESP32. If the same rough calculations are done with the modem off vs hibernation, we see a runtime range of 225mAh/25mA = 9hours to 225mAh/5uA =45000h = 1875days = 5.13years.

This is a perfect-world situation and is highly unlikely to happen, especially as it assumes the device would be asleep for the entire time, doing nothing productive. Though systems can be optimized to last for months or years, depending on their use case and the amount of power-saving logic applied.

Code

Below are the two sketches used for the measurements above:

• A baseline 2 Hz blinky
• A low-power version that uses __WFI() to sleep between timer ticks

//Baseline 2Hz Blinky
const int LED_PIN = 3;      // Built-in LED on Arduino Nano
const unsigned long TOGGLE_MS = 250;

unsigned long lastToggle = 0;
bool ledState = false;

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  unsigned long now = millis();

  if (now - lastToggle >= TOGGLE_MS) {
    lastToggle = now;
    ledState = !ledState;
    digitalWrite(LED_PIN, ledState);
  }
}

//Baseline 2Hz Blinky
const int LED_PIN = 3;      // Built-in LED on Arduino Nano
const unsigned long TOGGLE_MS = 250;

unsigned long lastToggle = 0;
bool ledState = false;

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  unsigned long now = millis();

  if (now - lastToggle >= TOGGLE_MS) {
    lastToggle = now;
    ledState = !ledState;
    digitalWrite(LED_PIN, ledState);
  }
}

// Low Power 2Hz Blinky
#include <Arduino.h>
const uint8_t LED_PIN = 3;
volatile bool tick = false;
extern "C" void SysTick_Handler(void)
{
  tick = true;
}

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);

  // Configure SysTick for 250 ms ticks
  SysTick_Config(SystemCoreClock / 4);  // 1/4 second = 250 ms
}

void loop()
{
  // Wait in low-power idle until interrupt fires
  while (!tick) {
    __WFI();   // Wait For Interrupt (CPU sleeps until an interrupt occurs)
  }
  tick = false;

  // Toggle LED each tick
  digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}

// Low Power 2Hz Blinky
#include <Arduino.h>
const uint8_t LED_PIN = 3;
volatile bool tick = false;
extern "C" void SysTick_Handler(void)
{
  tick = true;
}

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);

  // Configure SysTick for 250 ms ticks
  SysTick_Config(SystemCoreClock / 4);  // 1/4 second = 250 ms
}

void loop()
{
  // Wait in low-power idle until interrupt fires
  while (!tick) {
    __WFI();   // Wait For Interrupt (CPU sleeps until an interrupt occurs)
  }
  tick = false;

  // Toggle LED each tick
  digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}

Conclusion

Power profiling turns battery life from a guessing game into a measurable target for engineers. By capturing current over time, you can quickly spot spikes, reduce idle waste, and validate that firmware and hardware changes actually improve energy use. Even small changes, like sleeping between periodic tasks, can meaningfully reduce average current, and deeper optimizations can extend runtime further.

The post Power Profiling Embedded Systems: Tools, Techniques, and Real-World Results appeared first on DMC, Inc..

This calculator helps explore those tradeoffs by letting you tune system parameters and compare different battery and power architecture options. Unlike many simple online calculators, it breaks power usage down by operating mode and accounts for conversion efficiency so you can better see where energy is going and how design choices affect battery life.

The post Battery Life Calculator appeared first on DMC, Inc..

For example, a requirement might call for an “RS-232 interface.” However, after clarifying the technical details, the actual need might be a simple logic-level connection for debugging or communication between microcontrollers on the same circuit board. 

To a Firmware or Hardware Engineer, these terms represent two different layers of communication: the protocol (the logic) and the physical interface (the voltage, pinout, and cabling). Distinguishing between them helps ensure that hardware specifications match the actual system requirements and leads to smoother integration. 

Let’s look at the difference between the logic of the conversation (UART) and the physical medium it travels through (RS-232). 

UART

UART stands for Universal Asynchronous Receiver-Transmitter. 

Strictly speaking, a UART is not a communication standard like Wi-Fi or Ethernet. It is usually a hardware peripheral block inside a microcontroller (MCU). Its job is to format data. It takes parallel bytes from the CPU and serializes them into a stream of bits, framing them with start bits, stop bits, and optional parity to be transmitted via a pin. 

When a UART transmits data directly from the microcontroller’s pins, the signal exists at Logic Levels. Historically, these were known as TTL (Transistor-Transistor Logic) levels, which typically operated at 5V. Modern microcontrollers, however, are predominantly operating at lower voltages like 3.3V or 1.8V. 

Because of these voltage differences, compatibility is a key consideration. Connecting a legacy 5V signal directly to a modern 3.3V microcontroller can damage internal circuitry. It is worth verifying if specific pins can handle 5V signals. If not, you’ll have to create a logic level shifter to bridge the two voltage domains safely. 

In practice, UART is the workhorse of on-board communication. It is used to connect the main microcontroller to peripherals located on the same PCB: such as Wi-Fi modules, GPS receivers, modems, etc. 

It is also the primary interface for hardware bring-up and debugging, allowing developers to view system logs and interact with the firmware via a simple serial terminal. 

For this purpose, a USB‑to‑UART adapter becomes an essential tool. These adapters allow a developer to connect a PC directly to the microcontroller’s UART pins using a standard USB port. On the PC side, the adapter enumerates as a virtual COM port, which can be accessed using common terminal programs such as RealTerm. On the hardware side, the adapter outputs logic‑level UART signals (typically 3.3 V or 5 V), making it safe to connect directly to a PCB’s debug header. One of the examples of such USB-UART adapters is presented below. 

USART (Universal Synchronous/Asynchronous Receiver-Transmitter) 

If you look at datasheets from manufacturers like STMicroelectronics or Microchip, you will often see the peripheral labeled as USART. The “S” stands for Synchronous, meaning the hardware can support a clock line (CLK). Therefore, such USART peripherals can be configured to support common Synchronous protocols, such as SPI (Serial Peripheral Interface), and others. However, this peripheral can also be configured in Asynchronous mode, where it behaves exactly like a standard UART. 

RS-232 

RS-232 (Recommended Standard 232) defines the physical interface. It describes how the data is electrically transmitted to work reliably over cables in the “outside world,” away from the protection of the PCB. 

RS-232 transmits the same data packet as the UART, but with two major physical differences designed to improve noise immunity over longer cables. 

1. Voltage Levels – RS-232 uses bipolar signals. A valid signal typically ranges from ±3V to ±15V. 
2. Signal Inversion – This is a common point of confusion. The logic is inverted compared to UART: 
   • Logic ‘1’ (Mark) is represented by a Negative voltage (e.g., -12V). 
   • Logic ‘0’ (Space) is represented by a Positive voltage (e.g., +12V). 
   • Therefore, while the UART signal idles High (Vcc), the RS-232 signal idles Low (Negative Voltage). 

Despite its age, RS-232 remains ubiquitous in industrial and commercial environments due to its robustness and simplicity. It can be found in industrial automation for programming PLCs (Programmable Logic Controllers), other industrial and scientific equipment. Additionally, RS-232 serves as the standard “Console” interface on some networking equipment, Point of Sale (POS) peripherals like receipt printers and barcode scanners.

RS-232 ports used to be built into most PCs and laptops, but not anymore. Therefore, to interface modern computers with legacy equipment, a USB‑to‑RS‑232 adapter is typically used. These adapters bridge the gap between modern USB port and RS‑232 devices. On the PC side, the adapter appears as a virtual COM port to allow unified communication with RS-232 devices. Most USB-to-RS-232 adapters terminate in a 9pin DE9 connector (commonly referred to as DB9).

It is worth noting that while the modern standard is the 9-pin DE9 (often called DB9) connector, the original standard defined a 25-pin connector (DB25), which you can still find on some very legacy devices.  

Connecting UART to RS-232

Since a microcontroller cannot natively generate negative voltages or handle 12V signals, we cannot wire a standard RS-232 DE9 connector directly to the MCU. To implement an RS-232 interface, we use a Transceiver IC (such as the industry-standard MAX232 or similar). 

1. MCU Side – The UART peripheral is configured to use TX (Transmit) and RX (Receive) pins at MCU logic levels. 
2. Transceiver – The transceiver IC (MAX232 or similar) sits between the MCU and the RS-232 connector. It generates the required high voltages and handles the signal conversion. 
3. Connector – The transceiver IC outputs standard RS-232 signals to the port (DE9 connector). 

Such adapters are available as standalone boards that you can use for quick prototyping and experimentation. One of the options is presented below. 

Flow Control and Pinout

Many common integrations often only require a minimal connection consisting of TX, RX, and Ground. In these cases, software flow control (referred as XON/XOFF) is sometimes used to prevent sending too much data too fast and overflowing the receiver’s buffer, or the data rate is just low enough and the receiver can handle it fast enough that buffers do not overflow. 

However, Hardware Flow Control is not just a relic of the past. It is widely used in modern equipment to ensure data integrity. In this scenario, the firmware engineer configures two additional pins: RTS (Request to Send) and CTS (Clear to Send). These signals are also routed through the transceiver to help manage the data flow. These signals are standard on both DE9 and DB25 RS-232 connectors. 

Cabling Configuration: DTE vs. DCE

Another common pitfall involves cabling. The RS-232 standard historically distinguishes between Data Terminal Equipment (DTE), such as computers, and Data Communication Equipment (DCE), such as modems. While a straight-through cable connects a DTE to a DCE, connecting two DTE devices directly (e.g., a PC to an embedded system) requires a Null Modem cable or adapter to cross the transmit and receive lines correctly. 

On a related note, when connecting two UART devices, it is crucial to remember the crossover rule: the TX pin of the transmitting device must connect to the RX pin of the receiving device, and vice versa. 

Summary

Here is a quick breakdown of the key distinction: 

• UART is the protocol logic inside the chip. It is typically used for on-board communication or direct debugging. 

• RS-232 is the physical interface, most easily recognized by the standard DE9/DB9 connector. It is commonly employed to connect devices over external cables, using a transceiver to handle higher voltages and signal inversion. 

Understanding where the logic ends and the physical layer begins helps design more robust systems and avoid compatibility issues. 

The post UART vs RS-232: Understanding the Differences appeared first on DMC, Inc..

To illustrate how the industrial and embedded worlds can work together, I built a simple demo that connects an ESP32-based device directly to a Siemens PLC using the native Siemens S7 protocol. 

The result is an Ethernet-connected embedded system that reads PLC inputs in real time and uses that data to drive an RGB LED Pixels Strip: no gateways, no HMIs, and no middleware.

Demo Overview

The demo is intentionally simple. I am using our PLC lab setup with a few switches and buttons connected to the PLC to control a standard RGB LED Pixels Strip connected to an ESP32-P4 dev kit. The block diagram of the system is presented below.

Here is a picture of the complete setup below:

PLC Logic and Configuration

There are two external switches and two buttons attached to the PLC. Each input is mapped to a location in the PLC data block. The PLC program updates this data block continuously based on the switches/buttons’ state. 

The PLC exposes this data block that contains the state of four inputs: 

• Two switches 
  • DB1.DBX0.0: switch 1 – on/off 
  • DB1.DBX0.1: switch 2 – chase effect on/off 
• Two momentary push buttons 
  • DB1.DBX0.2: push button 1 – color green 
  • DB1.DBX0.3: push button 2 (normally closed) – color red 

The PLC should be configured to allow Siemens S7 PUT/GET communication. S7 is a native PLC protocol that allows external devices to read and write PLC memory areas over Ethernet. Unlike fieldbus protocols, S7 PUT/GET provides direct access to PLC data blocks, making it well-suited for lightweight integrations. 

In this demo, the ESP32 acts as an S7 client, connecting directly to the PLC and periodically reading the data block DB1. No custom function blocks or other logic are required on the PLC side. For embedded devices, this protocol could provide a simple way to exchange data with a Siemens PLC while keeping the PLC logic minimal.

There are a few important settings that need to be enabled on the PLC side for the S7 protocol to work properly:

1. Disable optimized block access. The data block used for communication (DB1 in this demo) must have optimized block access disabled. This allows the S7 protocol to address data in the data block using absolute addresses such as DB1.DBX0.0 

2. Enable PUT/GET communication. In the PLC Protection & Security tab, enable PUT/GET communication.

ESP32-P4 Firmware

The ESP32-P4 is the latest addition to Espressif’s popular line of embedded controllers, designed for high-performance industrial and IoT applications. The official ESP32-P4 development kit provides a great platform for rapid prototyping. 

For this demo, I selected the ESP32-P4 dev kit largely because it is new and it has native Ethernet support, allowing us to connect directly to the PLC without external adapters. This made setup straightforward, letting us focus on demonstrating seamless communication between embedded and industrial systems.

  The ESP32-P4 dev kit is configured in the Arduino IDE using Espressif’s official board support package. I am using largely default settings, but here is a screenshot of the dev kit configuration in Arduino IDE for reference.

To handle Siemens S7 communication on the ESP32, I am using Settimino, an open-source library. Settimino implements a lightweight S7 client that allows Arduino-compatible devices to communicate directly with Siemens PLCs over Ethernet/S7 protocol. In this demo, the library is used to periodically read a PLC data block and decode individual bits corresponding to physical switches and buttons.

There is a commonly available “WS2812” RGB LED pixel strip connected to the ESP32 dev kit GPIO pin. The firmware changes the LED strip color and triggers a chase effect based on the state of the buttons/switches.

• ESP32-P4 runs an Arduino-based sketch that:
• Initializes the Ethernet interface 
• Connects to the PLC over S7 
• Reads the data block DB1
• Decodes individual bits corresponding to switches and buttons 
• Updates the RGB LED Pixel Strip based on the buttons/switches   

The ESP32 acts as a read-only S7 client in this demo, which keeps the PLC configuration simple and the data safe. This pattern is especially useful when the PLC should remain the system authority and the embedded device is purely a consumer, reading the data and not affecting the logic PLC is doing. Although the same approach can easily be extended to write data back to the PLC if required. 

Takeaway 

This demo shows how a modern embedded platform like the ESP32 can integrate cleanly into a Siemens PLC environment using the S7 protocol without gateways, just straightforward Ethernet communication. 

For industrial products, this approach opens the door to smarter peripherals and better visualization at a potentially lower system cost. All while keeping the PLC program simple and maintainable. 

It is worth noting that Siemens S7 PUT/GET protocol is very insecure because it does not implement any encryption or authentication mechanism. So, it should only be used with caution and strictly on isolated networks to avoid unintended access to the PLC or other security risks.

You can also watch a short video overview of the demo.

The full Arduino source code and PLC project are available on GitHub.

The post Bridging the Embedded World and Siemens PLCs with an ESP32-P4 and Arduino  appeared first on DMC, Inc..

 No space left on device (errno = 28, ENOSPC) 

 No space left on device (errno = 28, ENOSPC) 

This error often shows up late in the build, after you’ve already invested significant time, and it can recur even after cleaning up build files and artifacts. The reason is that WSL storage has one extra layer compared to a typical Linux workstation, and Yocto is excellent at stressing it.

This post walks through what ENOSPC really means in WSL2, why Yocto triggers it so reliably, how to diagnose the root cause, and the correct fixes that make your builds predictable again. 

What ENOSPC Actually Means (and Why WSL2 Makes It Trickier)

On a traditional Linux machine, ENOSPC usually means one of two things: 

• You’re out of disk space
• You’re out of inodes (metadata entries used to track files) 

In WSL2, there’s a third common cause: the Linux filesystem lives inside a virtual hard disk file on Windows (typically ext4.vhdx). So, you effectively have two storage:

• Inside WSL2 (Linux view) – An ext4 filesystem with “available space.” 

• On Windows (host view) – A VHDX file that must be able to expand on the host disk 

If the VHDX can’t grow (because the Windows host drive is full, or because you’ve hit a configured limit), Linux reports ENOSPC even if you clearly remember deleting a bunch of files yesterday.

Why Yocto Builds Hit the Wall So Fast 

Yocto produces a large amount of output and (more importantly) a massive number of small files. A typical build tree can easily exceed 100GB once you include build artifacts, shared state, downloads, logs, and repeated iterations. A representative footprint looks like this: 

Even a “single” build can push you into triple-digit GB usage quickly, especially with multiple machine configs, SDKs, images, or rebuild cycles. This is why even developers with large SSDs hit space issues faster than expected. 

Why You Shouldn’t Put Yocto Under /mnt/… 

It’s tempting to just place your Yocto workspace on a Windows host drive (/mnt/c/yocto/…), so it uses space on your physical SSD instead of the virtual hard disk file. But the Windows filesystem (NTFS) gets mounted into WLS via a translation layer. That cross-OS layer is convenient, but it’s not optimized for this style of compilations/builds that deal with hundreds of thousands of files. 

Microsoft’s guidance for these situations is straightforward: for best performance, keep your build files inside the WSL filesystem. So, using the physical SSD won’t work in this case, and we should keep the Yocto tree under something like ~/yocto, and not under /mnt/c… 

The Right Fix: Clean, Reclaim, and Put the VHDX on the Right Disk 

Step 1: Clean Yocto Build Artifacts (Inside WSL) 

If you need to get unblocked quickly, removing build outputs helps:

rm -rf build/tmp/* 
rm -rf sstate-cache/* 
rm -rf downloads/* 

rm -rf build/tmp/* 
rm -rf sstate-cache/* 
rm -rf downloads/* 

This frees space inside ext4, which may be enough to complete a build. 

Step 2: Shrink/Optimize the VHDX (So Windows Actually Gets Space Back)

Deleting files inside ext4 does not necessarily reduce the physical size of ext4.vhdx. It’s common for the VHDX to grow during heavy workloads and not automatically return that space to Windows. 

To reclaim space on the Windows host, shut down WSL, then optimize the VHDX from PowerShell: 

wsl --shutdown 
Optimize-VHD -Path "D:\WSL\Ubuntu\ext4.vhdx" -Mode Full 

wsl --shutdown 
Optimize-VHD -Path "D:\WSL\Ubuntu\ext4.vhdx" -Mode Full 

This approach is commonly recommended for compacting WSL VHDX files after cleanup.

Note: Optimize-VHD requires the Hyper-V VHD tooling (available on many Windows editions). If you don’t have it, you may need to enable the appropriate Windows features. 

Step 3: Move the WSL Distribution to a Larger Drive 

If your Yocto workflow is a long-term need, the most robust fix is to ensure the distro (and therefore the VHDX file) lives on a drive with plenty of headroom. 

Method 0: Why “Moving Ubuntu” in Windows Settings Doesn’t Work 

Windows has an app setting that appears to “move” Ubuntu. In practice, this often moves the application wrapper, not necessarily the underlying storage you care about (VHDX file). If you need more space, you typically need to move the distribution’s VHDX (or relocate the distro) to a larger drive using WSL-supported methods (covered below). 

Method A: Export / Import (Reliable and Widely Supported)

wsl --export Ubuntu D:\backup\ubuntu.tar 
wsl --unregister Ubuntu 
wsl --import Ubuntu D:\WSL\Ubuntu D:\backup\ubuntu.tar --version 2 

wsl --export Ubuntu D:\backup\ubuntu.tar 
wsl --unregister Ubuntu 
wsl --import Ubuntu D:\WSL\Ubuntu D:\backup\ubuntu.tar --version 2 

This moves the distro storage to D:\WSL\Ubuntu 

Method B: wsl –manage –move (Newer, Simpler) 

Newer WSL releases include a built-in move command: 

wsl --update 
wsl --manage Ubuntu --move D:\WSL\Ubuntu  

wsl --update 
wsl --manage Ubuntu --move D:\WSL\Ubuntu  

This is supported in WSL versions that include the –move option and is often the cleanest approach when available. 

Conclusion 

In WSL2, “No space left on device” often isn’t just about what df shows inside Linux. It’s about how WSL stores Linux data in a Windows-hosted VHDX that expands over time and may not automatically shrink. 

The most reliable path to predictable Yocto builds is: 

1. Yocto is not a 20 GB project. Budget hundreds of GB. 
2. Keep Yocto workspaces on ext4 inside WSL (not /mnt/*).
3. Clean build artifacts when needed.
4. Compact the VHDX after cleanup.
5. Move the VHDL file to a larger drive.

The post Resolving “No Space Left on Device” (ENOSPC) When Building Yocto in WSL2  appeared first on DMC, Inc..

CAN Protocol – Electrical

The CAN (Controller Area Network) Protocol is a serial bus interface used to connect multiple devices in a Network. The devices all connect to a common Bus and share a twisted pair of wires called CAN High and CAN Low. The protocol requires 3 conductors to operate: CAN H, CAN L, and Ground. These CAN lines are opposites of each other. When the CAN lines are digital low, both CAN H and CAN L are at the same voltage. When the bus goes digital high, the line’s voltages go in opposite directions. For example, if they are digital low at a voltage of 2.5V, then at digital high, CAN H may be at 3.5V while CAN L would be at 1.5V. The voltages are equidistant from the digital low voltage which is called differential signaling. The benefits for differential signaling are that they minimize EMI (Electromagnetic Interference), allow long runs of wire, and high throughput. CAN is most used in vehicular communications and industrial automation.

How CAN Works – Logical Protocol

CAN in its simplest explanation can be thought of a group call full of people attempting to all talk to each other. Someone initiates a conversation by stating their ID and the ID of whom they need to communicate with. This allows the two to communicate effectively, all while sharing space with others. If two speakers attempt to communicate at the same time, the ID that is lower numerically is allowed to communicate first, the other follows unless a speaker with an ID that is lower attempts to speak. The speakers here are the devices (sensors, MCUs, etc.) and the shared space is the wires/bus.

What the Nano R4 CAN Now Do

This iteration of the Arduino Nano now has the R7FA4M1AB3CFM#HA0 32-bit MCU from Renesas which has a CAN controller packaged into it. The use of R4’s CAN peripheral requires an external CAN transceiver to work with a CAN bus. Arduino recommends transceivers such as the SN65HVD230 from Texas Instruments or the MCP2561 from Microchip. For my setup I used a TJA1050T made by NXP USA.

Example Code

#include <Arduino_CAN.h>
//This Code Honks the horn of a Tesla when a button is pressed on D6
#define BUTTON_PIN D6
#define HONK_TIME_MS 50
#define CAN_ID_HONK 0x273
bool lastButtonState = HIGH;

void setup() {
  // Serial is optional; do not block startup
  Serial.begin(115200);

  pinMode(BUTTON_PIN, INPUT_PULLUP); // button wired D6 → GND

  if (!CAN.begin(CanBitRate::BR_500k)) //Check if CAN started up fine
  {
    while (1); // hard fail
  }
}

void loop() {
  bool buttonState = digitalRead(BUTTON_PIN); //Read button

  if (buttonState == LOW && lastButtonState == HIGH)   // Detect button press and release
  {
    // Build CAN frame
    CanMsg hornMsg;
    hornMsg.id = CAN_ID_HONK; // ID273UI_vehicleControl
    hornMsg.data_length = 8;

    // Zero the 8 bytes
    for (int i = 0; i < 8; i++) {
      hornMsg.data[i] = 0;
    }

    // Bit 61 → byte 7, bit 5
    hornMsg.data[7] = 0x20;

    // Honk ON
    CAN.write(hornMsg);

    delay(HONK_TIME_MS);//Horn honks for 

    // Honk OFF
    hornMsg.data[7] = 0x00;
    CAN.write(hornMsg);
    Serial.println("Horn triggered"); 
  }
  lastButtonState = buttonState; //Set previous button state
}

#include <Arduino_CAN.h>
//This Code Honks the horn of a Tesla when a button is pressed on D6
#define BUTTON_PIN D6
#define HONK_TIME_MS 50
#define CAN_ID_HONK 0x273
bool lastButtonState = HIGH;

void setup() {
  // Serial is optional; do not block startup
  Serial.begin(115200);

  pinMode(BUTTON_PIN, INPUT_PULLUP); // button wired D6 → GND

  if (!CAN.begin(CanBitRate::BR_500k)) //Check if CAN started up fine
  {
    while (1); // hard fail
  }
}

void loop() {
  bool buttonState = digitalRead(BUTTON_PIN); //Read button

  if (buttonState == LOW && lastButtonState == HIGH)   // Detect button press and release
  {
    // Build CAN frame
    CanMsg hornMsg;
    hornMsg.id = CAN_ID_HONK; // ID273UI_vehicleControl
    hornMsg.data_length = 8;

    // Zero the 8 bytes
    for (int i = 0; i < 8; i++) {
      hornMsg.data[i] = 0;
    }

    // Bit 61 → byte 7, bit 5
    hornMsg.data[7] = 0x20;

    // Honk ON
    CAN.write(hornMsg);

    delay(HONK_TIME_MS);//Horn honks for 

    // Honk OFF
    hornMsg.data[7] = 0x00;
    CAN.write(hornMsg);
    Serial.println("Horn triggered"); 
  }
  lastButtonState = buttonState; //Set previous button state
}

Setup

To use the code shown above, one needs access to the CAN network in their Tesla vehicle. In the car used for this article, a 2021 Tesla Model Y Long Range, the CAN bus was found behind the center console, near the floor. A plastic cover needed to be pried off, and a splicer was purchased to connect in series. USB-C power was supplying the Nano R4. The provided code waits for a button to be pressed and released, connected to D6 and GND, and from there a data packet sends the honk horn bit for 50ms before setting it back to off. The idea is if the driver is hesitant to honk, the passenger can take some initiative. Below is the wiring needed for the CAN buses to work:

• Arduino GND to CAN Transceiver GND to Pin 5
• Arduino 5V to CAN Transceiver PWR
• CAN Transceiver CAN HIGH to Pin 6
• CAN Transceiver CAN LOW to Pin 14
• Arduino CAN RX to CAN Transceiver CAN RX
• Arduino CAN TX to CAN Transceiver CAN TX

CAN BUS Demo

Conclusion

In my sample code, I was able to control one of thousands of settings within my vehicle through the CAN bus. Some other examples could be starting seat heat on various seats, opening and closing the trunk, or turning on the wipers, with thousands of other controls for the vehicle. Some of these can damage the car and tinkerers should be careful not to damage the car with the messages being sent to it, especially whilst driving. The ones chosen here are generally low risk. Though overall CAN is a very robust protocol and can be used in many applications.

The post Arduino Nano R4 CAN Protocol appeared first on DMC, Inc..

That’s where EtherCAT comes in.

Originally developed by Beckhoff, EtherCAT (Ethernet for Control Automation Technology) has become one of the most popular real-time industrial Ethernet standards. It’s fast, reliable, and highly scalable – making it an excellent fit for applications where timing and performance are critical.

Why EtherCAT Fits High-Performance Embedded Applications

EtherCAT’s efficiency comes from how it moves data. EtherCAT masters can use standard off the shelf ethernet hardware, and they transmit standard Ethernet frames with the EtherCAT EtherType Identifier. The entire EtherCAT data payload (EtherCAT Telegram) for the entire network is embedded into the Ethernet payload. Every device on the network is daisy-chained together, and each device allows the entire Ethernet frame to pass through it, imparting minimal delay on the entire message. Each device will read out its section (Datagram) of the EtherCAT Telegram and insert the data that it is sending back to the master. This all happens on the fly as the frame is effectively passing through the device. The last device on the network will then turn the frame around and send it back up to the master. This is possible because of the full-duplex nature of Ethernet.

The following image shows how an EtherCAT frame might traverse through a network. The master transmits the frame, and each device will extract data in the Datagram addressed to it and insert its data on the fly into the Datagram. In this example very simple addressing is used as an example, most of the time such positional addressing is only used at network boot-up/discovery. Data not addressed to the slave is passed through the network until it reaches the end of the network, where the last slave sends it back to the master.

This “processing on the fly” approach eliminates most of the traditional Ethernet delays caused by the need to address each device individually and enables cycle times in the tens of microseconds, with minimal jitter.

The protocol can also implement a feature called Distributed Clocks (DC), where the master can measure time, it takes for each device to receive and respond to a sync message, then provide each device with an offset to ensure all devices are synchronized within ~100ns of each other. This allows each EtherCAT controller to create a synchronization event for each device on the network within 100ns of each other.

For custom devices, that means:

• Deterministic timing for motion control and automation.
• Relatively low resource overhead compared to the capabilities, since much of the protocol runs in hardware.
• Scalability, from a single board with a few I/O channels to complex multi-axis systems.

Types of EtherCAT Devices

There are two types of EtherCAT devices that can be implemented:

1. EtherCAT Masters

EtherCAT masters are usually run on controllers or embedded PCs that coordinate the network, process data and issue commands to each device on the network. In industrial applications (i.e. Industrial Automation) a master is usually an Industrial PC or PLC running TwinCAT.

Open-source stacks like Simple Open EtherCAT Master (SOEM) provide a lightweight, C-based master that runs on Linux or RTOS platforms. This can be a great option for small applications, such as a dedicated robot or lightweight real-time control system for highly integrated applications. These stacks typically work on commonly available hardware that supports standard Ethernet-based communication. This is because the master does not require any specialized hardware, it just needs raw access to the underlying Ethernet frames.

2. EtherCAT Slaves/SubDevice

Used when building custom EtherCAT-enabled devices like sensors, actuators, modular I/O, or motor/servo controllers.

Beckhoff’s Slave Stack Code (SSC) tool generates a firmware library that implements EtherCAT communication layer on your supported hardware. The “processing on the fly” of EtherCAT is really implemented in the EtherCAT slave controller hardware and not in software. So, the slaves/subdevices require specialized hardware to interface with the EtherCAT network properly.

This specialized hardware can take the form of a traditional microcontroller (i.e. STM32, TI C2000…) paired with an EtherCAT Slave Controller IC (ESC) like the LAN9252, or Beckhoff ET1100. Alternatively, some specialized microcontrollers, such as the TI TMS320F28388 or Infineon XMC4800 series, integrate the EtherCAT controller as a peripheral on chip.

In both cases, success depends on selecting compatible hardware and providing a real-time-capable software environment. For masters, that often means using a deterministic OS (e.g., PREEMPT_RT Linux or FreeRTOS). For slaves, it’s ensuring your MCU and ESC can handle EtherCAT’s timing and synchronization.

Explore Further Reading

• EtherCAT Technology Group
• SOME GitHub Repository
• Beckhoff Slave Stack Code (SSC)
• DMC Embedded Development Services

Conclusion

EtherCAT brings industrial-grade speed and synchronization to embedded systems without requiring massive computing resources. With the right combination of hardware, stack software, and validation tools, engineers can build compact, deterministic systems that rival full-scale automation controllers in responsiveness and reliability.

The post Integrating EtherCAT into Custom Applications appeared first on DMC, Inc..

A capacitor added to a classic voltage divider introduces a predictable delay before enabling another component, such as a DC-DC converter or logic device. The RC Voltage Divider Delay Calculator determines key timing parameters based on the divider components, input voltage, and the required threshold voltage.

Calculate Time Constant

The RC Time Calculator uses the following parameters to determine key timing characteristics:

Final capacitor voltage (V_final) - the final steady-state voltage the capacitor charges to, determined by the resistor divider ratio.
Time constant (τ, tau) -  determines the charging speed of the capacitor and depends on the Thevenin equivalent resistance of the divider and the capacitor value.
Threshold Voltage (V_threshold) - the required voltage level at which the target circuit becomes enabled or activated.
This is the voltage required, for example, at the Enable pin of a DC-DC converter, or the minimum logic-high level needed by a microcontroller input.
The calculator determines how long it takes for the capacitor to charge up to this user-specified threshold.

The capacitor in the circuit follows an exponential charging equation:

V(t) = V_final * (1 - e^(-t / τ))

where V_final is the final voltage the capacitor will reach, τ (tau) is the time constant, and t is time.

The voltage divider defines the maximum voltage the capacitor will reach:

V_final = Vin * (R2 / (R1 + R2))

The time constant τ determines the speed of how the capacitor charges and is calculated as:

τ = (R1 * R2) / (R1 + R2) * C

A higher τ value means a slower charge time.

To determine the delay before a device turns on, we calculate the time required for the capacitor to reach the specified threshold voltage:

t_enable = -τ * ln(1 - V_threshold / V_final)

This is the startup delay that occurs before the controlled circuit (such as a DC-DC converter or logic input) becomes active.

This formula calculates how long it takes for the capacitor voltage to reach the required level.

Summary

The RC Delay Time Calculator models the charging behavior of a capacitor in a voltage divider configuration. It is useful for estimating startup delays, power sequencing timing, enable-pin activation, and analog filtering performance.

The post Delay Calculator for RC Voltage Divider appeared first on DMC, Inc..