Thanks Will, I was reading this which shows some headaches of the multi platform SOC issues that Linux had.
https://archive.fosdem.org/2013/schedule/event/arm_in_the_linux_kernel/atta chments/slides/273/export/events/attachments/arm_in_the_linux_kernel/slides /273/arm_support_kernel.pdf I recommend looking at it since they have had similar issues (clock, pinmux, proliferating SOCs) etc. Paul On 2/3/16, 11:41 AM, "will sanfilippo" <[email protected]> wrote: >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, [email protected] 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" <[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 >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> >
