Howto get lower latency on the SPI bus

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Howto get lower latency on the SPI bus

Benny B. Simonsen
Hi,

I'm using a CAN controller (MCP2515) which is connected via the SPI bus.
I'ts working relatively ok with the exception that I loose CAN frames with "high load". It gets worse if I just type something on the console
The MCP2515 has only 2 CAN RX buffers and in the worst case I can get a frame each ~175uS (running 250Kbit on the CAN bus).
I have made a few changes to the mcp251x driver which is included in the kernel (I used the 2.6.35 version as base), but still have the problems with lost frames because of RX overruns.

Any suggestion to how I can improve that? Is it possible to get a better response by renice something or? In the application I only get small burst of CAN frames so everything else could wait.


Thanks for any suggestions
Benny


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
Hi Benny,

> I'm using a CAN controller (MCP2515) which is connected via the SPI bus.
> I'ts working relatively ok with the exception that I loose CAN frames with
"high load".
> It gets worse if I just type something on the console

How is the incoming RX frames indicated to the OMAP? Through a GPIO causing
an interrupt which then starts a SPI transfer? Changing this to become a FIQ
could give it priority over others (see the thread called "timer FIQ and
CONFIG_FIQ" from approximately 14 days ago where you might be able to find
useful information), which might help you...
 
Best regards - Good luck
  Søren

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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen
Hi Søren,

The incoming RX frames is indicated the way you describe.

I will try to figure out how and if I can change it to FIQ, but I'm quite new to the "kernel Linux area" and don't know how it will work on a driver which uses threaded interrupt (I'm using the mcp251x driver from 2.6.35). If I understand it correct FIQ will ensure that I arrive to my handler fast even if the OMAP is processing a normal IRQ, but after that any IRQ will actually be able to interrupt the handler. If thats what happens then I just have to be sure that my handler will have priority above handlers from other IRQ's, but how or am I way off here?

Thanks

Benny

2010/8/9 Søren Steen Christensen <[hidden email]>
Hi Benny,

> I'm using a CAN controller (MCP2515) which is connected via the SPI bus.
> I'ts working relatively ok with the exception that I loose CAN frames with
"high load".
> It gets worse if I just type something on the console

How is the incoming RX frames indicated to the OMAP? Through a GPIO causing
an interrupt which then starts a SPI transfer? Changing this to become a FIQ
could give it priority over others (see the thread called "timer FIQ and
CONFIG_FIQ" from approximately 14 days ago where you might be able to find
useful information), which might help you...

Best regards - Good luck
 Søren

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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

dtran11
Hi Ben,

I am having the same problem. Did you find a way to speed up the mcp251x driver? Also for some reason I am not able to send can messages with the cansend utility. I can only receive with candump.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

roystonvasey

dtran11 wrote
Hi Ben,

I am having the same problem. Did you find a way to speed up the mcp251x driver? Also for some reason I am not able to send can messages with the cansend utility. I can only receive with candump.

Thanks.
Hello,
With the socketcan from mainline kernel 2.6.34 I cant send only receive. sending frames eventually results in a no buffer space error so it looks like data isn't getting to the MCP2515. If I do a 'ifconfig can0 down' after a no buffer space error a single frame is sent so the hardware is OK. Using a virtual CAN (vcan) interface I can send and receive so it looks like a driver problem.
I'm going to try using the SocketCan svn as it uses IRQs rather than work queues to see if that works.

Cheers Mike.
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen
2010/8/12 roystonvasey <[hidden email]>



dtran11 wrote:
>
> Hi Ben,
>
> I am having the same problem. Did you find a way to speed up the mcp251x
> driver? Also for some reason I am not able to send can messages with the
> cansend utility. I can only receive with candump.
>
> Thanks.
>

Hello,
With the socketcan from mainline kernel 2.6.34 I cant send only receive.
sending frames eventually results in a no buffer space error so it looks
like data isn't getting to the MCP2515. If I do a 'ifconfig can0 down' after
a no buffer space error a single frame is sent so the hardware is OK. Using
a virtual CAN (vcan) interface I can send and receive so it looks like a
driver problem.
I'm going to try using the SocketCan svn as it uses IRQs rather than work
queues to see if that works.

Cheers Mike.
--
View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29414547.html
Sent from the Gumstix mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

I were able to send with the 2.6.34 version.
Now I'm using all the can stuff from 2.6.35 which I have made a patch which can be found here.
It's does still loose RX packets at high load, but it's better.

/Benny



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

dtran11
Which bitbake file should I apply this patch to?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen


2010/8/12 dtran11 <[hidden email]>

Which bitbake file should I apply this patch to?

Thanks.
--
View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29420718.html
Sent from the Gumstix mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


It's a patch against mainline kernel 2.6.35.

Do something like this script

*********************'
cd ${OVEROTOP}
bitbake -c clean linux-omap3
bitbake -c configure linux-omap3
cp -r user.collection/Linux_2.6.35_can/* tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r81/git/
patch tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r81/git/drivers/net/can/mcp251x.c < user.collection/mcp251x_patch/mcp251x.c.patch
bitbake omap3-console-image
*********************'
Where user.collection/Linux_2.6.35_can is the CAN related files from 2.6.35 (All files from drivers/net/can, include/linux/can and net/can)

I still don't get why you have the TX problems. A stupid question, but are you sure you have a CAN device attached that will send an acknowledge?

/Benny





------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

dtran11
Thanks for the script.

I built a can bus monitor with a pic32 some time ago. It is able to send and receive messages on the CAN bus. When I use candump, I see my generated can messages from the pic32. However when I use cansend to send a message, I do not see it on the pic32 side. I verified that my pic32 node is able to receive messages from my other nodes.

Another clue that it is not sending on the gumstix/mcp2515 side is that the tx packets count is always zero.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
In reply to this post by Benny B. Simonsen
Hi Benny,

> The incoming RX frames is indicated the way you describe.
Great :-)

> I will try to figure out how and if I can change it to FIQ, but I'm quite
new
> to the "kernel Linux area" and don't know how it will work on a driver
which
> uses threaded interrupt (I'm using the mcp251x driver from 2.6.35).
Hmm - I fear that you then won't gain anything in particular. The complete
idea of using FIQ is to get priority. In case of just getting priority for
scheduling some kind of DFC (thread) for doing the interesting time critical
work (reading stuff from the SPI bus) with interrupts enabled later I think
you might as well do nearly as good with just the current IRQ version. You
would need to get the critical stuff done in the FIQ context as well as I
see it, but this of cause might cause other interrupts to not be served
within time - The beauty of having to serve hard real-time stuff... :-)

> If I understand it correct FIQ will ensure that I arrive to my handler
fast even
> if the OMAP is processing a normal IRQ, but after that any IRQ will
actually be
> able to interrupt the handler.
I'm not sure I follow you 100% on this. An FIQ can break in to a IRQ, but
not the other way around.
Running in FIQ context will be like running with "Interrupts off" for normal
IRQs...

> If thats what happens then I just have to be sure
> that my handler will have priority above handlers from other IRQ's, but
how or
> am I way off here?
I'm not sure I follow you on this either - Please try to elaborate a bit and
I will try to comment

I hope this helped you forward - Best regards - Good luck
  Søren

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



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen
Hi Søren

2010/8/12 Søren Steen Christensen <[hidden email]>
Hi Benny,

> The incoming RX frames is indicated the way you describe.
Great :-)

> I will try to figure out how and if I can change it to FIQ, but I'm quite
new
> to the "kernel Linux area" and don't know how it will work on a driver
which
> uses threaded interrupt (I'm using the mcp251x driver from 2.6.35).
Hmm - I fear that you then won't gain anything in particular. The complete
idea of using FIQ is to get priority. In case of just getting priority for
scheduling some kind of DFC (thread) for doing the interesting time critical
work (reading stuff from the SPI bus) with interrupts enabled later I think
you might as well do nearly as good with just the current IRQ version. You
would need to get the critical stuff done in the FIQ context as well as I
see it, but this of cause might cause other interrupts to not be served
within time - The beauty of having to serve hard real-time stuff... :-)

> If I understand it correct FIQ will ensure that I arrive to my handler
fast even
> if the OMAP is processing a normal IRQ, but after that any IRQ will
actually be
> able to interrupt the handler.
I'm not sure I follow you 100% on this. An FIQ can break in to a IRQ, but
not the other way around.
Running in FIQ context will be like running with "Interrupts off" for normal
IRQs...

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 ;) 
Off topic off:

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?

 
> If thats what happens then I just have to be sure
> that my handler will have priority above handlers from other IRQ's, but
how or
> am I way off here?
I'm not sure I follow you on this either - Please try to elaborate a bit and
I will try to comment
 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). 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?

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?

Thanks for any feedback.
Benny


I hope this helped you forward - Best regards - Good luck
 Søren

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



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

ScottEllis
In reply to this post by Søren Steen Christensen
Hi Soren, Benny,

I agree with Soren that the interrupt handling priority probably won't get you
better spi speeds.

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.

That wasn't the big latency problem though.

Inside the irq handler for my tests, I submitted a spi request via spi_async
similar to the mcp251x driver. (The mcsp251x driver uses spi_sync, but
internally it's the same thing, spi_sync calls spi_async.)

It wasn't until at least 75 us later until I would see the first clock signal on the
spi bus. This was on an otherwise completely idle system. All the measurements
were done with an o-scope.

Inside the omap2_mcspi driver, the spi_message is put onto a linux work queue
in the controller driver's transfer function. The message gets processed
asynchronously when the kernel decides and importantly outside of the caller's
control. This is the explicit design of the linux spi subsystem.

There is no facility in the existing Linux spi framework for a protocol driver like the
mcp251x to force immediate read/writes on the spi bus. I didn't test further since it
was already too slow for this particular project, but I believe the 75 us I was measuring
is a best case and will only get worse on a busier system.

Possibly this spi latency is more of an issue then the irq response time.

Best Regards,
Scott

Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

dtran11
In reply to this post by dtran11
I was able to fix my transmit problem by following the steps in this blog: http://www.bobandeileen.com/?p=479

He modified u-boot to change pin 114 from internal pull down to pull up.
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen


2010/8/16 dtran11 <[hidden email]>

I was able to fix my transmit problem by following the steps in this blog:
http://www.bobandeileen.com/?p=479

He modified u-boot to change pin 114 from internal pull down to pull up.
--
View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29449177.html
Sent from the Gumstix mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

 
Ok thats why I didn't have the TX problem. I use a different level converter (TXB0104)

BR
Benny


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Benny B. Simonsen
In reply to this post by Søren Steen Christensen


2010/8/15 Søren Steen Christensen <[hidden email]>
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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

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.

Thanks
Benny



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
In reply to this post by Benny B. Simonsen

> Ok thats why I didn't have the TX problem. I use a different level converter (TXB0104)

 

Why should that be related to the level-converter? Being output the pin should be driven HIGH and you should thereby not be relying on the pull (neither up nor down).

 

I think it’s more related to requiring the line to be HIGH between SPI writes (when CS isn’t active)? Which won’t be the case if it’s set for pull-down AFAIR (although I’m not 100% sure)

 

Anything I missed?

  Søren

 

---

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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
In reply to this post by Benny B. Simonsen

Shame on me – Not reading the previous email in enough detail.

It was talking about the interrupt line and not the SPI SIMO line as I imagined. Then the result of cause depends on the output of the used level-converter – I totally agree…

 

Sorry about the error

  Søren

 

---

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

 

From: Søren Steen Christensen [mailto:[hidden email]]
Sent: Tuesday, August 17, 2010 11:48 PM
To: 'General mailing list for gumstix users.'
Subject: RE: [Gumstix-users] Howto get lower latency on the SPI bus

 

> Ok thats why I didn't have the TX problem. I use a different level converter (TXB0104)

 

Why should that be related to the level-converter? Being output the pin should be driven HIGH and you should thereby not be relying on the pull (neither up nor down).

 

I think it’s more related to requiring the line to be HIGH between SPI writes (when CS isn’t active)? Which won’t be the case if it’s set for pull-down AFAIR (although I’m not 100% sure)

 

Anything I missed?

  Søren

 

---

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


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

ScottEllis
In reply to this post by Benny B. Simonsen
Here's a project to take a look at. It's where I got my 12 us irq latency number.

http://github.com/scottellis/overo-irqlat

I think I am measuring the irq latency here, but I have never had anyone double check my assumptions.

Feedback would be appreciated since I use the results from this test as accurate when working new projects.

Reply | Threaded
Open this post in threaded view
|

Re: Howto get lower latency on the SPI bus

Søren Steen Christensen
Hi Scott,

> Here's a project to take a look at. It's where I got my 12 us irq latency
> number. http://github.com/scottellis/overo-irqlat
> I think I am measuring the irq latency here, but I have never had anyone
> double check my assumptions.
> Feedback would be appreciated since I use the results from this test as
> accurate when working new projects.

I now had a little time to look at you code, and I think it's basically OK.
I however have a couple of ideas for minor improvements.

1) You are reading gpio_get_value() in the interrupt routing - Why is this
needed? As I see it, it's just adding extra delay since the GPIO sub system
on OMAP3 is rather slow (~4MHz AFAIR) meaning that it would show the
interrupt latency a little longer than it actually is :-)

2) Likewise I would add a simple loop of:
for (int i=0; i<10; i++) {
   gpio_set_value(TEST_PIN, 0);
   gpio_set_value(TEST_PIN, 1);
}
in order to use the scope to measure the exact latency of the gpio_set()
routine in order to account for the delay for setting the GPIO in the
interrupt-routine.

This being said I think the above comments will only sum to around ~500ns
max => Your initial measurement of ~12us will still be valid...

Best regards
  Søren

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



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
12