There is a cycle count register[1] I'm not using wireless, so I don't know it's current status.
--Mark [1] https://markayoder.github.io/PRUCookbook/07more/more.html#_using_the_built_in_counter_for_timing On Thursday, February 18, 2021 at 12:38:24 PM UTC-5 wal...@edenconceptsllc.com wrote: > 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 >> wal...@edenconceptsllc.com 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 >>>> wal...@edenconceptsllc.com 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 >>>>>> wal...@edenconceptsllc.com 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 >>>>>>>>>> wal...@edenconceptsllc.com 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 >>>>>>>>>>>> wal...@edenconceptsllc.com 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 >>>>>>>>>>>>>> wal...@edenconceptsllc.com 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 >>>>>>>>>>>>>>>> wal...@edenconceptsllc.com 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 >>>>>>>>>>>>>>>>>> pierric...@gadz.org 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, >>>>>>>>>>>>>>>>>>> wal...@edenconceptsllc.com 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fa2e2379-4f96-494f-9225-b488acad16c3n%40googlegroups.com.
