Quickstart-Guide not uptodate

The newest beagleLogic-image from https://beaglelogic.readthedocs.io/en/latest/beaglelogic_system_image.html (Released on 2017-07-13)
comes with the kernel version 4.9 , but the quickstart "Option 1: Using the BeagleLogic system image" describes the sampling with a 4.8 kernel version i think.

In the image with the 4.9 kernel version some folders/paths have different names/are different now...
So replacing pru1 firmware (step 6) and setting up the pwm-signal for the clock (step 7, end of setup-script) doesnt work like described in the quickstart with the newest beaglelogic image...

[credentiality]

Indeed. That stuff has changed a lot across releases and I always had trouble finding good docs on the changes. Worse, the distros would ship incompatible versions of tools that would fail silently. If you can get it to work with the new stuff, it'll be good to have it on the wiki. But if you just want it to work, you're best off using the older distro linked in the quickstart.

…

Thanks for the answer! I think i will try the older one first...

Can I start and stop the sampling by pull P9_25 low/high?
Is that the right way to do it?

[credentiality]

That is indeed the enable pin for the adc. It might be what you want depending whether you want to start and stop sampling at the adc or by the firmware, and whether the firmware you're using is generating a clock signal or being driven by it.

Actually the firmware should stop sampling. So it should start and stop sampling from within my c++ programm. Not shure whether there is a file somewhere I can echo to? ( maybe /sys/devices/virtual/misc/beaglelogic/state ? )
Thanks a lot for your advice!

[credentiality]

Been a while since I played with beaglelogic, but yeah, looks like it maybe opening and closing /dev/beaglelogic affects capture, and maybe the triggerflags setting.

Yes, you are right! On the beagleLogic-github page there is a description of the sysfs-attributes (https://github.com/abhishek-kakkar/BeagleLogic/wiki/sysfs-attributes-Reference) and there it says at 'triggerflags':
"If data is not removed fast enough as it arrieved, it may be overwritten. Kernel logs can reveal where the overrun had occurred."
So I randomly tryed the dmesg-command and the nice thing is: it does not only inform you about an overun: every time you read from /dev/beaglelogic
(hexdump -d /dev/beaglelogic |head , or dd if=/dev/beaglelogic of=myfile.bin bs=1M count=64) , dmesg says "capture started with ..." and when the read is finished dmesg says "capture session ended".
So to stop sampling pulling P9_25 high is not necessary. You can simply start and stop reading from /dev/beaglelogic.
Thank you for the advice!

(Btw, the /sys/devices/virtual/misc/beaglelogic/state attribute is for testing purposes only)

This project is so cool =D

PRU1 waits for a rising or falling edge of the ADC-clock , than samples the ADC output pins. (The pru1 assembler code is also very interesting)
So am I correct in assuming that the beagleLogic samplerate-parameter is actually without function for the PRUDAQ project?

[credentiality]

Yes, I believe that's correct.