sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5c9e72f99d
nuttx/arch/arm/src
History
Gregory Nutt 5c9e72f99d Squashed commit of the following: 
arch/arm/src/tiva/hardware/cc13x0/cc13x0_fcfg1.h:  Adjust cloned CC13x9 FCFG1 header file so that it reflects reality.

    arch/arm/src/tiva/hardware/cc13x0/cc13x0_fcfg1.h:  Add CC13x0 FCFG1 header file.  Initial commit is the same as the CC13x2/CC26x2 FCFG1 header with a few name changes.

    arch/arm/src/tiva/hardware/cc13x2_cc26x2/cc13x2_cc26x2_fcfg1.h:  Initial FCFG1 header file for the cc13xx/cc26xx family.
2018-12-13 12:35:39 -06:00
..
a1x
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
efm32 arch/arc/src: Remove all driver-specific logic to set the interrupt priority. There is no good reason to change the interrupt priority unless you just want to debug a difficult problem. OR is you want to use high priority interrupts. In that case the specific interrupt priorities will need to be set by board-specific logic. 2018-12-06 13:34:41 -06:00
imx1
imx6 Kconfig files: Fix several errors noted by Alex Denisov in Bitbucket issue 115. 2018-08-05 10:48:02 -06:00
imxrt arch/arm/src: In most I2C drivers, correct upper index value in I2C trace dump. Eliminates the extra NONE event from the trace dump output. 2018-12-08 12:49:58 -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
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 arch/arc/src: Remove all driver-specific logic to set the interrupt priority. There is no good reason to change the interrupt priority unless you just want to debug a difficult problem. OR is you want to use high priority interrupts. In that case the specific interrupt priorities will need to be set by board-specific logic. 2018-12-06 13:34:41 -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
lpc2378 arch/arc/src: Remove all driver-specific logic to set the interrupt priority. There is no good reason to change the interrupt priority unless you just want to debug a difficult problem. OR is you want to use high priority interrupts. In that case the specific interrupt priorities will need to be set by board-specific logic. 2018-12-06 13:34:41 -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 arch/arc/src: Remove all driver-specific logic to set the interrupt priority. There is no good reason to change the interrupt priority unless you just want to debug a difficult problem. OR is you want to use high priority interrupts. In that case the specific interrupt priorities will need to be set by board-specific logic. 2018-12-06 13:34:41 -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 arch/arm/src/stm32/Kconfig: USB Host is an option. 2018-12-12 18:27:04 -06:00
stm32f0 arch/arm/src: In most I2C drivers, correct upper index value in I2C trace dump. Eliminates the extra NONE event from the trace dump output. 2018-12-08 12:49:58 -06:00
stm32f7 arch/arm/src: In most I2C drivers, correct upper index value in I2C trace dump. Eliminates the extra NONE event from the trace dump output. 2018-12-08 12:49:58 -06:00
stm32h7 arch/arm/src: In most I2C drivers, correct upper index value in I2C trace dump. Eliminates the extra NONE event from the trace dump output. 2018-12-08 12:49:58 -06:00
stm32l4 arch/arm/src: In most I2C drivers, correct upper index value in I2C trace dump. Eliminates the extra NONE event from the trace dump output. 2018-12-08 12:49:58 -06:00
str71x arch/arc/src: Remove all driver-specific logic to set the interrupt priority. There is no good reason to change the interrupt priority unless you just want to debug a difficult problem. OR is you want to use high priority interrupts. In that case the specific interrupt priorities will need to be set by board-specific logic. 2018-12-06 13:34:41 -06:00
tiva Squashed commit of the following: 2018-12-13 12:35:39 -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