I had been programming embedded systems for a while. I think the key thing you need to write good unit tests for embedded systems is that you need to have a clean interface for accessing hardware.
If your code accesses hardware everywhere, it is tightly-coupled and untestable. So it is related to software design knowledge rather than embedded programming knowledge.
Treat hardware as the external dependencies that are not always available, like some 3rd party web APIs. You don't want to connect hardware to run unit tests, although you need all dependencies for integration tests.
If you have a clean separation between code of accessing hardware and software logic, you can apply mocking/stubbing to write and run unit tests without hardware presence. Then you need may unit testing frameworks, but that should be less related to embedded programming.
My background is the opposite of you, I moved from embedding programming to general business software. The main challenge of writing unit tests of embedded systems is about the clean separation between hardware and software that I mentioned.
Comparatively speaking, changes to the code related to hardware is less frequent than usual software. Because the cost of testing and debugging is higher when involving hardware, it may involve manual procedures that cannot be automated.
Therefore, if the code is tightly coupled in the beginning, it tends to remains untestable, because the effort of refactoring to make it testable is high.
So my advice would be: make the code loosely coupled in the first place and spend more time in the design phase.