When you say "inclusion problems" I assume you're referring to trying to import and unit test parts of the STM32 HAL. My article mainly focused on unit testing business logic that sits above the hardware abstraction layer. The example I used the article is trivial of course. Perhaps I should have included a more comprehensive example to make that point more clear.
A case in which I've used unit testing in practice was with an interface for UART communication. On the real device, the interface implementation would receive characters and send them through to the STM32 HAL or into an RTOS queue. Because the interface was loosely coupled, I could use the interface to implement a Spy which processes those characters and confirms them against unit tests.
In this case the intention was to isolate and test the business logic all the way down to the characters that would be sent over the UART, while ignoring the queue or the HAL. Testing the queue or HAL would have meant testing on the target or using complex simulators - in either case, the cycle time of tests would have been very long. In comparison, running the tests of the business logic as I described above took less than a second and could be done frequently throughout development to catch bugs before they're covered up.
As you've discovered, unit testing may not be the optimal solution for testing closer to the hardware, but it's a valuable tool in testing other parts of your application. Testing business logic in isolation removes the doubt of the hardware element as it relates to the business logic itself. Other types of tests more specific to hardware would be valuable as well.
