How to handle very fast repeating interrupts?

How to handle very fast repeating interrupts?

[Martin Laabs]

Hi,

i'm using a lpx2214 board which is running with 60MHz.
Now I have an interrupt every 12us (so 80k per second.)
The Interrupt handler is very short. It has to read one
word from the external memeory interface and store it into a
buffer. This has to happen until the next interrupt will occure
because otherwise data would be lost.
Because it has to do so little but so often I'd like to
avoid the whole interrupt management/routing eCos implements.
I'd like to configure this interrupt as a FIQ and just want
to jump to my ISR routine. What do I have to pay attention
on when doing so?
I'd write the routine in ASM and store the register I use
to the stack. (Which stack will I use. The one of the current
process?)


When disabeling the "Use seperate stacks for interrupt ..." I
get the following trap. Do you have any idea?


0x00002810 in ?? ()
Loading section .sram, size 0x54 lma 0x40000540
Loading section .rom_vectors, size 0x40 lma 0x81010000
Loading section .text, size 0x14948 lma 0x81010040
Loading section .rodata, size 0x4544 lma 0x81024988
Loading section .data, size 0x718 lma 0x81028ecc
Start address 0x81010040, load size 103992
Transfer rate: 62066 bits/sec, 370 bytes/write.
(gdb) cont
Continuing.
[New thread 2]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to thread 2]
0x810103d8 in IRQ_10T ()
(gdb) bt
#0  0x810103d8 in IRQ_10T ()
#1  0x81013faa in Cyg_Interrupt::acknowledge_interrupt (vector=2)
    at /opt/agade-software/ecos/ecos/packages/kernel/current/src/intr/intr.cxx:765
#2  0x8102b250 in cygmem_pool_heap1 ()
#3  0x8102b250 in cygmem_pool_heap1 ()
Previous frame identical to this frame (corrupt stack?)
(gdb) 

Thank you,
 Martin L.

RE: How to handle very fast repeating interrupts?

[Chris Zimman]

>  i'm using a lpx2214 board which is running with 60MHz.
> Now I have an interrupt every 12us (so 80k per second.)
> The Interrupt handler is very short. It has to read one
> word from the external memeory interface and store it into a
> buffer. This has to happen until the next interrupt will occure
> because otherwise data would be lost.
> Because it has to do so little but so often I'd like to
> avoid the whole interrupt management/routing eCos implements.
> I'd like to configure this interrupt as a FIQ and just want
> to jump to my ISR routine. What do I have to pay attention
> on when doing so?
> I'd write the routine in ASM and store the register I use
> to the stack. (Which stack will I use. The one of the current
> process?)

Not to get of topic, but are you running eCos w/o the scheduler?  Because if
you're not, I don't see how you are going to be able to keep up with the time
interval that you need.

Figuring 1.1 DMIPS/MHz, you have 0.015151515 us/instruction, giving you about
792 instructions per 12us interrupt period, without including any bus wait
states etc. or other losses in time.  Even one context switch from eCos for
whatever reason may cause you to lose data if you really do need to service
it every 12uS.

That said, I would suggest just pointing the FIQ vector directly, and
managing your own stack.  You could just carve out a piece of memory for
yourself (many ways to do this, depending on your application) and use that.

--Chris

Re: How to handle very fast repeating interrupts?

[Martin Laabs]

Hello,

On Sun, 15 Feb 2009 23:33:55 +0100, Chris Zimman <czimman@bloomberg.com> wrote:

[Interrupt every 12us]

> Not to get of topic, but are you running eCos w/o the scheduler?  Because if
> you're not, I don't see how you are going to be able to keep up with the time
> interval that you need.

I use the scheduler...

> That said, I would suggest just pointing the FIQ vector directly, and
> managing your own stack.  You could just carve out a piece of memory for
> yourself (many ways to do this, depending on your application) and use that.

Yes - this was my idea too. Just beginnig a pice of assembler code at the
FIQ adress. (Even without a jump because it is at the end of the vector table)
Since the FIQ has 8 banked registers I fortunately do not even need a stack.

I'd like to place the ring-buffer into the fast onchip sram.
Can I just define some symbols in the linker script for that purpose? Or
can I tell the assembler to generate some symbols in a special section
like

.section ".sram_data"
_adc_buffer:
	.rept 64
	.long 0
	.endr
_adc_buffer_start:
	.long 0
_adc_buffer_end:
	.long 0


Greetings,
 Martin L.

RE: How to handle very fast repeating interrupts?

[Chris Zimman]

> I use the scheduler...

Then I'm surprised you're able to maintain the RT requirement that you need,
because it seems as that any scheduling or kernel event alone may be enough
to break it.
 
> Yes - this was my idea too. Just beginnig a pice of assembler code at
> the FIQ address. (Even without a jump because it is at the end of the
vector
> table)  Since the FIQ has 8 banked registers I fortunately do not even need
a
> stack.

> I'd like to place the ring-buffer into the fast onchip sram.
> Can I just define some symbols in the linker script for that purpose?
> Or can I tell the assembler to generate some symbols in a special section
> like
> 
> .section ".sram_data"
> _adc_buffer:
> 	.rept 64
> 	.long 0
> 	.endr
> _adc_buffer_start:
> 	.long 0
> _adc_buffer_end:
> 	.long 0

You probably don't even need to do that unless you have other external code
that needs to deal with it.
I mean this is kind of a one-off, so pretty much any solution you come up
with that's fast works here.

Can you do something like:

my_FIQ_ISR:
		[... FIQ setup ...]

		ldr 	r8_fiq, =ON_CHIP_SRAM
		ldr 	r9_fiq, =ADC_READ_ADDR
		ldr 	r10_fiq, #COUNT
1:
		ldr 	r11_fiq, [r9_fiq]
		str 	r11_fiq, [r8_fiq], #4
		sub	r10_fiq, r10_fiq, #1
		cmp 	r10_fiq, #0
		bne	1b

		[... cleanup/return ...]

--Chris

Re: How to handle very fast repeating interrupts?

[Martin Laabs]

Hello,

On Mon, 16 Feb 2009 13:08:34 +0100, Chris Zimman <czimman@bloomberg.com> wrote:

>> I use the scheduler...
>
> Then I'm surprised you're able to maintain the RT requirement that you need,
> because it seems as that any scheduling or kernel event alone may be enough
> to break it.

Is the FIQ interrupt disabled while scheduling? (And if so - is it
disabled that long time?) I hope it isn't ...
The only RT requirement is to read the data from the memory bus
12us after the interrupt at the latest. The processing afterwards
can be done in non-RT.



>> I'd like to place the ring-buffer into the fast onchip sram.
>> Can I just define some symbols in the linker script for that purpose?
>> Or can I tell the assembler to generate some symbols in a special section
>> like
>>
>> .section ".sram_data"
>> _adc_buffer:
>> 	.rept 64
>> 	.long 0
>> 	.endr
>> _adc_buffer_start:
>> 	.long 0
>> _adc_buffer_end:
>> 	.long 0
>
> You probably don't even need to do that unless you have other external code
> that needs to deal with it.

I'd like to read the data out of the buffer in a thread to filter and
store it afterwards. So I need some sort of external accessable buffer.
I imagine that the FIQ stores the data into a ring buffer and a normal
eCos thread is going to read out and process the data which accumulated 
in the buffer since the last time.

> I mean this is kind of a one-off, so pretty much any solution you come up
> with that's fast works here.
>
> Can you do something like:
>
> my_FIQ_ISR:
> 		[... FIQ setup ...]
>
> 		ldr 	r8_fiq, =ON_CHIP_SRAM
> 		ldr 	r9_fiq, =ADC_READ_ADDR
> 		ldr 	r10_fiq, #COUNT
> 1:
> 		ldr 	r11_fiq, [r9_fiq]
> 		str 	r11_fiq, [r8_fiq], #4
> 		sub	r10_fiq, r10_fiq, #1
> 		cmp 	r10_fiq, #0
> 		bne	1b
>
> 		[... cleanup/return ...]


Do I really have to use the _fiq appendix for the registers in the FIQ?
Anyway - this is very like I'd try it. But since a thread has to access the
buffer I have to implement a ringbuffer. (Because it could be interrupted
by the FIQ and this would overwrite the data in the buffer and/or corrupt
the counter.) And I don't need the loop since there is only one data
word I have to fetch each time.

Thank you,
 Martin L.

RE: How to handle very fast repeating interrupts?

[Chris Zimman]

> Is the FIQ interrupt disabled while scheduling? (And if so - is it
> disabled that long time?) I hope it isn't ...
> The only RT requirement is to read the data from the memory bus
> 12us after the interrupt at the latest. The processing afterwards
> can be done in non-RT.

Interrupts have to be disabled while you're in an ISR, and since the
scheduler is typically driven from a timer interrupt, you are going to run
into that.
I would be concerned that the time it takes to schedule anything may
interfere with the RT window that you need to operate in.

Not being familiar with your project, I can't really say, but if I were to
design something that needed this level of RT performance, I would probably
use a faster processor or a small CPLD/FPGA to help with the data
acquisition.

> I'd like to read the data out of the buffer in a thread to filter and
> store it afterwards. So I need some sort of external accessable buffer.
> I imagine that the FIQ stores the data into a ring buffer and a normal
> eCos thread is going to read out and process the data which accumulated
> in the buffer since the last time.

That's fine -- this can work just the way you want it to.

> Do I really have to use the _fiq appendix for the registers in the FIQ?
> Anyway - this is very like I'd try it. But since a thread has to access
> the buffer I have to implement a ringbuffer. (Because it could be
> interrupted by the FIQ and this would overwrite the data in the buffer
and/or
> corrupt the counter.) And I don't need the loop since there is only one
data
> word I have to fetch each time.

No, the _fiq appendix was just for the purposes of clarity in this example.  

The particulars of how you want to implement this are of course up to you and
beyond the scope of this general discussion.

--Chris

Re: How to handle very fast repeating interrupts?

[Martin Laabs]

Hi,

On Mon, 16 Feb 2009 13:48:22 +0100, Chris Zimman <czimman@bloomberg.com> wrote:

>> Is the FIQ interrupt disabled while scheduling? (And if so - is it
>> disabled that long time?) I hope it isn't ...
>> The only RT requirement is to read the data from the memory bus
>> 12us after the interrupt at the latest. The processing afterwards
>> can be done in non-RT.
>
> Interrupts have to be disabled while you're in an ISR, and since the
> scheduler is typically driven from a timer interrupt, you are going to run
> into that.

There is an option to allow nested interrupts. Since the FIQ priority
is higher than that of the timer (typical priority 0) it would interrupt
it.

> Not being familiar with your project, I can't really say, but if I were to
> design something that needed this level of RT performance, I would probably
> use a faster processor or a small CPLD/FPGA to help with the data
> acquisition.

There is a cpld already do deserialize the data. However - it has not enought
flipflops/macrocells to provide a buffer. (And no external or dualport memory.)

I will try the FIQ and nested interrupt aproach this evening and report the
results.

Greetings,
 Martin L.