Using PlatformIO on a Copilot device

Guess where I took this

I’m liking my Copilot laptop. Today I loaded it with Visual Studio Code and then tried to do some embedded stuff with PlatformIO. And I hit a snag. The problem is that PlatformIO notices that the computer is powered by an ARM processor and then tries to use ARM versions of all the software it brings in. This does not end well. The compilers I want to use for the ESP processors are only available for Intel X86 processors. The solution to this is to tell PlatformIO to use Intel/AMD for everything by creating the following environment variable.

PLATFORMIO_SYSTEM_TYPE=windows_amd64

Search for “Edit Environment variables” and then open the Systems Properties dialogue to do this. Then add the environment variable above, reboot your machine just to be sure everything can see it and then everything works. This means that PlatformIO will run slightly more slowly because it is now running on an emulated processor, but it still seems pretty sprightly to me.

Debug ESP32/ESP8266 programs in PlatformIO using the exception decoder

This is the prototype. I think I need to make a PCB for this..

I’ve been hard at work adding RFID abilities to Connected Little Boxes. It’s going mostly OK. It worked first time, which I hate because it means that the pain comes later. And it did, in the form of random crashes. The program would run for a while and then reset with an exception. The ESP devices produce a lump of debug output when they fail, but you then have to decode this text. The great news is that this behaviour is built into PlatformIO, the wonderful tool that I’m using to make the application. All you have to do is add the following line to the platformio.ini file in your project:

monitor_filters = esp8266_exception_decoder

The serial monitor will now look for the messages that mark the start of the debug information and then use the build file to tell you where the program was when it fell over. Very useful. In my case it allowed me to determine that the program was failing in WiFi code, not something that I wrote. Of course, even though it is not failing in my code, I still have to fix it. I have two golden rules when debugging embedded code:

1. First check the power supply.

2. Second check the memory allocation.

In this case the power is OK, so the problem must be memory. I thought I had enough free memory for the system keep going but this turned out not to be the case. I freed up a bunch of space and the device has been running solidly ever since.

Strings and C++ Warnings

When I build code I try to work in a “zero warnings” mode. That is, when I build the code I don’t see any mutterings about stuff the compiler thinks might think is stupid. However, sometimes I get warnings that I don’t think I deserve. For example, I tend to do things like this:

char * name;

name = “Rob”;

I know what I’m doing here. I’m creating a character pointer and then making it refer to a string literal. It’s how big chunks of the control code for my “Connected Little Boxes” work. In the land of C it is OK to do this (- at least I think it is). However, C++ is now all grown up, has a String type and thinks it’s OK to moan at me for doing this.

I’ve got round the problem by telling the compiler to ignore this particular warning:

#pragma GCC diagnostic ignored "-Wwrite-strings"

This is an instruction to tell the compiler disable that specific warning. The -Wwrite-strings bit is how I tell the compiler the warning that I want it to ignore. I did a bit of soul searching before I added this statement. Most of the time I really want to know if I might be doing something stupid. But I reckon this is a case of “greater good” in that it makes other mistakes more likely to stand out.

Using an M1 Powered MacBook to program ESP8266 devices

I’m loving my new M1 powered MacBook Air. The hardware makes a perfect laptop. It just works, goes very fast and is always there. The battery life is more like an iPad than a laptop. It doesn’t run Windows 10, so it isn’t perfect, but I’m slowly getting my head around Mac OS (WHY IS FOLDER NAVIGATION SO HARD???) .

I’m still using the Microsoft tools I use most of the time - Visual Studio Code, Word and PowerPoint all work perfectly. I’m using the Safari browser at the moment, but I’ll switch to Edge when they release a version that uses the M1 processor.

Anyhoo, I’ve been building code on the MacBook for my ESP32 and ESP8266 devices. As I reported a while back, there is a fault with the serial port auto-discover in the version of Python used by Platform IO (my embedded development environment of choice). I got round this by deleting some lines from the Pytool program that caused the error, you can find out more here. Then I hard-wired the name of the target device into my PlatformIO project.:

Mac OS uses Unix style names for its serial ports. If you want to find out the name of the port that your Wemos is plugged into you can use this command at the command prompt:

ls /dev/tty. usb*

This displays a directory listing of all the usb devices that are presently connected. My Wemos was called /dev/tty.usbserial-140. Yours will almost certainly be different.

upload_port = /dev/tty.usbserial-140

Once you know the port you can then add a line to the Platform.ini file to explicitly target this port when you deploy.

I’ve also discovered another issue; deploying a program to an ESP8266 seems to fail with a timeout problem. The best way to fix this seems to be by reducing the upload speed by adding this line to your ini file.

upload_speed = 115200

It takes a bit longer to deploy, but it does get there.