Closed RobMeades closed 2 months ago
@RobMeades in the latest commit where you removed the durationMs in at client test aroud lines 950-970 you are once using utimeoutStop.timeoutStart and in the timeoutStart to replace the similar durationMs timeoutCheck
@mazgch: yes, well spotted, the subset of tests I ran on that commit didn't include ones that ran that particular AT Client test, when I ran a more complete test that one failed; fixed on my local branch, didn't bother pushing it back here.
A new common API,
uTimeout
, is added and all timeouts are routed through it. This API performs time comparisons correctly with unsigned 32 bit arithmetic to ensure that timeouts are not affected if they happen to cross the 32-bit wrap point, which will occur every 50 days for a millisecond tick; otherwise there were instances where a timeout could potentially get "stuck" for 25 days (the unsigned 32-bit wrap length for a millisecond tick).The implementation of the API includes the ability to speed up the apparent wrap-rate of the underlying tick; this is used on test instance 23 (which includes cellular, GNSS and short-range module types) to give it a good thrashing.
Our thanks to warasilapm for raising this issue and my thanks to mazgch for providing the solution.
NOTE: this PR will not be merged it is simply posted here to make it possible for warasilapm to comment on it directly and for him to be able to see any comments made by mazgch.