I just pulled your changes and went to implement os_bsp_systick_init(). It was really just moving systick_init from os_arch_arm.c to os_bsp.c. However, the current sys tick_init code needs an interrupt vector priority which depends on the priority of the SVC. How should we resolve the interrupt priorities between the BSP and the OS.
On 2/2/16, 2:56 PM, "will sanfilippo" <[email protected]> wrote: >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 >>>>>>> >>>>> >>> >> >
