The two types of the CANMessage constructor accepting a data buffer have two issues. First, they limit the input buffer size to the 4 least significant bits of the passed length even though a CAN message cannot have more than 8 bytes of payload. Second, the used data length in the following memcpy() uses the initially passed data length which may exceed the internal data buffer size. Both will lead into hard to find bugs if the passed data buffer size is outside the limits according to the CAN standard. This fix intends to solve this by limiting the input data size to 8 bytes.
This far all SFDP Sector Map Table related data has been found in small
pieces inside SPIFBlockDevice. Purpose was to consolidate the data
under one SFDP structure where all the information gathered from
SFDP tables is stored.
More generic version of a function used for parsing a Sector Map Table
was taken into use to avoid duplicate code. The implementation taken
into use is the one which got split from QSPIFBlockDevice and resides
now under the SFDP module.
This far all SFDP Sector Map Table related data has been found in small
pieces inside QSPIFBlockDevice. Purpose was to consolidate the data
under one SFDP structure where all the information gathered from
SFDP tables is stored.
Parsing a Sector Map Table was made more generic so that later it can be
moved under SFDP module. Once that is done it can be shared with
SPIFBlockDevice to avoid code duplication.
Separates SFDP header retrieval and moves it as a part of the earlier
introduced SFDP file.
Purpose is to abstract away differences between SPIF and QSPIF devices
when it comes to fetching the SFDP headers from a device.
Original default constructor implementation wasn't quite working
properly; it didn't cope with the new "mode_limit" parameter.
Change mechanism so that this now works:
MbedCRC<POLY32_BIT_ANSI_CRC, 32, CrcMode::TABLE> crc;
Init values often need reflection, and use of `__RBIT` prevents constant
init being done at compile time (unless `__RBIT` uses a compiler
intrinsic, which it doesn't for GCC).
Rather than try to handle constants 0U and -1U with a special case to
avoid the RBIT, which can in turn lead to runtime bloat for nonconstant
inits, use a C++20 style is_constant_evaluated() check to switch between
C and assembly forms.
This reduces code-size for non-constant init, by eliminating a runtime
condition, and allows the bit-reversal of any constant init to happen at
compile time.
Clang emits warnings if it can see a declaration when it needs a
templated variable. Add declarations for the specialisations in
MbedCRC.cpp to MbedCRC.h keep it quiet.
Tighten up a little by making all `_crc_table` references conditional
on tables being configured on.
* Deprecate RawSerial.
* Introduce UnbufferedSerial to provide unbuffered I/O by implementing
with a FileHandle interface for I/O streams.
* Add Greentea test for the UnbufferedSerial class.
Related PR:
https://github.com/ARMmbed/mbed-os/pull/10924
The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized.
I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split.
If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
* Make mbed_error use bitwise MbedCRC call rather than local
implementation.
* Remove use of POLY_32BIT_REV_ANSI from LittleFS.
* Move some MbedCRC instances closer to use - construction cost is
trivial, and visibility aids compiler optimisation.
* Use compile-time detection of hardware CRC capability, so unneeded
code and tables do not go into the image.
* Add global JSON config option to allow choice between no tables,
16-entry tables or 256-entry tables for software CRC. Default set
to 16-entry, reducing ROM size from previous 256-entry.
* Allow manual override in template parameter to force software or
bitwise CRC for a particular instance.
* Micro-optimisations, particularly use of `RBIT` instruction and
optimising bitwise computation using inline assembler.
Incompatible changes:
* Remove special-case "POLY_32BIT_REV_ANSI" - users can use standard
POLY_32BIT_ANSI, which now uses the same 16-entry tables by default,
or can use hardware acceleration, which was disabled for
POLY_32BIT_REV_ANSI. MbedCRC<POLY_32BIT_ANSI, 32, CrcMode::TABLE> can
be used to force software like POLY_32BIT_REV_ANSI.
* The precomputed table for POLY_16BIT_IBM had errors - this has been
corrected, but software CRC results will be different from the previous
software calculation.
* < 8-bit CRC results are no longer are shifted up in the output value,
but placed in the lowest bits, like other sizes. This means that code
performing the SD command CRC will now need to use `(crc << 1) | 1`,
rather than `crc | 1`.
Anna Bridge
Martin Kojtal
daniel-starke
Shaik Abdul Sadiq
Veijo Pesonen
Hugues Kamba
Przemyslaw Stekiel
Kevin Bracey
cyliangtw
Przemysław Gąsior