Tickless mode fixes#13
Conversation
|
Started reviewing… Thanks! 😄 |
|
|
||
| // Is it time to wake this thread? | ||
| if (g_ar.tickCount >= thread->m_wakeupTime) | ||
| //TODO: would it be safe to cache tick_count? |
There was a problem hiding this comment.
I was wondering about that too. It's probably safe to cache it within a single function like this one, or ar_kernel_scheduler().
| return g_ar.tickCount * ar_get_milliseconds_per_tick(); | ||
| #endif // AR_ENABLE_TICKLESS_IDLE | ||
| return ar_port_get_time_absolute_ms(); | ||
| // return ar_port_get_time_absolute_ticks() * kSchedulerQuanta_ms; //do we have to limit resolution? |
There was a problem hiding this comment.
Imo, it's better if resolution is not limited.
There was a problem hiding this comment.
Ok, I was not sure about consequences. Will Fix.
| uint32_t ar_get_tick_count(void) | ||
| { | ||
| #if AR_ENABLE_TICKLESS_IDLE | ||
| uint32_t elapsed_ticks = ar_port_get_timer_elapsed_us() / (kSchedulerQuanta_ms * 1000); | ||
| return g_ar.tickCount + elapsed_ticks; | ||
| #else | ||
| return g_ar.tickCount; | ||
| #endif // AR_ENABLE_TICKLESS_IDLE | ||
| return ar_port_get_time_absolute_ticks(); | ||
| } | ||
|
|
||
| // See ar_kernel.h for documentation of this function. | ||
| uint32_t ar_get_millisecond_count(void) | ||
| { | ||
| #if AR_ENABLE_TICKLESS_IDLE | ||
| uint32_t elapsed_ms = ar_port_get_timer_elapsed_us() / 1000; | ||
| return g_ar.tickCount * ar_get_milliseconds_per_tick() + elapsed_ms; | ||
| #else | ||
| return g_ar.tickCount * ar_get_milliseconds_per_tick(); | ||
| #endif // AR_ENABLE_TICKLESS_IDLE | ||
| return ar_port_get_time_absolute_ms(); | ||
| // return ar_port_get_time_absolute_ticks() * kSchedulerQuanta_ms; //do we have to limit resolution? |
There was a problem hiding this comment.
ar_get_tick_count() and ar_get_millisecond_count() should probably be inline. That does mean exposing some port APIs publicly…
Or can we just completely remove them? Is there any reason to not directly call ar_port_get_time_absolute_<x>()? (Renamed?)
There was a problem hiding this comment.
Yeah, forgot to inline them. Even though, compiler would probably inline them anyway.
Well, I think that application should have access to system time. Also application should not have access to port functions.
| } | ||
|
|
||
| //TODO: is return type sufficient? | ||
| uint32_t ar_port_get_time_absolute_ms() |
| //TODO: move ar_get_microseconds() somewhere else and redirect to ar_port_get_time_absolute_us() ? | ||
| WEAK uint64_t ar_get_microseconds() |
There was a problem hiding this comment.
Yeah, move it next to the other get-time APIs.
flit
left a comment
There was a problem hiding this comment.
I like the changes! Thanks again. 👍
The only thing I see that really needs to be done is to split the timer-porting code from the rest of the Cortex-M porting code, so we don't have duplicates.
|
I see no problem i splitting them. Any idea about port sources structure? Should there be some automation in what is compiled (eg through ar_config) or leave it up to user, which sources to compile and link? What about:
|
This change allows to utilize HW timers more easily. (default ar_port.cpp using systick needs updating)
*Single* uses only one timer as microsecond counter between ticks. *Chained* uses two chained timer s (on hardware level) to count microseconds between tics and ticks themselves. Most precise timing with this solution.
- some f303 port cleanups - add port using generic ARM SysTick with explained limitations only lightly tested!
|
My sincerest apologies for being quiet for too long! 🙏 For the port sources, I guess I'm not sure what the best solution is. One of the goals I had for the Argon repo was for it to be usable as a git submodule, without including too much ancillary code you don't need. (I've used it like this in projects; it's nice.) Options:
For now I'm leaning towards your proposal. 😄 I can live with a relatively small number of device-support files in the core repo. And it can always be changed if needed. As for builds, I've never been a fan of using macros to include/exclude files in the build. So I'd rather leave it up to the user. |
This is initial effort to fix timing issues in Argon, more info in #11. I am open open to suggestions.