-
Notifications
You must be signed in to change notification settings - Fork 3k
Only schedule mbed_ticker interrupt if queue->head is changed #6515
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks good; it should improve insertion time for events the do not replace the head of the queue.
/morph build |
Build : SUCCESSBuild number : 1678 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1310 |
Test : FAILUREBuild number : 1471 |
/morph test |
I don't really know how the tests should work. It looks like this failure originates from a value from a previous test that is still in the interface_stub. The value expected is 0xCCCCCCCC but actually is 0x7000000 which is equal to TIMESTAMP_MAX_DELTA used in the test_legacy_insert_event_head(). |
Test : FAILUREBuild number : 1473 |
I am testing locally also and the change does seem to cause the issue but I don't really know why. EDIT: It also fails using the debugger, forgot to actually use the changed code, whoops. |
I have found the issue.
What is missing is the interrupt that would be caused by the interface time overflowing max_delta.
I have added the changes for the test to this PR. |
@marcemmers Thanks for the update, we will review |
@marcemmers I have analysed this with the same conclusion. |
/morph build |
Build : SUCCESSBuild number : 1708 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1342 |
Test : FAILUREBuild number : 1502 |
@marcemmers Can you rebase on top of the latest master? Ticker improvements landed and we would like to test this fix. |
Reverts change from commit 1057720
…e previous interrupt_timestamp would have triggered one anyway
f88dce9
to
046cf1d
Compare
@0xc0170 Should be ok now? |
/morph build |
Build : SUCCESSBuild number : 2212 Triggering tests/morph test |
Test : FAILUREBuild number : 2005 |
Exporter Build : ABORTEDBuild number : 1839 |
Test: tests-mbed_drivers-timer
fix is already being developed here #7070 |
@maciejbocianski Thought that error looked familiar. Gonna rerun the test CI on the off chance that it passes. Otherwise if it happens again we'll likely need to hold off for that PR to land. /morph test |
Test : SUCCESSBuild number : 2017 |
/morph export-build |
/morph mbed2-build |
Exporter Build : SUCCESSBuild number : 1857 |
Reverts change from commit 1057720
Description
It seems to me it is unneccesary to schedule a new interrupt the new event is further in the queue and head is still the same. This is essentially the same as is done in the remove_event function: only reschedule if the head is removed.
Doesn't really fix any issues but does result in better response time. Only tested on a STM32L072 in low power configuration.
Pull request type
[ ] Fix
[x] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change