examples/qencoder/qe_main.c:
* main(): Call to printf() had "%d" but argument was
int32_t, leading to compiler warning. Change format
specifier to PRIi32 (suggested by Gregory Nutt).
Results were difficult to interpret because the counts during the high priority, budget interval were included with other counts during the low priority interval. This corrects that reporting by using two counts: One for the low and one for the high priority interval. This makes the results much easier to interpret.
There should be no impact to anything other that the sporadic scheduler case of the OS test.
Tested using the the stm32f4discovery:sporadic configration. That configuration has no yet been merged but is available from incubator-apps PR 3097.
This commit adds the test developed by Jan Staschulat with Issue #incubator_nuttx/2935
It is expected to cause the OS test to fail for the time being since that issue reports a bug.
Tested using the (new) stm32f4discovery:sporadic configuratioin.
It's used in the code but missing in Kconfig.
I guess the PR [1] forgot to add this.
Make it "y" by default because it seems like the original behavior
before the PR [1]. I have no strong opinions on the default
either ways.
[1] https://github.com/apache/incubator-nuttx-apps/pull/570
from:
return - ECONNABORTED;
to:
return -ECONNABORTED;
The latter style is more commonly used within NuttX code base.
Note: nxstyle doesn't complain on either of them.
The current calculation easily overflows if the local time is
around the unix epoch. I guess it isn't too unusual for
devices without RTC. Or, the battery is dead. Or, whatever.
This commit avoids the overflow by simply dividing everything by 2.
While more sophisticated and precise solutions are possible,
I feel that they are overkill for this simple implementation.
For example,
The unix epoch (1970) is 0x83aa7e8000000000 in
64-bit NTP timestamp. (1900-origin)
The timestamp now, as of writing this, is 0xe3cda16b00000000.
With the code before this commit, the offset will be:
(lldb) p (long long)((0xe3cda16b00000000 - 0x83aa7e8000000000) + (0xe3cda16b00000000 - 0x83aa7e8000000000)) / 2
(long long) $16 = -2295952992316162048
(lldb)
with the new code, it would be:
(lldb) p (long long)((0xe3cda16b00000000 / 2 - 0x83aa7e8000000000 / 2) + (0xe3cda16b00000 / 2 - 0x83aa7e8000000000 / 2))
(long long) $17 = 6927419044538613760
(lldb)
It's the correct offset from the unix epoch:
(lldb) p 6927419044538613760 >> 32
(long) $0 = 1612915435
(lldb)
spacetanuki% date -r 1612915435
Wed Feb 10 09:03:55 JST 2021
spacetanuki%
