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-`.
In cases where more than one board is connected to a single computer it can become pretty hard to figure out which board you're actually talking to. For example, if you have several MIDI-compatible boards they all show up as "CircuitPython MIDI". This change allows boards to replace the "CircuitPython" part of their USB descriptors with more specific text, for example, "CircuitPython Feather" or just "Feather". This will let folks more easily tell boards apart.
The new option is named `USB_INTERFACE_NAME` and is available in `mkconfigboard.mk`. For example:
```
USB_INTERFACE_NAME = "Feather"
```
