> > Hi Iain > > >> If you have a board with a hardware timer that supports load/match/compare >> then you can schedule an external interrupt to be generated at a >> predetermined point in the hardware count. Thus, if you know the transform >> between your disciplined clock and the hardware counter of the timer that >> drives it, then you should be able to do this. I have spent some time >> working with the (pretty neat) timers on board a beaglebone black, and >> I've >> written some code to setup input capture and compare on up to 4 timers: >> >> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master >> > > Wait...You mean with your driver I essentially have a A->B->C->D TIC ? > _THAT_ I have a use or three for... > > The one catch is that you can only setup a BeagleBone Black timer to be in capture mode OR compare mode, not both. So, what I did was to set up two parallel timers that are driven by the same oscillator (and thus I don't drift relative to each other). I then perform synchronization against the first free-running timer. I then bootstrap the second timer with the count of the first one, which appears to have a fairly deterministic latency of 13 ticks. I can then setup a load/match to cause a rising edge at a very deterministic point in time. I have sort have named this an IOTIMER.
> Since there is also code out there to drive a BBB from an external > reference via TCLKIN, this gets very interesting. > Yes, I have a patch set for the 4.1.3x kernel, which sets up tclkin (although I haven't tested it since the 3.x kernel branch). https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/4.1.3-rt-roseline/patchset/?at=master My kernel module is loaded by the device tree as follows. In the snippet below I setup two IOTIMERS, the first of which (iotimer_a) performs compare on timer4 and event generation on timer5. The argument "1" says use the 24MHz oscillator to drive both timers -- "0" is for TCLKIN and "2" is for the 32kHz oscillator. The last parameter describes which edge to capture -- "0" is for rising, "1" is for falling, "2" is for both and "3" is for none. / { roseline { compatible = "roseline"; status = "okay"; iotimer_a = <&timer4 &timer5 1 0>; iotimer_b = <&timer6 &timer7 1 0>; pinctrl-names = "default"; pinctrl-0 = <&timer_pins>; }; }; Obviously, you'll also need to do the pinmuxes (TLKCIN causes you to lose HDMI). /* Timer configuration */ timer_pins: pinmux_timer_pins { pinctrl-single,pins = < 0x90 0x22 /* P8.7 MODE2 TIMER4 - 24MHz CAPTURE */ 0x98 0x02 /* P8.10 MODE2 TIMER5 - 24MHz INTERRUPT */ 0x9C 0x22 /* P8.9 MODE2 TIMER6 - TCLKIN CAPTURE */ 0x94 0x02 /* P8.8 MODE2 TIMER7 - TCLKIN INTERRUPT */ 0x1b4 0x2A /* P9.41A MODE2 TIMER4 TCLKIN */ 0x1a8 0x0F /* P9.41B MODE7 TIMER4 INPUT (high-Z, tied to P9.41A) - conflicts with HDMI */ >; }; Once the kernel module is loaded, you can communicate with it from userspace using ioctl. Simple example: https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/applications/misc/test_ioctl.c?at=master I still have to implement polling to notify the userspace of capture events. Right now you have to keep checking until the sequence number changes. > I might just have to compare your code against my own TIC code using > the PRUSS (Although that's only a traditional A-B or A-A TIC at the > moment, extending to 3 or 4 inputs would decrease the precision and > accuracy...) Please do! And let me know how it performs :) And if you have released your PRUSS code, please send me a link! > > > On Tue, Aug 25, 2015 at 8:24 AM, folkert <[email protected]> wrote: >> >> Hi, >>> >>> Not sure if it is interesting for you guys but I wrote a simple program >>> for e.g. Linux (or any other system with the pps api implemented) that >>> listens on a pps source waiting for a pulse and then toggles a gpio >>> pin. That way you can measure the latency introduced by the the kernel >>> when listening from userspace. Note that there's a little extra latency >>> due to the gpio-pin handling. >>> >> > Oh this might be very interesting, esp with something like the BBB, > which has the excellent counters that Andrew discusses above. Presumably > it is a five minute job to modify your code to do something other than > twiddle a GPIO pin. > > It would be very useful to try and characterise that kernel delay. I > will add it to the list of things to try, once I finish moving the time > lab around! Great -- keep us in the loop! Cheers Andrew _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
