Skip to main content
E
EvO
Associate II
October 23, 2024
Solved

Project organisation in CubeIDE - how to go about libraries

  • October 23, 2024
  • 3 replies
  • 2795 views

Background: most of our development so far has been with AVR and cmd line based, using make files for testing. We only ever used IDE's for compiling for target and uploading: Arduino IDE for prototyping with bootloader and MpLab without bootloader for production hardware. We are now transitioning some hardware to STM32 and plan to do any new developments on that platform.

The issue we are running into is that the integration of all hardware initialisation in the main.c file is different from the existing code: libraries with hardware interaction have all platform-specific code in separate c/h files. 

For example, a module that uses EE may have a writeEE and readEE function that are defined in 2 separate c files, e.g. atTiny402EE.c and atMegaEE.c. On an STM32 without internal EE, we will use external EE, so we will need functions that are in must cases only wrappers around HAL_I2C_Mem_Read(), etc.

My question is: where should this live?

  • inside the main.c file? : I prefer not, because that will become way to big, although initialisation(MX_I2C1_Init) is placed there automatically by the device config tool
  • in a separate source file inside the project folder (where)? : I prefer not, because the exact same file will probably be needed in other projects - as the HAL function is identical for multiple STM32's (is it?). If this is the way to do it, in which folder should it live? 
  • in a separate project? if so, if I start a new "C Project" and select "static library", I am asked to select the toolchain and end up in the device configuration tool: which is exactly what I am trying to avoid - this should be generic (because it should only be compiled when compiled/linked by the include in the abovementioned main.c)
  • as a separate source outside any projects in some custom folder in the workspace? in this case, what headers do I need to include for this to compile?

Or some other way? I probably completely mis the point of the organisation of the STM project / main.c file, but I am used to working with small files with narrow scope and I try to avoid duplicating code between projects at all cost...

Is there some documentation about project organisation / STM32Cube philosophy that I have missed?

Best answer by Andrew Neil

Note that there is an Arduino core for STM32:

https://www.stm32duino.com/ 

https://github.com/stm32duino

 

@EvO wrote:

the issue we are running into is that the integration of all hardware initialisation in the main.c file is different from the existing code: libraries with hardware interaction have all platform-specific code in separate c/h files

You can configure CubeMX to generate separate .c/.h files:

AndrewNeil_1-1729671841098.png

If you're familiar with the Arduino setup() and loop() structure for your user code, that can easily be achieved in the Cube-generated structure as:

AndrewNeil_3-1729672411085.png

 

That way, you can leave all the generated code alone - much as you never see Arduino's main() - and just work in your own files with your setup() and loop() functions ...

 

#ArduinoSetupLoop

3 replies

Andrew Neil
Andrew NeilBest answer
Super User
October 23, 2024

Note that there is an Arduino core for STM32:

https://www.stm32duino.com/ 

https://github.com/stm32duino

 

@EvO wrote:

the issue we are running into is that the integration of all hardware initialisation in the main.c file is different from the existing code: libraries with hardware interaction have all platform-specific code in separate c/h files

You can configure CubeMX to generate separate .c/.h files:

AndrewNeil_1-1729671841098.png

If you're familiar with the Arduino setup() and loop() structure for your user code, that can easily be achieved in the Cube-generated structure as:

AndrewNeil_3-1729672411085.png

 

That way, you can leave all the generated code alone - much as you never see Arduino's main() - and just work in your own files with your setup() and loop() functions ...

 

#ArduinoSetupLoop

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    E
    EvOAuthor
    Associate II
    October 23, 2024

    Thank you Andrew, that really helps. Especially the Code Generator bit. I will still have to duplicate some boiler plate code between projects, but at least there will be specific places where to put the wrappers. This should be the default IMHO.

    I wasn't after replicating anything arduino-like and the setup / while(1) structure is already in the STM main.c, so that was good enough for me, as those are are only calling a single function each in my case. Also I wasn't after using ArduinoIDE to manage the STM projects (and miss out on debugging).

    Your 2nd msg about the project structure was also very useful, I did not come across any of that in the documentation.

    Andrew Neil
    Andrew Neil
    Super User
    October 23, 2024
    @EvO wrote:

    I wasn't after using ArduinoIDE to manage the STM projects (and miss out on debugging).

    Current Arduino IDE supports debugging - doesn't it?

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    Andrew Neil
    Andrew Neil
    Super User
    October 23, 2024

    The standard project structure that CubeIDE generates is:

    AndrewNeil_4-1729672683038.png

    • Binaries contains the generated project binary - usually a .elf file
    • Includes is auto-generated
    • Core contains your project-specific generated source - including the main() function in main.c
    • Drivers contains the standard HAL drivers
    • Debug contains various intermediate build output

    I would create a separate folder for my user code - at the same level as Core.

    But you can structure your projects entirely as you wish.

     

    CubeIDE documentation: 

    https://www.st.com/en/development-tools/stm32cubeide.html#documentation

    Wiki: 

    https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:Introduction_to_STM32CubeIDE

    Training videos: 

    https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32CubeIDE_basics_MOOC.html 

     

    #CubeIDEProjectStructure #FolderStructure #ProjectStructure

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
      Andrew Neil
      Andrew Neil
      Super User
      October 23, 2024
      @Andrew Neil wrote:

      I would create a separate folder for my user code - at the same level as Core.

      For example:

      AndrewNeil_0-1729673369159.png

      In this case, my user code is in the 'common' folder

      (I called it "common" because it is common to several projects: details here, if you're interested)

      A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
        E
        EvOAuthor
        Associate II
        October 23, 2024

        There is an icon, but it is greyed out and when I hover over it, it sais "Debugging is not supported by 'Arduino Mega or Mega 2560'. Same for a few other chips, so I have never used it. MPLab does support some debugging which has come in helpful before.

        Generally I don't need much debugging on target HW because everything is under TDD, except for hardware-specific stuff. I hope using the HAL libs will do the rest :)

        Terms & ConditionsAccessibility statement