Raspberry Pi: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
| Line 101: | Line 101: | ||
==Interrupts and exceptions == |
==Interrupts and exceptions == |
||
By default the exception vector table on ARM starts at 0x0. You can use that but there are better ways. You can set a flag to use a high vector at 0xffff0000 or set the exception vector base address register to point to your own table anywhere ( |
By default the exception vector table on ARM starts at 0x0. You can use that but there are better ways. You can set a flag to use a high vector at 0xffff0000 or set the exception vector base address register to point to your own table anywhere (32 byte aligned) you like. |
||
Note: Interrupts are level triggered so you have to clear the source of an interrupt or mask it before returning from interrupt. The ARM |
Note: Interrupts are level triggered so you have to clear the source of an interrupt or mask it before returning from interrupt. The ARM CPU in the RPi also supports some extra instructions for storing registers on the stack of a different mode, switching modes and returning from interrupt. Those extensions are nicely described in the ARM arm. |
||
Note: The return address in LR during an interrupt will be 0-8 byte, depending on the type of exception, offset to what it should be and needs to be adjusted before returning. Again look into the ARM arm for which offset applies to which exception. |
Note: The return address in LR during an interrupt will be 0-8 byte, depending on the type of exception, offset to what it should be and needs to be adjusted before returning. Again look into the ARM arm for which offset applies to which exception. |
||
| Line 109: | Line 109: | ||
Implementing and testing the software interrupt first is a good idea since you can trigger it in a controlled way. |
Implementing and testing the software interrupt first is a good idea since you can trigger it in a controlled way. |
||
When configuring some peripheral to send an interrupt it is a |
When configuring some peripheral to send an interrupt it is a useful thing to have interrupts disabled in the CPSR, enable the interrupt you are interested in (or all) in the 3 interrupt enable registers and then poll the 3 pending registers in a tight loop and output changes. This allows you to see if the peripheral raises an interrupt and (if in doubt) which one. After that the real interrupt handler can be configured and tested. Gives you a nice half way point to test what you have so far. |
||
==Floating point support - VFP== |
==Floating point support - VFP== |
||