DISTORTEC / distortos

object-oriented C++ RTOS for microcontrollers
https://distortos.org/
Mozilla Public License 2.0
430 stars 66 forks source link

Add configuration for STM32F0DISCOVERY #55

Closed mbohdal closed 3 years ago

mbohdal commented 3 years ago

Simple blinker works fine. Cannot verify distortosTest because it exceeds the flash size:

cmake -C ..\configurations\ST_STM32F0DISCOVERY\test\distortosConfiguration.cmake .. -GNinja
ninja distortosTest
[...]
arm-none-eabi-gcc-10.1.0-200517/bin/../lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/bin/ld.exe: test\distortosTest.elf section `.text' will not fit in region `flash'
arm-none-eabi-gcc-10.1.0-200517/bin/../lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/bin/ld.exe: region `flash' overflowed by 15920 bytes

After compiling MINSIZEREL it was still to big by 3168 bytes.

mbohdal commented 3 years ago

@FreddieChopin Do You have any idea what to do with the to big test binary? Can we disable some tests to make it fit? Or ignore this fact and add the new board anyway?

FreddieChopin commented 3 years ago

Hello and - first of all - thank you very much for your contribution!

Well, the failure to build this test application for this board is the reason why the travis-ci build also fails: https://travis-ci.org/github/DISTORTEC/distortos/builds/746436235 These build tests just try to compile every configuration found in the repository, so if any fails, the whole test is considered failed.

Generally even if you would make this test application use less flash memory (you could - for example - disable all run-time checks, assertions, thread detachment and signals), it would still fail to work, because it is not written for such a small MCU as the one found on STM32F0DISCOVERY board. I think that some time ago I was struggling to make it work with 16 kB of RAM, so with just 8 kB it is not going to work anyway. The test application frequently spawns up to 8 threads at once, with stack sizes up to 512 B, but with all the other elements of the TCB I would expect these 8 threads to use up all available RAM...

For now I see two options to solve this issue:

  1. just drop the distortosConfiguration.cmake file (but obviously still add the board!)
  2. modify travis-ci runner so that it could have a hardcoded list of configurations that are not built

I know that an example configuration for a board (with configured clocks and all that other stuff) is pretty convenient, but that's how the situation looks for now...

So maybe to make things simpler, you could modify your pull-request to NOT include this distortosConfiguration.cmake file, then we will be able to merge it, and then we can have some more time to discuss what to do with the configuration - whether to ignore it completely or use option nr 2 described above.

Let me know what you think!

BTW... To be really honest, a chip with just 8 kB of RAM is far from being a good platform for a multithreaded application. You can obviously fit a few threads if you stay away from all the RAM-hungry functions (like printf()), but it would be hard to do a lot of different things in such an application.

mbohdal commented 3 years ago

I removed the test configuration. I think You are right, this board is not useful for a full blown RTOS, but it is still usable, as I was able to at least do a LED blinker with two threads blinking two LEDs. So I wanted to contribute ;)

FreddieChopin commented 3 years ago

So I wanted to contribute ;)

Thank you very much for your pull request, I hope this was not the last one! (;