From: Benny B. S. <bb...@se...> - 2010-08-08 08:33:15
|
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 |
From: Søren S. C. <li...@ss...> - 2010-08-08 22:52:31
|
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 |
From: Benny B. S. <bb...@se...> - 2010-08-10 06:14:16
|
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 <li...@ss...> > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: dtran11 <dt...@gm...> - 2010-08-11 22:03:24
|
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. -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29413347.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: dtran11 <dt...@gm...> - 2010-08-11 22:03:24
|
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. -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29413346.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: roystonvasey <mik...@ma...> - 2010-08-12 01:35:29
|
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. |
From: Benny B. S. <bb...@se...> - 2010-08-12 07:25:59
|
2010/8/12 roystonvasey <mik...@ma...> > > > > 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 > gum...@li... > 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. http://old.nabble.com/MCP-2515-RX-problems-td29365471.html It's does still loose RX packets at high load, but it's better. /Benny |
From: dtran11 <dt...@gm...> - 2010-08-12 16:43:20
|
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. |
From: Benny B. S. <bb...@se...> - 2010-08-12 17:48:43
|
2010/8/12 dtran11 <dt...@gm...> > > 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 > gum...@li... > 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 |
From: dtran11 <dt...@gm...> - 2010-08-12 17:58:32
|
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 varied 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. -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29421506.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-08-12 21:35:59
|
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 |
From: Benny B. S. <bb...@se...> - 2010-08-13 08:38:43
|
Hi Søren 2010/8/12 Søren Steen Christensen <li...@ss...> > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: ScottEllis <sco...@gm...> - 2010-08-13 10:38:14
|
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 -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29427479.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-08-15 20:46:39
|
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 arent 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 |
From: dtran11 <dt...@gm...> - 2010-08-16 17:13:34
|
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. |
From: Benny B. S. <bb...@se...> - 2010-08-17 21:21:24
|
2010/8/16 dtran11 <dt...@gm...> > > 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 > gum...@li... > 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 |
From: Søren S. C. <li...@ss...> - 2010-08-18 00:04:38
|
> 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 its more related to requiring the line to be HIGH between SPI writes (when CS isnt active)? Which wont be the case if its set for pull-down AFAIR (although Im not 100% sure) Anything I missed? Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk <http://www.ssc-solutions.dk/> |
From: Benny B. S. <bb...@se...> - 2010-08-17 21:35:50
|
2010/8/15 Søren Steen Christensen <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 > > > > ------------------------------------------------------------------------------ > 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 > gum...@li... > 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 |
From: Søren S. C. <li...@ss...> - 2010-08-17 22:15:06
|
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 - <http://www.ssc-solutions.dk/> www.ssc-solutions.dk From: Søren Steen Christensen [mailto:li...@ss...] 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 its more related to requiring the line to be HIGH between SPI writes (when CS isnt active)? Which wont be the case if its set for pull-down AFAIR (although Im not 100% sure) Anything I missed? Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk <http://www.ssc-solutions.dk/> |
From: ScottEllis <sco...@gm...> - 2010-08-18 23:37:55
|
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. -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29477118.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-09-05 13:08:34
|
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 |
From: ScottEllis <sco...@gm...> - 2010-09-05 20:53:15
|
Hi Soren, Søren Steen Christensen wrote: > > 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 :-) > Fixed. Soren Steen Christensen wrote: > > 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. > I'll add this test at a later time. Thanks for taking the time to look at this. Best regards, Scott -- View this message in context: http://old.nabble.com/Howto-get-lower-latency-on-the-SPI-bus-tp29378861p29627874.html Sent from the Gumstix mailing list archive at Nabble.com. |