Well, that would have been a better way to put it if you ask me. :-) A good example of picking a different timer would be time accuracy vs power related savings. For example, a device that is constantly powered may want to use a timer off a high accuracy crystal as opposed to one that is lower accuracy but conserves power. Another reason might be timer capabilities; one timer may be able to do more/less than another timer and application requirements could force use of a different timer. I agree, “generally” we could pick the correct timer but not in every case (imo).
I see what you are proposing. Well, at least I think so. The only thing I am not sure of in your proposal is where in the MCU specific directories this would go. What would the API call be and what file would it reside in? Will > On Feb 2, 2016, at 12:03 PM, Sterling Hughes > <[email protected]> wrote: > > 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 >>
