| .. |
|
a1x
|
Squashed commit of the following:
|
2018-06-21 10:59:58 -06:00 |
|
arm
|
Assertions: Identify the running task correctly when dumping task state information. It takes time to switch to the target task after g_readytorun has been modified. If panic/assert happen during this period, the dump will contain the incorrect and confusing information due to the difference between the real running task and the return value of this_task(). This change resolve this problem by adding g_running_task to track the real running task through the context switch.
|
2018-11-15 07:11:51 -06:00 |
|
armv6-m
|
Assertions: Identify the running task correctly when dumping task state information. It takes time to switch to the target task after g_readytorun has been modified. If panic/assert happen during this period, the dump will contain the incorrect and confusing information due to the difference between the real running task and the return value of this_task(). This change resolve this problem by adding g_running_task to track the real running task through the context switch.
|
2018-11-15 07:11:51 -06:00 |
|
armv7-a
|
Assertions: Identify the running task correctly when dumping task state information. It takes time to switch to the target task after g_readytorun has been modified. If panic/assert happen during this period, the dump will contain the incorrect and confusing information due to the difference between the real running task and the return value of this_task(). This change resolve this problem by adding g_running_task to track the real running task through the context switch.
|
2018-11-15 07:11:51 -06:00 |
|
armv7-m
|
This commit changes the lazy and non-lazy exception handler to remove a couple of cpsid instructions from them on ARMv7-m. If my understanding is correct then these interrupt manipulations aren't doing anything anyway because prioritization stops secondary interrupts arriving and, even if they did work, they would have introduced race conditions for the period of time between the interrupt arriving and further interrupts being disabled.
|
2018-12-06 07:20:21 -06:00 |
|
armv7-r
|
Assertions: Identify the running task correctly when dumping task state information. It takes time to switch to the target task after g_readytorun has been modified. If panic/assert happen during this period, the dump will contain the incorrect and confusing information due to the difference between the real running task and the return value of this_task(). This change resolve this problem by adding g_running_task to track the real running task through the context switch.
|
2018-11-15 07:11:51 -06:00 |
|
bcm2708
|
EFM32, Kinetis, BCM2708: Juha Niskanen's fix of commit 4a32325e3c also applies to BCM2708, EFM32, and Kinetis.
|
2018-10-10 06:45:03 -06:00 |
|
c5471
|
All network drivers! Change pre-processor logic that selects the high priority work queue or gives preferential treatment to the high priority work. All network logic must run on the low priority work queue! Or suffer the consequences.
|
2018-11-21 07:57:26 -06:00 |
|
common
|
arch/: Update all _exit() implementations for all architectures so that they correctly called the scheduler instumentation layer for the new task that runs when the old one exits. This missing instrumentation was confusing the Critical Section Monitor logic with uses this instrumentation to track the state of critical sections.
|
2018-11-24 18:20:57 -06:00 |
|
dm320
|
arch/arm/src: All ARM architctures now support CONFIG_ARCH_IDLE_CUSTOM
|
2018-05-07 10:13:20 -06:00 |
|
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
|
arch/arm/src: All ARM architctures now support CONFIG_ARCH_IDLE_CUSTOM
|
2018-05-07 10:13:20 -06:00 |
|
imx6
|
Kconfig files: Fix several errors noted by Alex Denisov in Bitbucket issue 115.
|
2018-08-05 10:48:02 -06:00 |
|
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
|
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 |
|
kl
|
arch/arm/src: All ARM architctures now support CONFIG_ARCH_IDLE_CUSTOM
|
2018-05-07 10:13:20 -06:00 |
|
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
|
Fix lots of typos in C comments and Kconfig help text
|
2018-07-08 18:24:45 -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
|
Replace non critical PANIC with DEBUGPANIC to save the code space
|
2018-08-24 06:21:15 -06:00 |
|
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
|
arch/arm/src: All ARM architctures now support CONFIG_ARCH_IDLE_CUSTOM
|
2018-05-07 10:13:20 -06:00 |
|
lpc2378
|
arch/arm/src: All ARM architctures now support CONFIG_ARCH_IDLE_CUSTOM
|
2018-05-07 10:13:20 -06:00 |
|
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
|
Squashed commit of the following:
|
2018-08-26 11:17:33 -06:00 |
|
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
|
Fix lots of typos in C comments and Kconfig help text
|
2018-07-08 18:24:45 -06:00 |
|
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
|
All network drivers! Change pre-processor logic that selects the high priority work queue or gives preferential treatment to the high priority work. All network logic must run on the low priority work queue! Or suffer the consequences.
|
2018-11-21 07:57:26 -06:00 |
|
samd2l2
|
arch/arm/src/max326xx: Add framework for MAX326XX standard DMA support.
|
2018-11-20 08:09:03 -06:00 |
|
samd5e5
|
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 |
|
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 #773)
|
2018-12-05 11:46:36 +00:00 |
|
stm32f0
|
arch/arm/src/stm32f0/stm32f0_clockconfig.c: Fixes the problem in GPIO port clocks. Only port A clock was enabled although the comment states otherwise.
|
2018-12-04 06:50:32 -06:00 |
|
stm32f7
|
Merged in david_s5/nuttx/master_f7_i2c (pull request #774)
|
2018-12-05 21:24:59 +00:00 |
|
stm32h7
|
STM32H7 and STM32L4: Applied David Sidrane's I2C to:
|
2018-12-05 15:38:42 -06:00 |
|
stm32l4
|
STM32H7 and STM32L4: Applied David Sidrane's I2C to:
|
2018-12-05 15:38:42 -06:00 |
|
str71x
|
Replace non critical PANIC with DEBUGPANIC to save the code space
|
2018-08-24 06:21:15 -06:00 |
|
tiva
|
arch/arm/src/tiva/hardware: Correct an error in header guard definitions found in build testing.
|
2018-12-06 08:30:50 -06:00 |
|
tms570
|
Replace all ASSERT with DEBUGASSERT to save the code space
|
2018-08-24 06:58:30 -06:00 |
|
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
|
|
|
|
Makefile
|
Squashed commit of the following:
|
2018-06-20 12:30:37 -06:00 |
