Or just mix everything and do not worry about this?
No, please do worry about this.
I've worked in high level languages and I've worked in low level languages. I've worked when time was not a factor to when it was life critical. One thing that has been true throughout: It's best to think about making things easy to read before you think about making them fast.
- As for me, I prefer linux-kernel-like codestyle with all_lower_case() function names and 8-spaces wide tabs as indents.
No one cares what you like. They care if they can read it. What makes your code readable is good names, consistent style, and good use of white space. (8-spaces, really? Sheesh)
You are free to set your own style provided you don't mix it with other styles. You are free use things that use other styles but don't do it by copy and paste. You should hide the other styles behind abstractions. Come to think about it even when not thinking about style you should be hiding other code behind abstractions. Wrapper functions are one way to do that.
- ST provides its own HAL with names of functions like HAL_Delay(), HAL_UART_Receive() etc. They use two-space indentation, all brackets on new line and other ST-specific codestyle features.
Unless you're doing something silly like adding their code to yours using copy and paste, the only part of this that could possibly show up in your code is the names. Wrappers take care of that.
- Also, it is very common to use FreeRTOS on embedded systems. They use function names like xTaskCreate() and in general its own coding standard.
Second verse, same as the first.
How to manage all this stuff in such situations? Make wrapper inline functions?
Use the best abstraction you can. Don't assume inline functions are the only thing you can use. Virtual functions can be very powerful. If you're concerned about speed, stop it. Don't worry about that until a test proves you have to.
Remember RTOS doesn't mean fast. It means consistently slow. Don't let your environment tell you what your requirements are. The task at hand should tell you that.
Work to create a place in the code where everything speaks in one style with one vocabulary. Push the details away and write something that makes a nice clear point.