tuples will be useful for things like `mbed::Event` and
`mbed::Callback` - storing parameter packs from variadic templates.
Create a C++14(ish) `<tuple>` for ARMC5, and a `<mstd_tuple>` that
adds `apply` and `make_from_tuple` from C++17.
Add another missing unified syntax directive. Was previously fixed in
03f1ac3ffd, but the same problem was not addressed in the pending PR that
added the `NEWVAL_2OP` assembler.
* Modify Doxygen grouping of `drivers` Public/Internal APIs
* Correct classification of `mbed_events.h`
* Amend name of Doxygen group containing Device Key API
* Classify `CallChain.h` as public API and relocate file
* Remove Doxygen group from `equeue_platform.h` as it has no Doxygen compliant documentation
* Move USB target specific code back to `usb/device/targets`
* Change Doxygen groups structure, splitting first by Public/Internal
This commit also does the following:
* groups the documentation of related API
* moves `events/internal/equeue.h` to `events/equeue.h`
* merges `events/source/README.md` to `events/README.md`
Also includes:
* rename `mbed_sleep_manager.c` to `mbed_power_mgmt.c` to match its
header file
* create Doxygen groups for public and internal APIs
* use relative path to include header files where inconsistent
* update references to internal APIs throughout libraries
* update the copyright year for all modified files
* Fixed wrapper functions for IAR
* Fixed and renamed profile to minimal-printf.json
* Moved minimal-printf under platform
* Removed minimal-printf/mbed_lib.json
* Modified exporter template to work with partial profile
* Prevented optimization of printf to avoid compiler function substitution
Add add-standard-as-possible version of C++11 <mutex>.
A lot of the stuff in there is generic, but the actual mutex classes and
call_once need to interface with the OS.
For those, they're not available in ARMC5 or IAR; retargetting would be
necessary for ARMC6 and GCC, and I've yet to investigate how whether
that's possible. So for now I'm using local implementations.
Although `Mutex` in principle could support `timed_mutex` and
`recursive_timed_mutex`, we don't have `chrono` for the time parameters,
so hold off for now.
For the generic stuff like mstd::unique_lock, they are aliased to
std::unique_lock where possible.
* Adjust definition to make the default constructor `constexpr`.
This permits use in classes that want lazy initialization and their
own `constexpr` constructor, such as `mstd::mutex`.
* Add `get_no_init()` method to allow an explicit optimisation for
paths that know they won be the first call (such as
`mstd::mutex::unlock`).
* Add `destroy()` method to permit destruction of the contained object.
(`SingletonPtr`'s destructor does not call its destructor - a cheat
to omit destructors of static objects). Needed if using in a class
that needs proper destruction.
Regularise the C++ support glue, adding `<mstd_type_traits>` etc.
These include the base toolchain file, backfill `namespace std` as much
as possible for ARM C 5, and then arrange to create unified
`namespace mstd`, which can incorporate toolchain bypasses
(eg `mstd::swap` for ARM C 5, or `mstd::atomic`), and include local
implementations of post-ARM C++14 stuff.
All APIs in `namespace mstd` are intended to function as their
`namespace std` equivalent, and their presence there indicates they
are functional on all toolchains, and should be safe to use in
an Mbed OS build (including not unreasonable memory footprint).
See README.md for more info.
For all compilers add post-C++14 stuff to namespace mbed:
* invoke, invoke_result, is_invocable, is_invocable_r,
is_nothrow_invocable, is_nothrow_invocable_r, unwrap_reference,
unwrap_ref_decay
For ARM C 5, add C++11 bits based on above to namespace std:
* result_of, reference_wrapper, ref, cref, mem_fn
Revert back to older behaviour where we hold deep sleep lock only while
timing a sleep. Previous version was a speed optimisation, but broke
some tests.
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.
Kyle Kearney
Martin Kojtal
Kevin Bracey
Andrew Chong
Anna Bridge
Evelyne Donnaes
George Psimenos
Hugues Kamba
Seth Itow
Arto Kinnunen