Its the using spidev results that are the issue, the GPIO bit option was just to "prove" the real-time code was correct enough to not be the problem, and it wasn't userspace to kernel and back overhead that was causing the long latencies latencies.
To use spidev the test program needs to be edited for the proper /dev/spidevX.Y device name string and launched as: "swave_spidev spi" as root user for realtime priority. The nature of spidev means no actual hardware needs to be connected to the spi pins. Seeing what kernel version the apparent fix happened might be helpful in also solving the issue on Beaglebone and Pandaboard as well. As was discussed here a while ago: http://www.eewiki.net/display/linuxonarm/PandaBoard_Comments The BeagleBoard xM with v3.7.10-x10 up to now had been the closest to being real-time enough. --wally. On Monday, September 16, 2013 2:36:30 PM UTC-5, Celso Providelo wrote: > > More results from an older kernel: > > {{{ > Using GPIO 32. > Using realtime priority. > Interval Max(mS): 2.6 @N=250399 Min: 0.1 @N=250401 Total Samples: > 300000 > gpio time Max(uS): 1232.5 Min: 7.8 > Intervals +50% over N: 37 0.0% -50% under N: 38 0.0% > drops, N intervals >= 2 mS: 20 0.0% > > cprov@bone-one:~/spi$ uname -a > Linux bone-one 3.8.8-bone14 #1 SMP Wed Apr 24 13:59:33 UTC 2013 armv7l > armv7l armv7l GNU/Linux > > cprov@bone-one:~/spi$ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 13.04 > Release: 13.04 > Codename: raring > }}} > > > > On Mon, Sep 16, 2013 at 1:32 PM, <[email protected] <javascript:>> wrote: > >> Some more: >> >> Using spidev. >> Using realtime priority. >> Interval Max(mS): 1.6 @N=721 Min: 0.4 @N=722 Total Samples: 300000 >> spidev time Max(uS): 1518.5 Min: 56.6 >> Intervals +50% over N: 1 0.0% -50% under N: 1 0.0% >> drops, N intervals >= 2 mS: 0 0.0% >> >> arau@beaglebone1:~$ uname -a >> Linux beaglebone1 3.8.13-bone26 #1 SMP Sat Aug 17 00:43:59 UTC 2013 >> armv7l armv7l armv7l GNU/Linux >> >> arau@beaglebone1:~$ more /etc/lsb-release >> DISTRIB_ID=Ubuntu >> DISTRIB_RELEASE=13.04 >> DISTRIB_CODENAME=raring >> DISTRIB_DESCRIPTION="Ubuntu 13.04" >> >> On Saturday, September 14, 2013 7:48:18 PM UTC+2, [email protected] wrote: >>> >>> Thank you for running the test program and reporting the results. I >>> hope someone figures out the problem sometime soon. >>> >>> >>> On Saturday, June 8, 2013 3:24:45 PM UTC-5, Johan Henselmans wrote: >>>> >>>> I just tested it with the latest img via >>>> BBB-eMMC-flasher-2013.06.06.**img, >>>> and installed spidev via the instructions of Carl Johnson, on a BeagleBone >>>> Black. >>>> >>>> These were the results I got: >>>> >>>> root@beaglebone:/home/golang# ./swave_spidev spi >>>> Using spidev. >>>> Using realtime priority. >>>> Interval Max(mS): 5.9 @N=246713 Min: 0.2 @N=128385 Total Samples: >>>> 300000 >>>> spidev time Max(uS): 5742.4 Min: 109.9 >>>> Intervals +50% over N: 69 0.0% -50% under N: 193 0.1% >>>> drops, N intervals >= 2 mS: 53 0.0% >>>> root@beaglebone:/home/golang# ./swave_spidev >>>> Using GPIO 32. >>>> Using realtime priority. >>>> Interval Max(mS): 1.3 @N=163452 Min: 0.7 @N=163453 Total Samples: >>>> 300000 >>>> gpio time Max(uS): 374.4 Min: 17.8 >>>> Intervals +50% over N: 0 0.0% -50% under N: 0 0.0% >>>> drops, N intervals >= 2 mS: 0 0.0% >>>> >>>> It's still not under 1.5 ms, or comparable with the gpio results, but >>>> it is getting better. >>>> >>>> On Tuesday, June 4, 2013 4:09:14 PM UTC+2, [email protected] wrote: >>>>> >>>>> IMHO SPI should be removed from the "feature" set for the Beaglebone, >>>>> Beaglebone Black, and Pandaboard. Even if you manage to configure and >>>>> build a kernel with SPI support you will find it suffers from random long >>>>> latencies in the 4-15 mS range running a 1 mS servo loop. I've posted >>>>> real time priority test code that shows the issue with SPIDEV and shows >>>>> essentially perfect timing if a GPIO output is toggled instead of doing a >>>>> SPIDEV write, proving the latency is in the SPI device system calls. >>>>> >>>>> The Beagleboard has so far shown the best performance with this test >>>>> code, but still is not good enough. >>>>> >>>>> I've attached the test code here again for your convenience, although >>>>> the SPIDEV and GPIO names will need to be changed to match your board and >>>>> kernel, as this is for the Pandaboard. >>>>> >>>>> If anyone can run this test code and get SPIDEV worse case latency >>>>> below 1.5mS I'd love to know about it and which board and kernel you are >>>>> using! >>>>> >>>>> --wally. >>>>> >>>>> >>>>> On Wednesday, May 22, 2013 5:21:54 PM UTC-5, Tianlan Wang wrote: >>>>>> >>>>>> After reading a lot of threads, I am still a little confused about >>>>>> device tree mechanism. Could anyone give me a overview of how it works? >>>>>> >>>>>> - Update device tree on run time is called overlay. It need to >>>>>> create a .dst file and compile it. then put it into a directory. >>>>>> >>>>>> >>>>>> 1. it will tell kernel turn on the SPI hardware >>>>>> 2. Set the pin to correct model, so that the signal >>>>>> is available at headers >>>>>> >>>>>> >>>>>> - Then I need to install spidev, which is the driver of SPI in >>>>>> linux >>>>>> >>>>>> This is my understanding, I would be surprised if it is correct, So >>>>>> please point out where ever I am wrong. >>>>>> >>>>>> BTW, I have some silly question again: >>>>>> >>>>>> 1. Some guy mentioned SPI1 is used by HDMI, however, after I >>>>>> went through the BBB_SRM. I merely found *Table13. P8 LCD >>>>>> conflict Pin* on *Pg.87* shows the pin that hdmi uses. SPI1 is on >>>>>> *P9*, so where do you guys finger out that SPI1 is used by hdmi. >>>>>> 2. where can I find source of BONESCRIPT, or how do you find >>>>>> where is the source of bonescript. >>>>>> 3. On BBB_SRM.pdf *page 96*, the table shows AIN0-AIN3 is on P8, >>>>>> it is different from Table 11 on *page 77. *is it typo? >>>>>> >>>>>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Celso Providelo > IRC: cprov, Skype: cprovidelo > 1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469 > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
