Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 21 of 21

Thread: PTP (IEEE 1588) Library

  1. #1
    Senior Member
    Join Date
    Jul 2014
    Posts
    140

    PTP (IEEE 1588) Library

    This thread is really to firstly gauge the interest there might be in a Teensy PTP library, then to possibly document any progress.

    PTP aka IEEE1588 allows for much tighter synchronization between systems on the same subnet.

    I am tempted to write one and do a proof of concept where it triggers a digitalWriteFast to occur at the same time on 2 networked Teensy's and see how close they come...

    The likely platform will be a Teensy 3.1 with a WIZ820IO module, using the interrupt line for consistent timestamping (crucial for PTP).

  2. #2

    Yes, please

    This thread is now several years old but still a top Google search result on Teensy IEEE1588.
    I want it to reflect at least some level of interest.
    I would use such a library if it existed.
    My use case would be synchronizing output events outdoors (light show, fountains), with input events indoors(music, touch panel, script).

  3. #3
    Junior Member
    Join Date
    Aug 2019
    Posts
    3
    I am interested in this. What is the current status? How does the Teensy 4.0 support IEEE1588? Firmware or ???

  4. #4
    Junior Member
    Join Date
    Aug 2019
    Posts
    3
    Just to confirm my background...I am actively using 801.1AS software on an Analog Devices FIDO5200. I am synchronizing at 20 nSec between 2 development boards.

  5. #5
    Junior Member
    Join Date
    Aug 2019
    Posts
    3
    Whoops. 802.1AS.

  6. #6
    Senior Member
    Join Date
    Mar 2013
    Posts
    147
    This makes sense on Teensy 4.1 which has native IEEE1588.

  7. #7
    Senior Member
    Join Date
    Jul 2014
    Posts
    140
    It makes sense on any teensy, hardware support isn't a necessity for a PTP implementation. Hardware support only changes the layer at which the NIC packet timestamping occurs, and hence the quality of syncronisation.

  8. #8
    Senior Member
    Join Date
    Mar 2013
    Posts
    147
    Quote Originally Posted by macaba View Post
    It makes sense on any teensy, hardware support isn't a necessity for a PTP implementation. Hardware support only changes the layer at which the NIC packet timestamping occurs, and hence the quality of syncronisation.
    I have mainly used PTP in situations where high quality synchronization was desired (e.g. AVB).
    In my reference to the Teensy 4.1 I was also thinking of the convenience that the hardware is largely already there on the board.

  9. #9
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,094
    Note that the T4 has a tweak-able audio clock rate - so good use can be made of synchronization.

    A 1 pps single wire input to the teensy also works fine. Even a once per second byte from a USB attached PC works well enough.

  10. #10
    Junior Member
    Join Date
    Sep 2020
    Posts
    13
    Is there any progress on the implementation of the PTP?

  11. #11
    I would say ptp on teensy 4.1 would be extremely useful, I might even be interested in giving a shot implementing it if no one has yet, since according to the RT1060 manual, the ethernet module has the IEEE 1588 hardware timestamping capability:

    The Ethernet Media Access Controller (MAC) is
    designed to support 10/100 Mbit/s Ethernet/IEEE 802.3
    networks. An external transceiver interface and
    transceiver function are required to complete the
    interface to the media. The module has dedicated
    hardware to support the IEEE 1588 standard. See the
    ENET chapter of the reference manual for details.
    And NXP has a fairly detailed 27-page application note (Implementing an IEEE 1588 V2 on i.MX RT Using PTPd, FreeRTOS, and lwIP TCP/IP stack):

    A dedicated hardware with
    timestamping capabilities (such as the MAC-NET peripheral module or the 10/100-Mbps Ethernet MAC
    (ENET) of the NXP i.MX RT 1050 and 1020) enables synchronization with significantly improved
    accuracy.
    3. IEEE 1588 functions on i.MX RT
    The i.MX RT10xx devices integrate the MAC-NET core (in conjunction with a 10/100-Mbit/s MAC) to
    accelerate the processing of various common networking protocols, such as IP, TCP, UDP, and ICMP,
    providing wire speed services to client applications. The unified DMA (uDMA), internal to the ENET
    module, optimizes data transfer between the ENET core and the SoC and supports the enhanced buffer
    descriptor programming model to support IEEE 1588 functionality. To enable IEEE 1588 (or similar)
    time synchronization protocol implementations, the MAC is combined with a timestamping module to
    support precise timestamping of incoming and outgoing frames. Set the EN1588 bit in the ENET_ECR
    (Ethernet Control Register) to enable 1588 support.
    though it seems they are using their own SDK which implements the "NXP ENET driver"...so I'm guessing that driver code is something that still needs to be done on Teensy's end:

    The MIMXRT10xx Evaluation Kit (EVK) board is used as the hardware platform for hardware
    timestamping-based IEEE 1588 V2 PTP. The solution uses the MCUXpresso SDK IDE for the
    i.MX RT10xx EVK board, which includes the NXP ENET driver of the i.MX RT10xx MCU, the PHY
    driver, the ported FreeRTOS OS, and the ported lwIP TCP/IP stack for the EVK-MIMXRT10xx board.
    The IEEE1588 V2 PTP is implemented by the PTP daemon application, which is an open-source
    implementation of the PTP
    and conclusion says:

    This application note describes the IEEE 1588 Precision Time Protocol demo application based on the
    open-source PTP daemon, FreeRTOS OS, lwIP TCP/IP stack, SDK for i.MX RT10xx, and the
    i.MX RT10xx Evaluation Kit (EVK-MIMXRT1050) board. This demo can be easily ported to other
    processors from the i.MX RT series with the FreeRTOS OS, lwIP, and TCP/IP stack support.
    The demo system is targeted for applications that require precise clock synchronization between devices
    with accuracy in the sub-microsecond range.
    And I have plenty of ptp network interfaces to test with, as well as a couple AVB Motu interfaces. Though I wonder if there is anything particular with the board EVK-MIMXRT1050 that is missing, but I don't think so.

    I notice there is a port of FreeRTOS for teensy 4.1 (https://github.com/tsandmann/freertos-teensy) so maybe that would need to be used, or at least to make the ptp quicker to implement.

    Would be great to use a ptp-synced teensy for generating midi/osc note events with precision timestamping sent through the ethernet.

  12. #12
    Junior Member
    Join Date
    Sep 2020
    Posts
    13
    Quote Originally Posted by ericfont View Post
    I would say ptp on teensy 4.1 would be extremely useful, I might even be interested in giving a shot implementing it if no one has yet....
    That would be more than appreciated!
    I can support you with some beta-testing if needed..

  13. #13
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,094
    With hardware time stamping, I'd expect excellent performance without a RTOS.

    PTPv2 is a required part of AES67.

  14. #14
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    394
    I'm experimenting with adding IEEE 1588 stuff to QNEthernet. To make sure I'm going in the right direction, here's the features I've added so far:

    1. Read the timer register (ENET_ATVR):
      1. uint32_t Ethernet.readIEEE1588Timer()
      2. Low-level: uint32_t enet_read_1588_timer()
    2. Get the timestamp of a received UDP packet. I'm thinking of changing this to a single function instead, to match how I'm doing this with the TX timestamp.
      1. bool EthernetUDP::hasIEEE1588Timestamp()
      2. uint32_t EthernetUDP::ieee1588Timestamp()
    3. Send a UDP or raw packet with a timestamp:
      1. Send raw: Ethernet.sendRaw(..., bool doTimestamp)
      2. Send UDP: EthernetUDP::endPacketWithTimestamp()
      3. Get the TX timestamp: bool EthernetUDP::ieee1588TXTimestamp(uint32_t *timestamp)
      4. Low-level: bool enet_read_1588_tx_timestamp(uint32_t *timestamp)


    Is there also a need for having an API for an external signal as well?

    There's two things to do:
    1. Validate that the API is useful, and
    2. Verify that the code works as expected.


    I'll need help with these two things from people more experienced than I with PTP/IEEE 1588 timestamping/timers.

    Here's the experimental branch: https://github.com/ssilverman/QNEthernet/tree/ieee1588
    Note that neither the README nor CHANGELOG show the changes.

  15. #15
    Senior Member
    Join Date
    Feb 2020
    Posts
    118
    Shawn,

    An example that mimics the single-pulse-per-second: https://www.nxp.com/docs/en/nxp/appl...es/AN12149.pdf, would be nice to verify timing with a scope.

    What that means for your API, well I would rely on those more experienced in creating the architecture and examples.

    Thank you for working on this. Do you have a buymeacoffee link?

  16. #16
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    394
    @TeensyWolf I do See the top of the README here. Thank you for asking about it.

  17. #17
    Junior Member
    Join Date
    Sep 2020
    Posts
    13
    Quote Originally Posted by shawn View Post
    I'll need help with these two things from people more experienced than I with PTP/IEEE 1588 timestamping/timers.
    Thank you Shawn for starting these activities, I am looking forward to use your PTP implementation.
    Is there anything an inexperienced user can help you with, i.e. testing your code etc.?
    If so, can you explain how to use your code and what software do you use on the computer side?

  18. #18
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    394
    I just provided an interface to the low-level timestamping and timer functions. I’m not well versed in using them or what the “actual needs” are yet.

    The requirements are knowing how to use a GitHub branch in the Arduino libraries.

    I like to think of it as me providing the hammer and nails, but not the house plans or lumber.
    Last edited by shawn; 01-05-2022 at 08:49 PM.

  19. #19
    Junior Member
    Join Date
    Sep 2020
    Posts
    13
    For the server side, this link might help for Linux users:
    http://linuxptp.sourceforge.net/

    I just checked my hardware, and it seems I have only software time-stamping available:
    Code:
    sudo ethtool -T enp4s0
    Time stamping parameters for enp4s0:
    Capabilities:
    	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    PTP Hardware Clock: none
    Hardware Transmit Timestamp Modes: none
    Hardware Receive Filter Modes: none
    Can someone suggest what hardware is required on PC side for hardware time-stamping?

  20. #20
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    394
    I updated (force-pushed) the `ieee1588` branch in QNEthernet to include raw frame timestamping ability.

    The link: https://github.com/ssilverman/QNEthernet/tree/ieee1588

  21. #21
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    394
    I did a new version and here's the list of PTP/IEEE 1588 building blocks:

    1. Read the timer,
    2. Write the timer,
    3. Get the timestamp of RX frames,
    4. Timestamp TX frames and get the timestamp,
    5. Adjust the timer by nanoseconds per second as time progresses,
    6. Adjust the timer with a new adjustment period and increment (called by the previous),
    7. Set channel mode (there's a bunch of modes that include input capture and output compare; I refer you to the chip docs),
    8. Set channel output pulse width,
    9. Set channel compare value, and
    10. Get channel input capture or output compare status.

    And of course, raw frames (both RX and TX) are supported, so low-level PTP packets are also supported.

    I believe that should cover what's needed to build a complete NTP/PTP/IEEE 1588 application. Am I missing anything?

    Update: I'm missing using an exernal reference clock instead of the internal 25MHz one, but that shouldn't be too hard to add...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •