Creating a UI on a microcontroller: Part 8

This week I'm back working on my 'rod for my own back' project, ie. making a library to display a useful user interface over the UART of a generic microcontroller.

This week I've started on actually using it for its intended purpose, faking up a retro mainframe computer on ESP8266/ESP32. Trying to refactor my original code for this application to use the library has shown up a few of things.

First I was definitely right to pull out all the code and turn it into a generic library. Secondly it was missing a few features I need but thirdly and most annoyingly it still has lots of bugs.

In particular I had created lots of bugs with redrawing changing items or things that appear, disappear or change frequently. The main application is too complicated to troubleshoot with so I wrote this trivial alarm clock. You set the time and alarm with the +/- under each digit and when they match it turns red, rings the bell and a cancel button appears.

Trivial as this application is, it's really helped with the troubleshooting and I've added a load more functions, one of which changes the title bar of the terminal emulator, if allowed. It's all boilerplate, not fancy algorithms, but I still get a real sense of satisfaction in controlling an AVR Arduino with the mouse and keyboard on the computer it's plugged in to.

Here's a little video of it in action.

Nordic Semiconductor Power Profiler II - dead useful

 I have been playing with the Nordic Power Profiler again today. I'm doing some SD card benchmarks. Not for any real reason but I'm curious.

As well as the speed, I was interested in the power use. Here you can see writes (on the left) using more peak power than the reads (on the right). However, unexpectedly the writes use less overall power. I assume this is because the code I'm using leaves the card in a different state between reads. The writing does a file.flush(); inbetween each test, so I will investigate if this is what's at play.

This is exactly what I bought this thing for.

Also it's a bit like having a tiny bench PSU connected to your computer with USB. I have used it to replace a 3.7v LiPo battery, direct 3.3v supply to a microcontroller and 5v supply to a development board instead of USB.

I continue to be very pleased with it. Only grumble so far is the 'digital channel'  display only shows when looking at 3s or less of samples. If you're using pins on a microcontroller as a low speed 'status' indicator rather than for busier signals this is not helpful.

Espressif ESP32-S2-Saola-1R development boards

On account of wanting to assess the power use of the ESP32-S2, not long ago I bought a WROOM module programmer on Tindie, mostly because there's a dearth of the single core ESP32-S2 in the wild. Most Espressif powered boards either use the dual core ESP32 or are still using the ESP8266.

Like most manufacturers, Espressif have their own development boards, but they're not widely sold. The ESP32-S2 variant, the Saola-1, is actually very affordably priced, only ~£5 and on release I considered buying some but the postage from any of the stockists was double the board cost.

Given I was ordering something else already that took me over the free delivery threshold, I tacked a couple of these onto my order. Now I have some boards that are easier to work with than the module programmer, which is nice but not really breadboard friendly.

These official development boards are well made and 'just work'. They're reminiscent of the original NodeMCU, slightly too long for a mini-breadboard and with nice sturdy tactile buttons connected to the reset and GPIO0 for programming. Not that you'll need them, auto-reset/program works like you'd expect.

There's a lack of clutter, beyond a single WS2812 RGB LED, connected to GPIO18.

You can buy them in both WROOM and WROVER variants and with/without a PCB antenna. I picked up the WROVER as I want to experiment with using the 2MB of PSRAM. My plan is to use this for storing bigger data structures than most microcontrollers can deal with, mostly as a big cache of messages sent over my mesh network so that they can be 'retained' for a fixed time if a node is temporarily unreachable.

Nordic Semiconductor Power Profiler II

Given I've been doing a lot of work recently that involves assessing power consumption, I saw a timely video from Adafruit looking at the Nordic Semiconductor Power Profiler II.

I've been sticking cheap INA219 modules into my various stripboard prototypes and exporting data every minute over MQTT. These are great for broad, macro scale measurements over a long-ish period.

What they can't however do is measure down to the resolution needed to assess how efficient deep sleep is and whether changes to code reduce the time spent transmitting or waiting to receive data over WiFi. The former is very power hungry and must be minimised to save battery. The latter might be tuneable to help.

Professional equipment to do this is really quite expensive. The newly released Power Profiler II kit from Nordic is in the hobbyist friendly price range of ~£100. Mildly extravagant and you could perhaps roll your own but this price point is not ridiculous given the time you'd spend building the tool if you want it to work well. Which is why I've treated myself to my first new tool of 2020.

I've got one of my old macro spreadsheets to analyse for the ESP32-S2 WROOM module, but after that I'll be using the Power Profiler to delve deeper into how much power my prototypes are using and if there's anything I can do to improve this.

Solar charging ESP-Now BATMAN prototype 5

 After generating some good data on power use of the ESP8285, I've finally got around to sticking an ESP32S2 into the same board using a hand-soldered adaptor based around a programming board. The board has LEDs on but I can probably account for this extra load. Mostly I want to know a rough equivalent power usage.

With a little tweaking of the code it runs fine, so I'll conduct a charge test over 24 hours and see what the graphs look like. If it's promising I may be migrating the project to an ESP32S2 because of the extra pin count and resources. Squeezing an SD card slot in along with the connections to the charge controller uses almost every usable pin the ESP8285 has.

Also, while I don't want to include a USB FTDI chip on the board, a spot for an OTG USB connector is another matter as by itself it uses no power. It would allow my board to also run CircuitPython, which is quite popular and were I to stick some on Tindie broaden interest I think. It's also a nice 'desk charging connector' and the 5V could go straight to the charge controller. The added component count would only be the socket itself and a resistor I think.

In winter, this is what you resort to.

I've been doing more work with the MCP73871 charge controller today, initially playing with my bench PSU and taking readings from the INA219s I've built into the board to simulate varying amounts of available supply from solar panels.

This didn't quite work as VPCC reduces the load on the supply but as the voltage from my bench PSU isn't actually sagging it keeps reducing the current until it hits zero because the voltage never recovers.

With very little daylight on an overcast winter day I resorted to an old school halogen spotlight playing directly on some solar panels to test how it really behaves.

Starting out with a fixed resistor network for VPCC I could see that it was doing some form of load regulation but not what difference it makes as it varies, so this got changed for an old guitar potentiometer I had kicking around.

It's very tricky to set by tweaking the pot. As you change the VPCC threshold for the voltage from the panel it does change the load on the cell slightly but beyond a very narrow range, it stops charging.

Grabbing the data once a second I put this into a spreadsheet and did a scatter of the power provided vs the voltage from the panels, which is moderated by the VPCC threshold.

I'm no scientist but this seems to make it reasonably clear the best power was extracted from the panels when at about 4.5-4.7v under load. This is completely at odds with my initial thinking to set the VPCC threshold at or slightly under the nominal voltage of the panels I'm using, which is 5.5v.

Below about 4.4v we start running into the problem of there being not enough headroom above the battery voltage to allow for charging and it stops dead. More headroom could be had from a higher voltage panel, but then you start approaching the 7v limit on supply for the MCP73871, the highest I'd like to go is 6v.

I also visualised how the power is used over a day of real usage. Even when there is not enough sun to power the board, the panels support the battery, reducing the amount of power taken from it. This is exactly the behaviour I wanted from the charge controller. Anything 'negative' is where panels are powering the ESP8285 and charging the battery. Which now I look at it, feels pretty good for a winter day. The big spikes are when the sun came out briefly and made for a bright afternoon. It's the great stretch of darkness in the evening that really sucks the life out of the battery.

The main outcome of all of this testing is it's shown me that VPCC has little beneficial effect with the panels I have and had I set it by instinct it would have severely compromised charging. Bypassing VPCC and allowing the MCP73871 to draw as much power as it wants lands them in the 4.5-4.7v range which is where they appear to be most efficient anyway.

The other outcome is I have ordered some larger (165x165) 6v panels as all this was making me come around to the idea I just need larger ones. This may help offset things further so the dark evening doesn't leave such a charge deficit overall.

Interestingly during this testing when charging from USB I'm seeing one bit of behaviour that doesn't match the data sheet.

In the datasheet it says..

The MCP73871 device USB-Port current regulation set input (PROG2) is a digital input selection. A logic Low selects a one unit load input current from the USB port (100 mA) while a logic high selects a five unit load input current from the USB port (500 mA).

In practice with PROG2 high I see it max out at 400mA. No matter, I won't often see this as an issue with the little solar panels I expect to use in normal conditions.

Solar charging ESP-Now BATMAN prototype 4

After the last test run, I decided I wanted to investigate the supply load tracking feature of the MCP73871 charge controller to see if it improves charging. With a small solar cell in winter, it will be very easy for the charging circuit load to drag down the voltage from the cell such that it ceases to be of use.

In order to see how well this works you also really need a good measure of the voltage and current at both the battery and the charging input. Which means adding the INA219 modules back again after I took them out.

Having considered reworking the previous board it's just too untidy and with the SD card reader attached the ESP8285 doesn't have enough pins to go around. Using socketed modules allowed me to just make a new carrier board and swap them over. I also made a big effort at tidier wiring, the last one was offensive.

The supply load tracking feature on the MCP73871 is called Voltage Proportional Charge Control (VPCC) and reduces load to the supply if the voltage drops below a threshold. VPCC needs a simple voltage divider that provides 1.23v (or more) at a pin while the supply is OK. If this voltage drops, it reduces current draw to bring it back up. On the new board I've fitted a small socket header so I can fit different values to the voltage divider.

We're also getting to the time of year where it might go below freezing and the thermal protection circuit needs testing. So I've added another header for the thermistor network, temporarily bypassed with a resistor while I fiddle with the VPCC in isolation. I'm going to move my test location to near an indoor window where there's more sun for more of the day and hang the solar cell out of the window. Once I've investigated the practical worth of VPCC I'll add the thermistor network and do some tests with heating and cooling it.

Solar charging ESP-Now BATMAN prototype 3

After the component selection failure with my last solar prototype, I resolved to have another go.

This time, I decided to build as close an equivalent as possible on stripboard despite the presence of several SMD-only components. For this I needed a QFN20 breakout and with the buck convertor, I used one of the first boards I had made, cutting off the large empty sections. The QFN20 was not fun to solder but it works.

I'm glad I went through this step as it showed up a poor selection of GPIO pins for the connection to the MCP73871 charge controller. My very first prototype used an evaluation board and not all the connections are broken out on it. Moving the status connections to the ESP8285 did what I wanted but dragged one of the pins low and stopped it from booting in some states. This is one of those things that again I should have picked up from reading the datasheets, but didn't.

With a little shuffle of pins, the prototype is ugly but seemingly nicely functional so I've dropped it into the shed to test. Late November is a bad time for solar power in the UK, so it's a bit of a 'torture test' of charging viability. It's quite likely to fail as I've not put much in the way of smarts yet about when it sleeps or switches off the radio.

In the meantime I've bought an ESP32S2 module and breakout adapter from a Tindie seller. I may build a second prototype based around this as the S2 is like an ESP8266++ with Bluetooth support and lots more resources without seemingly much more power draw. The extra GPIO pins won't be unwelcome too, the ESP8285 has few and I've ended up re-using the UART pins. Not a big deal but it means you can't have Serial debug info with the charge controller working and you need to rely on OTA updates after an initial upload of the code.


This prototype ran for roughly 66 hours before the battery got low and it started sleeping in an attempt to allow the sun to charge them. That's plenty enough for my requirement of a full weekend's service.

However, from the logs it looks like it only spent 4 hours actively charging the battery, which is shockingly low even given its shady position in the low winter sun. As the MCP73871 only has three binary status indicators I don't feel I have enough data to be clear what contribution the solar panel was making to the runtime so I am going to modify this prototype and add an INA219 current monitor inline with the battery.