What Is a Power Profiler?

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

Devices Used

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

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

Lower Power Techniques

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

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

Examples

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

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

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

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

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

Code

Below are the two sketches used for the measurements above:

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

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

unsigned long lastToggle = 0;
bool ledState = false;

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

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

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

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

unsigned long lastToggle = 0;
bool ledState = false;

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

The post MOSFET Power Loss Calculator appeared first on DMC, Inc..

Another way Espressif is improving their Bluetooth capabilities is by porting a new BLE-only stack called NimBLE into their ESP-IDF. ESP-IDF is Espressif’s software development kit (SDK) for the ESP32. Previously, the only option for Bluetooth on the ESP was BlueDroid, which implemented classic Bluetooth and Bluetooth LE. BlueDroid is large in terms of both code size and runtime memory—even if the application only uses Bluetooth LE. I recently implemented a GATT server using NimBLE on the ESP32 and in this blog, I’ll share some of the things I learned.

NimBLE Functionalities 

NimBLE is the BLE stack used for Mynewt OS, a cross-platform OS targeted at IoT devices. Mynewt contains a variety of lower-level functions and structures that are used across their higher-level communication protocol stacks (NimBLE included). Espressif therefore had to port over some of these lower-level functions and structures along with the NimBLE stack, such as the ble_hs_mbuf_to_flat() function.

Data in NimBLE is passed around via memory buffers named mbufs. Mbufs are a linked list containing data needed for any type of packet in Mynewt OS. Data coming to my application from the NimBLE stack would be in an mbuf, and the data I want to send to the NimBLE stack needed to be in an mbuf. There are a few functions ported into ESP-IDF to encode or decode mbufs to a Uint8Array, but the ones I primarily used were:

ble_hs_mbuf_to_flat()

ble_hs_mbuf_from_flat()

I used these when I needed to create an mbuf to be passed into NimBLE, or when I needed to access the raw data from an mbuf passed to my application from NimBLE.

Customization

With NimBLE, creating custom services and characteristics is surprisingly easy. For background, all BLE services and characteristics have universally unique identifiers (UUIDs). Some generic UUIDs are reserved by the Bluetooth SIG and should only be used by specific metrics. For example, the device name should always be at UUID 00002A00-0000-1000-8000-00805F9B34FB. Some applications require data to be sent that does not fall into any of these generic UUIDs, and therefore require a custom service or characteristic. Doing so is as easy as passing a ble_gatt_svc_def structure to the NimBLE stack. Part of the ble_gatt_svc_def structure requires a user callback. This user callback will be called to handle BLE events like writes or reads of any characteristic. I found this easy to set up and clean if you need to expand and customize BLE services or characteristics.

You can check out some examples of the NimBLE port inside ESP-IDF. There are examples showing GATT servers/clients, and one for creating a BLE mesh. I hope this can help in creating your next BLE project with the ESP32!

Read more about DMC’s embedded development and programming expertise and contact us to get started on your next project. 
 

The post Creating a GATT Server With ESP-IDF’s Latest Bluetooth LE Stack: NimBLE appeared first on DMC, Inc..

A Chip That Packs a Punch

The nRF9160 is a system-in-Package (SiP) that includes an LTE modem with an Arm Cortex-M33 processor for user applications. The modem can support either LTE-M or NB-IoT, but it can also be updated dependent on the application. The processor has 1MB of flash, 256 KB of RAM, and 32 GPIO. The SiP also has a built-in GPS receiver. I think one of the most impressive things about this chip is that its only 16mm X 10mm X 1mm. It’s tiny, but it really packs a punch! I couldn’t wait to get my hands on this development kit.

The nRF9160 Development Kit

Development Environment

Nordic’s documentation for setting up the development environment made it easy to get to the point where I could flash sample programs. The desktop app, called nRF Connect for Desktop, is their suite where they house their apps for nRF devices. The app called Getting Started Assistant walked me through setting up their toolchain, SDK, and development environment. 

nRF Connect for Desktop application

The IDE of choice for the nRF modules is SEGGER Embedded Studio (SES). Nordic has their own edition of SES that is used to open their nRF Connect SDK Projects. Installing this edition of SES is covered in the Getting Started Assistant application. You can open one of their SDK projects through File -> Open nRF Connect SDK Project… This will autogenerate some files necessary to open your project through SES, as well as create some configuration files. 

Their samples are combinations of solutions that consist of smaller projects that compile to C libraries. You can configure what projects are included in your solution by selecting Project -> Configure nRF Connect SDK Project. This menu is also used to enable the options of Zephyr, the RTOS used with their SDK. This menu then updates a configuration file for Zephyr and other projects in your build directory. The initial values of these configuration files are set through the prj.conf file in your project folder. 

nRF Connect SDK configuration menu

Create an Application

To begin creating your own application, you’ll probably want to start with one of the sample projects. You can use the project named libapp.a to store your application files. You can open your applications CMakeList by right-clicking your project and choosing Open CMakeLists.txt in Editor. This lets you choose all included directories and source files needed by your application. When you are ready to test, you can go to Build -> Build and Run or Build -> Build and Debug. 

I hope this helps you have as much fun creating user applications with this chip as I did! One thing to note is that, since this chip is still fairly new, there are some kinks to be worked out in the SDK. Luckily, Nordic has been very responsive to issues in their forums and are continuously releasing bug fixes and features to their SDK. Stay tuned for some of the amazing applications that will come out of this chip!

Learn more about DMC’s embedded development expertise.

The post Unveiling the Power of the Nordic nRF9160 SiP appeared first on DMC, Inc..

These new networks are the future of IoT. However, as this writing, many of these networks still have a lot of kinks to work out. Cellular module vendors are rapidly developing and lunching modules for these networks. These modules are all new and so is the network, so challenges launching a product on one of these networks are to be expected.

What to Do

1. Know your Module Vendor
When selecting a cellular module vendor make sure they have a good support network. With new network deployments, there will be a LOT of updates happening in the background. The cell providers will be making adjustments and so will the module vendors. It’s important to understand the level of support you will get from the module vendor if your device happens to uncover a bug or incompatibility between the module and the network, or worse, between the module and a specific cell tower.

  
ublox SARA-R4 series, SIMCom SIM7000X, and Nordic nRF9160

2. Understand the Module Power Requirements
Most of these cellular module vendors provide a lot of marketing material about the low power requirements of their modules. These low power modules promise battery-powered cellular connectivity with years of battery life. It’s true, these modules have very low average currents while operating. The important thing to understand is that they also have relatively high peak current demands, which means you need to select your battery and design your power circuitry carefully. You won’t see any cellular IoT devices running on coin cells anytime soon.

Lithium Thionyl Chloride is popular cell chemistry for super long-life Wi-Fi or Bluetooth IoT devices, but most of the batteries made with this chemistry fail to provide the high peak current required by the cellular modules. Spiral wound Lithium Thionyl Chloride batteries use the same chemistry but provide higher peak current (by increasing the electrode surface area), however these batteries may still not meet the peak current demands.

Spiral wound Lithium Thionyl Chloride batteries

Instead, you may need to consider hybrid batteries like these from Xeno Energy which consist of a Lithium Thionyl Chloride cell and a parallel supercapacitor. The supercapacitor can provide high peak currents while exhibiting very low leakage.  Although the cost is higher for this battery topology, it provides the performance needed for long life cellular IoT devices. 

Hybrid battery

3. Test Your Module in a Wide Variety of Conditions
These modules contain closed-source vendor-supplied firmware. The operation of the module may not be fully documented. Part of your testing protocol should include adding attenuators to the cellular antenna (to simulate poor cellular reception) and observing how the module functions with reduced signal strength.

Modules draw significantly more average current when operating at this reduced signal level. Not knowing this ahead of time can be problematic, especially if your product advertises a minimum battery life expectancy. The actual battery life will largely depend on your connection to the cellular network. The total energy required to transmit a message from your device to the backend server can vary significantly depending on your signal strength and the number of retries required. 

Add attenuators to the cellular antenna to test at a reduced signal strength

4. Expect and Plan Time for Network Issues
These networks are going to be great, but until they are fully stable your product launch is going to go slower than you hoped. Add extra time in your launch schedule to account for these unknowns and extend your engineering budget to account for the time required to work through these issues. 

Keep in mind that different cell towers may contain different vendor hardware. Each of these vendors may be interpreting the CAT-M1/LTE-M specification differently and you may encounter situations where the firmware in your device performs better on some towers than others. If you encounter issues like this, move your device to a different location to see if it picks up a different tower and starts working. Eventually, these issues will be worked out by the carriers and module providers, but you should initially be prepared to work through these situations during your testing and product rollout.           

The firmware in your device may perform better on some cell towers than others due to hardware differences

Learn more about DMC’s IoT solutions. 

The post 4 Tips for Launching a Product on Emerging Cellular Networks appeared first on DMC, Inc..

Espressif developed the Espressif Internet Development Framework (ESP-IDF) as their SDK for developing with the ESP32. There is a very good guide to getting their toolchain and SDK setup on Espressif’s website. The ESP-IDF has components for almost anything you’d like to do with the ESP32. There are drivers for GPIO, Wi-Fi, IoT communication standards, and so much more. Espressif recently began modifying their SDK for the ESP8266 to be similar to the ESP-IDF.

The ESP-IDF uses a menuconfig to enable sections of the ESP-IDF API, configure peripherals, etc. This is nice for finding all the components that are available through ESP-IDF and their options. Some of these options can also be changed on the fly through API calls, but I’d argue that I’d rather have these configured before runtime.

The ESP32 and ESP8266 are both great modules to work with, but each of them has their quirks. Below, I’ve compiled a list of tips for getting started with the Espressif modules:

1. The sdkconfig file saves all the changes made in the menuconfig
   • The menuconfig saves all configurations in a file called sdkconfig. Sdkconfig shows all options available to be set through menuconfig. If you are searching for a specific option, it can be quicker to ctrl = f through sdkconfig and backtrack to find the location through menuconfig.
   • Menuconfig does read and write from sdkconfig, so changes you make in sdkconfig will be reflected in menuconfig. If you have a lot of trouble finding a parameter through menuconfig, this can be a backup option (though it is not recommended by Espressif so be warned!)
2. Run make with parallel jobs
   • Building a project using ESP-IDF can take a while because they do not automatically run parallel jobs. This causes long compile times when rebuilding from scratch. Since every change in menuconfig requires a complete rebuild, this can start to eat a significant amount of development time.
   • To build with parallel jobs, you need to add the -j option to your make commands. A command of make -j4 will run make with 4 parallel jobs. Espressif recommends running with option -j(number of CPUs +1)
3. Not all GPIO pins have full functionality
   • The ESP32 has 4 pins that are labeled as input only. These pins are GPIO 34, 35, 36, and 39.
   • The ESP32 also has 18 ADC pins, however, 10 of these cannot be used while Wi-Fi is being used! The pins that cannot be used as ADC with Wi-Fi are GPIO 0, 2, 4, 12, 13, 14, 15, 25, 26, 27.
   • Since the ESP32 and ESP8266 have external flash, the modules have a SPI interface. On some development boards, these pins are exposed, so it is recommended to not use these pins in your projects. On both boards, these pins are GPIO 6-11.
4. Default FreeRTOS tick is 10ms
   • The default tick rate for FreeRTOS in ESP-IDF is 100. This can be updated up to 1000 with no issues, but anymore than that I’ve heard is unreliable. If you need timing more precise than 1ms, you may need to implement RTC timers with interrupts.
5. OTA updates for ESP32
   • ESP-IDF gives the user control over how the external flash is utilized through a partition table. Setting up the flash partitions correctly is essential for OTA updates. OTA updates require at least 3 entries, otadata, ota_0, and ota_1.

     

   • On first boot, the bootloader jumps to ota_0 partition (if the factory partition is not specified) and begin running the firmware. When the firmware activates a firmware update, it then updates the ota_1 partition. The device then runs the firmware in ota_1 and updates otadata to mark ota_1 as the active partition, so that on bootup, ota_1 is run.
   • One of the cool features included in this method of updating firmware is that it allows for firmware verification on every update. This way, if you push code to your device that doesn’t pass your user-defined tests, the device can roll back to the previous ota partition and continue running. This is a nice feature to be rolled into the ESP-IDF as it can save.
6. Add more RAM
   • Both the ESP32 and ESP8266 support adding additional RAM. Espressif has even developed an SRAM device for the ESP32, called the ESP-PSRAM32. The external RAM is connected in parallel with the external flash chip, allowing the new RAM to be accessed the same as internal RAM.
   • Espressif also has the ESP32-WROVER module, which contains an external 4MB SPI Flash and 8MB external PSRAM, in case you don’t want to add these yourself.
7. Security
   • Both modules support signed firmware updates. This can help guarantee that any code updates are only applied by you (or anyone who gets a hold of your private key). Additionally, the ESP32 supports secure boot and flash encryption. Secure boot is another method of ensuring only your code can run on your device. Flash encryption protects your firmware from being accessible to anyone with physical access to your device.
8. Low-Power Mode
   • Both the ESP8266 and ESP32 can enter either light sleep or deep sleep.
   • In light sleep, clock pulses are powered off and RAM is retained. When exiting light sleep, and the program continues from wherever light sleep mode was entered from. There is also the ability to enable automatic light sleep, which can retain Wi-Fi connection by cycling between active mode and light sleep mode.
   • In deep sleep, the CPU and memory are powered off. The RTC module is still powered in this mode, which is responsible for periodic wakeups and can store a small amount of memory. The ESP32 also has an ultra-low power processor that can be enabled in deep sleep!

Contact Us Today to Speak With Our Embedded Development Solutions Experts and We Can Get Started on Your Next Project!

The post Getting Started with the ESP32 & ESP8266: 8 Tips and Tricks appeared first on DMC, Inc..

Projects using MicroPython and JerryScript attempt to provide a means to write Python and JavaScript code and provide frameworks for “compiling” and running scripts on a variety of bare-metal targets. However, these types of frameworks have some inherent drawbacks. JavaScript and Python are both interpreted languages with garbage collection and weak typing. Running these languages requires relying on a run time or more complex cross compiler.

A New Language for Embedded Systems

More recently, Rust has emerged as an appealing language for applications that require memory safety and efficiency. Both of these features are often critical for embedded devices. Manual memory management often creates bugs which are hard to isolate and are not always easily remedied due to the resource constraints of embedded devices.

Additionally, C/C++, even given all of its faults, remains a highly efficient language due to the control it provides developers and because it can use many target-specific optimizations at compile time. C/C++ sets a high benchmark for speed that is difficult for interpreted languages to match.

Rust, fortunately, solves both problems in ways that are particularly well suited to microcontrollers. Rust does not require any run-time engine for garbage collection or memory management. Rust instead chooses to enforce memory safety at compile time. Furthermore, because Rust compiles to LLVM, target optimizations rivaling those achievable with C/C++ are possible. Recently, the Rust core team has made support for new target architectures a priority, and there are already many open source projects aimed at expanding support for embedded devices in Rust.

Nucleo PCB Running on Rust

Getting Started with Rust

The Embedded Rust Book provides many details regarding getting started with Rust on embedded devices. For this blog, I’ll highlight a few key components that make up the Rust embedded landscape. Specifically, I’ll be discussing support for ARM Cortex M based microcontrollers.

The Rust ecosystem is built on an extensive library of packages called “Crates.” A few specific crates, “cortex-m” and “cortex-m-rt”, make up the core support for ARM targets. These packages provide the bare minimum of code to get a basic program up and running. It allows access and control of the core ARM registers.

Below is an example of setting up the systick peripheral taken from the Rust Embedded Book.

use cortex_m::peripheral::{syst, Peripherals};
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let mut systick = peripherals.SYST;
    systick.set_clock_source(syst::SystClkSource::Core);
    systick.set_reload(1_000);
    systick.clear_current();
    systick.enable_counter();
    while !systick.has_wrapped() {
        // Loop
    }

    loop {}
}

use cortex_m::peripheral::{syst, Peripherals};
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let mut systick = peripherals.SYST;
    systick.set_clock_source(syst::SystClkSource::Core);
    systick.set_reload(1_000);
    systick.clear_current();
    systick.enable_counter();
    while !systick.has_wrapped() {
        // Loop
    }

    loop {}
}

To implement something more interesting than a simple timer, we’ll need a Peripheral Access crate. These crates are typically specific to a vendor and family of microcontrollers. For example, the STM32F4 crate provides an API for accessing various peripherals such as GPIO, UART, and I2C for the STM32F4 family of devices.

Pulling in a Peripheral Access crate, we can build a program for toggling an LED:

fn main() -> ! {
    let mut peripherals = stm32f429::Peripherals::take().unwrap();

    //Enable gpio b clock
    let rcc = &peripherals.RCC;
    rcc.ahb1enr.write(|w| w.gpioben().bit(true));

    //set pin 14 to output
    let gpio = &peripherals.GPIOB;
    gpio.moder.write(|w| w.moder14().bits(1));

    //Turn on led
    gpio.odr.write(|w| w.odr14().set_bit());

    loop {

        delay(10000);
        if  gpio.odr.read().odr14().bit()
        {
            gpio.odr.write(|w| w.odr14().clear_bit());
        }
        else {
            gpio.odr.write(|w| w.odr14().set_bit());
        }
        
    }
}

fn delay(count: u32) {
     for _ in 0..count { cortex_m::asm::nop() }
}

fn main() -> ! {
    let mut peripherals = stm32f429::Peripherals::take().unwrap();

    //Enable gpio b clock
    let rcc = &peripherals.RCC;
    rcc.ahb1enr.write(|w| w.gpioben().bit(true));

    //set pin 14 to output
    let gpio = &peripherals.GPIOB;
    gpio.moder.write(|w| w.moder14().bits(1));

    //Turn on led
    gpio.odr.write(|w| w.odr14().set_bit());

    loop {

        delay(10000);
        if  gpio.odr.read().odr14().bit()
        {
            gpio.odr.write(|w| w.odr14().clear_bit());
        }
        else {
            gpio.odr.write(|w| w.odr14().set_bit());
        }
        
    }
}

fn delay(count: u32) {
     for _ in 0..count { cortex_m::asm::nop() }
}

Although Rust is an exciting new option for embedded development, it will take some time for it to supplant C/C++ as the standard. A lack of official support from major silicon vendors like ST, NXP, and Silicon Labs means that adding support for new microcontrollers can be a tedious process. Additionally, C/C++ frameworks like ARM’s mbed offer large, general purpose libraries and drivers that can be used across a variety of ARM targets with little to no modification.

Learn more about DMC’s Embedded Product Development Services and Embedded Systems Platforms expertise.

The post Oxidizing Bare Metal: Rust Programming for ARM Microcontrollers appeared first on DMC, Inc..

Schematic Library

From the Schematic Editor, select Design -> Make Schematic Library.

Altium will convert each component on your schematic into a library component and will use the Library Reference parameter to name each component. However, if you use part parameters to store information like part numbers, vendor links, etc. (which you should be!), Altium will flag components with the same Library Reference but different parameters. An example of this is shown below. Two of the capacitors in my schematic use the same symbol but have different part number fields ("different internal structure" in Altium-speak).

There's no need to have several different capacitor (or inductor, resistor, etc) symbols in your symbol library – you just need to make sure you edit/verify the component parameters when you add the component to your schematic. But you do that anyway, right?

If you select "Process only the first instance and ignore the rest" and then click "Remember the answer and don't ask again", it will only create one schematic symbol per Library Reference.

When finished, the new symbol library will be added to your project and opened in Altium. By default, the library filename is set to whatever your project file is named.

Footprint Library

To generate a footprint library, go to your PCB Editor and select Design -> Make PCB Library. As before, Altium will create a new library component for each footprint in your design and then open the library for your perusal when complete.

Library Trimming

This functionality is useful in a few other cases as well. The main case is useful for handing off the finalized design to a client or manufacturer. In large embedded projects, it's common to make changes to the component selection in order to drive cost down, improve functionality, decrease power consumption, etc. As a result, there will be extra library components hanging around. Using the procedures described above, you can create libraries that contain only the parts in your design, rather than manually searching for and deleting the extras.

Happy PCB designing!

Learn more about DMC's embedded development and programming services.

The post Recovering Missing Library Components in Altium Designer appeared first on DMC, Inc..

Active/Sleep Programming

One of the first steps DMC took to help improve battery life was to use an active/sleep architecture for running the program. In this design, the microcontroller and any other high-current devices are shut down/put to sleep when they are not needed. This inherently created a variable current draw for the device, but ended up being much more efficient than having the hardware idly chewing up current without accomplishing anything (idle operations).

This was accomplished with a microcontroller by using hardware interrupts to bring the microcontroller out of a sleep state to process new data or actions. Specifically, DMC used a TI MSP430 that sat in an ultra-low power state that was interrupted by a couple of conditions: a timer set to update the user display, a button action, or new data from an external chip. Once interrupted, the microcontroller did all the necessary calculations and then went back to sleep. The microcontroller was also limited in how often it could be awoken, even when being constantly interacted with, to guarantee a certain duty cycle of sleep vs. active. Using this in place of code that actively waited for those conditions reduced the microcontroller’s average current draw by orders of magnitude. 

DMC further increased battery life by optimizing the active/sleep timing and behavior for the customer’s exact application, increasing the battery life of an inactive device from 160 to 240 hours. This was done by running all communications in parallel with processing using interrupts, and by reducing the display update frequency while keeping the user experience intact. Both of these allowed the microcontroller to get to sleep quicker and stay asleep longer.

Clockspeed Adjustments

The next step DMC took was to optimize the clock speed at which the microcontroller was operating. Almost all microcontrollers have the ability to change their clock speed, and some even dynamically while running code. If running off of an external power source, it is typical to just run the device at the highest clock speed, and with a sleep/active architecture, some may argue that the active clock speed is not important since a faster clock speed allows you to run your calculations quicker and get back to a sleep state.

However, remembering the conditions from the first post, a higher current draw has a bigger impact than a low current draw, even if they average to be the same. Therefore, DMC optimized the clock so that it only ran as fast as necessary to complete our code in the allotted amount of time. In this application, DMC used an oscilloscope to time the processing of certain functions under specific conditions, allowing the clock speed to be changed for each case while still maintaining responsiveness and accuracy.

In the image above, you can see the change in current draw when the clock speed in our application was reduced. In both cases, the amount of computation is the same, as is the average current draw over time, but the higher clock rate has a much greater peak current draw. The results of decreasing this peak were an increase in idle battery life from 260 to 300 hours and dynamic life from 150 to 180 hours.

Capacitor smoothing

In addition to reducing the clock speed when actively processing data, DMC also added capacitance to the battery supply to further reduce the peak current draws seen by the battery. By placing a fairly large capacitor in parallel with the battery, the capacitor can act as a power source when high currents are required. The result is that the battery does not have to supply all of this current, and the capacitor can be recharged during periods of low current draw. In the end, the battery sees a much smoother current profile and gets closer to our ideal situation of constant low current draw.

In the image below, the addition of a 100 mfd capacitor dramatically reduced the peak current draw seen by the battery. This resulted in an increase in dynamic battery life from 180 to 210 hours.

Conclusion

By leveraging DMC’s knowledge in embedded software and hardware development, DMC was able to improve the customer’s battery life by almost 90% when inactive and 40% when active. This, in the end, will provide a better selling point for the device and reduce battery costs and downtime for the end user.

The post Improving Battery Life in Low Power Embedded Applications Part 2: Case Study appeared first on DMC, Inc..