A fast and easily customised operating system
for ARM devices
Page "Wiki/versions/new/8" does not exist. Please create it now, or hit the "back" button in your browser.
OS_ClaimDeviceVector
Programmer's Reference Manuals
» Part 15 – SWI Calls
» OS
» OS_ClaimDeviceVector
OS_ClaimDeviceVector
(SWI &4B)
| Entry | |
|---|---|
| R0 | Device number * flag in bit31 |
| R1 | Address of device driver routine |
| R2 | Value to be passed in R12 when driver is called |
| R3 | Address of interrupt status if R0 = podule “IRQ” or “FIQ as IRQ” on entry |
| R4 | Interrupt mask to use, if R0 = podule “IRQ” or “FIQ as IRQ” on entry |
| Exit | |
|---|---|
| R0 | Preserved |
| R1 | Preserved |
| R2 | Preserved |
| R3 | Preserved |
| R4 | Preserved |
Use
The purpose of this call is to claim a device vector.
Notes
This installs the device driver. If the same driver has already been installed on the vector then the old copy is removed from the vector. This does not enable interrupts from the device. The previous driver is added to the list of earlier claimants. Your driver is called if the IO controller receives an interrupt from the appropriate device, the corresponding interrupt mask bit is set, and your driver was the last to claim the vector.
When your code is being called, you’ll find the following entry conditions:
- The ARM is in IRQ mode and interrupts are disabled
- R3 points to the base of the IO controller chip memory space
- R12 has R2’s value when claiming the vector
Your routine should:
- Service the interrupt
- Stop the device from generating interrupts, when necessary
- Return to kernel using
MOV PC, R14
You should ensure:
- A very high execution speed
- If your routine takes more than 100µs, you should re-enable interrupts, if previously disabled, to ensure other devices’ interrupts can be serviced – e.g. disc ops. With interrupts enabled your routine must cope with being re-entered.
- Saving R14_svc to a stack before calling SWIs and reloading it after it returns to prevent double use of R14_svc
- Strictly avoiding the use of non re-entrant SWIs, because the supervisor stack would become corrupted if used
- Clearing the interrupt flags when finishing
- You cope with SWI-error handling. You must use XSWIs. As there is no-one to pass the error on to, you must either handle it yourself or store an error indicator, so that the next SWI call (or the current, if already threaded) to this module will generate an error.