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 >>>> >>
