Jonatan Antoni [Tue, 3 Mar 2020 16:25:11 +0000 (17:25 +0100)]
DoxyGen: Added Armv8.1-MML and CM55 to template lists.
- Removed implemented extensions from device name for ARMCM55
as adding all those becomes unmaintainable.
Jonatan Antoni [Tue, 3 Mar 2020 13:46:07 +0000 (14:46 +0100)]
Core(M): Refactored/aligned L1 Cache Functions
- Moved functions from core_cm7.h to cachel1_armv7.h
- Added L1 Cache to CM55 and ARMv8MML/ARMv81MML devices
reinhardkeil [Wed, 19 Feb 2020 14:38:29 +0000 (15:38 +0100)]
CMSIS-Core documentation: partition_<device>.h includes now partition_gen.h (that is generated using CMSIS-Zone); added FPU settings to partition_<device>.h
Jonatan Antoni [Fri, 31 Jan 2020 12:33:23 +0000 (13:33 +0100)]
Core(M): Ignore -Wpedantic on Armv8-M core headers.
The MPU register definition makes use of (non ISO C99) features, i.e.
the struct definition contains unnamed structs/unions, deliberately.
reinhardkeil [Thu, 24 Oct 2019 11:49:23 +0000 (13:49 +0200)]
CMSIS-Pack:
- api documentation improved
- added bash_script to support pack generation on Linux or Windows
- added custom attribute to component element
- added TrustZone-disabled value to software model selection
Kevin Bracey [Wed, 9 Jan 2019 13:51:08 +0000 (15:51 +0200)]
IAR: RRX doesn't modify flags, but has flags as input
IAR assembler version of RRX had a "cc" clobber for RRX, but this is
unneeded - it doesn't modify the condition codes - it's not "RRXS".
Instead the assembler should have a volatile, as already seen in GCC and Clang
versions to reflect the CC input to the instruction.
CMSIS intrinsics use "volatile" attributes to force ordering of
instructions that work on the PSR, either input or output.
A "cc" clobber does not have that effect, at least in gcc; it only
indicates "changes condition codes", not "reads condition codes", so
CC-clobbering instructions can be reordered. This reflects that in
general the compilers make no guarantees about preserving flag state
between assembler sequences, meaning that __RRX will always be prone to
unreliability.
But the volatile marker increases the chances of stuff coming out in the
right order.
Kevin Bracey [Wed, 9 Jan 2019 12:22:32 +0000 (14:22 +0200)]
GCC: add WFI/WFE compiler barriers
Add "memory" clobber to __WFI and __WFE. Architecturally these should
always be immediately preceded by a __DSB (eg to ensure the write buffer
is drained). Without a barrier on WFI, the following compiler reordering
would be permitted:
This could cause some power issues with the external bus not being
idle.
The added barrier should have no impact on code size, assuming these
instructions are always accompanied by DSB, as DSB does have its own
memory clobber already.
SEV not modified as there are no issues with the equivalent reordering;
we only need the SEV to not be reordered before the DSB, which is
ensured by volatile.
Kevin Bracey [Wed, 9 Jan 2019 13:23:03 +0000 (15:23 +0200)]
IAR: LDRT et al must be asm volatile
As these functions take volatile pointers, the API is promising that the
loads and stores will happen, so the assembler statements need volatile
qualifiers too.
If the functions took non-volatile pointers, or had a separate
non-volatile overload for C++, then the volatile could be omitted - the
instructions are normal loads and stores with no side-effects.
GCC and clang assembler already is "asm volatile", and armcc uses
intrinsics.
Kevin Bracey [Thu, 17 Jan 2019 13:53:51 +0000 (15:53 +0200)]
ARMCC: remove explicit DSB/DMB/ISB barriers
ARMCC documentation states that the __dsb etc intrinsics act as
optimisation barriers. Even though that's a bit woolly about the exact
equivalent barrier intrinsic, take its word that it's doing the right
thing.
It seems safe to assume that it is, because the __schedule_barrier()
intrinsics here are not actually sufficient for DSB and DMB. They need a
__memory_barrier(). If no-one has seen any problems, then presumably
they already include one.
Kevin Bracey [Thu, 17 Jan 2019 13:39:17 +0000 (15:39 +0200)]
Core(A)/armclang: Remove ISB/DSB/DMB barriers
Core(M) versions of files already do not have explicit barriers, so this
makes Core(A) consistent - the built-ins are specified as having barriers
anyway.
Christophe Favergeon [Wed, 12 Jun 2019 11:29:14 +0000 (13:29 +0200)]
CMSIS-DSP: New testing framework
(For our internal use. In short term, we won't give support about it).
CMSIS-DSP: Update to cmake build for the testing framework
CMSIS-NN:Implementation of arm_fully_connected_s8
Use API and quantization compatible with TF Lite.
Jonatan Antoni [Tue, 9 Jul 2019 11:44:41 +0000 (13:44 +0200)]
Doxygen:
- Aligned version of CMSIS-Zone documentation with upcoming release.
- Relaxed condition on CMSIS-Drivers, i.e. applicable to all Cortex processors.
The change breaks compatibility with released software components.
Anonymous structs/unions are not strict C99 but available as an extension. Its a reasonable feature to be used. The code is more clean and readable.