Newbie unfortunately. I need to pass data received from a CANbus interrupt interrupt to the application (note I am not using an RTOS at present).

I am looking for a safe way to pass data acquired by the interrupt into the application. I was hoping to use a simple fifo queue mechanism but I am concerned the application and interrupt might collide while accessing the fifo queue.

So I was considering disabling interrupts momentarily in the application while accessing the fifo, or using a SWI function from the application to fetch the next available CAN message from the fifo.

I considered setting bits I and F in the CPSR however reading section 7.1 of UM10114 (LPC21XX Rev.03) it appears there is a non-zero risk of an interrupt being called regardless. The risk appears minimal but I would welcome advice.

The second approach would be call a SWI function from the API to read from the fifo queue. In this case the interrupts would be sequential and that would solve my problem. However this means messing with global pointers or records as SWI functions do not accept parameters.

The third approach would be to implement a circular buffer in which the write pointer is owned by the interrupt and read pointer is owned by the application. However it means checking for overruns (where the write pointer catches up to the read pointer)

I would greatly appreciate any suggestions or thoughts on how best to transfer data from an interrupt into the application. This is a rather generic problem and I'm guessing it's been solved many, many times over. So apologies again for being a newbie. Thanks!

Start a New Thread

--- In l..., "alastair.stell" wrote:
> The third approach would be to implement a circular buffer in which the write pointer is owned by the interrupt and read pointer is owned by the application. However it means checking for overruns (where the write pointer catches up to the read pointer)

And what could you do about it anyway? Your CAN bus is accepting and queuing messages faster than your app can process them. So, is it a CAN problem of too much traffic or just a sluggish app?

If an infinitely large queue can't hold the messages, there is no hope!

I don't know anything about the 2119 but I do know that if you are in an interrupt routine, your app isn't changing pointers. Think about the worst case: the app is just about to tell the queue there is one more slot available (by updating the output pointer) and the interrupt comes along and prevents it. So what? It just means there is one less cell available and if your queue gets that full you have a larger problem.

The other side, where the output process just looked at the queue and found it empty and, a microsecond later the interrupt routine stuffs a message. Again, so what? The output process will look again later.

It seems to me that a circular buffer is always a safe implementation but I have been wrong before.

Richard

Start a New Thread

alastair.stell wrote:
> I considered setting bits I and F in the CPSR however reading section
> 7.1 of UM10114 (LPC21XX Rev.03) it appears there is a non-zero risk of
> an interrupt being called regardless. The risk appears minimal but I
> would welcome advice.

I think you misunderstood the text. How I understand it is, that there is one
more possibility to get an interrupt between the msr instruction and the first
protected instruction of your code. You actually can *not* get interrupts
*during* your protected code. If you are not using FIQs and the tricks
explained in the UM section, you should be fine.

--

Timo

Start a New Thread