I'll look into the pthread tutorials. So is there no way to just read the clock on the PRU to get elapsed time?
Also, I've booted my BBB Wireless with the SD card with the OS that you recommended and the access point doesn't come up. It doesn't appear to be disabled in uEnv.txt. Any ideas on this? Walter On Thursday, February 18, 2021 at 11:45:52 AM UTC-5 Mark A. Yoder wrote: > 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/a827f670-e620-4f65-9581-beee6d4c2906n%40googlegroups.com.
