Arduino for STM32

Hi,
I recently compiled a Atmega328P code to a STM32G0.
I just changed the pins for the new hardware and build.

First try But then I realised:


Wow, using flash is so different! is it due to all uin8_t variables instead of uint32_t?
This is basically my first experience with STM32 and general embedded arm development.

Any suggestions for making this lighter?? I switched to STM32 to expand the code but after seeing this ...

Greetings,
Nicolò

using small flash / sram mcus say 4k sram and 16k flash say an m0, g0 etc would have quite various challenges running stm32duino.
that in part as stm32duino pack lots of 'standard' initializations and features/functions.
a possible way is to make a 'custom' core, that is 'trimmed down' in terms of functions/features etc.
it'd take quite some skills though which i'm not too good with either.

i think it is possible to examine the symbols compiled into the elf file, that is 1 step before compiling into a 'bin' file.
reviewing the symbols may give some hints to make that custom, heavily trimmed down core.

if possible use something like a stm32f401cc which has adequate ram and flash, this has adequate space (sram and flash), and it is pretty *fast* in part as it has the 'art accelerator' (on chip cache) and FPU.
I think there is the nucleo stm32f401 or f411 which is one of the supported boards.
https://github.com/stm32duino/Arduino_Core_STM32
there are also quite popular stm32f401/f411 'black pill' boards, try searching for them on aliexpress etc
https://stm32-base.org/boards/STM32F401 ... -Pill-V3.0
there are many more from the likes of adafruit
https://www.adafruit.com/product/4382
olimex
https://www.olimex.com/Products/ARM/ST/
etc. get those with adequate ram and flash

i'd think stm32f103c{b,8} (blue pill, maple mini (clones)) is 'doable' but somewhat cram.
and targetting very small mcus like those 4k sram and 16k flash, one would confront the challenges of putting too much into too little space.

I've choosed this IC due to the fact that I needed MCO/LSE output. I thought that flash and ram was plenty.
I wanted a cheap IC. I don't need a bluepill or a F4 with float acceleration.

The sketch above is mostly a I2C master slave implementation.
I think that I'll go back to AVR for next revision of the board if this is the flash usage...

hitech95 wrote: ↑Thu Nov 18, 2021 10:56 pm I've choosed this IC due to the fact that I needed MCO/LSE output. I thought that flash and ram was plenty.
I wanted a cheap IC. I don't need a bluepill or a F4 with float acceleration.

The sketch above is mostly a I2C master slave implementation.
I think that I'll go back to AVR for next revision of the board if this is the flash usage...

Flash usage is of-courses partially impacted by int16_t vs int32_t, but the chip architecture is significantly superior, thus more complexity. Complexity with any C++ compiler will translate to larger binary files.
There were recent discussions on this subject:

viewtopic.php?f=18&t=1071&p=7130&hilit=flash+size#p7130

viewtopic.php?f=14&t=1216&p=8033&hilit=flash+size#p8033

AVR (now Microchip) will exhibit similar flash-growth in sophisticated 32-bit varieties. The hardware drives the low-level core code complexity.


Ray

depending of you need you can disable or optimize some part of code on user side.
See the Wiki:
https://github.com/stm32duino/wiki/wiki ... tes-of-ram