SerialWireOutput was outputting 1 character per 32-bit write to the
ITM stimulus port. This is inefficient, and causes processing problems
with some viewers due to them receiving 3 NUL bytes between each
desired character.
Rework to allow us to be more efficient, and eliminate those NUL bytes:
* Retain existing mbed_itm_send() and clarify it's a single 32-bit write.
* Add new mbed_itm_send_block() that is appropriate for sending
character data, and modify SerialWireOutput to use it.
* Move "wait for FIFO ready" check to before the write, rather than
after.
One minor correction - FIFOREADY is a single bit of the register read.
Don't interpret reserved bits.
Keep the prototypes in rtc_api.h even when DEVICE_RTC is not defined.
This allows devices that aren't fully compliant with the RTC API to
still use the header and prototypes.
Current version:
The function ticker_init resets the internal count and disables the ticker interrupt.
Proposed version:
The function ticker_init allows the ticker to keep counting and disables the ticker interrupt.
This is a result of the following discussion:
https://github.com/ARMmbed/mbed-os/pull/5233#pullrequestreview-86677815
Sleep - within 10us
Deepsleep - within 10ms
Note about mbed boards with interface, moved to lpc176x, as they are target related,
should be documented in the target documentation.
The tests will come as separate PR, to conform to this updates to sleep API.
- Move CRC polynomial enum into HAL layer, so it's accessible from platform
implementations
- Add enum to CRC class to indicate which mode the CRC class should use:
HARDWARE, TABLE, or BITWISE
- Add calls to HAL Hardware CRC API to each of the compute functions when the
class is in HARDWARE mode.
- Add missing constructor call to template constructor, and remove const from
delegating constructor.
Define the HAL API header for the Hardware CRC module. This set of functions
allows hardware acceleration of a subset of CRC algorithms for supported
platforms by providing access to the hardware CRC module of certain platforms.
The API is defined as four separate functions:
- hal_crc_is_supported(polynomial)
Indicates to the caller if the specific CRC polynomial is supported.
- hal_crc_compute_partial_start(const uint32_t polynomial)
Initializes the hardware CRC module with the given polynomial.
- hal_crc_compute_partial(*data, size)
Writes an array of bytes to the CRC module to be appended to the calculation
- hal_crc_get_result()
Applies the final transformations to the data and returns the result to the
caller.
Initial work by Bartek Szatkowski in https://github.com/ARMmbed/mbed-os/pull/4079,
reworked following review of https://github.com/ARMmbed/mbed-os/pull/5202 to
transform the entire system into C++, retaining the basic functionality.
Bartek's summary:
* Porting ethernet to EMAC
* Updating EMAC to enable multiple interfaces
* Untangling networking classes, making the abstractions a bit clearer to follow, etc
* General refactoring
* Removal of DEVICE_EMAC flag and introducing DEVICE_ETH and DEVICE_WIFI
Revisions since initial branch:
* Remove lwip depencies
* Correct doxygen warnings
* Remove emac_api.h, replace with C++ EMAC abstract class.
* Create OnboardNetworkInterface, and LWIP implementation.
* Mappings since #4079
lwip-interface/nsapi_stack_lwip.c -> LWIPStack.cpp
lwip-interface/ipstack_lwip.c -> LWIPInterface.cpp
netsocket/mbed_ipstack.h -> OnboardNetworkStack.h
hal/emac_api.h -> EMAC.h
* Reinstate use of EthInterface abstraction
* Correct and clarify HW address EMAC ops
* Restore MBED_MAC_ADDR implementation
* Integrate PPP support with LWIP::Interface.
* Convert K64F lwIP driver to K64F_EMAC.
To do:
* Convert emac_stack_mem.h to follow this pattern.
* Figure out DEVICE_ETH/EMAC
* Update all drivers to use EMAC
Some low power tickers take multiple cycles of the low power clock
to set a compare value. Because of this if the compare value is set
twice back-to-back these implementations will block until that time
has passed. This can cause system stability issues since interrupts
are disabling for this time.
To gracefully support this kind of hardware this patch adds code
to prevent back-to-back writes to the hardware. It does this by
recording the low power clock cycle of the initial write. If any
writes come in too soon after this initial write the microsecond
ticker is used to schedule the new write in the future when the
hardware is ready to accept a new value.
To enable this feature on a target the macro LOWPOWERTIMER_DELAY_TICKS
must be set to the number of low power clock cycles that must elapse
between writes to the low power timer.
Kevin Bracey
Martin Kojtal
Przemyslaw Stekiel
Marc Emmers
Bartek Szatkowski
Russ Butler
jeromecoutant
Steven Cartmell
Martin Kojtal
Amanda Butler
Cruz Monrreal
Senthil Ramakrishnan
Deepika
ccli8