nuttx

a1x

…

am335x

arch/arm/include/amm335x: Trivial, cosmetic changes after review

2019-01-08 08:15:04 -06:00

arm

Squashed commit of the following:

2019-04-29 14:52:05 -06:00

armv6-m

Squashed commit of the following:

2019-04-29 14:52:05 -06:00

armv7-a

Squashed commit of the following:

2019-04-29 14:52:05 -06:00

armv7-m

Squashed commit of the following:

2019-04-29 14:52:05 -06:00

armv7-r

Squashed commit of the following:

2019-04-29 14:52:05 -06:00

c5471

…

cxd56xx

Merged in alinjerpelea/nuttx (pull request #884 )

2019-06-05 14:05:56 +00:00

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

Merged imxrt1020 into master

2019-04-30 16:08:46 -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

arch/arm/include/nrf52/ and arch/arm/src/nrf52: 1. Added 52840 family support 2. Use common irq and memory layout header file for 52832 & 52840.

2019-03-12 09:43:49 -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

…

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

stm32f0l0g0

Rename STM32F0L0 to STM32F0L0G0 since it now alsow supports the STM32G0 thanks to Mateusz Szafoni's contribution

2019-05-27 08:16:24 -06:00

stm32f7

*Merged in zhoukejun/nuttx_nucleo-f767zi (pull request #838 )

2019-03-11 03:44:57 +00:00

stm32h7

arch/arm/src/stm32h7/: Add stm32h7 ethernet driver. This is the initial push for the ethernet driver. The driver has been tested to be working on a nucleo board. This is still WIP, it doesn't for example do MAC filtering on HW level, but just receives all ethernet packets.

2019-04-30 08:43:39 -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

arch/arm: Add the initial cortex-a7 archtiecture support

2019-03-19 11:51:29 -06:00

limits.h

…

spinlock.h

arch/arm: Add the initial cortex-a7 archtiecture support

2019-03-19 11:51:29 -06:00

stdarg.h

…

syscall.h

arch/arm: Add the initial cortex-a7 archtiecture support

2019-03-19 11:51:29 -06:00

tls.h

…

types.h

…