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&nbsp;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&#2013265935;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