During the SiP workshop, we discovered that 3% is too narrow due to a combination of:
Voltage rail differences between target and FPGA
Extension of lesser-resolution ADC's to 16-bit results
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.
VSCode exporter was generating a launch config that contained absolute paths to the
compiler executables. It makes more sense to use the executables that are
installed into the system PATH.
Functions related to serial flow control should not be exposed
if DEVICE_SERIAL_FC is not defined
* serial_set_flow_control,
* serial_cts_pinmap,
* serial_rts_pinmap.
On Nuvoton targets, lp_ticker_set_interrupt(...) needs around 3 lp-ticker
ticks to take effect. It may miss when current tick and match tick are very
close (see hal/LowPowerTickerWrapper.cpp). Enlarge LPTICKER_DELAY_TICKS to
4 from 3 to address this boundary case.
Fix minor style fixes and typos:
1. Change file name to correct one.
2. Change copyright year.
3. Insert whitespaces before and after paranthesis.
4. Put `*` next to pointer name.
Steven Cooreman
Tymoteusz Bloch
Volodymyr Medvid
Martin Kojtal
Russ Butler
Chun-Chieh Li
jeromecoutant
Mahesh Mahadevan
Kevin Bracey
Filip Jagodzinski
Arto Kinnunen
Mark Edgeworth
Ron Eldor
Devaraj Ranganna
Przemyslaw Stekiel
Przemyslaw Stekiel