I will disagree that a task cannot successfully be owned by a class. My wrappers successfully make class objects that contain a task defined as a member function of that class. The actual task function that is passed to the create task function is an extern “C” thunk that casts the void * pointer that it gets as a parameter to be the Task* object pointer that is the pointer to the Task Wrapper base class for the object. This fully gets around the typing issue.
The one trick is you need to make sure if the task is being created after the scheduler is started that the task starts out at a low priority then the task creating it, so the constructor finishes before the task starts. Then in the initial task function, if needed, the priority of the task can be set to where you want it.
As far as C calling C++ functions if the C++ function is declared extern “C” there should be no problems. For many platforms, the extern “C” isn’t actually needed as C and C++ use the same calling conventions so the extern “C” is only needed for functions called by ‘name’ to remove the C++ name mangling from the name of the function.
As to the ST Hal layers, the problem isn’t C++, it is just that many of those routines are just not written to be thread-safe, and need helpers to make them usable. I thnk that is what you are saying but I am not positive. I often find this a problem with the vendor-supplied I/O library and tend to use it as a guide to write my own. I also have developed a platform-independent I/O layer to meet my usual needs, and that means that the business logic ends up largely platform-independent and can easily be ported to other machines.