Reply by karthikbalaguru●January 21, 20082008-01-21
NewToFPGA wrote:
> Can an RTOS guarantee that interrupt latency will never exceed a
> predefined maximum? if so, where do we define this value in the
> programming?
No. But, It can be done by careful design of your system by you.
Karthik Balaguru
Reply by Arlet Ottens●January 21, 20082008-01-21
NewToFPGA wrote:
> Do we need to configure Interrupt rate limiting on the processor per
> application basis? If so, can I configure it on only selective
> interrupts?
If a device supports it properly, it can be always be enabled. If the
amount of traffic is low, the device won't delay the interrupts (low
latency/bandwidth). Only if the interrupt rate is going up, and there
is still FIFO space available, the interrupt rate will be limited, which
trades off higher latency for higher bandwidth.
Consult the documentation of any devices capable of interrupt rate
limiting for exact details of this option.
Reply by NewToFPGA●January 21, 20082008-01-21
Do we need to configure Interrupt rate limiting on the processor per
application basis? If so, can I configure it on only selective
interrupts?
Reply by Tim Wescott●January 20, 20082008-01-20
On Sun, 20 Jan 2008 17:17:50 -0800, NewToFPGA wrote:
> On Jan 20, 4:38 pm, Arlet Ottens <usene...@c-scape.nl> wrote:
>> NewToFPGA wrote:
>> > In Wikipedia it says that modern hardware implements interrupt rate
>> > limiting that reduces the amount of time spent servicing interrupts,
>> > allowing the processor to spend more time doing useful work. Does it
>> > not make the system loose some of the data comming in and not get
>> > chance to get processed?
>>
>> Interrupt rate limiting is best used in combination with a FIFO in the
>> device. Based on interrupt timing, the device can delay interrupts if
>> they occur too close together, and save up the date in the FIFO. When
>> the FIFO is getting full, it no longer delays the interrupt so the CPU
>> can process all the data at once, reducing overhead.
>
> Is it safe to assume that if the expected rate of the interrupts are
> high and it is most likely that the FIFO going to get full then there is
> no advantage from Interrupt rate limiting?
FIFO'ing data to reduce interrupt rates works on comm systems when each
bit of data doesn't have to be responded to in an extremely snappy
manner, and when the overhead of calling the interrupt is expensive
compared to the cost of processing a byte of data - so the processor
works on the data in small batches instead of dropping everything, doing
one, picking everything up, dropping everything, etc.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by NewToFPGA●January 20, 20082008-01-20
On Jan 20, 4:38=A0pm, Arlet Ottens <usene...@c-scape.nl> wrote:
> NewToFPGA wrote:
> > In Wikipedia it says that modern hardware implements interrupt rate
> > limiting that reduces the amount of time spent servicing interrupts,
> > allowing the processor to spend more time doing useful work. Does it
> > not make the system loose some of the data comming in and not get
> > chance to get processed?
>
> Interrupt rate limiting is best used in combination with a FIFO in the
> device. Based on interrupt timing, the device can delay interrupts if
> they occur too close together, and save up the date in the FIFO. When
> the FIFO is getting full, it no longer delays the interrupt so the CPU
> can process all the data at once, reducing overhead.
Is it safe to assume that if the expected rate of the interrupts are
high and it is most likely that the FIFO going to get full then there
is no advantage from Interrupt rate limiting?
Reply by Arlet Ottens●January 20, 20082008-01-20
NewToFPGA wrote:
> In Wikipedia it says that modern hardware implements interrupt rate
> limiting that reduces the amount of time spent servicing interrupts,
> allowing the processor to spend more time doing useful work. Does it
> not make the system loose some of the data comming in and not get
> chance to get processed?
Interrupt rate limiting is best used in combination with a FIFO in the
device. Based on interrupt timing, the device can delay interrupts if
they occur too close together, and save up the date in the FIFO. When
the FIFO is getting full, it no longer delays the interrupt so the CPU
can process all the data at once, reducing overhead.
Reply by NewToFPGA●January 20, 20082008-01-20
In Wikipedia it says that modern hardware implements interrupt rate
limiting that reduces the amount of time spent servicing interrupts,
allowing the processor to spend more time doing useful work. Does it
not make the system loose some of the data comming in and not get
chance to get processed?
Reply by Tim Wescott●January 20, 20082008-01-20
On Sun, 20 Jan 2008 14:30:37 +0000, Alex Colvin wrote:
>>> Can an RTOS guarantee that interrupt latency will never exceed a
>>> predefined maximum? if so, where do we define this value in the
>>> programming?
>>>
>>> thanks.
>
>>No, but a competent programmer with a competently-written RTOS can.
>
> I might point out that this also requires guaranteed instruction
> timings. They can be long, but they need to be bounded. Caches and
> pipeline flushes make these hard to determine.
>
> And measuring ISR latency doesn't cut it, unless you measure these
> effects.
>
> Which is why you see more DSPs and RISCS and fewer pentia in RTOSs.
Too true -- but nearly all of the RISC chips, and some of the higher-end
DSPs, feature pipelines and/or caches, so that's getting harder, too.
In theory one could calculate this in a sensible way, but it would take
deep knowledge of both the processor and RTOS at hand, and it would
probably be tedious in the extreme.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by Alex Colvin●January 20, 20082008-01-20
>> Can an RTOS guarantee that interrupt latency will never exceed a
>> predefined maximum? if so, where do we define this value in the
>> programming?
>>
>> thanks.
>No, but a competent programmer with a competently-written RTOS can.
I might point out that this also requires guaranteed instruction timings.
They can be long, but they need to be bounded. Caches and pipeline flushes
make these hard to determine.
And measuring ISR latency doesn't cut it, unless you measure these
effects.
Which is why you see more DSPs and RISCS and fewer pentia in RTOSs.
--
mac the na�f
Reply by Tim Wescott●January 20, 20082008-01-20
On Sat, 19 Jan 2008 19:43:13 -0800, NewToFPGA wrote:
> Can an RTOS guarantee that interrupt latency will never exceed a
> predefined maximum? if so, where do we define this value in the
> programming?
>
> thanks.
No, but a competent programmer with a competently-written RTOS can.
As Grant pointed out in his thread, the RTOS can only guarantee that it
will respond to OS calls in some maximum time, and that it will only
block interrupts for some maximum time. The RTOS writers have no control
over what the system programmer does with interrupts or the RTOS, which
is where the competent programmer comes in.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html