This improves performance of running python code by 34%, based
on the "pystone" benchmark on metro m4 express at 5000 passes
(1127.65 -> 1521.6 passes/second).
In addition, by instrumenting the tick function and monitoring on an
oscilloscope, the time actually spent in run_background_tasks() on
the metro m4 decreases from average 43% to 0.5%. (however, there's
some additional overhead that is moved around and not accounted for
in that "0.5%" figure, each time supervisor_run_background_tasks_if_tick
is called but no tick has occurred)
On the CPB, it increases pystone from 633 to 769, a smaller percentage
increase of 21%. I did not measure the time actually spent in
run_background_tasks() on CPB.
Testing performed: on metro m4 and cpb, run pystone adapted from python3.4
(change time.time to time.monotonic for sub-second resolution)
Besides running a 5000 pass test, I also ran a 50-pass test while
scoping how long an output pin was set. Average: 34.59ms or 1445/s on m4,
67.61ms or 739/s on cbp, both matching the other pystone result reasonably
well.
import pystone
import board
import digitalio
import time
d = digitalio.DigitalInOut(board.D13)
d.direction = digitalio.Direction.OUTPUT
while True:
d.value = 0
time.sleep(.01)
d.value = 1
pystone.main(50)
If you define MONITOR_BACKGROUND_TASK, then a physical output pin
(Metro M4 Express's "SCL" pin by default) will be set HIGH while in
the background task and LOW at other times
This code is shared by most parts, except where not all the #ifdefs
inside the tick function were present in all ports. This mostly would
have broken gamepad tick support on non-samd ports.
The "ms32" and "ms64" variants of the tick functions are introduced
because there is no 64-bit atomic read. Disabling interrupts avoids
a low probability bug where milliseconds could be off by ~49.5 days
once every ~49.5 days (2^32 ms).
Avoiding disabling interrupts when only the low 32 bits are needed is a minor
optimization.
Testing performed: on metro m4 express, USB still works and
time.monotonic_ns() still counts up
To benefit from gcc's "once-only headers" implementation, the
"wrapper-#ifndef" must be the first non-comment part of the file,
according to the manual for various gcc/cpp versions.
On a Debian 10 system, the number of arguments to xargs was such that
it would not fit in a single invocation (xargs --show-limits prints
"bytes: Size of command buffer we are actually using: 131072").
In this situation, the output from the second invocation of xgettext
would replace the output of the first one, so messages that appeared only
in files early in the list would be lost. Strings in "extmod" were most
frequently the victim, including "incorrect padding" from modubinascii.c.
Unfortunately, when the github environment was similar enough to the
environment where "make translate" was invoked, the problem was not
found by "check-translate", because the same (incorrect, truncated)
potfile would be generated on both systems. Apparently Ubuntu and Debian
were different enough that the problem could become visible.
xgettext has a mode where it reads files from stdin ('-f-'), but this does
not have a zero-delimited variant documented. Still, we will assume
that files with adversarial names are not committed to circuitpython
or created by the build process, and print newline-delimited filenames
from `find` to be processed by `xgettext -f-`.
I manually inspected the changes relative to 5.0.0-alpha.5-93-g8778f367e
and believe they are innocuous; Besides restoring some translations
that had become fuzzy, "c-format" was removed from many (all?) fuzzy
messages, and the word-wrapping of one message was changed.
On a Debian 10 system, the number of arguments to xargs was such that
it would not fit in a single invocation (xargs --show-limits prints
"bytes: Size of command buffer we are actually using: 131072").
In this situation, the output from the second invocation of xgettext
would replace the output of the first one, so messages that appeared only
in files early in the list would be lost. Strings in "extmod" were most
frequently the victim, including "incorrect padding" from modubinascii.c.
Unfortunately, when the github environment was similar enough to the
environment where "make translate" was invoked, the problem was not
found by "check-translate", because the same (incorrect, truncated)
potfile would be generated on both systems. Apparently Ubuntu and Debian
were different enough that the problem could become visible.
xgettext has a mode where it reads files from stdin ('-f-'), but this does
not have a zero-delimited variant documented. Still, we will assume
that files with adversarial names are not committed to circuitpython
or created by the build process, and print newline-delimited filenames
from `find` to be processed by `xgettext -f-`.
