Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add wait_ns API #9812
This provides the ability to generate really small delays - it's often
There have been a few local implementations - it makes sense to
Based on the local implementation inside the Atmel 802.15.4 driver.
Pull request type
Testing shows a bunch of failures: https://mbed-os.mbedcloudtesting.com/job/mbed-os-ci_greentea-test/1244/testReport/
Looks like I need to do something to make the M7 timing predictable - the nRF51 and RTL8195 seem to have some sort of target-specific problem - either a clock error or unexpectedly high interrupt load.
Updated with something that I hope stabilises the M7 timing -
Still need to figure out RTL8195 and NRF51_DK - maybe some input from relevant teams might be useful.
In my latest run RTL8195 and M7 devices passed, nRF51 still fails, and now Nucleo L073 and F072 failed too.
It's possible it's down to alignment again, rather than specific platforms - flash sometimes not able to keep up with the instruction flow? Rerunning that one to see if consistent for one build, and will keep fiddling.
If I can't force alignment (seems to be hard to do), may be able to get it down to a tolerable difference between fast and slow alignment by putting enough NOPs in - smoothing out the flow.
Some platforms seem to be quite persistently running 30% slower than expected, but not been able to lock down a cause. Falling back to making the upper tolerance bound higher, to try to make sure the test is stable. It would be nice to get it more precise, but for the sort of use case envisaged, taking 40% longer is acceptable.
Trying some repeated test system runs to get confidence.
referenced this pull request
Feb 27, 2019
I approved the PR, so not holding it back, but I find it pointless to add