You also need measure the difference between your pulse and the received pulse and adjust your pulse frequency according, if the goal is synchronization of both board's for exact parrellel processing or comparison processing once you start using interrupts their will be small latency. If you are using time of day based synchronization of linked processors as in gas meters on mesh network you need a software time system which drifts irregardless of how stable processor clock is.IMO as your application increases in complexity you might have trouble meeting your requirement.Not sure what any of this has to do with accuracy of time protocol's. Perhaps you can expand your requirement explanation it's not clear what exactlyyour doing. It's one thing to postulate possibilities of a trivial polled example that doesn't meet your objective of actually completing a project that generates result's on real hardware. I'd suspected that's how can't such project would be graded even at undergraduate level. Trivial to get an example program running that doesn't complete your requirement with Data and while the experience of playing with this is invaluable the Professor should expect real proof as timestamp and we didn't delve into getting that data out for proof as well as how you plan on debugging hate to see you fall into a rabbit hole and end up with no real Data or working example. You might spend lesser time finding out whether it's possible by doing a higher level design and thoroughly being sure you have a good platform for what you're timeline and experience is as opposed to what's cheap that's part of the design is rapid proof of concept.
Sent from Yahoo Mail on Android On Sat, Feb 29, 2020 at 8:40 AM, TJF<[email protected]> wrote: Your target seems to be possible. The PRU clock is very stable. Start with example code at pruss_toggle. Adapt the pinmuxing and the PRU firmware: - PRU generates your desired 1 Hz pulse train - PRU starts first, waits for the first PRU-1 pulse on a GPIO input, and then sends synchronised pulses on a GPIO output. The only problem is to get PRU-1 starting at the obtained timestamp by the ARM (linux) process. -- 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/4726a01c-b83b-4061-ac1a-e5ac086c539e%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1602057901.3825215.1582989839276%40mail.yahoo.com.
