That is a good question; wish I had a good answer. For now we could kick the
can down the road and simply pass the priority in the API. Or just have the BSP
program the interrupt priority to 1 less than the lowest priority. We could
also return the interrupt vector used by the BSP to the OS and have the OS set
the priority.
> On Feb 3, 2016, at 10:28 AM, p...@wrada.com wrote:
>
> 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" <wi...@runtime.io> 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, p...@wrada.com 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" <ma...@runtime.io> 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 <sterl...@apache.org>
>>>>> 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
>>>>>>> <sterling.hughes.pub...@gmail.com> 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 <wi...@runtime.io>
>>>>>>>> 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 <sterl...@apache.org>
>>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>
