Deprecate wait() in favour of acquire(), try_acquire(),
try_acquire_for() and try_acquire_until().
Brings Semaphore more into line with CMSIS-RTOS 2 (which uses "acquire"),
itself (as it has "release"), and other classes having "try", "try for"
and "try until".
Also steps away from vague "wait" term - the primary operation here is
to acquire the semaphore, and this will of course sleep.
Some targets may not provide zero-wait-state flash performance. Export this function
to be overridable for targets to provide more accurate implementation like locating
'delay_loop_code' in SRAM.
The USB Device must change the address within 2 ms after completing
SET ADDRESS status stage.
Wait 2 ms before issuing GET DESCRIPTOR under the new address. In my
case, this completely resolves the timeout issues.
It has been found that there is a problem with the new K66F SPI driver when clock polarity is high.
After setting clock polarity to high SCLK line is still low. When transmission starts and CS is asserted (in case of manual CS handling) SCLK signal is invalid (low). After first transfer SCLK idle state becomes high.
SPI implementation on FPGA test shield is resistant on this bug and transmission is successful. The problem has been found on two boards communication test where transmission fails.
The idea is to add support to the FPGA test shield to catch such errors and verify this in the test.
Clang warns about reserved user-defined literals by default. This
warning is not terribly helpful; compilers aren't normally in the
habit of warning about use of reserved identifiers. It can interfere
with, for example, deliberate emulation of a future standard
language feature.
The warning was promoted to an error in an mbed client build, due to a
non-C++11 "%s"name occurring in a macro. But the macro itself was never
invoked, so the misinterpretation as C++11 caused no problems other than
this warning. Killing the warning will let that code build on ARMC6.
The code already built on GCC and IAR.
If that macro ever was used, then a separate error about operator ""
name not being defined would be generated, on all 3 toolchains.
This is limited to ARMC6 because as of µVision V5.27 you can't set C++11
for ARMC5.
Also current µVision does not support gnu++14. We should be able to get
is as `<default>`, as it is the default for ARM Compiler 6.10-6.12,
but this option does not work as documented and actually requests
gnu++89 explicitly. So gnu++14 is mapped to gnu++11.