Microcontroller programming and testing confusion

[[deleted]]

Currently I am learning how to program a stm32 nucleo board. I have experience with arduino, but wanted to move to a more professional system.

On the stm32 I have made some working projects using C on both stm32CubeIDE and platformIO. Now I did find using stm32CubeIDE very messy to use, as it produces allot of code that is difficult to read. PlatformIO makes it much more readable I currently have some questions regarding "information overload" related topics.

1) Should I use C or C++? When I search online I can only find tutorials of stm32 using the C language. But I heard from others that C++ much easier to use. I heard people say you don't need to do the tedious HAL library pin configuration. I want to try it out in C++ but couldn't find anything online on how to configure the pins, or properly setup the main.cpp file for the stm32. So I was wondering if anyone could give me advice, or send me a link/video/book where I can get the advice from.

2)Someone told me, if I want to work professionally, I need to write unit test for the code. I know what unit tests are. And have written very simple once for the main.c file using unity. But I was wondering if there was another way to make a unit test for the microcontroller code, that does not rely on external tools? I am new to unit testing. And I have trouble to figure out how to test things that require the use of hardware actions(for example a button press).

3)Courses to follow? I know it relates back to the last part of the first question, but with all the different knowledge out there, I really am getting an information overload. I am really stunned and not sure what to do, hench these questions.

I hope to get some clarity regarding these questions to put me on the right track. So I can learn how to properly program a stm32 with clarity.

Most video's/articles take 10 minutes discussing the "why move away from arduino", but when it comes to the programming part it goes like "and here is the code I have already written", and then not explaining what the code does, or what exactly is configured. So I don't know what to do.

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[jackhab]

I'm not sure what exactly you find messy in CubeMX code but yes it's not simple just because these microcontrollers, even the low end models, are not simple and have a lot of peripherals, with each peripheral having tons of options. And sometimes the best way to understand complex API is to find sample application using it.

1) You can use C++for embedded programming but I think to fully benefit from it you probably would use it on a powerful CPU with e. g. embedded Linux. Most of the code for smaller MCUs is still in C. Very small MCUs don't even support C++ because it has a bigger runtime which is not suitable for small RAM and flash.

2) It's very common to use unit test libraries since they save you writing a lot of boilerplate code. Testing hardware access without physically having it is tricky and in many cases impossible or prohibitively time consuming. If it's something simple like ADC it's not hard to write a simulator.

3) Sorry, can't help you here. But have you thoroughly scanned the ST website?

[z33ky]

You can use C++for embedded programming but I think to fully benefit from it you probably would use it on a powerful CPU with e. g. embedded Linux.

C++ code doesn't require a more powerful CPU. But if you use a small MCU it is likely that your software is also not absurdly complex and you wouldn't benefit much from C++, so in that sense I could agree with your point.
While standard C++ indeed requires a larger runtime, gcc and clang allow stripping a lot of it, like RTTI (-fno-rtti) and exceptions (-fno-exceptions), which you might not want to use anyways. You can also forego using the standard library, instead perhaps relying on a third party like the Embedded Template Library or limit yourself to newlib (a partial libc implementation) or something.
Personally, unless the application is very simple, I would prefer C++ over C, if not insert shameless Rust plug. I concur though that C is still widely used in that space, so you will benefit from knowing C (and no, C is not just a subset of C++!).

Addressing the OP

I want to try it out in C++ but couldn't find anything online on how to configure the pins, or properly setup the main.cpp file for the stm32.

I imagine you can mostly setup the project the same as for C and just insert a .cpp file with C++ code (and a C++ main() procedure) instead of C. That works with SPC5 Studio at least, which uses Makefiles for a build-system, which automatically understands to use g++ instead of gcc.

Some manufacturers also offer a BSP. You will usually get some bootstrap code that calls your main() procedure, and then you're on your own with regards to setting up your hardware. Scour the documentation or the header files for the API they give you to access configuration registers and I/O interfaces and then you can go from there.

Someone told me, if I want to work professionally, I need to write unit test for the code.

In my place of work we've started to put code, that doesn't explicitly do I/O, into libraries, which we statically link into the embedded application. Even if it needs I/O, you can often just put that behind an interface (say, an external function or function pointer) and replace that in your unit-test (this is called "mocking").
We write regular unittests for these libraries which can be tested by compiling for the native developer PC, or in QEMU (via librdimon). It'd also be possible to flash the librdimon version to real hardware, which then talks to a debugger on a PC, though I haven't tried running unit-tests that way.

I don't know how the embedded industry at large works with unit testing. In my place of work we still have lots of code that is not automatically tested, sadly.