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

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

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.

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

The model we tested was the M5 Stack Core Basic. We chose this model for its simplicity, physical buttons, and validation that the most basic model can be used effectively. This model is equipped with an ESP32, SD Card slot, three physical buttons, a color LCD TFT screen, a speaker, and GPIO pinouts. Additionally, we purchased a larger battery and a proto stack, which all stacked together, nice and clean. There is also a USB-C port used for charging and programming, along with a power/reset button. 

Left to right: M5 Stack Core Basic, Battery Stack, and Proto Stack

The device is based on two or three possible architectures, including Arduino, MicroPython, and UI Flow 2. MicroPython and UI Flow 2 can be combined since UI Flow 2 is a drag-and-drop language that is translated into MicroPython. The main gap between UI Flow 2 and base MicroPython is the online vs. offline aspects of the two. Since drag and drop most likely won’t be used, we’ll focus on the other two architectures. 

UI Flow 2

UI Flow 2 is a web-based IDE that allows the user to flash and burn the device through a browser-based serial. It does this using the MicroPython environment, which has a base firmware loaded to the ESP32, then replaces the main.py code for fast flashing and testing. I have supplied short tutorials for each of the methods at the end of the document, or have provided the M5 curated document.
 
A nice feature in UI Flow 2 is the ability to design a UI in the IDE and have it created into MicroPython code. This helps when designing a screen since you can see how it looks in real time without having to flash the device each time a change is made. I did not use the drag and drop functionality much for main development, although I did use it to get an instance reference to the source code. For example, to set up UART, I dragged an Init UART and Setup UART block to get the MicroPython code that showed how those functions are actually used. I did this for many peripherals to find out how to use them without referencing the source code directly. 

UI Flow 2 main IDE

I encountered one issue when using the UI Flow 2 cloud save function. My entire project seemed to have been deleted, and I couldn’t find out why. After that, I did my work in Visual Studio Code and copied the code into UI Flow 2 for fast flashing and error checking.

Aside from that issue, I think a user could get very far with just UI Flow 2, and I would highly recommend it as a starting point to using the M5 stack, as it demonstrates how the device can be used and can even write much of it for you using the drag and drop functions. Some functions that were tested and confirmed to work were UART, screen-related changes, the buttons, write/read to the SD card, ISR, an async library, and programming the device. 

Arduino

Since the device is based on an ESP32, Arduino is another option for using the device. This can be done through the desktop-based Arduino IDE. The M5 tutorial was generally fine, although it did not show a step to get the specific device library files.

Once all was set up, I used example code to test the board and its peripherals. The same tests that I did on the UI Flow 2 setup were done in Arduino, all of which worked.

Another benefit of the Arduino framework is the C/C++ based language, as it is often used within DMC Embedded. Since this is a C/C++ based method, a major downfall was time. Being a compiled language, I lost a lot of time waiting for compilation and flashing of the device. Although I would prefer to use a C/C++ based language, I do not feel Arduino is the ideal environment to use the M5 in. It may have great applications depending on the use case if certain libraries are only found in Arduino. A benefit of Arduino over UI Flow 2 was that the error messages when compiling were much clearer. 

Arduino IDE with some sample code

MicroPython

Although I covered some of the functionality in the UI Flow 2 section, this section focuses more on a local setup of using MicroPython on the device. This method used a different base firmware from MicroPython directly. Because of this, I had to add libraries to the firmware for the MicroPython code to work.

When testing, I focused more on the accessibility of the device through command-line interfaces. The goal was to use VS Code extensions, although at the time of writing, none of them seemed to work anymore. Some good offline options are Thonny and PowerShell using esptool, ampy, mpremote, and REPL. The benefit of these is that you don’t need an internet connection to use them, and development can thus happen anywhere and without fear of the site being down or discontinued. This method was very quick and allowed for a similar workflow as seen in UI Flow 2. The only downside is setting things up to do this, as it can be a bit confusing. I’ve included instructions below for the reader’s ease. Also, you can use scripts to make a simpler one-click solution. You can use the base UI Flow 2 firmware as a starting point, as it has the needed drivers and libraries within it to use the M5 device effectively. 

Tutorials

UI Flow 2

The tutorial provided by M5Stack is pretty good. The general steps go as follows:

1. Download M5Burner.exe
2. Burn the related UIFlow2.0 firmware
   1. Choose COM port that the device is attached to and set baud to 1500000
3. Open the UIFlow2 IDE
   1. This requires you to make an account to save things
4. Install drivers for your specific setup. I used CP210x_VCP_Windows.
5. Once in UI Flow 2, make a project and open it
   1. A simple demo of things working is to make the screen a color
      1. On the left side, under the UI drop-down down select UI-> Screen and drag a “Set screen background color ‘Palette’” block to after the “Init built-in hardware at beginning” block
      2. Select a color
      3. In the bottom right corner, press run
      4. A WebTerminal will come up and or a browser serial picker
      5. Choose a serial port that corresponds to your setup
         1. If this doesn’t come up, press the chain link icon in the top left corner of the terminal
      6. Press the play button to send the code to the device. The screen should now be the color you picked
   2. To burn a file to the device to use on battery power
      1. Sometimes the burn button to the right of run works, but if not, follow the directions below
      2. In the WebTerminal, select File, scroll down to main.py->Delete
         1. This will delete what is stored locally on the device 
      3. Create a file called main.py in a text editor, and paste your code there
      4. Press Send File to Here and select main.py-> Confirm

Arduino 

The tutorial provided by M5Stack is pretty good.

MicroPython

This documentation is neither great nor clear. Here is the tutorial I followed. A general guide is here:

1. Either download a bin file or use the M5Burner.exe to burn the UIFlow2.0 firmware. If you download a bin, keep following; if not, skip to step 7
2. Open a CMD or PowerShell terminal
3. Create a virtual environment for this project
4. Run pip install esptool in the terminal, this will install the esptool
5. Run esptool.py –port COMX erase_flash 
   1. Change X with your com number
   2. If this doesn’t work, try esptool –port COMX erase_flash
6. Run esptool.py –chip esp32 –port COMX write_flash -z 0x1000 YOUR_FW.bin
   1. This should be run where your file is located
7. If this doesn’t work, try esptool.py –chip esp32 –port COMX –baud 460800 write_flash -z 0x1000 YOUR_FW.bin
8. Your ESP32 will now have firmware on it
9. At step 1.5 in the MicroPython tutorial, it changes to this tutorial
10. Now we will work on getting a main.py onto the device
11. Run pip install adafruit-ampy 
12. Run ampy –port COMX put main.py
13. Run ampy –port COMX run main.py
14. You should now have your file running on the M5 Device

Useful Links

• Source code references
• Devices list
• UI Flow 2 IDE
• MicroPython homepage

The post M5 Stack Analysis as a Rapid Prototyping Platform appeared first on DMC, Inc..

There are only two simple rules to bring a dog to the office. First and most importantly, they must behave well. This means that they play nicely with other dogs and humans alike, they don’t destroy things around the office, and they are able to keep an overall peaceful office setting for all. A second much easier hoop to jump through is to get the approval of our Founder & CEO, Frank Riordan.

As time moves on, more companies are including policies that allow pets into office settings. DMC believes they are great additions to the workplace and make all those involved much happier.

Lenny lays in a chair supervising the Chicago office

Dunkin sits on his blanket bed in the Chicago office

Bently sticks out his tongue at his owner, Nicolette from the other side of the Recruiting & Onboarding team’s quad in Chicago

Pepper is tired from a long day at the Chicago office

Many employees at DMC take advantage of this rule and bring their dogs into the office. Some visit the office occasionally and others every day.

Allowing office dogs in the workplace is great for some obvious reasons. This allows DMC pet owners to not have to stress over their dogs being home alone all day and trying to organize a way to feed them or take them out throughout the workday. The dogs also seem to enjoy the policy as they get to be in a more social environment as opposed to being home alone for the day.

A third beneficiary of this policy is for those in the office who don’t have dogs. Dogs are known to reduce stress and boost human morale. The joy that stems from the sounds of excitement coming from the voices around the office when DMCers get to pet and greet a dog is contagious.

Charlie begs for belly rubs to distract Aaron and others from Chicago’s Embedded team

Ronin enjoys his lunch break in San Diego

Arthur checks the Automation team’s floor levelness in Chicago

Margaux takes a power nap in the Chicago Test & Measurement team’s quad

Bailey naps in the Marketing Quad during her first week in the Chicago office

As a dog owner myself, being able to bring my dog Lenny is an amazing perk of working at DMC. Not only do I enjoy spending time with him throughout the day, but it also helps in situations where he would otherwise be left home alone. Dogs left home alone can become stressed out, so this policy helps avoid stress on both and dogs and their owners!

A day for a DMC Dog is very consistent. They start with a strong breakfast of kibble and some water to wash it down. From there, they can situate themselves in their owner’s quad or office and may even put their toys in places their owner will only find three weeks later or see in a Slack channel. After this, they start their first of many naps. These naps must be taken underneath desks or in high foot traffic areas — to ensure the dogs get the type of attention they are looking to receive while in the office of course.

Occasionally, someone may be in the kitchen and the sound of a dog’s nails on the hardwood is coincidentally heard; these things must be investigated thoroughly. Every couple of hours the dogs must get dressed in their harnesses, some in coats too, to go outside and take care of business. After a group lunch, the dogs have had their fill of food and love, and they can begin their real work: which is supervising. DMC dogs are well trained in this field as they can sit anywhere and watch DMCers fulfil one of our Core Values: Make Things Happen.

The last duty of a DMC dog is to wander around and hope someone pets them, talks to them in a baby voice, and maybe even spoils them with a treat. Frank’s office is a guaranteed treat haven.

With all this talk about dogs, one may consider asking “what about cats?” Well, DMC has that covered too. On certain occasions, cats have also visited the office — some for a few hours and others for an entire day. Cats do need some higher levels of supervision as they can be quite curious, so it often helps to work in a room or closed office to prevent cat-based mischief.

Sasha tests ribbon samples in Chicago

Pepper dresses up in her Halloween costume in Denver

Ben assists Leon in a code review

Nola provides IT support in DMC Denver

Bowser’s first day in the office was exhausting

Nooner and Luna join Elizabeth in a meeting in Seattle

Denver tongue inspections

Chicago’s weekly lay down

DMC is a pet-loving environment and is welcoming to them as long as it makes sense, so no pet alligators, I would assume. Our pets also bring a lot of culture to the workplace as they are another topic of conversation and way for employees to interact with each other. With the kind employees at DMC, you can even find a dog sitter if a less dog-friendly meeting must occur at the office.

This policy brings joy to many of DMC’s offices and many office settings could benefit from dogs in the workplace. In DMC’s case, this is one of the best parts of going into the office!

Learn more about DMC’s culture and explore our open positions!

The post DMC Dogs in the Office appeared first on DMC, Inc..

While talking with some of my colleagues, the topic of an April Activity Fund event came up, and I took the initiative of getting an event planned. The ability for any DMC employee to plan an event for their office has always been something I thought was interesting – and  somewhat scary – but after the fact, it makes me want to host more events in the future.

Go karting was an easy choice primarily for the desire for acceleration, the need for speed if you will. The main selling point of these go-karts was that they have a max speed of 45 MPH and they don’t make you smell like gasoline. After planning with K1, we had a date, time, and general schedule for the event with about 20 people attending (including +1’s). With the closeness of the DMC community, everyone was able to make the trip by carpooling despite the long distance.

Once everyone had arrived and signed their safety waivers, K1 served food and drinks. As we ate, excitement grew. When everyone finished eating, K1 employees gave us a safety debrief on how to drive the karts and what to look out for and avoid when racing.

People began to size up their helmet liners/facemasks and their competition; in the end, it was still a race to be the best.

Everyone got their helmets, and half of the group was ready for their first race. Each racer was entitled to two races. The first race was the 12-lap qualifier: the goal was speed. Racers were given their ranking by fastest laps around the track. After both groups finished their first set of laps, their stats were used to make their race order for race two, the finals.

The finals were different from race one; this was position based. Racers now had to worry about taking over other racers and holding their position from other racers, all while driving around a track at high speeds. Each racer got their race stats via email for viewing – which showed metrics like individual lap speed, fastest lap, and data of the other racers as well to compare for bragging rights.

After many bumps, drifts, spinouts, and acceleration that puts a smile on your face, everyone involved had a blast.

For a potential return to K1, DMC has considered going to a drift night that focuses more on the precision of the driver as opposed to their ability to maneuver at high speeds. Some other potential activities at K1 included a Whirly Ball clone, an arcade, and various other mode on the go-kart track.

I think the positivity of this event will bring in those that came the first time and many more in the future. I loved being able to plan the event and bring something to DMC that everyone enjoyed. With this experience of planning, I’d like to put it towards the planning of another event that, hopefully, everyone enjoys even more.

Learn more about DMC’s company culture and check out our open positions!

The post Speeding Into Spring appeared first on DMC, Inc..

The AD2 includes important features such as a two-channel, 14-bit, 100 MS/s oscilloscope, two-channels for wave generation, a variable power supply, a voltmeter, and many other useful tools as shown in Figure 2.

This can all be controlled through Digilent’s WaveForms PC app, available on Windows, MacOS, and Linux.

Figure 1: The Analog Discovery 2

Figure 2: The WaveForms app showing a full list of functions

The WaveForms Application

The WaveForms application wraps all functions for a clear user interface that includes all of the settings required for the task at hand. For example, the oscilloscope page shown in Figure 3 has many options including scaling and viewing the two channels, and functions for achieving the desired WaveForm.

Along the top of the interface, the user can choose from supplemental subplots that display helpful visuals such as a spectrogram to see the strength of a signal.

Some other non-plot options can be found in the measurements tab, which allows the user to look at specific qualities of a channel such as the frequency, duty cycle, period, and even custom measurements defined by the user. The full list can be found in Figure 4.

Figure 3: The oscilloscope screen

Figure 4: The measurement options

The Wave Generator Screen

Moving on, the wave generator screen has all the essential features of most WaveForm generators, such as an area to choose the parameters for a specific wave, as seen in figure 5. The device can create two WaveForms at once that have their own specific settings.

The voltmeter and supplies are fairly simple but very useful for someone looking for a low current -5V to 5V supply. If more current is required, the AD2 allows for an auxiliary power source through its barrel connector which raises the max power from 500mW via USB to 2.1W with AUX. These two screens can be seen in Figure 6.

Figure 5: The Wave Generator screen

Figure 6: The Voltmeter and Variable Power Supply screens

Logic and Protocol Analyzers

Another useful feature of the AD2 is its logic and protocol analyzers. The logic/ protocol analyzers are useful when communications like UART, I2C, CAN, or SPI are being used. There are 16 digital I/O pins on the board that can be used for the logic analyzer and other digital I/O features such as the ability to use the I/O pins as buttons, LEDs, and switches.

The AD2 is a powerful tool for someone who wants a full debugging toolkit that can easily be stored in their tool bag or backpack. Only a Micro-USB cable and the jumper wires required for the task are necessary to access the full capabilities of the device.

Most of the functions can be used in tandem, such as generating a wave through a system and watching the output in the oscilloscope on the same device and screen.

Digilent’s AD2 reference manual provides extremely detailed coverage of each of the device’s functions to best aid the user. There are also many resources on the internet about some of the more niche features, for those that require that information.

Learn more about DMC’s Embedded Development expertise and contact us for your next project.

The post Introduction to the Digilent Analog Discovery 2 appeared first on DMC, Inc..