I¹ll throw in my support as well. Certainly on some processors different timers have different current draw and require different sleep states. For wearables, this is super critical for battery life. I expect that folks will want to use alternate timers for the system tick to maximize battery life.
Maybe I¹m saying the same thing as Will, but I think the right approach is to have the system tick defined in the MCU but be able to be turned off like Sterling said. If I were implementing a board with the MCU and I turned off the standard system tick, I¹d want to implement my systick code in my BSP. Paul On 2/2/16, 2:24 PM, "marko kiiskila" <[email protected]> wrote: >I agree with Sterling. > >MCU specific code seems like the best place to keep this. For the cases >where BSP wants to use a non-default >timer, it can influence MCU compilation. > > >> On Feb 2, 2016, at 2:05 PM, Sterling Hughes <[email protected]> wrote: >> >> I think even in those use cases, that would probably apply per-BSP. I >>don't think its very common that the OS timer would be used differently >>within the same BSP. Have you/has anyone seen cases where the only >>difference was the time source, but otherwise the BSP was identical? >> >> In order to setup the compile options: you would have a function to >>setup the OS time tick, that would get defined by the MCU. You would >>surround that function with: >> >> #ifndef USE_BSP_TICKER >> int >> os_setup_timer() >> {....} >> #endif >> >> Then, if the BSP wanted to override the os_setup_timer(), it would >>export the following capability: >> >> BSP_OS_TICKER_DEF >> >> Each MCU must, in order to respect that setting have the following in >>it's egg.yml file: >> >> egg.clags.BSP_OS_TICKER_DEF: -DUSE_BSP_TICKER >> >> Sterling >> >> On 2/2/16 12:41 PM, will sanfilippo wrote: >>> 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 >>>>> >>> >
