IMO, I dont think any “OS" related things belong in hw/mcu. Something like “os_setup_timer()” should not be placed in any hw/mcu directory. The hw/mcu directories provide a standard interface to the outside world through a HAL. The HAL should have timer interfaces (RTC, generic timer, etc). Note that the CMSIS-HAL already provides a SysTick config API. One of these HAL interfaces should be used for the os time ticker.
BTW, older versions of the code did have the os time tick API in the bsp. It is still there in os_arch.h; it is called os_bsp_systick_init(). So here is a solution that might be fine for all: we use the bsp interface and that calls out a specific HAL interface provided by the MCU. This will be SysTick for MCU’s which support it; otherwise the bsp will use a different HAL timer (provided by the MCU). Sound good? Will > On Feb 2, 2016, at 2:43 PM, [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 >>>>>> >>>> >> >
