Is 16kB of RAM realistic?

[davidgiven]

I have a device which I think would be cool to port Micropython to (it's a $2 smart watch based on an MCU from Telink). The only problem is that it's a bit anaemic when it comes to RAM: 16kB (although it's got 512kB of flash).

I know the docs say that Micropython will work on this, but it's that technically working or usefully working? How big of a program could I expect to run here? e.g this device supports BLE; should I just abandon any expectations of integrating the BLE stack?

[rkompass]

You can compare that to the Microbit 1.0 which also has 16kB of RAM.
Micropython works quite well on it (using a special mode of the interpreter for saving RAM). However regarding Bluetooth the docs say:

While the BBC micro:bit has hardware capable of allowing the device to work as a Bluetooth Low Energy (BLE) device, it only has 16k of RAM. The BLE stack alone takes up 12k RAM which means there’s not enough memory for MicroPython to support Bluetooth.

Working well, has to be added, means it is a useful resource to start to learn Python. Probably not much more.
I2C, SPI, neopixel and others work however (see the link).

[davidgiven]

Thanks, that's useful. This device does have its own Bluetooth stack with some configuration options to reduce RAM usage, but the docs don't have any actual numbers. I'll need to do some investigation.

Without any form of communication I suppose the thing's still fun to play with as a Python-powered smartwatch. BLE is its main party trick, though.

[mattytrentini]

I would argue that no, it's not realistic, at least not if you want a BLE stack.

Technically it may be possible, but you'll need to invest a lot of effort and cut out many parts of the system - and it still may not work...

[davidgiven]

I did a CORE_LEVEL port (aided by the fact that TC32 machine code is so much like Thumb assembly that I was able to port the GC and NLR stuff with a literal search and replace to change the instruction names! I suspect that the instruction encodings differ by maybe one bit, too).

The basic port, with just a REPL and the CORE features, reports 11984 bytes of free RAM.

Meanwhile, if I go over to some of my TC32 example programs and build the BLE example, I can see that it's using only about 3kB of data RAM, which is great... except it's also put the entire 10kB BLE stack into RAM meaning that there's absolutely nothing available. Turns out that this thing uses SPI flash with a bridge, and Telink decided that it was too slow for BLE so all the time-critical stuff gets copied to RAM. (Also, the flash bridge has a 2.5kB cache which has to be located in SRAM, which doesn't help.)

So this basically means that BLE is a dead loss. Which is a shame. Oh, well, looks like I'll be drilling some holes in the side of my $2 watch to get access to the UART pins...

Thanks, all!

[rkompass]

Seems you did the first port of Micropython to the TC32 architecture.
Are there processors out there that have more RAM?

[davidgiven]

I'm not sure I would consider it new, given that this thing is a Cortex-M0 with the serial numbers filed off... Telink produce similar chips with up to 64kB of RAM, but this is the most common one, a TLSR8232. http://wiki.telink-semi.cn/wiki/chip-series/TLSR823x-Series/ It's the one used by the ubiquitous cheap-and-nasty barely-functional fitness bands you can get from the usual sources. https://www.aliexpress.com/item/1005006745477397.html You get a tiny battery, an 80x160 screen, a single capacitative button, an accelerometer, a vibrator, a fake heartrate sensor that's just a blinking LED, and a fairly neat case. The built-in software is a dead loss.

Most of my work is based on this: https://rbaron.net/blog/2021/07/06/Reverse-engineering-the-M6-smart-fitness-band.html (Although I did write my own debug bridge on a Pi Pico as I couldn't make the STM32 one work...)

One interesting thing is that the TC32 compiler is a binary-only download from Telink, despite being gcc-based. Hmmm...