Re: [Gumstix-users] Howto get lower latency on the SPI bus

[Søren S. C. <li...@ss...>]

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
problem 
> (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
afterwards...

> 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
only 
> 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?
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 changing
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 have
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
  Søren 

---
SSC Solutions ApS - Denmark - www.ssc-solutions.dk