TaskManagerIO update, tcMenu 2.0 testing, mbed improvements

As promised last week, here’s an inflight update for this week. It’s been a busy week as we get further along in the preparations for tcMenu 2.0, and try to bring mbed further into the fold.

First of the bat this week was to fix the last of the bugs we knew about in tcMenu 2.0 development branch, so as far as we know, anything outstanding is now fixed, and we are ready to do the final testing!!

TaskManagerIO 1.2

We’ve finally got around to add that missing feature in task manager, to be able to schedule captured lambdas, but we can only do it on 32-bit boards, because there’s no support for it on some platforms. What does this mean, lets take a quick example below:

void setup() {
    int someValue = 42;
    taskManager.scheduleFixedRate(1000, [someValue]() {
        // someValue is available here - only on 32-bit boards
    });
}

Lighter lists and support for battery backed RAM on STM32

In IoAbstraction 1.8 we’ll support the battery backed RAM on STM32F4 and above devices as an EepromAbstraction. This means that it can be used directly with tcMenu just like any other EEPROM. The only thing to remember is that the values are cached just like ESP EEPROM class, so you need to call initialise(startingOffset) before use, and use commit() to make it write back to backed up RAM.

We’ve also backpedalled on list, it used to be a fully templated class, but this caused around 10-15K of additional code in tcMenu, even in production builds that were optimized. We considered this unacceptable and went about converting it into a semi template class, I’m pleased to say this has taken nearly all of that overhead away, leaving about 1.5K. It should be 100% compatible with any current usage.

Memory usage of tcMenu 2.0

We are still not 100% happy with memory usage in TcMenu 2.0, but for what’s essentially a skinnable UI, it’s still pretty good, although I think there is a very small amount of room for further improvement.

Memory usage, local menu on an Uno is still possible

You can still build a menu on an Uno, it takes about 24K of FLASH, and generally less than 1K of RAM. To do this just use a directly connected LiquidCrystal unit (such as DfRobot), and select the build for Uno option in code generator.

Below we now go into detail of the allocation for graphical boards with ethernet control, these are obviously much larger and deserve a breakdown.

SAMD, encoder, TFT, Ethernet

A moderate to large menu with graphical color display (AdaFruit_GFX), rotary encoder, and ethernet control(Ethernet2) on SAMD:

Actual production build size:

• RAM: 16.3% (used 5336 bytes from 32768 bytes)
• Flash: 30.5% (used 80032 bytes from 262144 bytes)

Debug build breakdown - these numbers are much larger than production and don’t match the above:

MEGA2560, encoder, Nokia5110, Ethernet

A fully fledged menu running on a mega 2560 with graphical display (AdaFruit_GFX Nokia 5110), rotary encoder and UIP Ethernet as follows:

Actual production build size:

• RAM: 39.7% (used 3250 bytes from 8192 bytes)
• Flash: 31.3% (used 79544 bytes from 253952 bytes)

Debug build breakdown - these numbers are much larger than production and don’t match the above:

STM32Fx framebuffer update

Unfortunately, the LTDC framebuffer support stays in BETA for now. There are some occasional rendering issues that look like either we are calling something with a bad parameter, or doing something that’s causing the framebuffer to misbehave, more on this once 2.0 is released.

Summary

So in summary a busy week so far, so much so that I need an extra mid-week update to avoid the weekly one becoming too big. Removing the template code shaved 10K off TcMenu, and looking around I think there’s another few kilobytes could be shaved off over time. There’s always going to be an overhead to using a general purpose library, but we want to make that as small as possible.