Hi, > On May 11, 2016, at 10:02 AM, Kevin Townsend <[email protected]> wrote: > > Hi Will, > > I'll be happy to throw my opinions in on the PLL or clock changes at the BSP > level. > > This also touches on some important issues with power management if you start > thinking about an API around that (which is critical to anything IoT of > course). Often, just before going into sleep modes you want to configure the > clock(s) with a specific setup, and then when you wakeup move them back to a > previous configuration. That's beyond the scope of the core clock setup at > the BSP level, but you'll still probably want to have clock configuration as > part of the overall HAL for both reasons. > > I agree it's non trivial, though, since every microcontroller or SoC will > have it's own clock configuration values and parameters. It may end up making > more sense to provide a 'weak' clock setup function(s) that can be easily > overridden, with a sensible defaults at the mcu level, and document the enum > values for each MCU?
that matches mostly what my thinking around the subject has been as well. I would place the code for clock configuration within MCU code, but have BSP decide (or override) what it should be. Presence/or non-presence of external low-speed oscillator is a great example of why this makes sense. As well as frequency of external high-speed clock source. I’m not sure whether this is something that needs to be abstracted with HAL, though. The system clock config feels very much like a thing that only goes between BSP and MCU, therefore it might not need a generic HAL API. I could be convinced otherwise, if there’s a use case. Power management does needs a HAL API, I think. Both for controlling generic system level power modes, as well as peripheral level settings. And those hook-up calls on enter/exit from low-level modes would be nice to have.
