0

I'm quite a fan of the STM32G030x6/x8 "line" since it is small and fits most of (my) needs as a more modern replacement to the Arduino platform built around the 8-bit Atmel/Microchip micros.

However when it comes to developing software for it, I'm struggling a little bit because my goal is to have a small bunch of files which can be easily compiled and do not depend on many "tools". And currently I don't know how to achieve it.

With the ATMega328 (Arduino Uno) I just create some C- & H-files, write my code and it compiles then. My experience with the STM32xxx is that it is much more complicated:

  • Using CubeMX there are two ways for "small projects" but the resulting project consists of many files and loads of comments inside the files which makes up for a feeling of a humongous file and the API documentation is not that great, approx. 4 MB+ in size
    • Using HAL, and toolchain "Makefile"
    • Using LL, and toolchain "Makefile"
  • Using libopencm3 the documentation is better, it has much more files, approx. 17 MB+ for an empty, compiled project, but it contains many unused stuff (not in the final build obviously) and getting it to compile is not that easy (depends on how well you know Makefiles) for example in a easy folder-based environment
  • Using tinygo the development environment is nice but the documentation is not that great yet (for example: try to find out how to set a specific GPIO pin) and it seems that it more targeted at a DIY/Maker users which have not a deep knowledge in C or don't want to mess with it so the API is created much more high-level

Does anybody know of simpler alternatives?

mythbu
  • 167
  • 7
  • Have you tried standalone GCC toolset? The real issue is of course complexity of the IO, but it all depends on what you're controlling. – jonathanjo Apr 08 '23 at 06:51

2 Answers2

0

If you look into packages installed for every Arduino board you will find hundreds of source files specific for the board. There are probably more of these files than installed for specific STM32 chip by CubeIDE.

The reason development on Arduino is so simple and your code seems so small is that the framework hides hardware from you and puts libraries into separate folder. Furthermore, while trying to achieve code portability, they sometimes restrict functionality to lowest common denominator that can work on all supported chips.

So, if your "goal is to have a small bunch of files" then you should stay with Arduino platform, especially since STM32-based Arduino is already available.

Maple
  • 11,755
  • 2
  • 20
  • 56
  • Maybe I didn't formulate well: I meant ATMega328, which you can develop for together with avr-gcc with only a hand full of files. That Arduino as a platform ships with many abstractions, e.g. the Wire/SPI/... library, is totally clear. But the complexity introduced by them is not "visible" (as you also stated), because they make the frontend so easy to use. The statements like "PORTC |= (1 << PC0);" make it then so easy & performant to use it "bare-bone". I was just generally wondering if there is another way than the three I found. I like stuff to be small and neat :-) – mythbu Dec 18 '21 at 22:37
  • 1
    if you compare the datasheet of the mega328 with the user manual of the stm32 device, you'll see a significant difference in the number of pages. A simple peripheral like the GPIO on the mega328 has two basic registers- DDRx and PORTx, whereas the STM32 will have a plethora. Libraries like CubeMX seek to abstract the complexity into a simple API. As well, it provides a common interface to a number of their STM32 devices where the GPIO peripheral might have significant differences. There is nothing to stop you from accessing the peripheral directly but be prepared to read the documentation. – Kartman Dec 19 '21 at 00:21
  • @mythbu You are looking in the wrong place. The libraries like Wire are high level abstractions. But they are built on top of core software, located in various folders, like "packages", "cores", "bootloader" etc. For example, nRF52 board definition alone has 32MB sources in over 600 files. All that is necessary to build your "small and neat stuff". – Maple Dec 19 '21 at 01:30
0

If you have simple IO requirements, perhaps the ARM GCC toolchain suffices for what you need. You end up with a straightforward commandline gcc, suitable for generating code for "bare metal" ARM processors. Perhaps this is what you need:

enter image description here https://developer.arm.com/Tools%20and%20Software/GNU%20Toolchain

jonathanjo
  • 12,049
  • 3
  • 27
  • 60
  • The CubeIDE already contains gcc compiler. The point was to figure out a small "framework" how to make short programs fast. Armed with a bare compiler, it has no support for the peripherals, so you as the user must read the register manuals to initialize the MCU and each peripheral in order to use them. So that part is long to write which is why the frameworks and libraries exist. – Justme Apr 08 '23 at 07:27
  • Respectfully, the question asks about minimising tools ('my goal is to have a small bunch of files which can be easily compiled and do not depend on many "tools"') not on making programs quickly. I **completely** agree about the massive complexity of the IO. If you're just doing a little bit of GPIO, however, the gcc toolset can be pretty minimal. Hence the beginning of my answer "**If** you have simple IO requirements ..." – jonathanjo Apr 08 '23 at 07:33
  • The question asks "more smaller and simpler library for software development than HAL/LL/libopencm3/tinygo", which are not tools. You can have one tool, CubeIDE, and you can develop and debug HAL/LL programs out of the box (it does some file fetching for you), but HAL and LL consists of many files and complex include/source folder structure even if you only need to init the MCU and blink a LED. You can write no library programs as well, but you need to find everything yourself, including startup assembly code and linker scripts for your MCU, before you can start poking around registers. – Justme Apr 08 '23 at 07:39
  • @Justme I completely agree, it's a lot of work. It does have a very small toolset footprint, however, and for some developers that is important. – jonathanjo Apr 08 '23 at 07:48