Electronics

Nov

2021

How to handle both OTA and serial upload in platformio.ini

When you’re writing a PlatformIO firmware that can be uploaded using both ArduinoOTA and over the serial port, I recommend this platformio.ini setup:

Start with your normal config for serial upload:

[env:d1_mini]
platform = espressif8266
board = d1_mini
framework = arduino
monitor_speed = 115200

And now add a new OTA target that extends the serial config, effectively inheriting the complete build configuration including the lib_deps:

[env:d1_mini_ota]
extends = env:d1_mini
upload_protocol = espota
upload_port = 192.168.178.166

In upload_port you need to enter either the IP address or the mDNS name of the board that shall be flashed. The IP address we entered (192.168.178.166) is just an example.

Also note that depending on the name of your original build target, change

extends = env:d1_mini

to the name of your original target (including env:)

Complete `platformio.ini` example

[env:d1_mini]
platform = espressif8266
board = d1_mini
framework = arduino
monitor_speed = 115200

[env:d1_mini_ota]
extends = env:d1_mini
upload_protocol = espota
upload_port = 10.9.1.106

Nov

2021

How to fix PlatformIO ESP8266 ArduinoOTA error: stopAll is not a member of WiFiUDP

Problem:

When compiling your PlatformIO firmware, you see an error message like

/home/uli/.platformio/packages/framework-arduinoespressif8266/libraries/ArduinoOTA/ArduinoOTA.cpp: In member function 'void ArduinoOTAClass::_runUpdate()':
/home/uli/.platformio/packages/framework-arduinoespressif8266/libraries/ArduinoOTA/ArduinoOTA.cpp:268:12: error: 'stopAll' is not a member of 'WiFiUDP'
  268 |   WiFiUDP::stopAll();
      |            ^~~~~~~

Solution:

Remove WiFi from the lib_deps secton of your platform.ini. Before the fix:

lib_deps =
    ESP Async [email protected]
    [email protected]
    WiFi

After the fix:

lib_deps =
    ESP Async [email protected]
    [email protected]

Now check your source code and replace any

#include <WiFi.h>

#include <ESP8266WiFi.h>

in order to prevent the WiFi.h: No Such File or Directory issue as outlined in How to fix PlatformIO ESP8266 WiFi.h: No Such File or Directory

Now you need to completely remove the `.pio` folder from your project directory in order to ensure a clean build:

rm -rf .pio

After that, recompile your firmware.

Nov

2021

How to fix PlatformIO ESP8266 WiFi.h: No Such File or Directory

Problem:

When compiling your PlatformIO firmware, you see an error message like

src/main.cpp:2:10: fatal error: WiFi.h: No such file or directory

**************************************************************
* Looking for WiFi.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:WiFi.h"
* Web  > https://platformio.org/lib/search?query=header:WiFi.h
*
**************************************************************

    2 | #include <WiFi.h>

Solution:

Instead of

#include <WiFi.h>

use

#include <ESP8266WiFi.h>

Now delete the .pio folder from the project directory to ensure a clean build by using:

rm -rf .pio

In case that doesn’t help, see our article on how to fix this issue by adding the WiFi library to the dependencies: How to fix PlatformIO WiFi.h: No Such File or Directory

Nov

2021

How to fix PlatformIO multiple definition of `WiFi’ error

Problem:

When compiling your PlatformIO firmware, you see an error message like

Linking .pio/build/d1_mini_lite/firmware.elf
/home/uli/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld: .pio/build/d1_mini_lite/libbc0/libWiFi.a(WiFi.cpp.o):(.bss.WiFi+0x0): multiple definition of `WiFi'; .pio/build/d1_mini_lite/libd39/libESP8266WiFi.a(ESP8266WiFi.cpp.o):(.bss.WiFi+0x0): first defined here
collect2: error: ld returned 1 exit status
*** [.pio/build/d1_mini_lite/firmware.elf] Error 1

Solution:

Move WiFi in the lib_deps section in platformio.ini to the top of the list. Before the fix:

lib_deps =
    ESP Async [email protected]
    [email protected]
    WiFi

After the fix:

lib_deps =
    WiFi
    ESP Async [email protected]
    [email protected]

Now you need to completely remove the `.pio` folder from your project directory:

rm -rf .pio

After that, recompile your firmware.

Complete `platformio.ini` example after fixing the issue:

[env:d1_mini_lite]
platform = espressif8266
board = d1_mini_lite
framework = arduino
monitor_speed = 115200
lib_deps =
    WiFi
    ESP Async [email protected]
    [email protected]

Nov

2021

How to fix PlatformIO WiFi.h: No Such File or Directory

Important note: On the ESP8266, this solution is not recommended. See How to fix PlatformIO ESP8266 WiFi.h: No Such File or Directory instead

Problem:

When compiling your PlatformIO firmware, you see an error message like

src/main.cpp:2:10: fatal error: WiFi.h: No such file or directory

**************************************************************
* Looking for WiFi.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:WiFi.h"
* Web  > https://platformio.org/lib/search?query=header:WiFi.h
*
**************************************************************

    2 | #include <WiFi.h>

Solution:

Add WiFi to the lib_deps in platformio.ini (create lib_deps if it is not present already):

lib_deps =
    WiFi

and then recompile.

Complete `platformio.ini` example:

[env:d1_mini_lite]
platform = espressif8266
board = d1_mini_lite
framework = arduino
monitor_speed = 115200
lib_deps =
    ESP Async [email protected]
    [email protected]
    WiFi

Nov

2021

How to fix PlatformIO SPI.h: No Such File or Directory

Problem:

When compiling your PlatformIO firmware, you see an error message like

In file included from .pio/libdeps/esp32dev/Adafruit BusIO/Adafruit_BusIO_Register.h:2:0,
                 from .pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.h:21,
                 from .pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.cpp:31:
.pio/libdeps/esp32dev/Adafruit BusIO/Adafruit_SPIDevice.h:6:17: fatal error: SPI.h: No such file or directory

*************************************************************
* Looking for SPI.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:SPI.h"
* Web  > https://platformio.org/lib/search?query=header:SPI.h
*
*************************************************************

Solution:

Add SPI to the lib_deps in platformio.ini, for example, before:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1

After:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1
    SPI

and then recompile.

Nov

2021

How to fix PlatformIO Adafruit_BusIO_Register.h: No Such File or Directory

Problem:

When compiling your PlatformIO firmware, you see an error message like

In file included from .pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.cpp:31:0:
.pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.h:21:37: fatal error: Adafruit_BusIO_Register.h: No such file or directory

*********************************************************************************
* Looking for Adafruit_BusIO_Register.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:Adafruit_BusIO_Register.h"
* Web  > https://platformio.org/lib/search?query=header:Adafruit_BusIO_Register.h
*
*********************************************************************************

Solution:

Add adafruit/Adafruit BusIO @ ^1.9.3 to the lib_deps in platformio.ini, for example, before:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1

After:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1
    adafruit/Adafruit BusIO @ ^1.9.3

and then recompile.

Nov

2021

How to fix PlatformIO Wire.h: No Such File or Directory

Problem:

When compiling your PlatformIO firmware, you see an error message like

In file included from .pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.cpp:31:0:
.pio/libdeps/esp32dev/Adafruit INA219/Adafruit_INA219.cpp:29:18: fatal error: Wire.h: No such file or directory

**************************************************************
* Looking for Wire.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:Wire.h"
* Web  > https://platformio.org/lib/search?query=header:Wire.h
*
**************************************************************

Solution:

Add Wire to the lib_deps in platformio.ini, for example, before:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1

After:

lib_deps =
    adafruit/Adafruit INA219 @ ^1.1.1
    Wire

and then recompile.

Nov

2021

How to compute parallel resistor values in Wolfram Alpha

In Wolfram Alpha, you can just enter X parallel Y

9.75Ohm parallel 120Ohm

to compute the equivalent value of two resistors. In order to use Kiloohm or Megaohm, just use SI prefixes like k and M:

9.75kOhm parallel 120kOhm

Nov

2021

What is the typical & maximum clock frequency for XY2-100?

XY2-100 typically operates at 2.0 MHz clock rate. This is due to the typical 100 kHz frame rate, with 20 bits being transmitted per frame, hence $20\cdot{}100 \text{kHz} = 2.0 \text{MHz}$ .

The maximum clock frequency is rarely specified but Raylase lists it as 10 MHz.

Source: Raylase

Nov

2021

Which line driver should one use for XY2-100 and XY3-100?

Raylayse recommends in this manual to use

UA9638CD

as a line driver. Note that each UA9638CD contains two separate driver circuits while you need five drivers (CLK, SYNC, X, Y & Z), so you need to use three UA9638CD chips to be able to drive a XY2-100 interface.

In general, any RS422 or RS485 driver (with RS485 drivers being operated in fixed transmit mode with the driver being disabled) will do the job. However there are certain considerations:

The driver must be able to operate at 15 MBaud / 15 MHz input speed. Some (although few) RS485/RS422 drivers are slew rate limited, i.e. they cannot drive any signal faster than X kBaud/MBaud. I recommend not to use a driver that is slew rate limited. Most RS485/RS422 drivers are able to drive 15 MBaud and this is fine for XY2-100.
The driver should be able to withstand ESD surges, as usual in industrial equipment
Only ever use drivers with internal short circuit protection. Almost all line drivers do that anyway, but it’s really important in guaranteeing the robustness of your equipment
When using multiple separate driver chips, always use only one type of driver chip, as the receiver could experience skew between the different signals which might lead to bad received data. Never ever use different types of driver chips.
In general, drivers driven by 5V instead of 3.3V (or even 1.8V) provide a higher current into a given resistance, leading to high signal to noise ratios, plus they are quite expensive. Use 3.3V or 1.8V RS485/RS422 drivers only if not possible otherwise, but always check if the logic level of the MCU driving the line driver fits the input logic level of the line driver.

My opinion is that you should go with the following specs for most products:

Use three dual RS422 drivers with 15 MBaud speed capability
Use drivers with 5V supply with 3.3V compatible logic level
Use only drivers with at least ±8kV ESD (HBM), preferred ±15kV, and internal short circuit protection. These are reasonably robust.

My recommendation of finding a suitable receiver is to first search on the manufacturer’s websites because they provide more appropriate filters for this usecase:

Texas Instruments
ST Microelectronics
Maxim Integrated
Intersil

(it’s usually best to google for e.g. Texas Instruments RS422 to get directly to the correct page) and then check on Octopart etc if the part has sufficient stock quantities (at least 1k).

and, if searching on the manufacturer’s sites doesn’t yield any suitable result, search on DigiKey, Mouser and Farnell for other (typically smaller) manufacturers or different models that you might have missed.

In my case, I identified the Maxim MAX22508E as an excellent choice, since it supports high datarates up to 50 Mbps (leading to slightly more EMI but also possibly better signal integrity since the eye patterns is more open when using a much faster transceiver, leading to more accuracy in detecting the timing of the flank, leading to lower error rates). While it is somewhat expensive (2.50€/pc at small qtys), this is fine for many laser applications.

Oct

2021

Does the i.MX RT1060 / Teensy 4.x support Bit-Banding?

The i.MX RT1060 is a Cortex M7 microcontroller. Cortex M7 microcontrollers do not support bitbanding. Hence, the i.MX RT106x series (including the Teensy 4.0 and 4.1 boards) do not support bitbanding. See this ARM forum post for more details.

Oct

2021

How to enable Teensy 4.x GPT timer in free running mode

In this example, we’ll use direct register access to enable the GPT1 timer module at 8 MHz counter frequency in free-running mode. Free-running mode means that the timer will just roll over once it has reached 0xFFFFFFFF (maximum 32 bit value).

How to configure the timer

CCM_CCGR1 |= CCM_CCGR1_GPT1_BUS(CCM_CCGR_ON); // Enable clock to GPT1 module
GPT1_CR = 0; // Disable for configuration
GPT1_PR = 3 - 1; // Prescale 24 MHz clock by 3 => 8 MHz
GPT1_CR = GPT_CR_EN /* Enable timer */
  | GPT_CR_CLKSRC(1) /* 24 MHz peripheral clock as clock source */
  | GPT_CR_FRR /* Free-Run, do not reset */;

Full example

This example works in PlatformIO without any external libraries, but you need to set monitor_speed = 115200 in platformio.ini so the serial port is read at the correct speed.

#include <Arduino.h>

void setup()
{
    // Setup USB serial port so we can print the timer value
    Serial.begin(115200);

    // Enable timer    
    CCM_CCGR1 |= CCM_CCGR1_GPT1_BUS(CCM_CCGR_ON); // Enable clock to GPT1 module
    GPT1_CR = 0; // Disable for configuration
    GPT1_PR = 3 - 1; // Prescale 24 MHz clock by 3 => 8 MHz
    GPT1_CR = GPT_CR_EN /* Enable timer */
      | GPT_CR_CLKSRC(1) /* 24 MHz peripheral clock as clock source */
      | GPT_CR_FRR /* Free-Run, do not reset */;
}

void loop()
{
    // Print the timer count every ~100 ms
    Serial.println(GPT1_CNT);
    delay(100);
}

Oct

2021

Teensy 4.1 interrupts at multi-MHz speed using TeensyTimerTool

As shown in our example Teensy 4.1 PlatformIO 2MHz Timer interrupt GPIO output you can use TeensyTimerTool to generate multi-MHz timer interrupts. In our experiments, we could generate GPIO-toggling interrupts up to 4 MHz:

The trick here is to use std::chrono time literals. The TeensyTimerTools PeriodicTimer example only shows us how to use microsecond resolution:

t1.begin(callback, 250'000); // 250ms

but we can simply use 250ns to obtain nanosecond resolution:

t1.begin(callback, 250ns);

Here’s our observation what works and what doesn’t:

Multi-MHz GPIO-toggling interrupts as shown in our example only work on GPT1 and GPT2, they do NOT work on PIT and TMRx. We did not investigate the precise reasoning behind this, and there might also be ways to
As usual, the interrupt must only contain a small number of instructions. We’re using digitalWriteFast(), but using direct register access would be even faster.

Oct

2021

Teensy 4.1 PlatformIO 2MHz Timer interrupt GPIO output

The following PlatformIO example uses TeensyTimerTool on the Teensy 4.1 to run a simple GPIO toggle interrupt at 4 MHz interrupt frequency (i.e. the interrupt is being run 4 million times each second), resulting in a 2 MHz GPIO output:

#include <Arduino.h>
#include <TeensyTimerTool.h>
using namespace TeensyTimerTool;

PeriodicTimer t1(GPT2);

void callback() // toggle the LED
{
    digitalWriteFast(33, !digitalReadFast(33));
}

void setup()
{
    t1.begin(callback, 250ns);

    pinMode(33, OUTPUT);
}

void loop()
{
}

platformio.ini:

[env:teensy41]
platform = teensy
board = teensy41
framework = arduino
lib_deps = luni64/TeensyTimerTool @ ^0.3.5

The 2MHz output looks like this on the oscilloscope:

Oct

2021

Where to find Pin number to GPIO number mapping for Teensy 4.1

The TeensyDocuments repository provides a full Teensy 4.1 pin map complete with GPIO numbers. The list is also available as XLSX.

For example, pin 33 is listed as GPIO4.7 in said pinmap.

Oct

2021

How to convert PlatformIO firmware with build offset to firmware without

Some firmwares are build with a build offset to accomodate flash space (like 32k – 0x8000) for a bootloader that is started before the firmware. One of the downsides of using such a firmware is that it always depends on a compatible bootloader to be present (compatibility is mostly defined by how much flash is allocated for the bootloader)

If you want to convert a firmware to a “normal” non-bootloader firmware, this is what you’ll have to do:

Set board_build.offset to 0x0 – look not only in your build configuration in platformio.ini and all included files, but also look in the configuration that your config extends, if any.
Set board_upload.offset_address to 0x0. This mostly affects uploading with a debugger, but you should always keep this information consistent because debugging that is a huge nightmare.
Edit the specific linker script your firmware is using and set the flash offset appropriately:

Look for the MEMORY section like this:

MEMORY
{
FLASH (rx)      : ORIGIN = 0x8008000, LENGTH = 512K
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
}

As you can see in

FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 512K

the flash for this STM32 (example) is not at the MCU’s flash address 0x8000000, but at 0x8008000 – basically, the linker is told to skip the 0x8000 (32k) the bootloader occupies (else, it would overwrite the bootloader.

Change this to your MCU’s flash adress. For ARMs like the STM32, this is typically 0x8000000.

Now recompile and your firmware should work without the bootloader.

Oct

2021

How to hide all boot text & blinking cursor on Raspberry Pi

In order to hide all the boot messages (including the terminal) and the blinking cursor on the Raspberry Pi, edit /boot/cmdline.txt and first change

console=tty1

console=tty3

After that, add the following to the end of the line:

 loglevel=3 quiet logo.nologo vt.global_cursor_default=0

Now you can reboot and enjoy the clutter-free experience.

Oct

2021

How to change OctoScreen minimum extrusion temperature

Problem:

When trying to extrude low-temperature filaments using OctoScreen, you will see this error message:

The temperature of the hotend is too low to extrude. Please increase the temperature and try again

By default, OctoScreen has a minimum extrusion temperature of 150°C which is fine for PLA, but for some low temperature materials you need to change the hardcoded value.

Note that setting you minimum extrusion temperature too low might damage or even destroy your extruder, if the material is not properly melted. So take caution in setting the correct value here.

Solution:

Open utils/tools.go and edit this line:

const MIN_HOTEND_TEMPERATURE = 150

Just set your desired temperature and then recompile (see the OctoScreen README on how to do that)

Note that often the firmware (like Marlin) has a separate cold extrusion prevention limit, so you need to change the limit in both OctoScreen and the firmware. For Marlin, see How to disable Marlin cold extrusion prevention via G-Code.

Oct

2021

How to auto-reset Marlin after Kill

Under certain critical circumstances like thermal runaway protection, Marlin entered a killed state. You typically need to hard-reset the mainboard after entering that state. However, in environments where physical access to the machine, hard-resetting Marlin is not possible, so you might need to implement.

Note that diagnosing & fixing the underlying issue that caused the reset is extremely important and ignoring it might lead to further issues, up to a fire hazard or the destruction of the printer. So be sure to know what you are doing before just.

The following guide was tested with Marlin 2.0.9.1. It should work with most Marlin 2.x versions with minor adjustments.

First, note that as an alternative to hard-resetting the mainboard there is the SOFT_RESET_ON_KILL option which allows you to trigger a soft reset out of kill mode using a button connected to a pin. We won’t delve into more detail on this, since it doesn’t really change the requirement for physical access to the printer.

Open Marlin/src/MarlinCore.cpp and find the minkill(bool) function.

At the end, this function contains a preprocessor-controlled branch of the following structure:

#if EITHER(HAS_KILL, SOFT_RESET_ON_KILL)
  // Branch 1 ...
#else
  // Branch 2 ...
#endif

We will replace this entire branch by these lines:

// Wait for 5 seconds for controller to catch up
for (int i = 5000; i--;) { DELAY_US(1000); watchdog_refresh(); } // 5000*1ms = 3s
// Auto-reset after kill
HAL_reboot();

I prefer to insert the 5-second delay into the reboot logic so no superordinate controller (like a Raspberry Pi running OctoPrint) can miss that the Marlin board has been killed. Although most controllers should be able to detect the killed state from the G-Code, this 5-second delay will simulate the default behaviour of not resetting at all after the killed state has been reached. However note that in case you absolutely need to reset ASAP after the kill state has been reached, it’s typically safe to omit the wait loop.

Complete platformio.ini example

Problem:

Solution:

Now you need to completely remove the .pio folder from your project directory in order to ensure a clean build:

Problem:

Solution:

Problem:

Solution:

Now you need to completely remove the .pio folder from your project directory:

Complete platformio.ini example after fixing the issue:

Problem:

Solution:

Complete platformio.ini example:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

How to configure the timer

Full example

Problem:

Solution:

Search

Categories

Complete `platformio.ini` example

Now you need to completely remove the `.pio` folder from your project directory in order to ensure a clean build:

Now you need to completely remove the `.pio` folder from your project directory:

Complete `platformio.ini` example after fixing the issue:

Complete `platformio.ini` example: