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
