-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error if OS tickrate is changed #5264
Conversation
The current mbed-os drivers rely on a tickrate of 1ms for timing. This means that if OS_TICK_FREQ is set to any value other than 1000 then mbed-os driver will no longer delay for the correct amount of time. To prevent this from happening this patch triggers a compile time error if a tickrate other than 1m is used.
Is this "locking" required? I recall we had earlier discussion about this during tickless where we calculate the freq in the runtime as there is API to get it. We always assumed that tick is 1ms, and I recall it is in our codebase used in various primitives. We could potentionaly update the codebase to calculcate it runtime to enable a user to change it, but the question this patch is trying to answer - is it worth considering? I am inclined to have this assumption - tick 1ms. What others think? |
At the current moment the assumption that 1 tick equal 1ms is present in the code. For example cornerstone functions like Triggering error if
I think it is good enough for now however changing the tickrate may help a (very little) bit to save power. That may be a good things to have conversion functions |
retest uvisor |
What do you think @c1728p9 ? would this be feasiable to do |
i agree it's good for now, but in general we should do as @pan- suggested and fix up our OS to make it more robust. |
With tickless I don't know if there is much of a reason to adjust the tickrate. The OS will stay in sleep mode without ticking as long as there is nothing to do. Because of this, the only benefit I can see of adjusting the tickrate is less overhead for context switching if multiple threads are ready to run since context switching will occur less frequently. The addition of I'm not against having a variable tickrate, but at the moment the to me it seems the downsides outweigh the benefits. @pan- or anyone else, did you have use cases in mind for a variable tickrate? |
I would say we should leave it as it is, with this change. And address it if it pops out (is requested). |
Build : SUCCESSBuild number : 73 Triggering tests/test mbed-os |
Test : SUCCESSBuild number : 44 |
retest uvisor |
Waiting for uvisor CI to be finished. Once green, 4 ppl 👍 for this, going in |
The current mbed-os drivers rely on a tickrate of 1ms for timing. This means that if OS_TICK_FREQ is set to any value other than 1000 then mbed-os driver will no longer delay for the correct amount of time. To prevent this from happening this patch triggers a compile time error if a tickrate other than 1m is used.