Xiang Xiao 818d8dda1e Remove empty seria.h and all references		2019-01-26 15:08:14 -06:00
..
a1x
am335x	arch/arm/include/amm335x: Trivial, cosmetic changes after review	2019-01-08 08:15:04 -06:00
arm	arch/arm/src/include/xxx/syscall.h: Align semi-hosting call style with other syscalls	2019-01-26 07:40:47 -06:00
armv6-m	arch/arm/src/include/xxx/syscall.h: Align semi-hosting call style with other syscalls	2019-01-26 07:40:47 -06:00
armv7-a	arch/arm/src/include/xxx/syscall.h: Align semi-hosting call style with other syscalls	2019-01-26 07:40:47 -06:00
armv7-m	arch/arm/include/syscall.h: Add missing inclusion of arch/armv7-r/syscall.h for CortexR.	2019-01-26 07:43:31 -06:00
armv7-r	arch/arm/src/include/xxx/syscall.h: Align semi-hosting call style with other syscalls	2019-01-26 07:40:47 -06:00
c5471
dm320
efm32	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
imx1
imx6
imxrt	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
kinetis	Merged in dagar/nuttx/pr-kinetic_minor_fix (pull request #820)	2019-01-19 15:39:46 +00:00
kl
lc823450	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
lpc11xx	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
lpc17xx	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
lpc31xx
lpc43xx	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
lpc54xx	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
lpc214x
lpc2378
max326xx	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
moxart
nrf52	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
nuc1xx
sam34	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
sama5
samd2l2
samd5e5	configs/metro-m4: Fix RxD interrupt pin selection. The number SERCOM interrupts do not refer to PAD numbers, but to bit positions in the INFLAG register (very tiny footnote in the data sheet). With with final fix, the basic NSH configuration appears fully functional.	2018-09-01 15:29:22 -06:00
samv7	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
stm32	Merged in raiden00/nuttx_pe (pull request #796)	2019-01-02 12:12:28 +00:00
stm32f0l0	Merged in raiden00/nuttx_lora (pull request #811)	2019-01-12 07:59:31 +00:00
stm32f7	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
stm32h7	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
stm32l4	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
str71x
tiva	arch/arm/include/tiva and src/tiva: Improve GPIO interrupt support by removing unnecessary, hard-coded per-MCU defines and using the existing Kconfig configuration options instead.	2018-12-31 07:19:30 -06:00
tms570
xmc4	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
.gitignore
arch.h
elf.h	arch/arm/include/syscall.h: Add missing inclusion of arch/armv7-r/syscall.h for CortexR.	2019-01-26 07:43:31 -06:00
inttypes.h
irq.h
limits.h
spinlock.h
stdarg.h
syscall.h	arch/arm/include/syscall.h: Add missing inclusion of arch/armv7-r/syscall.h for CortexR.	2019-01-26 07:43:31 -06:00
tls.h
types.h