Since QSPi is not yet supported by base TARGET_PSOC6,
there is no need to remove the device label from
FUTURE targets that inherit from TARGET_PSOC6.
This will need to be reverted back once the QSPI support
is implemented for Cypress PSOC6 targets.
An extra start signal was observed on the bus which was
discovered by the FPGA test shield.
This is because the hardware sends out a transaction as soon
as a write to the START bit. Hence the write to the START
bit is delayed by using a flag.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Add a C++ `Atomic<T>` template to make atomics even easier. Basically
compatible with C++11 `std::atomic<T>`, but using the underlying
`core_util_atomic_xxx` functions from mbed_atomic.h, so appropriate for
synchronising with interrupts and optimised for uniprocessor.
One extra piece of functionality beyond the `core_util_atomic_xxx`
functions is the ability to have an arbitrary atomic type - eg a small
structure with 2 `uint16_t`s can be stored in a `uint32_t` container.
Avoid template ambiguities using type_identity_t.
Previously the compiler would be unable to figure out whether
uint8_t x;
core_util_atomic_store(&x, 0);
should invoke core_util_atomic_store<uint8_t>, matching the pointer
type, or core_util_atomic_store<int>, matching the value, leading to
an ambiguity error.
Templates now select only on the type of the atomic pointer parameter.
Even though C/C++11 don't offer pre-op forms (that do the operation then
return the new value) of their freestanding functions, we will be making
them visible via pre-op operators on `Atomic<T>` (++, --, +=, -=, &=,
|=, ^=).
It is easier to do a pre-op than a post-op, as we can use one
fewer register in the assembler, so it's worth optimising for what will
be quite common cases. Make these forms accessible for `Atomic<T>`, but
don't document them for standalone use at this stage.
According to comment in the implementation this target supports the
hardware flow control on UART1 peripheral.
This patch fixes build errors after adding DEVICE_SERIAL_FC guards to
hal/serial_api.h.
After adding DEVICE_SERIAL_FC guards to serial_api.h
serial_set_flow_control is not available. In case of this
implementation, this function is a no-op and may be safely removed.
After adding DEVICE_SERIAL_FC guards to serial_api.h
serial_set_flow_control is not available. In case of this
implementation, this function is a no-op and may be safely removed.