@Richardman - I would normally agree with porting to a saner API, but that's not always an option. Also ChibiOS doesn't expose all the functionality you may need - their HAL and drivers expose only the basics, anything more platform specific and you are back to writing into registers.
One approach that has worked for me when trying to make some STM32 peripherals work was to examine the peripheral registers and compare with the reference manual whether the values are sensible. Basically walk through the documentation for the peripheral from top to bottom and check each register. STM32 has most registers working in such way that the defaults (zeros) are typically the values you will most commonly want, so not many bits need to be set. That approach let me discover some bits that the STDPeriph library wasn't setting and thus my code wasn't working. The same with ChibiOS or Cube/HAL.
Tie this with some hardware analyzer - either a scope or logic analyzer and you are golden. I prefer scope for the initial troubleshooting, because a logic analyzer will not show issues like a signal distortion due to two chips attempting to drive the line at the same time (e.g. because pin mode has been configured wrong or assigned to an incorrect alternate function).
The HAL is bloated, poorly documented and buggy, but it is not THAT unusable. It works for many common cases without issues. Whether or not you use HAL makes no difference if you are debugging without adequate instruments - you will be still facing the same issues trying to make ChibiOS or whatever else to work.
Home
Help
Search
Login
Register
