STM32 with small flash + HAL + DEBUG + no Optimization...

[LCE]

... leads to "funny" results:

STM32L011 with 16 kB of flash, HAL inits and LED toggle in main, DEBUG, no optimization:

93% of flash used

I had not expected it to be that bad! :grinning_face_with_sweat:

Okay, I will probably not use too much HAL, will use Release version with optimization,
but I better select an L01 in the next bigger QFN package (4x4) to get 32 kB of flash.

[LCE]

Okay, I'll check that.

I'm far from being a software guy, still have more experience with 8-bitters and FPGAs than with STM32...

[waclawek.jan]

> still have more experience with 8-bitters

And do you use modern development environments together with clicking configurators and abstraction libraries with the 8-bitters?

While I don't have first-hand experience with these, I'm quite confident these days you can find some of these being capable of filling up the FLASH of a low-end target mcu quite safely, too.

It's 21st century, after all.

JW

[Andrew Neil]

---

@waclawek.jan wrote:

While I don't have first-hand experience with these, I'm quite confident these days you can find some of these being capable of filling up the FLASH of a low-end target mcu quite safely, too.

---

You certainly can - just take a look at  Atmel's  Microchip's ASF stuff for the AVRs ...

And, again, there's the C runtime - just a printf() is a great way to fill a small micro's Flash.

Or some floating-point ...

[BarryWhit]

Also note that CubeIDE by default compiles/links with --gc-sections as an "optimization". I bet without that flag being on by default, the skeleton binary wouldn't even fit in flash...

That said, engineers usually pick these tiny parts either  for high-volume cost-sensitive applications, or because they to want to use the smallest package possible. I think it's a reasonable compromise to do development and debugging on a beefier partnum from the same family, and then shoehorn the release version into the cheapest part number that will do, for actual production. There's some risk involved in this approach, but it makes sense if you're working under certain kinds of constraints . 

[Tesla DeLorean]

The 16KB part is pretty tight, especially with the float library pulled in.

For the L011 there's likely a drop in C0 or G0 that can maintain a small package with larger memory.

STM32C011F6U6TR
IC MCU 32BIT 32KB FLASH 20UFQFPN (3x3 mm)

[LCE]

Atmel's AVRs were my main MCU over the last 20 years or so... surely never used something like HAL or a library. :D

Having recently worked so much with the H7, I thought I'd try a small STM32, because for that project I would have taken a (for us) new AVR, so I could go STM32.

Anyway, I chose the L03 with 32 kB flash. And I love the Nucleos...

Firmware's almost done, I only use LL stuff for clock setup and ADC, otherwise direct register, no float for printf.

Biggest chunk in flash is now my standard debug UART interface with lots of const char strings for printf, but I'm far from the 32 kB limit, using size optimization though.

[BarryWhit]

> Biggest chunk in flash is now my standard debug UART interface with lots of const char strings for printf, but I'm far from the 32 kB limit, using size optimization though.

I was sure something like this existed, and I was not disappointed:

https://github.com/atomicobject/heatshrink

purported foorprint of decoder is about 1K flash + 100bytes RAM (min, your can ram usage for decoding speed).

(Update: also found Segger SMASH. I'm sure others exist. It's an obvious idea.)

If you have enough low-entropy data, it might provide a net gain. One approach to making the most efficient use of small controllers is to trade what you have in excess to get some more of what is scarce. Can you give away some SRAM to gain some Flash?

[Tesla DeLorean]

I've tried to migrate us from old SiLabs 8051's where possible, I need something for basic initialization / customization. Typically needs to be physically small, but workable, so BGA and WSP generally not favoured by the crew in PCBA, or the more costly PCB

The 16KB L011 worked well until feature creep set it, people wanted configuration and diagnostics for production, bit too tight, 32KB would have more headroom as all the libraries took their bite from the first 16KB

[Tesla DeLorean]

Frequently SMALL is what I want, the 3x3 QFN20 is perfect, ST's not had a good game here, TTSOP20 is just too massive, and honestly I don't have the space-time to prototype with larger parts, nor have to deal with higher costs/complexity of PCB and BGA with pin-in-pad issues (fill and planarization). People demand boards the size of a postage stamp, not a post card.

MAXIM had some very small CM4F with relatively large FLASH, 96MHz, 256KB/96KB, 4x4mm, overkill for my application for sure, but demonstrative of what the right process/geometry can deliver, beyond CM0(+). This is how you exorcise 8-bit MCU, not by barely replacing them, or forcing a redesign into 3V3. When you can pivot into a order of magnitude more effectiveness the choices/decisions get a lot simpler for the guys with bigger hats.

[Andrew Neil]

---

@LCE wrote:

Atmel's AVRs were my main MCU over the last 20 years or so... surely never used something like HAL or a library. :D

---

The newer AVRs are getting more complex peripherals - more akin to XMega & SAM - hence the arrival of ASF for AVRs.

But, indeed, for the "classic" AVRs of decades ago, it's a waste.