Can you explain this? then synchronizing the hardware clock and PRU to the obtained timestamp Typically you synchronize a software timer which is based off the processor clock and adjust it for drift if your goal is to have two board's running on exactly same Time to a sub microsecond resolution via synchronization of the 1 sec pulse they share via PRU and then adjust both clocks I see some issues. Assuming you were able to quickly share some protocol Time like NTP from Linux to PRU via shared ram Write a 1 sec timer on PRU that generates an interupt or place value into PWM timer to generate a toggle between PRU Wrote this in PRU assembly ( your New you said) I don't think you have enough instructions to meet your resolution. The problem I see is what you observed in your opening. Since Linux isn't realtime in fact it's an albatrosscompared to barebones as far as latency or even an RTOS they added this PRU that has no albatross and said hey look PRU it's realtime. The funny part is an ARM core running at GHz frequency with no Albatross ( Linux) in barebones or RTOS can do exactly what you want to do. Unfortunately you need a TCP/IP stack ie RTOS. In the real world in industry hard realtime application like say a high end motor controller running PID and Control algorithms on a DSP using RTIS clock ticks in the nano HZ frequency that require what you wanna do use a paid for RTOS like Green Hills Integrity with the stack and an interupt service routine to synchronize your two separate ARM core's running at much higher clock speed's. If you don't need the TCP/IP stack or have the skills to get FreeRTOS, or a board that supports TI RTOS ( this board doesn't) running those are options certainly not for a beginner. The problem is 35 years ago everything was barebones, Assembly and real time that's how they tought you right out school. Now they Take CS students who know Unix supply them with a cheap board complete with Linux lot of Jazzy scripts and over Lay's so it changes in a weekly basis and your lost without Linux. And when you say you need real time the salesman in Houston he tell you hey buy this board it's got a processor running Linux(Albatross) and Programmable Realtime Units 🤪😜🤑 Hmmm Mr Salesman I see you made a career in these doggy boards,isn't a GHZ ARM core real-time Uhhm yes sir sorry it is But We don't support barebones/ JTAG in this group we debug Linux using prints 😂🤓🤪 and even have a doggy board with 4 PRU You won't find any examples that will be adaptable to achieve your goals if you're doing what I think you are. Hey but if you learned Linux in school you can buy this board and put Real Time on your resume. PROGRAMBLE REAL-TIME 🤫
Sent from Yahoo Mail on Android On Fri, Feb 28, 2020 at 8:26 PM, Venkatesh Vadde<vva...@gmail.com> wrote: We have been using a Beaglebone Black for a while now using the PRU(s) for time sensitive experiments. In our estimate the PRU has shown a very stable clock, running at 200MHz with tight control. The clock does run off a very stable TCXO and the two PRUs are synchronized to within mHz of offset (relative to each other) likely attributable to any clock skew effects. Getting day and time stamp does need synching up to a network time server via NTP. I hope that helps. Venky On Sat, Feb 29, 2020, 12:05 AM Dennis Lee Bieber <dennis.l.bie...@gmail.com> wrote: On Fri, 28 Feb 2020 01:35:54 -0800 (PST), in gmane.comp.hardware.beagleboard.user Jaka Koren <jaka.koren.isys-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: >-Is using a PRU even suitable for this kind of experiment? I am aiming for >sub-microsecond accuracy. >-My task for example would require obtaining global time via selected >protocol, then synchronizing the hardware clock and PRU to the obtained >timestamp. Is this possible, considering PRU is a separate unit on the >board? The processor clock(s) will be only as reliable as the crystal(s) used on the board. These crystals are not, to my knowledge, temperature compensated, nor are they in an "oven" -- so some drift as the circuit warms up or the environment changes temperature is to be expected. >-Is PRU clock accessible to programs in same way as processor clock (via >hwclock on linux)? Is there a way to send pulses on pins periodically, but >starting on a predefined moment on clock? The PRUs do not have a time-of-day clock. The main processor time-of-day is periodically synchronized using NTP, and I suspect is incremented using an interrupt from a 32.768kHz crystal. The main processor itself appears to be driven by a 24MHz clock (probably via some multiplier to get to the 1GHz internal cycle). The PRU processor clock is 200MHz, which I believe gives a 5ns instruction timing (you'll have to figure out how many instructions will be needed to handle GPIO toggling and any time delays). I expect this clock, as with the processor main clock, are conditioned on the 24MHz crystal frequency. The time-of-day clock likely is not synchronized to the ARM processor clock (except as an artifact of interrupt signal gating). -- Dennis L Bieber -- 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/mani5f5fhkhuvtinqsurh7tep79458toik%404ax.com. -- 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/CAHW0bcx%3DSdYNFMPURxHsxFp7gjHn5CuwBTLmFNL-ft8EVL3Opw%40mail.gmail.com. -- 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/429681845.3717091.1582948119649%40mail.yahoo.com.
