STC15W101 128 RAM, 1KB flash - limit code size?

[mightymos]

I have a STC15W101 mounted to a circuit board (sonoff door sensor). This chip apparently has 128 bytes of RAM, 1KB of code flash, and 4KB of EEPROM flash.

It appears that just gpio hal alone requires about 2KB of flash.

I did notice that gpio-hal.h defines the GPIO_HAL_H macro. It is stated that this macro greatly helps reduce flash footprint. However it appears to only reduce the flash size a few bytes. (by comparing flash size reported by .mem files)

I'm really not sure what type of overhead to expect for HAL.

Is there anything I can do to shrink usage but allow use of HAL? Or alternatively, with 8051 there's no keyword/macro to place functions in eeprom flash?

[area-8051]

The BASIC_GPIO_HAL removes support for the GPIO enhancements available on STC8 MCU, so it doesn't help with an STC15. I'll clarify this in the comment.

It is possible to run code from the EEPROM space because it's just emulated with flash memory. You may have to struggle a bit with the linker, but the MCU can do it, it is documented in section 2.2.2 "Software reset" of the STC15 technical reference manual (EEPROM space is referred to as the "ISP memory").

However, from my experience, 8K flash seems the practical minimum to have some room left for any decent application. From a RAM standpoint, 128 bytes will also probably be insufficient, 256 bytes is a minimum. I'll document this too. This means that with such a limited MCU, you'll have to do without a HAL.

Also, SDCC uses RAM for function parameters, and of course stack space, which means you might well bang your head against the wall trying to write any firmware in C. With such memory constraints, assembly becomes a sensible option, in line with the degree of complexity this chip is designed to deal with (no UART, no SPI, no PCA, no ADC, only 2 timers and 6 GPIO lines).

[area-8051]

Also, I don't know if you created a header file for the STC15W101, or instead reused an existing one. In the latter case, memory footprint is likely to be higher than needed, and you may want to try the following in your project-defs.h file instead:

define MCU_FAMILY 15

define MCU_SERIES 'W'

define MCU_PINS 8

define NB_TIMERS 2

include <uni-STC/stcmcu.h>

[mightymos]

I was able to use the headers as you advised (and delay routines). The board I'm flashing blinks LED at a specified rate so that's good. Only other need was toggling RF pin with Manchester encoding at a slow rate.

RAM usage is then about 48 bytes RAM and 504 bytes of FLASH.

I'll check out boot with ISP bit if/when time allows to hopefully gain 4KB code space.

In any case it's been nice to stick with C for now. 433 MHz RF transmission has not worked yet but still trying.

Thank you so much for the help.

[area-8051]

Thank you for your feedback, it's very interesting!

[area-8051]

I have added a header for the STC15W10x series and taken into account the fact that they don't have P5, so this should save a few more bytes flash in gpio-hal.

[mightymos]

Thanks this include was a little bit less typing for user than before:

include <STC/15W10x/DIP8.h>

With gpio-hal and delay support ram usage is about the same and flash is 1031 bytes. So nearly fits into 1KB flash maximum.

If RF works some day, can try further experimentation with HAL or 4KB code space.

[mightymos]

EDITED: I am waiting on the mail for more door sensor boards with STC15. In the mean time I am working on using EEPROM as code space.

I've seen that stcgal can program flash/eeprom hex files together. I've built an ISP bootload hex and blink hex for either space respectively.

I've familiar with needing to relocate ISR jump tables and functions for 8051 bootloaders. However I guess I'm struggling to understand how ISP behaves after restart and where I would need to put things (with linker).