5 Commits

Author	SHA1	Message	Date
Gregory Nutt	e6af32c88f	Run nxstyle against all files modified by PR 848	2020-04-22 21:36:41 +01:00
Gregory Nutt	545cfada38	This commit removes CONFIG_ARCH_INT_DISABLEALL. In the normal course of things, interrupts must occasionally be disabled using the up_irq_save() inline function to prevent contention in use of resources that may be shared between interrupt level and non-interrupt level logic. Now the question arises, if we are using BASEPRI to disable interrupts and have high priority interrupts enabled (CONFIG_ARCH_HIPRI_INTERRUPT=y), do we disable all interrupts except SVCall (we cannot disable SVCall interrupts). Or do we only disable the "normal" interrupts? ... If we are using the BASEPRI register to disable interrupts, then the answer is that we must disable ONLY the "normal interrupts". That is because we cannot disable SVCALL interrupts and we cannot permit SVCAll interrupts running at a higher priority than the high priority interrupts (otherwise, they will introduce jitter in the high priority interrupt response time.) Hence, if you need to disable the high priority interrupt, you will have to disable the interrupt either at the peripheral that generates the interrupt or at the NVIC. Disabling global interrupts via the BASEPRI register cannot effect high priority interrupts.	2019-08-09 10:52:35 -06:00
Gregory Nutt	c300f27130	arch/arm/include/armv7-m/nvicpri.h: In the 'normal' case, the priority of the SVCALL interrupt was the same as the priority of the high priority interrupt. This means that SVCALL interrupt processing can defer the high priority interrupt and result in the jitter in that interrupt response. Fix is to raise the priority of the high priority interrupt above the priority of the SVCALL interrupt. Suggested by Nathan Hartman.	2019-08-09 07:07:16 -06:00
Xiang Xiao	bda6d7f065	arch/arm/include/syscall.h: Add missing inclusion of arch/armv7-r/syscall.h for CortexR.	2019-01-26 07:43:31 -06:00
Dave Marples	d0cda60442	In the current implementation we only use very high priority interrupts (levels 0, 0x10 and 0x20 in CORTEX-M speak) but that means there are loads of lower priority ones that are effectively unused. I have *not* changed the semantics of these levels but have 'shifted' them to be based around the midpoint of the available interrupts (0x80) rather than at the top end....that allows for interrupts to be defined above (or, indeed, below) them as needed by the application. This should have no functional effect on existing code but adds in a clean capability to define higher priority interrupts.	2018-12-03 17:41:59 -06:00