Getting synchronzied timestamp during run

[mnissov]

I was looking at the IEEE 1588 implementation and was curious regarding the following function

bool enet_ieee1588_read_timer(struct timespec *t) {
  if (t == NULL) {
    return false;
  }

  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    t->tv_sec = ieee1588Seconds;

    ENET_ATCR |= ENET_ATCR_CAPTURE;
    while ((ENET_ATCR & ENET_ATCR_CAPTURE) != 0) {
      // Wait for bit to clear
    }
    t->tv_nsec = ENET_ATVR;

    // The timer could have wrapped while we were doing stuff
    // Leave the interrupt set so that our internal timer will catch it
    if ((ENET_EIR & ENET_EIR_TS_TIMER) != 0) {
      t->tv_sec++;
    }
  }

  return true;
}

I want to use this to timestamp events which aren't necessarily associated to receiving/sending over ethernet or interrupts on pins.

For example if I wanted to timestamp an event, assuming teensy synchronized to computer or GPS, is the timing information from EthernetIEEE1588Class::readTimer reliable vs something like ARM_DWT_CYCCNT from last PPS interrupt? Of course timing from ARM_DWT_CYCCNT is simple but with the drawback that it is only loosely connected to the synchronized PTP time (in that it is also anchored to the same PPS).

Example desired use case could look like

timespec ts_event;
void eventCallback(){
  qindesign::network::EthernetIEEE1588.readTimer(ts); // get timestamp of event

  // other code
}

Asking because the resolution of the ENET timer seems to be ~40ns and the execution time of readTimer seems to be ~250ns. Of course these are small numbers, but not small in comparison to ARM_DWT_CYCCNT, not to mention the overflow handling required.

[ssilverman]

I haven't forgotten about this. I just haven't had a chance to look at it in depth. The IEEE 1588 stuff is currently lower on my priority list.