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 come back 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 storages: 

• 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.

If you are working through WSL2 and/or Yocto setup challenges, or “works‑on‑my‑machine” issues across your team, DMC can help you design and set up a development environment that is stable, scalable, and fast. 

Learn more about DMC’s embedded development and programming expertise and contact us today to get started.

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.

Learn more about DMC’s Embedded Development and Programming services and contact us for your next project!

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.

Contact DMC’s Embedded Development team to implement custom EtherCAT devices today!

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.

Ready to take your embedded project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

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

Low-Pass Signal Filtering

When working with embedded systems and reading data from sources prone to noisy measurements (e.g., temperature sensors), it’s common to need a way to reduce high-frequency noise and reveal the slower, meaningful signal underneath. One effective approach is using a low-pass filter, which allows lower frequencies through while reducing higher frequencies. Low-pass filters are especially useful for cleaning up signals from ADCs (Analog-to-Digital Converters).

Now, let’s explore how to implement a digital version of this filtering technique.

Low-Pass IIR Filter

There are multiple types of digital filters available, but we’ll focus on implementing an IIR (Infinite Impulse Response) filter. Without diving too deeply into specifics, these filters incorporate feedback from the output into the input, effectively creating a recursive filter. Such filters are typically less complex, resulting in strong performance that is particularly valuable for embedded systems. It should be noted, however, that the feedback mechanism may impact stability, although we’ll ignore this potential issue in this blog post.

The actual filter calculation is very simple, we have to run this formula from Wikipedia on every input sample to calculate the output: y[i] = α * x[i] + (1 – α) * y[i-1]

Let’s not get confused by all these variables yet, but simplify this formula by rearranging it a bit, primarily to minimize the number of operations to improve performance: ​y[i] = y[i-1] + α * (x[i] – y[i-1])

We can now explain these variables:

• x[i] is the filter input. For example, a new sample we received from ADC. Remember that we must execute this calculation for each input sample
• y[i] is the filter output (filtered signal)
• y[i-1] is the previous output of the filter. This is the feedback I mentioned above, so the filter output considers the previous output/state of the filter
• a is a magic coefficient that defines the filter – we’ll talk about it in the next section

Calculate Filter Coefficient

The magic coefficient a that I mentioned above determines the filter’s cutoff frequency. This means that signals above this frequency start to attenuate. At the cutoff frequency, the signal is already reduced to about 70% of its input voltage, so it is crucial to choose a cutoff frequency slightly higher than your maximum useful signal frequency.

Besides the desire cutoff frequency, this coefficient also depends on the sample rate, which sounds pretty natural too.

Knowing both the sampling frequency (Fs) and your desired cutoff frequency (fc), we can use an online calculator to calculate this magic coefficient, a.

Filter Implementation (C++)

Once you know the filter formula and the coefficient a, you can implement the filter easily: it’s just one line of code, which you might include, for example, in your ADC interrupt routine:

filter_output = filter_output + a * (new_sample – filter_output); 

Note: remember that filter_output variable is also the previous filter state/output, so this variable should persist between calls.

It would also be nice if we could wrap the filter into a simple class and include the logic to calculate the coefficient a, so we don’t have to think about calculating the coefficients online. This implementation is presented below.

Header File

/*
* LowPassIIR.h
*
*  A very simple implementation of a basic low-pass IIR filter.
*/
#ifndef INC_LOWPASSIIR_H_
#define INC_LOWPASSIIR_H_

class LowPassIIR
{
public:
	// Class constructor, calculates a coefficient based on the parameters:
  //   sample_frequency and desired cutoff frequency
	LowPassIIR(float sample_frequency, float cutoff_frequency);

  // Call with method with each sample. It processes the sample and updates the filter
	//   Returns filtered value
	float ProcessSample(float new_sample);

private:
	// Calculated a coefficient
	float a;

	// Filter internal value
  float y;
};
#endif /* INC_LOWPASSIIR_H_ */

/*
* LowPassIIR.h
*
*  A very simple implementation of a basic low-pass IIR filter.
*/
#ifndef INC_LOWPASSIIR_H_
#define INC_LOWPASSIIR_H_

class LowPassIIR
{
public:
	// Class constructor, calculates a coefficient based on the parameters:
  //   sample_frequency and desired cutoff frequency
	LowPassIIR(float sample_frequency, float cutoff_frequency);

  // Call with method with each sample. It processes the sample and updates the filter
	//   Returns filtered value
	float ProcessSample(float new_sample);

private:
	// Calculated a coefficient
	float a;

	// Filter internal value
  float y;
};
#endif /* INC_LOWPASSIIR_H_ */

C++ File

/*
* LowPassIIR.cpp
*  A very simple implementation of a basic low-pass IIR filter.
*  It is based on this article: https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter
*	It is important to note that the performance of this filter may not be optimal due to C++ and other overheads
*	Therefore, for performance-critical applications, it may make more sense to implement the core logic inside the
* ADC interrupt for example
*/

#include <LowPassIIR.h>

// Class constructor, calculates a coefficient based on the parameters: 
//   sample rate and desired cutoff frequency
LowPassIIR::LowPassIIR(float sample_frequency, float cutoff_frequency)
{
	// Calculate a, based on the formula from wikipedia article
  //   https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter
	float dt = 1 / sample_frequency;
	a = 2 * 3.14159f * dt * cutoff_frequency / (2 * 3.14159f * dt * cutoff_frequency + 1);

	// Reset internal sum
	y = 0.0f;
}


// Call with method with each sample. It process the sample and updates the filter
//   Returns filtered value
float LowPassIIR::ProcessSample(float new_sample)
{
	// Update filtered value and return it
	y = y + a * (new_sample - y);
	return y;
}

/*
* LowPassIIR.cpp
*  A very simple implementation of a basic low-pass IIR filter.
*  It is based on this article: https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter
*	It is important to note that the performance of this filter may not be optimal due to C++ and other overheads
*	Therefore, for performance-critical applications, it may make more sense to implement the core logic inside the
* ADC interrupt for example
*/

#include <LowPassIIR.h>

// Class constructor, calculates a coefficient based on the parameters: 
//   sample rate and desired cutoff frequency
LowPassIIR::LowPassIIR(float sample_frequency, float cutoff_frequency)
{
	// Calculate a, based on the formula from wikipedia article
  //   https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter
	float dt = 1 / sample_frequency;
	a = 2 * 3.14159f * dt * cutoff_frequency / (2 * 3.14159f * dt * cutoff_frequency + 1);

	// Reset internal sum
	y = 0.0f;
}


// Call with method with each sample. It process the sample and updates the filter
//   Returns filtered value
float LowPassIIR::ProcessSample(float new_sample)
{
	// Update filtered value and return it
	y = y + a * (new_sample - y);
	return y;
}

Will the DSP Filter Slow Down my Embedded Device?

DSP performance is always a concern with signal processing on embedded systems. Although this filter is so basic, it should not affect the performance too much. But let’s test it.

For demonstration, here is how the above class runs the STM32F429 Nucleo board with MCU configured at a modest 50MHz speed.

• The first screenshot shows ADC interrupt time, without calling the filter
  • ​The total ADC interrupting handling time is ~3.7us​
• The second screenshot is when we are calling the ProcessSample method within the ADC interrupt.
  • The total ADC interrupt handling time increased to ~4.3us
  • It means that the filter adds 4.3us – 3.7us = 0.6us per sample

This demonstrates that this low-pass filter introduces minimal overhead, making it an excellent choice for embedded systems.

This is a very simple illustration of DSP techniques. If you need support with DSP, whether basic or advanced, please contact us today to learn more about our solutions and how we can help you achieve your goals.

The post Simplifying DSP Filters for Embedded Systems appeared first on DMC, Inc..

1. Fail Fast and Fail Often

A classic engineering motto. No matter how precious your product may be, it’s always best to push it to its limits and see where improvements or fixes can be made. Be sure to include testing in your timeline, as unforeseen issues are bound to arise when developing products of all types. Having a dedicated engineering team for product design, testing and planning can be an invaluable addition, as you can expect your product to undergo fewer iterations, streamline the process, and ultimately save yourself both time and money.

2. Consider Support for Your Users

It’s very easy to get caught up in the excitement of developing a new product. So much so that it’s challenging to anticipate your customers’ needs once your product is in their hands. Support can look like replacing or repairing units, handling support cases, implementing firmware updates for quality of life, and a plethora of other tasks if IoT is involved. If you find yourself lacking the spare hands to tackle support requests, you always have the option to outsource work, even if temporary.

3. Backup Your Files

As a contractor, I’ve heard many horror stories of clients having lost their precious source code. Your future self will be so grateful that you took the extra precaution to keep the fruits of yesterday’s labor safe. This can apply to many different types of files: CAD, PCB design files, documentation, software/firmware, and much more. At DMC, we heavily utilize GitLab to track development and releases, but there are many other platforms to choose from. Once you adopt version control, long gone are the days of file names like “source files (final) (2) (fixed).zip”.

4. Identify Your Needs for Internal Teams

Depending on the intricacy of your product, you may need to employ dedicated teams to cover the different scopes involved. These teams may be involved with mechanical design, electrical design, firmware, backend software, and much more. To tie all these teams together, a project manager is essential for cohesion between teams.

5. What Does User Experience Look Like?

If a user needs to install your device, how can you simplify the process and minimize frustration? If your system is complex with multiple moving pieces, what user feedback is there to inform customers of proper use? The nature of user interaction varies widely from one product to another, but a polished and intuitive design is the ultimate driver of user satisfaction.

6. Determine Your Goals for Production

Find a unique balance between the cost per unit in materials, the cost for assembly, and components used. Optimizing these aspects will have a significant impact on the profitability and success of your product. 3D printing is fantastic for highly customized parts, but terrible for large-scale production. Drop-in off-the-shelf components may be a breeze to work with but may incur significantly higher production costs than a fully custom solution.

7. Do What You Can to Simplify Assembly

Assembly costs for a physical product can be a big budgetary blind spot. A robust and visually elegant design can still be one that is awkward to assemble, incurring exponential assembly costs. Whether you are assembling in-house or using a contractor, designing your product for ease of assembly will save you time and money in the long run.

8. What Technologies Are Associated With Your Niche?

If you’re serving a high-tech market, you need to keep up with the latest technological advancements. If you’re entering a market that is standardized in antiquity, you’ll need to be familiar with the nuances and pitfalls of its technology to ensure the success of your device. If you and your team lack the technical know-how, outsourcing is always an option to satisfy the needs of your niche, whether that is getting a second opinion or completely outsourcing a given aspect of your product’s development.

9. Does Your Device Need Any Certification Before It Can Hit the Shelves?

Many products need to be up-to-snuff with different regulatory bodies. If you aren’t sure what certifications you may need, looking at what your competitors are trying to meet is always a good starting point. Some regulatory bodies I have worked with are involved in communications and safety regulations, like the FCC and the CSA. Having a more intimate knowledge of the goings-on of these tests will ensure your device surpasses its requirements.

Main Takeaways

While this list is certainly not comprehensive, it hopefully got some gears turning. Knowing all the unknowns is unrealistic when you’re at the starting line, but you don’t have to be alone on your journey. DMC offers a wide range of services to help bring your product to life, from the idea’s initial conception to the final ‘IT’S ALIIIVVEE!’ moment.

If you’re ready to elevate your consumer electronics product, be sure to contact us today to see how we can help make your next project smoother, smarter, and way more gratifying.

The post 9 Things to Consider When Developing Consumer Electronics appeared first on DMC, Inc..

As a Chicago-based engineering firm specializing in embedded systems, industrial automation, and hardware-software integration, DMC has completed more than 10,000 projects across 40 countries. Our team is now focused on refining the motion systems and embedded intelligence that drive CardMill’s high-speed scanning and sorting capabilities.

We’re working alongside Beyond Design, a long-time collaborator with deep expertise in industrial design and user experience. Together, we form a synchronized team that’s fully integrated into CardMill’s development process.

Engineering for Performance and Scalability

We’re currently focused on refining the core mechanics that make CardMill powerful and reliable:

• Optimizing motion systems for smooth, consistent card movement
• Enhancing tray and feeder design for improved capacity and flow
• Evaluating cameras, motors, and processors to boost speed and reliability
• Strengthening alignment and durability for long-term performance

DMC and Beyond Design are also helping CardMill evaluate manufacturing partners to support tooling, pilot builds, and full-scale production. With over 60 years of combined experience, our teams are guiding the product toward a scalable and efficient manufacturing process.

Built for Collectors, Designed to Last

CardMill’s mission is to make high-performance card sorting accessible to everyday collectors. With DMC and Beyond Design leading the next phase, we’re confident the final product will deliver on that promise. The result will be an affordable, all-in-one scanner and sorter that’s built to last.

We’re proud to be part of this journey and look forward to sharing more updates as we move closer to delivery.

If you are charting a similar path from concept to production, connect with DMC to accelerate your project.

The post Partnering with CardMill and Beyond Design to Bring a Game-Changing Product to Market appeared first on DMC, Inc..

Calculate Filter Coefficient

The first step to implement this filter is to calculate the filter coefficient, which depends on the sample rate and desired cut-off frequency. 

The formula to calculate this coefficient is from Wikipedia: 

Where is the filter cut-off frequency, and is the sampling period (but it is easier to enter it as a Sampling Frequency, Fs). 

Filter Implementation

Knowing the filter coefficient  a, it is pretty easy to implement our filter: 

filter_output = filter_output + a * (new_sample - filter_output) 

Where: 

• filter_output is a variable that must survive between calls, it can be a static variable, something global, etc.  

• a is a coefficient we just calculated above 

• new_sample is a new ADC sample 

The filter calculations should be called on every sample, so it may be a good idea to implement them inside the ADC interrupt. However, you can also run the filter on an array of values—whatever works best for your architecture. 

Don’t forget that the filter calculations should generally use real (float) values! 

Learn more about DMC’s Embedded Development and Programming services and contact us for your next project!

The post DSP Low-Pass IIR Filter Calculator  appeared first on DMC, Inc..

Out of IoT, IIoT, or the Industrial Internet of Things, is emerging as a common and necessary term. This guide provides insight into IIoT and into DMC’s process for completing successful IIoT projects.

Table of Contents

• IIoT Overview
• Our Five-Step Process
• Step One: Field Device Platform Selection
• Step Two: Determine Communications
• Step Three: Determine Cloud Platform
• Step Four: Web Application Development
• Step Five: Go Live and Maintenance

IIoT Overview

Much like IoT, IIoT uses sensors and other technology but in an industrial setting to leverage real-time data to monitor and control devices in the field and communicate and display that data in a way that allows for better decision making in industrial processes.

Our Five-Step Process

DMC has completed hundreds of projects incorporating a wide range of solutions. Through experience, our engineers have developed a process for implementing IIoT solutions. We begin by starting at the lowest level and then fill in the gaps, going up the stack.

Step One: Field Device Platform Selection

Getting reliable, accurate data from the physical system is the primary challenge for any system design and the most important decision you can make. Once you secure the data, you can do anything you want with it. Answer the following questions to select hardware used in the field:

• What are you trying to measure or control?
• What does the device in the field need to be able to do on its own? How complex?
• How many devices do you anticipate on deploying?
• Are you the end-user and maintainer of this equipment, or are you selling a solution (operated and maintained by others)?
• What does new device provisioning look like? (the ideal process)
• How will this device be powered?

Keep in mind, the software platform is determined by hardware selection. For example, when you pick a particular PLC, you have to use the manufacturer’s software to program it. For an embedded device this will be C++, etc.

Device Hardware: Selecting the Right Parts

Let’s say the average PLC costs $1,000, so every time you put one out in the field, that is another $1,000 of hard costs. PLCs are great for some things while NI has developed expert tech for other uses. DMC engineers can leverage experience from hundreds of completed projects to advise on making the best choice for each project.

0-10 Devices – Small Deployments

10-100 Devices – Larger Deployment, off the shelf products, but start to have cost-optimized decisions

100-1000+ Devices – Discuss an embedded solution because the hardware starts to get expensive

Step Two: Determine Communications

After determining your device platform, deciding how your networking devices are configured is key. Consistent communication between devices is essential. DMC’s engineers help scope what needs to be done. Consider the following:

• How are you going to communicate with devices?
• Where is the internet coming from?
  • Cellular, Wi-Fi, from the plant?
• What happens when the internet is not available?
  • Local caching, buffer and retry, operational impacts
• What are the protocol security requirements?
  • Encryptions, certificates, secure comm management

Step Three: Determine Cloud Platform

There are a lot of cloud platforms to choose from when you reach this phase of the process. Ask yourself, what out of the box services (provided by these hosting entities) will your application need/or take advantage of? Some cloud platforms include Azure, AWS, and Google.

This phase is when we need to assess how to save on custom development, and where it’s possible to use solid foundational pieces already developed for these types of applications. Ask yourself:

• Do you need a website?
• Do you need database(s)?
• Do you need user management?
• Do you need integrations to other cloud services?
• Do you need SMS, e-Mail, or other mass notification capabilities?
• Do you need an AI engine or advanced analytics support?
• Do you need a flexible reporting framework (points to things like PowerBI)?
• What type of data store is needed?
  • How much data?
  • How often will it be sampled?
  • How will the data be used?
• Where and how will security be enforced for cloud resources?
• How many monthly active users do you anticipate on this cloud application?
• What in house cloud/web development resources do you have?
  • What are they comfortable with and willing to maintain?

Step Four: Web Application Development

DMC’s full-stack development team builds custom web applications with intuitive interfaces designed for usability and stable back ends designed for scalability. 

Consider the following during this step:

• Define the UI/UX experience
• How are you going to onboard new users?
• How are you going to onboard new devices?
• How are you going to manage devices?
• How are users going to view data?
• What access restrictions should apply? (user levels)
• What types of notification and alerts are required?
• When should devices be alerted to changes?
• What visualizations for data or information are required?
• What type of reporting is required? How are users notified of reports?
• Is a native Mobile App also required?
• Is a generic API (accessible by third parties) required?
• Define support plan for end-users of the application

Step Five: Go Live and Maintenance

• Are you using continuous Integration tools in Development, Staging, and Production environments?
• Do you have planned downtime for production-level updates?
• Are database migrations required? Data integrity checks?
• Deploy and active service health monitors?
• Are support and service avenues (emails/phone) active and being monitored?

Industry Credentials

DMC holds several key industry credentials with leading technology providers.

View all partners

Our Work

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

The post A Complete Guide to Planning Your IIoT Solution appeared first on DMC, Inc..

The form factor is the same as other Nanos although the storage and speed have increased significantly. The focus for this article is on the USB HID functionality supported by this new design, along with the ability to create a simple keyboard wedge using the Nano R4. 

Keyboard Wedge

A keyboard wedge is a device that uses HID to mimic a keyboard without one being present. This is a common use case in industrial applications such as barcode scanners, sensor logging, and various automations when inputs are required. No special software is needed as the computer thinks it is a keyboard that is plugged in and making the inputs. This feature of the new design can also be used to make a mouse wedge which would mimic a mouse’s inputs on a computer. Any program that has an area to input text (Excel, Chrome, Word, Notepad, etc.) can be used with an HID like the Arduino Nano R4.  

Keyboard Wedge Example

To illustrate the capability and functionality of the wedge, a demonstration has been built using the following: 

• Arduino Nano R4 

• Tactile Button 

• Ultra-sonic Sensor 

If the button is pressed, the reading from the ultra-sonic sensor is read and formatted into a line like this “Distance: X cm” where the X is the current distance measured by the sensor. If I were to open any area on my computer in which text can be entered, Excel for example, then the above line would print into a new cell on each cycle. The speed can also be changed within the code, which can be found below.  

This logic can be applied to many other use cases and sensors. The user can decide how they need their keyboard wedge to work. As mentioned previously, a mouse wedge is also an option, though it is often not as practical except in some niche cases. A sample code is provided to see the effect of a mouse wedge, in a fun way! This code spirals the mouse in and out as long as the Arduino Nano is connected to the PC, the code can be found below.

Keyboard Wedge Code

#include <Keyboard.h> 

#define LOOP_TIME_MS 500 

const int trigPin = 3; 

const int echoPin = 4; 

const int buttonPin = 2; 

  

void setup() { 

  pinMode(trigPin, OUTPUT); 

  pinMode(echoPin, INPUT); 

  pinMode(buttonPin, INPUT_PULLUP); // Use internal pull-up resistor 

  

  Keyboard.begin(); 

  delay(1000); // Wait for USB to stabilize 

} 

  

void loop() { 

  // Check if button is pressed (LOW due to pull-up config) 

  if (digitalRead(buttonPin) == LOW) { 

    long duration; 

    int distance; 

  

    // Send ultrasonic pulse 

    digitalWrite(trigPin, LOW); 

    delayMicroseconds(2); 

    digitalWrite(trigPin, HIGH); 

    delayMicroseconds(10); 

    digitalWrite(trigPin, LOW); 

  

    // Read echo time 

    duration = pulseIn(echoPin, HIGH); 

  

    // Calculate distance in cm 

    distance = duration * 0.034 / 2; 

  

    // Send distance as keystrokes 

    Keyboard.print("Distance: "); 

    Keyboard.print(distance); 

    Keyboard.println(" cm"); 

  

    // Debounce delay so it doesn't repeat too fast 

    delay(LOOP_TIME_MS); 

  } 

} 

#include <Keyboard.h> 

#define LOOP_TIME_MS 500 

const int trigPin = 3; 

const int echoPin = 4; 

const int buttonPin = 2; 

  

void setup() { 

  pinMode(trigPin, OUTPUT); 

  pinMode(echoPin, INPUT); 

  pinMode(buttonPin, INPUT_PULLUP); // Use internal pull-up resistor 

  

  Keyboard.begin(); 

  delay(1000); // Wait for USB to stabilize 

} 

  

void loop() { 

  // Check if button is pressed (LOW due to pull-up config) 

  if (digitalRead(buttonPin) == LOW) { 

    long duration; 

    int distance; 

  

    // Send ultrasonic pulse 

    digitalWrite(trigPin, LOW); 

    delayMicroseconds(2); 

    digitalWrite(trigPin, HIGH); 

    delayMicroseconds(10); 

    digitalWrite(trigPin, LOW); 

  

    // Read echo time 

    duration = pulseIn(echoPin, HIGH); 

  

    // Calculate distance in cm 

    distance = duration * 0.034 / 2; 

  

    // Send distance as keystrokes 

    Keyboard.print("Distance: "); 

    Keyboard.print(distance); 

    Keyboard.println(" cm"); 

  

    // Debounce delay so it doesn't repeat too fast 

    delay(LOOP_TIME_MS); 

  } 

} 

Mouse Wedge Code

#include <Mouse.h> 

#include <math.h> 

  

float angle = 0.0; 

float radius = 0.0; 

const float maxRadius = 50.0; 

const float minRadius = 5.0; 

const float angleStep = 0.3; 

const float radiusStep = 0.1; 

bool expanding = true; 

  

void setup() { 

  Mouse.begin(); 

  delay(1000); // Let USB settle 

} 

  

void loop() { 

  // Calculate position in polar coordinates 

  int dx = int(radius * cos(angle)); 

  int dy = int(radius * sin(angle)); 

  

  // Move the mouse 

  Mouse.move(dx, dy, 0); 

  

  // Advance angle 

  angle += angleStep; 

  

  // Adjust radius 

  if (expanding) { 

    radius += radiusStep; 

    if (radius >= maxRadius) expanding = false; 

  } else { 

    radius -= radiusStep; 

    if (radius <= minRadius) expanding = true; 

  } 

  delay(10); 

} 

#include <Mouse.h> 

#include <math.h> 

  

float angle = 0.0; 

float radius = 0.0; 

const float maxRadius = 50.0; 

const float minRadius = 5.0; 

const float angleStep = 0.3; 

const float radiusStep = 0.1; 

bool expanding = true; 

  

void setup() { 

  Mouse.begin(); 

  delay(1000); // Let USB settle 

} 

  

void loop() { 

  // Calculate position in polar coordinates 

  int dx = int(radius * cos(angle)); 

  int dy = int(radius * sin(angle)); 

  

  // Move the mouse 

  Mouse.move(dx, dy, 0); 

  

  // Advance angle 

  angle += angleStep; 

  

  // Adjust radius 

  if (expanding) { 

    radius += radiusStep; 

    if (radius >= maxRadius) expanding = false; 

  } else { 

    radius -= radiusStep; 

    if (radius <= minRadius) expanding = true; 

  } 

  delay(10); 

} 

Conclusion

The Arduino, with its small form factor and relatively easy coding environment can be used in many ways to automate anything the user needs. Whether it be for a personal project or a business or industrial need, an HID keyboard wedge can save the user time and money at scale.

DMC can implement HID Keyboard Wedges into your specific needs. Learn more about our Embedded expertise and  contact us today.

The post Arduino Nano R4 USB HID Functionality and First Impressions appeared first on DMC, Inc..