2010/8/15 Søren Steen Christensen <lists@...>
> Hi Scott and Benny,
> Trying to make a combined answer to your two emails :-)
> > BennyBS: Off topic on:
> > I guess my understanding is correct, but my english writing might be the
> > (I could do the writing in danish, but guess a few on the list would
> consider that as a problem ;)
> Feel free to contact me off list if you need consultant help (in Danish :-)
> After all Hobro is pretty close to Aalborg :-)
> > BennyBS: A FIQ can't break into an IRQ, but when the driver uses threaded
> interrupt then
> > the only thing that happens in the FIQ (in the actual interrupt) is to
> wake the
> > handler thread and when that handler thread is running then any IRQ could
> > interrupt it (the handler thread is just a normal process). Correct?
> A FIQ can interrupt an IRQ - In IRQ can't interrupt a FIQ...
> Both a FIQ and an IRQ can interrupt a threaded handler scheduled
> > BennyBS: If every driver did use threaded interrupts, then the time spent
> in the actual
> > interrupt routines would be very minimal (the interrupt routine should
> > take care of wake the correct handler thread).
> Agree, but the time spend in the handler thread might still be long...
> > BennyBS: The priority between getting the actual work done after an
> interrupt would
> > then be decided by the nice level off the different handler threads.
> Correct - Assuming that a context switch can happen straight after an
> interrupt - You will of cause have the delay of the context switch and you
> might as well have parts of a thread running with interrupts off, which as
> well would affect your worst case timing.
> > BennyBS: If I have 2 X Correct then the MCP2515 interrupt handler thread
> should have a low
> > nice level and everything will be great unless there is just one other
> driver that
> > spends "long" time in an interrupt routine. Correct?
> Agree - Again assuming that you aren’t already killed by the time of the
> context switch or something in your threaded handler as suggested by Scott
> (see below)? I don't know how critical CAN timing is?
> > ScottE: I did some tests for another project awhile back. The time to
> respond to an incoming interrupt
> > on a gpio pin was consistently around 10-12 us. I have no experience with
> fiq handlers, but I
> > imagine this is what you would be trying to improve with that approach.
> I'm not sure you can bring down the average of this number a lot by
> from IRQ to FIQ, but you can bring down the worst case value, which would
> occur if you were running in a IRQ when the GPIO is flipped => You will
> to wait for the current IRQ to finish before being able to service the new
> IRQ. For a FIQ you can go on immediately (assuming no other FIQs already
> running of cause - I this case you will be back to square one :-)
> > ScottE: Possibly this spi latency is more of an issue then the irq
> response time.
> Totally agree with your comments about the SPI sub-system and the risks of
> the way it's implemented for a task like this. Thinking about it I actually
> as well think this is the biggest problem - Not the IRQ/FIQ response time,
> but I order to have a fully stable system I think you would need to be in
> better/full control of both...
> Best regards
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
> This SF.net email is sponsored by
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> gumstix-users mailing list
Hi Søren, Scott
Thanks again for the input.
I'm a little busy with other things for the moment, but hope I have time to
do some further testing next week.
The first thing I will start with is to check if the IRQ latency is as short
on my system as what Scott had seen (~12uS).
I will post the result here.