Time synchronization of hardware clock and PRU?

GoogleGroups
1

Greetings, I am a student researching protocols for global time synchronization in embedded systems, and am using Beaglebone Black for testing and demonstration. Current goal is to test the accuracy of selected protocol by independently synchronizing the clocks of two boards, then having both send a pulse on an output pin on set time, for example on every second exactly. I would then measure the delay between pulses of both boards to determine the reliability of the protocol.

There are obviously obstacles, the first one with Linux not being a real time operating system. One part of my research is measuring the delay caused by task scheduling, but for now I want to achieve a real-time response. I have read about PRU units having this capability, but have some questions:
-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?
-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?

Any answers or tutorials would be welcome. I admit I am new to programming on this board.

Cheers,
JK

2

-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).

3

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

4

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 albatross
compared 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 :crazy_face::stuck_out_tongue_winking_eye::money_mouth_face:

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 :joy::nerd_face::crazy_face: 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 :shushing_face:

5

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:

  1. PRU generates your desired 1 Hz pulse train
  2. 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.
6

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 exactly
your 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.

7

A belated response -- I stumbled upon the linked article while cleaning
out some stale bookmarks in my browser...

http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Industrial_Protocols_PTP.html

8

Thank you for explanation.
I have discussed this with my mentor - for now, we will focus on accuracy and drift of the processor clock.
We found out Beaglebone Black has support for high resolution timers within kernel modules - the kind that support nanosecond timestamping with ktime_get and such functions. These seem to be what we need.
I want a timer that, after clock synchronization to global time, would trigger a gpio toggle on specific timestamp set in advance. For example, having it toggle on a specific timestamp that’s about 10 minutes after synchronization to measure drift, or every 10 seconds for a period of time. Are there any examples of this?

Dne petek, 28. februar 2020 19.35.40 UTC+1 je oseba Dennis Bieber napisala:

9

Kernel module timers are in the eCAP modules in the PWMSS subsystems. Three modules are present, but only two are wired to the big headers, the third is at JT or SDcard-slot (32 bit counters at 100 MHz → maximal toggling time stamp = 42,9s).

Additional the TIMER[4-7] subsystems provide that feature (32 bit counters with divider at 24 MHz → maximal toggling time stamp = 45812984s).

Find details and example code at

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPins.html#sSecTimer

But as long as you synchronise both systems by an LINUX app, you’ll face latency in a nano or even milli second range.

More accurate is the PRU-firmware I mentioned above, synchronised by a wired GPIO signal.