Interrupt Vector dillema

I’ve been scanning the PRMs and the forums to see how it is possible to service an unknown hardware devices interrupt, this is in relation to those generated by the SPI in the BCM2835 and BCM2836 chips in the Raspberry Pi.

I don’t particularly want to claim the hardware IRQ vector and I see using the software IrqV is frowned upon, I’m assuming the SPI interrupts would go through both of these vectors if enabled.

Currently there is no device vector number for the SPI, I expect this is because it is not a standard interface.

In the PRMs there is a reference about there being a better method than using the IrqV software vector but it does not state what that better method is.

I have written software to interface external hardware via an I/O Podule in the past to capture weather satellite images using interrupts, but this type is catered for within RiscOS.

The better method is probably referring to HAL_IRQ* entry points. As you point out you’d need to discover the device and it’s not currently (as far as I’m aware) implemented in the HAL on BCM.

You can use IrqV (the software, not the hardware version) – it’s the final fallback and applicable in this scenario. If/when the HAL does include SPI it can easily be changed.

I see using the software IrqV is frowned upon

I don’t understand why that statement is there, I nearly reworded it a few weeks back as there are situations where it’s applicable. I believe the advice is actually trying to say “check there’s not a more preferable method before using this vector” with a link to the relevant HAL entry points.

The SPI interrupt number is 54.
You may need to enable the SPI interrupt in the interrupt controller though.
I have an interrupt handler (in assembler) that is used in my PiSerial module, if you wish to see how its used.

Yes I’ve seen the list, including 54 for SPI. I looked at the HAL IRQ today but as you say, it does not include SPI. I think I’m stuck with IrqV and yes please, a look at your irq code Tank would be useful. I tried yesterday to add the IrqV code but when I do an rmkill on the module the machine hangs even though the OS_Release appeared to be correct.

The correct way of doing things under RISC OS 5 is basically as follows:

1. Find the hardware-specific IRQ/device number of the device (Ignore the list in the PRMs). The preferred way of doing this is to get the device number from the HAL somehow, usually by using OS_Hardware 4 to look for a known type of HAL device. But we don’t create HAL devices for the SPI so for now you’ll have to hard-code it :-)
2. Call OS_ClaimDeviceVector to install your IRQ handler for that device. Ignore R3 and R4, they’re only relevant to podules.
3. Enable interrupts in the interrupt controller by calling HAL_IRQEnable
4. Do whatever’s necessary to enable IRQ generation in the SPI controller, etc.

When your IRQ handler is called:

1. Service the interrupt in the SPI controller
2. Call HAL_IRQClear to clear the interrupt status in the IRQ controller (some IRQ controllers latch the interrupt source and need to be manually told to resume looking for new interrupts)
3. Return from the IRQ handler

If you want to enable interrupts from within your IRQ handler then you need to make sure you’ve silenced the interrupt in the SPI controller (e.g. clear the IRQ mask register) and performed the HAL_IRQClear, otherwise the processor will probably get stuck recursively re-entering your IRQ handler.

On shutdown of your driver:

1. Disable interrupt generation in the SPI controller
2. Call OS_ReleaseDeviceVector to release your IRQ handler

Note that you shouldn’t call HAL_IRQDisable – in the case of a shared interrupt that would disable it for everyone. The kernel will automatically disable an interrupt if nobody handles it (although I don’t think any current hardware uses a shared IRQ for SPI).

Had another go with the IrqV route just now, this time on issuing an rmkill it didn’t hang! I haven’t enabled any interrupts yet and the handler does nothing, just passes any interrupt on. Don’t know why it didn’t work the other day, I cannot see any difference.

I’ll have another look at using the HAL and OS_ClaimDeviceVector etc. When you say hard code it I assume you mean you have to create a descriptor which matches the unknown device.

The point of all this is to eventually use Buffer_Manager to store the data received under interrupts from an SPI device, then use events to supply that data to software not so dependent on the underlying hardware.

But we don’t create HAL devices for the SPI so for now you’ll have to hard-code it :-)

Are you saying an SPI device should be created? If so, is that something that can be added easily or is it a case of requesting an official allocation etc?

Bill, send me an email to webmaster@tankstage.co.uk and I’ll send you my code.

But we don’t create HAL devices for the SPI so for now you’ll have to hard-code it :-)

Are you saying an SPI device should be created? If so, is that something that can be added easily or is it a case of requesting an official allocation etc?

Yes, it’s definitely something that should be created. Both to avoid hard-coding of the IRQ number, and to avoid hard-coding of the physical address (one of the big changes between the Pi 1 and the Pi 2 was that they shuffled the physical memory map around in order to allow the extra RAM to be squeezed in).

You don’t need to request an allocation by email, you just need to have write access to (or know someone who has write access to) CVS since the HAL device types & IDs are all listed in this kernel header

You don’t need to request an allocation by email, you just need to have write access to (or know someone who has write access to) CVS

And the next obvious question…Who is in the inner circle of trust and what do we need to specifically request?

Who is in the inner circle of trust

ROOL (obviously), myself, Sprow and John Ballance are the people I know of with CVS write access.

what do we need to specifically request?

• A new device type (SPI is a serial interface, so you’d probably want HALDeviceSerBus_SPI)
• A new device ID for the Pi (probably HALDeviceID_SPI_BCM2835)
• For these allocations to be useful you’d also want the BCM HAL to be modified to create & register the HAL device on startup, specifying that it should fill in (at least) the IRQ number and hardware address

Of course, since these are all code changes, and the person making the request is likely to be a programmer, it’s preferable if the person making the request was to make the changes himself and then submit a patch of some kind :-)

For more advanced cases (e.g. if you were aiming to make a generic SPI HAL device which can cover other platforms like OMAP, iMX6, etc.) then you’d probably want to include a new C and/or assembler header in your request which extends the base HAL device to add all the SPI-specific stuff (e.g. see the RTC header, which adds a couple of extra properties and a couple of function pointers onto the base struct)

A new device ID for the Pi (probably HALDeviceID_SPI_BCM2835)

And one for the Pi2 I guess.

Of course, since these are all code changes, and the person making the request is likely to be a programmer, it’s preferable if the person making the request was to make the changes himself and then submit a patch of some kind :-)

Well, you can probably guess where this is heading. It probably requires yourself or Sprow to make the necessary code changes, I doubt many understand what needs changing at code level to create/register a HAL device on startup.

For more advanced cases (e.g. if you were aiming to make a generic SPI HAL device which can cover other platforms like OMAP, iMX6, etc.) then you’d probably want to include a new C and/or assembler header in your request which extends the base HAL device to add all the SPI-specific stuff (e.g. see the RTC header, which adds a couple of extra properties and a couple of function pointers onto the base struct)

Sounds very sensible and does future proof it.

A new device ID for the Pi (probably HALDeviceID_SPI_BCM2835)

And one for the Pi2 I guess.

There’s not really any need for a separate ID for the Pi 2 – apart from the base address of the registers the SPI controller is exactly the same as in the Pi 1 (or at least we can assume it’s the same, since there doesn’t seem to be any official docs released for the BCM2836 yet). So it’s easier to just stick to the one ID, so that the SPI driver only has one device ID to look for instead of two.

If we had a generic SPI HAL device then having lots of device IDs wouldn’t be an issue – the driver module wouldn’t care about what the ID is, it can just assume that anything which is an SPI controller (and potentially matches against a min/max API version) is going to adhere to the common interface. But because this device will be purely for the Pi it’s important to check for specific device ID.

Of course, since these are all code changes, and the person making the request is likely to be a programmer, it’s preferable if the person making the request was to make the changes himself and then submit a patch of some kind :-)

Well, you can probably guess where this is heading. It probably requires yourself or Sprow to make the necessary code changes, I doubt many understand what needs changing at code level to create/register a HAL device on startup.

Yeah, that’s fine. I’ll remember to link to the changes from here once I’ve submitted them :-)

Yeah, that’s fine. I’ll remember to link to the changes from here once I’ve submitted them :-)

You’re a gentleman. Did you get my eMail?

Yes :-)

When I first used RISC OS on R-Pi, I thought that I would never need SPI since all current hardware attachment projects used I2C. I now have a chip that I need to interface which is SPI only. I am just wondering whether there are any prospects for an SPI module to be released please, along with HAL updates mentioned earlier in this thread. Thanks.

HAL updates mentioned earlier in this thread

I think this is one of those situations where I volunteer to do something and then forget to add it to my todo list!

Anyway, I’ve just submitted some changes to add some basic SPI HAL devices to the Pi HAL.

• For all controllers it will expose the register base address and IRQ number. Note that for SPI1 and SPI2 this is the base address of the register sub-block – i.e. AUXSPI0_CNTL0 & AUXSPI1_CNTL0 from the reference manual.
• For SPI1 and SPI2 the Activate and Deactivate entries will enable/disable the controllers in the aux enable register
• SPI1 and SPI2 also have a TestIRQ entry, to cope with the fact their IRQ is shared
• GPIO mapping isn’t dealt with – there are a few too many variables to deal with (e.g. how many chip select lines are desired). Perhaps a future version of the code could deal with this by adding a ‘Configure’ entry point.

To acknowledge the fact that SPI0 is very different from SPI1 & SPI2, there are two different device IDs in use. For SPI0 the first word of the HAL device will be &405 (type &405 device ID 0). For SPI1 and SPI2 it’ll be &10405 (type &405 device ID 1). I’m also using the unit number (low 8 bits of the location, i.e. byte 5 of the device) to differentiate between the controllers – SPI0 is unit 0, SPI1 is unit 1, SPI2 is unit 2. Also note that the SPI1 and SPI2 devices will only be registered if the OS is running on a model which has the relevant GPIOs available – so SPI1 is only available on B+ and later (needs the larger 40 pin expansion header), and SPI2 is only available on the Compute.