Will - I didn't mean anything too harsh by calling it insanity- what I meant was "it seems really hard to have every build project define the cpu system timer."
What are the specific cases where you'd define which system timer to use on a per-project basis? I could potentially see scaling CPU usage during system operation- but that seems like a different API to me. I was proposing that we make it default per MCU, and optionally per-BSP by using the newt capability API to create a define in the MCU specific directories (-DUSE_BSP_TICKER) which would ifdef away the OS ticker and allow the BSP to override it. Sterling. > On Feb 2, 2016, at 11:37 AM, will sanfilippo <[email protected]> wrote: > > Insanity? That is a bit harsh dont you think? I dont think using words like > “insanity, ridiculous, stupid, etc" are conducive to having folks contribute > to the project. Just my opinion… > > I am not quite sure what you are proposing, meaning I would not know what to > implement based on your reply. It must be my insanity. > > >> On Feb 2, 2016, at 10:21 AM, Sterling Hughes <[email protected]> wrote: >> >> >> >>> 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 >
