On 2/2/16 10:15 AM, will sanfilippo wrote:
Hello:
Porting the OS to the nrf51 has exposed an issue for certain cortex-M MCU’s,
namely the lack of SysTick. Furthermore, it may be advantageous from a power
perspective to use a different timer for the OS time tick. Thus, the problem is
this: how does the developer pick the timer to use for the os time tick?
Personally, I think this is a project/os configuration option. Placing this
decision in hw/mcu would force every project that used the MCU to use a
particular timer. Putting it in the bsp is slightly better, but then every
project using that BSP would use the timer chosen by the BSP. One possible
benefit to putting this decision in the bsp (or mcu) is that it shields the
developer from HW/MCU specifics. Not sure that this is a good thing though!
What I am thinking of is something more like this:
* The HAL provides a set of timers to use: rtc, generic timer, cputime,
systick. Note that some of these currently dont exist. :-)
* The developer has some means of picking one of these HAL timers to use.
If folks agree with the basic idea, any thoughts on how to do this? Should we
modify the os_init() or os_start() API? Should there be some sort of os
configuration file per project? In the project egg? In the target?
I definitely don't think this should be per-project: that's insanity.
Generally it's clear on an MCU which timer is best suited for the OS to
run off of. If we want to override this depending on a BSP, I think we
could have the BSP export a capability BSP_SYSTICK, and if that
capability is specified, the MCU definition will not include the OS
definition.
Sterling
