I use *__delay_cycles()* on the PRU to get accurate timing. Each cycle is 5 
ns.  

Here [1] is an example of passing data between the PRU and the ARM.

Try googling *pthread tutorial,* there appear to be many examples.

I'm still voting for pthreads.

--Mark

[1] 
https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_neopixels_through_a_kernel_driver
 

On Thursday, February 18, 2021 at 11:27:48 AM UTC-5 
[email protected] wrote:

> I think if I could just find how to read the clock on the PRU with C, I 
> can probably take it from here.   And of course, it needs to be giving me 
> milliseconds.  From what I read the main clock functions don't work below 
> seconds.
>
>
> On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:
>
>> Have you tried starting a pthread that sleeps for 20 ms and then it stops 
>> the read?
>>
>> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
>> [email protected] wrote:
>>
>>> Mark, 
>>>
>>> I use usleep a lot but in this case I don't want to pause.  I want to 
>>> keep reading the sensors for N milliseconds.   I do pause between reads 
>>> using usleep(20000) to create a 20ms delay between sensor reads.   I 
>>> started with a routine that essentially counts up the amount of time by 
>>> estimating how long the sensor read routine takes plus the fixed delay time 
>>> between sensor reads and accumulating this value in a while loop until it 
>>> reaches the 'stop value' that is approximately the time the valve needs to 
>>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.   
>>>
>>> In essence, I'm looking to interrupt the sensor read procedure after N 
>>> milliseconds pass.   
>>>
>>> Walter
>>>
>>>
>>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>>>
>>>> Walter:
>>>>   It's good to hear you have the PRUs working.  I still think if all 
>>>> you need is millisecond timing the PRUs are over kill.
>>>>
>>>> In C you can use *usleep()* and pass it the number of microseconds you 
>>>> want to pause.
>>>>
>>>> --Mark
>>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>>> [email protected] wrote:
>>>>
>>>>> I've gone through the cookbook and it's very helpful. 
>>>>>
>>>>> I'm still fuzzy on how to do what I need to do.  
>>>>>
>>>>> My main code for controlling the valves, getting user input, etc. is 
>>>>> in C.  
>>>>>
>>>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>>>> procedure the number of milliseconds it should read the sensors and then 
>>>>> return to the main program and turn the valves off.   The number of 
>>>>> milliseconds can, and will likely, change depending on what we are 
>>>>> processing with these valves.   I get that input at the start of the main 
>>>>> program.    
>>>>>
>>>>> My thought is that in the procedure that reads the sensors, it will 
>>>>> grab a start time (doesn't have to be actual time) value from the PRU, 
>>>>> read 
>>>>> the sensors, and loop until the current time-start time equals the amount 
>>>>> of time it should read the sensors.  Then it will return to the main 
>>>>> program.
>>>>>
>>>>> I just don't know how to read the PRU's clock to get the time values.  
>>>>>  I don't think I saw an example in the cookbook for 'branching' out from 
>>>>> a 
>>>>> main program to use the PRUs for this type of processing.  Just point me 
>>>>> in 
>>>>> the right direction, please.
>>>>>
>>>>> Walter
>>>>>
>>>>>
>>>>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>>>>
>>>>>> Mark ,
>>>>>>
>>>>>> It is working with the updated OS.  Thanks so much!   
>>>>>>
>>>>>> Now I will explore how to get the simple timing that I need using the 
>>>>>> PRU.
>>>>>>
>>>>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer 
>>>>>> wrote:
>>>>>>
>>>>>>> Mark, 
>>>>>>>
>>>>>>> With the current OS there isn't a /dev/remoteproc even.   
>>>>>>>
>>>>>>> I'm going to try the updated OS build this morning.  
>>>>>>>
>>>>>>> Walter
>>>>>>>
>>>>>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>>>>>
>>>>>>>> What do you get running
>>>>>>>> *ls /dev/remoteproc*
>>>>>>>>
>>>>>>>> I get:
>>>>>>>> *ls -ls /dev/remoteproc*
>>>>>>>> total 0
>>>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>>>>>>> /sys/class/remoteproc/remoteproc1
>>>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>>>>>>>> /sys/class/remoteproc/remoteproc2
>>>>>>>>
>>>>>>>> If you are missing pruss-core0 and pruss-core1 you could try adding 
>>>>>>>> the links by hand and see what happens.
>>>>>>>>
>>>>>>>> *cd /dev/remoteproc*
>>>>>>>>
>>>>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>>>>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>>>>>>>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>>>>>>>> [email protected] wrote:
>>>>>>>>
>>>>>>>>> I'll get this one onto an SD card and give it a try.   If I can 
>>>>>>>>> just get this configured I think I can make quick work of this 
>>>>>>>>> problem!  
>>>>>>>>>
>>>>>>>>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Good point, it should work....  I'm running a newer test 
>>>>>>>>>> image[1], but I took my Beagle home so I can't do a quick check on 
>>>>>>>>>> it until 
>>>>>>>>>> later.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --Mark
>>>>>>>>>> [1]
>>>>>>>>>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>
>>>>>>>>>>> I asked because the ones on the page @ the link are older than 
>>>>>>>>>>> the one I have installed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. 
>>>>>>>>>>> Yoder wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On newer versions of the SD card image /var/lib/cloud9 is a git 
>>>>>>>>>>>> repo which you can do a git pull to update.  Your version is too 
>>>>>>>>>>>> old.
>>>>>>>>>>>>
>>>>>>>>>>>> Follow the instructions at: 
>>>>>>>>>>>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>>>>>>>>>>>  
>>>>>>>>>>>> to download and install an updated version of the SD card image.
>>>>>>>>>>>>
>>>>>>>>>>>> --Mark
>>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Mark, 
>>>>>>>>>>>>>
>>>>>>>>>>>>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git 
>>>>>>>>>>>>> repository (or any of the parent directories): .git 
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm such a neophyte on git.  What do I need to do?
>>>>>>>>>>>>>
>>>>>>>>>>>>> And, what do you mean by updating to a new version of the SD 
>>>>>>>>>>>>> card? The OS is booting from the SD card and the version.sh 
>>>>>>>>>>>>> information 
>>>>>>>>>>>>> posted earlier is based on that.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. 
>>>>>>>>>>>>> Yoder wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I suggest updating to a new version of the SD card.  It looks 
>>>>>>>>>>>>>> like the PRUs are getting started at boot time, but the path 
>>>>>>>>>>>>>> isn't setup 
>>>>>>>>>>>>>> right. I think we setup some links so the path* 
>>>>>>>>>>>>>> /dev/remoteproc/pruss-core0/state  
>>>>>>>>>>>>>> *points to the right place.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You could also try:
>>>>>>>>>>>>>> *cd */var/lib/cloud9
>>>>>>>>>>>>>> *git* pull
>>>>>>>>>>>>>> to update cloud9 folders.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Mark
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mark, 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I got the latest PRUCookbook downloaded and when trying to 
>>>>>>>>>>>>>>> make the hello.pru0.c program in 1.6, I got this error.  
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$
>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> make TARGET=hello.pru0*
>>>>>>>>>>>>>>> */var/lib/cloud9/common/Makefile:29: 
>>>>>>>>>>>>>>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>>>>>>>>>>>>>>> *-    Stopping PRU 0*
>>>>>>>>>>>>>>> */bin/sh: 1: cannot create 
>>>>>>>>>>>>>>> /dev/remoteproc/pruss-core0/state: Directory nonexistent*
>>>>>>>>>>>>>>> *Cannot stop 0*
>>>>>>>>>>>>>>> *CC      hello.pru0.c*
>>>>>>>>>>>>>>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning 
>>>>>>>>>>>>>>> #1181-D: #warning directive: "Found am335x"*
>>>>>>>>>>>>>>> *LD      /tmp/cloud9-examples/hello.pru0.o*
>>>>>>>>>>>>>>> *-       copying firmware file 
>>>>>>>>>>>>>>> /tmp/cloud9-examples/hello.pru0.out to 
>>>>>>>>>>>>>>> /lib/firmware/am335x-pru0-fw*
>>>>>>>>>>>>>>> *cp: cannot create regular file 
>>>>>>>>>>>>>>> '/lib/firmware/am335x-pru0-fw': Permission denied*
>>>>>>>>>>>>>>> */var/lib/cloud9/common/Makefile:180: recipe for target 
>>>>>>>>>>>>>>> 'install' failed*
>>>>>>>>>>>>>>> *make: *** [install] Error 1*
>>>>>>>>>>>>>>> *rm /tmp/cloud9-examples/hello.pru0.o*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Initially, I did not have a folder called 
>>>>>>>>>>>>>>> /var/lib/cloud9/common.  To remedy this I copied the contents 
>>>>>>>>>>>>>>> of 
>>>>>>>>>>>>>>> /var/lib/cloud9/PRUCookbook/docs/common to 
>>>>>>>>>>>>>>> /var/lib/cloud9/common.  Maybe 
>>>>>>>>>>>>>>> this created a problem?Nevertheless,  I found some other 
>>>>>>>>>>>>>>> discussions that 
>>>>>>>>>>>>>>> suggested updating the scripts and kernels from 
>>>>>>>>>>>>>>> beagleboard.org/upgrade which I did.  I am now running...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue 
>>>>>>>>>>>>>>> Aug 25 01:48:39 UTC 2020 armv7l GNU/Linux
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And the output of version.sh is 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
>>>>>>>>>>>>>>> *[sudo] password for debian:*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
>>>>>>>>>>>>>>> *eeprom:[A335BNLT00C04417BBBK1847]*
>>>>>>>>>>>>>>> *model:[TI_AM335x_BeagleBone_Black]*
>>>>>>>>>>>>>>> *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
>>>>>>>>>>>>>>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>>>>>>>>>>>>> SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 
>>>>>>>>>>>>>>> -0500)]:[location: dd 
>>>>>>>>>>>>>>> MBR]*
>>>>>>>>>>>>>>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>>>>>>>>>>>>> 2018.09-00002-g0b54a51eee]:[location: dd MBR]*
>>>>>>>>>>>>>>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
>>>>>>>>>>>>>>> 2018.03-00002-gac9cce7c6a (Apr 05 2018 - 13:07:46 
>>>>>>>>>>>>>>> -0500)]:[location: dd 
>>>>>>>>>>>>>>> MBR]*
>>>>>>>>>>>>>>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>>>>>>>>>>>>>> 2018.03-00002-gac9cce7c6a]:[location: dd MBR]*
>>>>>>>>>>>>>>> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
>>>>>>>>>>>>>>> *kernel:[4.14.108-ti-r137]*
>>>>>>>>>>>>>>> *nodejs:[v6.14.4]*
>>>>>>>>>>>>>>> */boot/uEnv.txt Settings:*
>>>>>>>>>>>>>>> *uboot_overlay_options:[enable_uboot_overlays=1]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
>>>>>>>>>>>>>>> *uboot_overlay_options:[disable_uboot_overlay_video=1]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
>>>>>>>>>>>>>>> *uboot_overlay_options:[enable_uboot_cape_universal=1]*
>>>>>>>>>>>>>>> *pkg check: to individually upgrade run: [sudo apt install 
>>>>>>>>>>>>>>> --only-upgrade <pkg>]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]*
>>>>>>>>>>>>>>> *WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]*
>>>>>>>>>>>>>>> *pkg:[kmod]:[23-2rcnee1~stretch+20171005]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]*
>>>>>>>>>>>>>>> *groups:[debian : debian adm kmem dialout cdrom floppy audio 
>>>>>>>>>>>>>>> dip video plugdev users systemd-journal i2c bluetooth netdev 
>>>>>>>>>>>>>>> cloud9ide gpio 
>>>>>>>>>>>>>>> pwm eqep admin spi tisdk weston-launch xenomai]*
>>>>>>>>>>>>>>> *cmdline:[console=ttyO0,115200n8 
>>>>>>>>>>>>>>> bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro 
>>>>>>>>>>>>>>> rootfstype=ext4 
>>>>>>>>>>>>>>> rootwait coherent_pool=1M net.ifnames=0 quiet]*
>>>>>>>>>>>>>>> *dmesg | grep remote*
>>>>>>>>>>>>>>> *[    1.147260] remoteproc remoteproc0: wkup_m3 is available*
>>>>>>>>>>>>>>> *[    1.231303] remoteproc remoteproc0: powering up wkup_m3*
>>>>>>>>>>>>>>> *[    1.231426] remoteproc remoteproc0: Booting fw image 
>>>>>>>>>>>>>>> am335x-pm-firmware.elf, size 217168*
>>>>>>>>>>>>>>> *[    1.233981] remoteproc remoteproc0: remote processor 
>>>>>>>>>>>>>>> wkup_m3 is now up*
>>>>>>>>>>>>>>> *[  108.634522] remoteproc remoteproc1: 4a334000.pru is 
>>>>>>>>>>>>>>> available*
>>>>>>>>>>>>>>> *[  108.656634] remoteproc remoteproc2: 4a338000.pru is 
>>>>>>>>>>>>>>> available*
>>>>>>>>>>>>>>> *dmesg | grep pru*
>>>>>>>>>>>>>>> *[  108.019424] pruss 4a300000.pruss: creating PRU cores and 
>>>>>>>>>>>>>>> other child platform devices*
>>>>>>>>>>>>>>> *[  108.634522] remoteproc remoteproc1: 4a334000.pru is 
>>>>>>>>>>>>>>> available*
>>>>>>>>>>>>>>> *[  108.634642] pru-rproc 4a334000.pru: PRU rproc node 
>>>>>>>>>>>>>>> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed 
>>>>>>>>>>>>>>> successfully*
>>>>>>>>>>>>>>> *[  108.656634] remoteproc remoteproc2: 4a338000.pru is 
>>>>>>>>>>>>>>> available*
>>>>>>>>>>>>>>> *[  108.656808] pru-rproc 4a338000.pru: PRU rproc node 
>>>>>>>>>>>>>>> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed 
>>>>>>>>>>>>>>> successfully*
>>>>>>>>>>>>>>> *dmesg | grep pinctrl-single*
>>>>>>>>>>>>>>> *[    0.783913] pinctrl-single 44e10800.pinmux: 142 pins at 
>>>>>>>>>>>>>>> pa f9e10800 size 568*
>>>>>>>>>>>>>>> *dmesg | grep gpio-of-helper*
>>>>>>>>>>>>>>> *[    0.796624] gpio-of-helper ocp:cape-universal: ready*
>>>>>>>>>>>>>>> *lsusb*
>>>>>>>>>>>>>>> *Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root 
>>>>>>>>>>>>>>> hub*
>>>>>>>>>>>>>>> *END*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. 
>>>>>>>>>>>>>>> Yoder wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The PRUs can give you 10's of ns timing, which is more than 
>>>>>>>>>>>>>>>> good enough for milliseconds, but might be over kill.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd think using C on the ARM processor should be fast 
>>>>>>>>>>>>>>>> enough.  I'd use gpiod[1].
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you really want the ns timing of the PRUs, check out the 
>>>>>>>>>>>>>>>> PRU Cookbook[2]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --Mark
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://github.com/starnight/libgpiod-example
>>>>>>>>>>>>>>>> [2] https://github.com/MarkAYoder/PRUCookbook
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 
>>>>>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Depending on how precise you need to be, I would go for 
>>>>>>>>>>>>>>>>> the PRU-ICSS. They can control the GPIOs pretty easily. 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Le mardi 16 février 2021 à 10:03:47 UTC-5, 
>>>>>>>>>>>>>>>>> [email protected] a écrit :
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I have a BBB Wireless running Linux beaglebone 
>>>>>>>>>>>>>>>>>> 4.14.108-ti-r106 #1 SMP PREEMPT Fri May 24 22:12:34 UTC 2019 
>>>>>>>>>>>>>>>>>> armv7l 
>>>>>>>>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am writing in C.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I turn a valve on and then need to read some sensors for 
>>>>>>>>>>>>>>>>>> N milliseconds and then turn the valve off.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What's the best way to read milliseconds on the BBBw?  I 
>>>>>>>>>>>>>>>>>> don't have a RTC on this particular unit but could add one 
>>>>>>>>>>>>>>>>>> using I2C.  I 
>>>>>>>>>>>>>>>>>> have an Adafruit 4282 with a DS3231 RTC on it on another 
>>>>>>>>>>>>>>>>>> BBBw that I could 
>>>>>>>>>>>>>>>>>> use temporarily to prove it works.  What other options are 
>>>>>>>>>>>>>>>>>> available?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>

-- 
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/15c68b45-9390-49b7-aa6f-7b70b0e407a1n%40googlegroups.com.

Reply via email to