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
