One more quick note. I think that there are probably a number of things in the MCU that are good defaults for most folks, but we may want to allow override in the BSP. I wish I had a good list, but I don’t :(.
On 2/2/16, 2:43 PM, "[email protected]" <[email protected]> wrote: >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 >>>>>> >>>> >> >
