Best development platform out of HAL/Bare Metal/RTOS/Other OS

[MVerm.2]

Hi

I have just startedworking on STM32 (STM32F407VET6 Board) and successfully implemented some basic LED patterns using the HAL drivers.

I would like to hear suggestions/advices on which software environment I should start developing my applications/projects which will be advantageous as a long term skill development.

I have researched a bit and the available options I found were:

1. STM32 provided HAL drivers
2. Free RTOS
3. MBED
4. LINUX
5. Bare Metal way
6. Any other OS/library/environment

Any advice will be appreciated. I am also open to work on multiple environments.

Thanks

[KnarfB]

On the long run, tools will change, libraries will change, chips will change.

What helped me throughout my engineering life

• profound knowledge of the C programming language and its translation to machine code
• knowledge of typical IO and communication principles and associated hardware
• ability to read data sheets, schematics and other docs for using them during software development
• knowlege of different OS including RTOS, their synchronisazion principles and alternatives
• measurement, debugging and similar bring-up techniques in the lab

Start with what you can cope with and never stop.

hth

KnarfB

[MVerm.2]

Thank you @KnarfB​ for the useful opinions.

[waclawek.jan]

Cube/HAL, mbed and Arduino are rapid development tools, providing quick results for a limited ("typical") group of problems.

C++, RTOS, Linux are frameworks helping to cope with extensive problems.

There's no One True Way in embedded. It all depends on the particularities of given problem. Knowledge never hurts.

As KnarfB said, the key is in everyday exercise.

JW

[MVerm.2]

Extensive Problems like what?

[Radosław]

only 2 and 5 option make sens.

[waclawek.jan]

>> C++, RTOS, Linux are frameworks helping to cope with extensive problems.

> Extensive Problems like what?

Mostly problems which are *rarely* present in what is the traditional domain of microcontrollers, i.e. hard-real-time controlling applications. Contrary, these problems are common in the domain of "large computers".

As the 32-bitters became packed with memories and running at multimegahertz clocks, the mere fact that you are using a single-chip mcu is not a good way anymore to distinghuish, which domain you work at.

Object oriented programmig is aimed at applications with a large number of, well, objects (think of struct in C), with repeating patterns (i.e. different structs have common parts, handled by the same or similar code), usually hierarchically organized. The canonical example is GUI. C++ mixes object-oriented programming with some other features (mainly syntactical, e.g. operator overloading) which are not strictly related to objects thus not "extensive", but to some developers they are much appealing.

RTOS is just repackaged pre-emtipve multitasking. This came around when people wanted to use timesharing on large computers, i.e. run simultaneously multiple programs which were not designed to run simultaneously. In mcus there are no multiple users, but one usually needs to run multiple tasks simultaneously. Writing tasks which are aware of that and allow cooperative multitasking (ie. don't need to be run under RTOS) means to have good understanding of state of the task; this is usually easy for typical tasks in controller applications, as they not only don't need to be complex, they must not be complex because of their purpose. However, writing tasks in cooperative way requires a certain mindset and skillset, and some programmers see that kind of programming to be tedious. RTOS are used as a convenience tool to allow to write tasks which don't need to be aware of other tasks. This convenience may be worth going for it; but not all that glitters is gold and RTOS, while they promise solving some typical problems, often exchange them for different ones. Typical example of a complex task written with cooperative multitasking in mind is the lwip networking stack. Typically, mass-storage drivers are not written in cooperative manner, so anything depending on them is mostly non-cooperative too. Another typical example of tasks not suitable well for cooperation are lengthy non-realtime arithmetic calculations employing large datasets (this again in mcu environment are typically GUI-related).

Linux is an extensive bundle of OS, drivers and a set of applications of various complexity. It provides a PC-like experience at the cost of hardware (which these days is incredibly cheap); however, forget realtime operation a.k.a. control. You may run Linux on something called mcu, but the name is deceiving there.

JW

[MVerm.2]

Thank you so much for this information.

[waclawek.jan]

> Which is not entirely true.

As no classification/definition in such a wide and volatile field can ever be. I always expect and enjoy being corrected. Als I know I am provocative.

> (ever heard of a "Wind River unit" ?)

Hear hear!

> entirely different carreer path

One that never sees joy?

(Just joking.)

JW