Assert that the length is greater than one rather than the value
itself. This bug was introduced in the commit:
329be06ad0 -
"exporters - group by directories in prj root"
Let's make the code more common for gpios.
The only difference between STM32 families is that BRR register may
not be available. In case BRR is not available, we use the 16 left bits
of BSRR instead. We could always use BSRR, but BRR saves one left-shift
operation, so let's use it when available.
By default we will consider using BRR, except for platforms that define
GPIO_IP_WITHOUT_BRR.
This commit improves consistency between different platforms' linker
scripts. In particular, we use "__UVISOR_SRAM_START" instead of
"__UVISOR_BSS_START" as the uVisor BSS sections might be outside of the
SRAM (for example, when using a tightly-coupled memory).
When building with the debug profile, certain ST plaforms error with
'get_i2c_timing' not being defined. This is because the function is not
defined as 'static inline', but just 'inline'.
Following HAL update, this is needed to use the I2C API function
rather than previously used MACRO.
An assert would fail at compilation time otherwise.
Previously, when "length = 0" as failsafe, "return 0" is executed.
But we changed so that only START bit and STOP bit are executed same as other devices.
New usage:
python update.py <args>
Where <args> are:
[-c <file.json>] optional argument for example list, default
example.json
-U <github user with forked repos>
-T <github authorisation token>
tag
Update exporter grouping code to group by directories in the root
of the project rather than by the parent directory of each file. This
reduces the number of groups and allows all mbed-os code to reside
in its own folder.
For equeue_sema_wait, -1 is used to indicate an infinite wait.
This wasn't handled in the nonrtos implementation and caused
undefined/weird behaviour after an overflow on integer multiplication.
On most boards, the infinite wait would return after ~50 days, on the
STM32F4 the timeout killed all other timeouts for some reason.
* Rename because the tool has been renamed
* Removed duplicate symbol definitions
* Removed common flags from ld flags (common are c/c++ only)
* Moved EmBlitz to it's own folder
In case Rx is not initiliased its content might be random from stack.
This is causing problem in case of 8 bits read only as the left-side 8 bits
of the returned int value may contain this random byte data. This was for
instance detected when using SDFileSystem Lib.
Jimmy Brisson
Russ Butler
Sarah
jeromecoutant
Laurent MEUNIER
Mike Fiore
Alessandro Angelino
adustm
Martin Kojtal
Anna Bridge
Brian Daniels
Mahadevan Mahesh
TomoYamanaka
Seppo Takalo
bcostm
Jan Jongboom
Christopher Haster
Franz Schnyder