Interrupt handling (ARM) - Revision history

Ebiggers: Use SourceFile template

2013-09-12T01:44:06Z

Use SourceFile template

Ebiggers: Add `markup`


2013-09-08T15:27:23Z
Add <code> markup

				
				
				
				
				
				← Older revision
				Revision as of 15:27, 8 September 2013
				
Line 14:
Line 14:
  === Receiving an IRQ or FIQ ===   === Receiving an IRQ or FIQ ===
    
− When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address 0x18.  Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address 0x1C.  Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address.  In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored.  In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in ''loader/arch/arm/start.S''.  The "full" IRQ handler is located in ''system/arch/arm/irq_handler.S''. + When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address <code>0x18</code>.  Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address <code>0x1C</code>.  Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address.  In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored.  In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in ''loader/arch/arm/start.S''.  The "full" IRQ handler is located in ''system/arch/arm/irq_handler.S''.
    
  === Banked registers ===   === Banked registers ===
Line 22:
Line 22:
  == Managing interrupts ==   == Managing interrupts ==
    
− The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (cpsr) are 0.  By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs.  Similarly, software can set them to 1 if it needs to disable IRQs and FIQs.  However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction "cps" (Change Program State) is available that can handle changing these bits, as well as changing processor modes. + The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (<code>cpsr</code>) are 0.  By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs.  Similarly, software can set them to 1 if it needs to disable IRQs and FIQs.  However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction named <code>cps</code> (Change Program State) is available that can handle changing these bits, as well as changing processor modes.
    
− Below we explain the enable(), disable(), and restore() functions used by Embedded Xinu to manage interrupts.  These are all implemented in the ARM assembly language file ''system/arch/arm/intutils.S''. + Below we explain the <code>enable()</code>, <code>disable()</code>, and <code>restore()</code> functions used by Embedded Xinu to manage interrupts.  These are all implemented in the ARM assembly language file ''system/arch/arm/intutils.S''.
    
− === enable() === + === <code>enable()</code> ===
    
− enable() allows the processor to receive the IRQ exception. + <code>enable()</code> allows the processor to receive IRQ exceptions.
    
    <nowiki>     <nowiki>
Line 35:
Line 35:
  	mov pc, lr</nowiki>   	mov pc, lr</nowiki>
    
− enable() uses the "cpsie", or "Change Program State Interrupt Enable", instruction to enable IRQs.  (Recall that FIQs are not used by Embedded Xinu.)  It then overwrites the program counter with the link register to return from the function.  As the second instruction is merely overhead of a function call, enable() could be implemented as an inline function containing inline assembly instead. + <code>enable()</code> executes the <code>cpsie</code> ("Change Program State Interrupt Enable") instruction to enable IRQs.  (Recall that FIQs are not used by Embedded Xinu.)  It then overwrites the program counter (<code>pc</code>) with the link register (<code>lr</code>) to return from the function.  Note that since the second instruction is merely overhead of a function call, <code>enable()</code> could instead be efficiently implemented as an inline function containing inline assembly.
    
− === disable() === + === <code>disable()</code> ===
    
− disable() blocks IRQ exceptions and returns a value that can be passed to restore() to restore the previous state.  The previous state may be either IRQs disabled or IRQs enabled.  Note that an IRQ exception received during a region of code where interrupts are disable()d is not lost; instead, it remains pending until IRQs are re-enabled. + <code>disable()</code> blocks IRQ exceptions and returns a value that can be passed to <code>restore()</code> to restore the previous state.  The previous state may be either IRQs disabled or IRQs enabled.  Note that an IRQ exception received during a region of code where interrupts are <code>disable()</code>d is not lost; instead, it remains pending until IRQs are re-enabled.
    
    <nowiki>     <nowiki>
Line 47:
Line 47:
  	mov pc, lr</nowiki>   	mov pc, lr</nowiki>
    
− disable() copies "cpsr" (the Current Program Status Register) into r0, which as per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref> is the return value of the function.  Therefore, the "cpsr" is treated as the value that can be passed to restore() to restore the previous interrupt state.  The code then uses "cpsid" (Change Program State Interrupt Disable) to actually disable the IRQ exception. + <code>disable()</code> copies the <code>cpsr</code> (Current Program Status Register) into <code>r0</code>, which as per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref> is the return value of the function.  Therefore, the <code>cpsr</code> is treated as the value that can be passed to <code>restore()</code> to restore the previous interrupt state.  The code then executes the <code>cpsid</code> (Change Program State Interrupt Disable) instruction to actually disable the IRQ exception.
    
− === restore() === + === <code>restore()</code> ===
    
− restore() restores the IRQ exceptions disabled/enabled state to the state before a previous call to disable(). + <code>restore()</code> restores the IRQ exceptions disabled/enabled state to the state before a previous call to <code>disable()</code>.
    
    <nowiki>     <nowiki>
Line 58:
Line 58:
  	mov pc, lr</nowiki>   	mov pc, lr</nowiki>
    
− As per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref>, the argument to restore() (the previous state value--- in the code this is often stored in a variable named "im", for "interrupt mask") is passed in r0.  r0 is then copied to the "cpsr" (Current Program Status Register), which is the opposite of what disable() does.  restore() then overwrites the program counter with the link register to return from the function.  As the second instruction is merely overhead of a function call, restore() could be implemented as an inline function containing inline assembly instead. + As per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref>, the argument to <code>restore()</code> (the previous state value--- in the code this is often stored in a variable named <code>im</code>, for "interrupt mask") is passed in <code>r0</code>.  <code>r0</code> is then copied to the <code>cpsr</code> (Current Program Status Register), which is the opposite of what <code>disable()</code> does.  <code>restore()</code> then overwrites the program counter with the link register to return from the function.  Note that since the second instruction is merely overhead of a function call, <code>restore()</code> could instead be efficiently implemented as an inline function containing inline assembly.
    
  == Further reading ==   == Further reading ==



Ebiggers: Further reading:  Add link
2013-09-08T14:31:26Z
Further reading:  Add link

				
				
				
				
				
				← Older revision
				Revision as of 14:31, 8 September 2013
				
Line 64:
Line 64:
  As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does not provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions.   As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does not provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions.
    
− * The interrupt controller on the Raspberry Pi is the [[BCM2835 Interrupt Controller]]. + * The interrupt controller on the [[Raspberry Pi]] is the [[BCM2835 Interrupt Controller]].
    
  == Notes ==   == Notes ==
    
  <references />   <references />



Ebiggers: Add a couple links
2013-09-08T14:29:25Z
Add a couple links

				
				
				
				
				
				← Older revision
				Revision as of 14:29, 8 September 2013
				
Line 1:
Line 1:
− This page provides an overview of how Embedded Xinu performs interrupt handling on ARM architectures.  This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the Raspberry Pi.  Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>.  This page is only intended to give an overview of relevant details in the context of Embedded Xinu. + This page provides an overview of how [[Embedded Xinu]] performs interrupt handling on [http://en.wikipedia.org/wiki/ARM_architecture ARM architectures].  This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the [[Raspberry Pi]].  Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>.  This page is only intended to give an overview of relevant details in the context of Embedded Xinu.
    
  == IRQs and FIQs ==   == IRQs and FIQs ==



Ebiggers: Adjust file names
2013-09-08T14:28:09Z
Adjust file names

				
				
				
				
				
				← Older revision
				Revision as of 14:28, 8 September 2013
				
Line 14:
Line 14:
  === Receiving an IRQ or FIQ ===   === Receiving an IRQ or FIQ ===
    
− When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address 0x18.  Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address 0x1C.  Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address.  In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored.  In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in start.S.  The "full" IRQ handler is located in irq_handler.S. + When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address 0x18.  Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address 0x1C.  Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address.  In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored.  In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in ''loader/arch/arm/start.S''.  The "full" IRQ handler is located in ''system/arch/arm/irq_handler.S''.
    
  === Banked registers ===   === Banked registers ===
Line 24:
Line 24:
  The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (cpsr) are 0.  By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs.  Similarly, software can set them to 1 if it needs to disable IRQs and FIQs.  However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction "cps" (Change Program State) is available that can handle changing these bits, as well as changing processor modes.   The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (cpsr) are 0.  By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs.  Similarly, software can set them to 1 if it needs to disable IRQs and FIQs.  However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction "cps" (Change Program State) is available that can handle changing these bits, as well as changing processor modes.
    
− Below we explain the enable(), disable(), and restore() functions used by Embedded Xinu to manage interrupts.  These are all implemented in the ARM assembly language file system/platforms/arm-rpi/intutils.S. + Below we explain the enable(), disable(), and restore() functions used by Embedded Xinu to manage interrupts.  These are all implemented in the ARM assembly language file ''system/arch/arm/intutils.S''.
    
  === enable() ===   === enable() ===
Line 62:
Line 62:
  == Further reading ==   == Further reading ==
    
− As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does no' provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions. + As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does not provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions.
    
  * The interrupt controller on the Raspberry Pi is the [[BCM2835 Interrupt Controller]].   * The interrupt controller on the Raspberry Pi is the [[BCM2835 Interrupt Controller]].



Ebiggers: Created page
2013-08-02T18:44:39Z
Created page
New page
This page provides an overview of how Embedded Xinu performs interrupt handling on ARM architectures.  This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the Raspberry Pi.  Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>.  This page is only intended to give an overview of relevant details in the context of Embedded Xinu.



== IRQs and FIQs ==



=== Overview ===



ARM processors define two types of "interrupts":



* '''IRQs''' (Interrupt Requests).  These are the "normal" type of interrupt.

* '''FIQs''' (Fast Interrupt Requests).  These are an feature that software can optionally use to increase the speed and/or priority of interrupts from a specific source.  For simplicity, Embedded Xinu does '''not''' use FIQs.  However, FIQs could be useful for those looking to design real-time and embedded software on top of or instead of the base Embedded Xinu kernel.



Both IRQs and FIQs are examples of '''exceptions''' supported by the ARM.  Beware that the term "IRQ" is often used generically, whereas here it specifically refers to the ARM-architecture IRQ exception.



=== Receiving an IRQ or FIQ ===



When the ARM receives an IRQ, it will enter a special '''IRQ mode''' and, by default, begin execution at physical memory address 0x18.  Similarly, when the ARM receives a FIQ, it will enter a special '''FIQ mode''' and, by default, begin execution at physical memory address 0x1C.  Before enabling IRQs or FIQs, software is expected to copy ARM instructions to the appropriate address.  In the case of IRQs, there is only room for one ARM instruction, so it needs to be a branch instruction to a place where the full handler is stored.  In Embedded Xinu, these special "glue" instructions, or '''exception vectors''', are set in start.S.  The "full" IRQ handler is located in irq_handler.S.



=== Banked registers ===



In IRQ mode and FIQ modes, some registers are '''banked''', meaning that their contents are dependent on the current processor mode.  The advantage of such registers is that their original values do not need to be explicitly saved by the interrupt handling code.  FIQ mode banks more registers than IRQ mode, but both IRQ mode and FIQ mode bank the stack pointer (sp), which essentially means that each mode can use its own stack.  However, for simplicity and consistency with other CPU architectures, Embedded Xinu does '''not''' use this capability.  Instead, the interrupt handling code immediately switches the processor from IRQ mode to "System" mode, which is the mode in which Embedded Xinu normally operates the ARM CPU.  This means that the interrupt handling code uses the stack of the currently executing thread, so perhaps the main disadvantage of this approach is that it increases the stack size required by each thread.



== Managing interrupts ==



The ARM responds to IRQs and FIQs if and only if bits 7 and 6, respectively, of the Current Program Status Register (cpsr) are 0.  By default (after reset) these bits are both 1, so software must initially set them to 0 to enable IRQs and FIQs.  Similarly, software can set them to 1 if it needs to disable IRQs and FIQs.  However, software does not necessarily need to explicitly manipulate these bits because an alternate instruction "cps" (Change Program State) is available that can handle changing these bits, as well as changing processor modes.



Below we explain the enable(), disable(), and restore() functions used by Embedded Xinu to manage interrupts.  These are all implemented in the ARM assembly language file system/platforms/arm-rpi/intutils.S.



=== enable() ===



enable() allows the processor to receive the IRQ exception.



 <nowiki>

enable:

	cpsie i

	mov pc, lr</nowiki>



enable() uses the "cpsie", or "Change Program State Interrupt Enable", instruction to enable IRQs.  (Recall that FIQs are not used by Embedded Xinu.)  It then overwrites the program counter with the link register to return from the function.  As the second instruction is merely overhead of a function call, enable() could be implemented as an inline function containing inline assembly instead.



=== disable() ===



disable() blocks IRQ exceptions and returns a value that can be passed to restore() to restore the previous state.  The previous state may be either IRQs disabled or IRQs enabled.  Note that an IRQ exception received during a region of code where interrupts are disable()d is not lost; instead, it remains pending until IRQs are re-enabled.



 <nowiki>

disable:

	mrs r0, cpsr

	cpsid i

	mov pc, lr</nowiki>



disable() copies "cpsr" (the Current Program Status Register) into r0, which as per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref> is the return value of the function.  Therefore, the "cpsr" is treated as the value that can be passed to restore() to restore the previous interrupt state.  The code then uses "cpsid" (Change Program State Interrupt Disable) to actually disable the IRQ exception.



=== restore() ===



restore() restores the IRQ exceptions disabled/enabled state to the state before a previous call to disable().



 <nowiki>

restore:

	msr cpsr_c, r0

	mov pc, lr</nowiki>



As per the ARM calling convention<ref>http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</ref>, the argument to restore() (the previous state value--- in the code this is often stored in a variable named "im", for "interrupt mask") is passed in r0.  r0 is then copied to the "cpsr" (Current Program Status Register), which is the opposite of what disable() does.  restore() then overwrites the program counter with the link register to return from the function.  As the second instruction is merely overhead of a function call, restore() could be implemented as an inline function containing inline assembly instead.



== Further reading ==



As mentioned in the introduction, this page deals with ARM-architecture details only and therefore does no' provide a full explanation of interrupt handling on any specific platform, which typically requires the use of some interrupt controller to actually assign meaning to IRQ exceptions.



* The interrupt controller on the Raspberry Pi is the [[BCM2835 Interrupt Controller]].



== Notes ==



<references />

← Older revision		Revision as of 14:29, 8 September 2013
Line 1:		Line 1:
−	This page provides an overview of how Embedded Xinu performs interrupt handling on ARM architectures. This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the Raspberry Pi. Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>. This page is only intended to give an overview of relevant details in the context of Embedded Xinu.	+	This page provides an overview of how [[Embedded Xinu]] performs interrupt handling on [http://en.wikipedia.org/wiki/ARM_architecture ARM architectures]. This only concerns ARM-specific details; in particular it must be understood that the actual meaning prescribed to interrupts is determined using a board-specific mechanism, such as the [[BCM2835 Interrupt Controller]] on the [[Raspberry Pi]]. Furthermore, note that the ARM architecture and its exception/interrupt handling mechanisms are well documented by ARM Ltd., especially in various versions of the ''ARM Architecture Reference Manual''<ref>http://infocenter.arm.com/help/index.jsp</ref>. This page is only intended to give an overview of relevant details in the context of Embedded Xinu.

	== IRQs and FIQs ==		== IRQs and FIQs ==

Interrupt handling (ARM) - Revision history

Ebiggers: Use SourceFile template

Ebiggers: Add markup

Ebiggers: Further reading: Add link

Ebiggers: Add a couple links

Ebiggers: Adjust file names

Ebiggers: Created page

Ebiggers: Add `markup`