Hello, I am currently learning about the Teensy 4.1 ptp IEEE1588 features.
Specifically, the timer correction feature that allows to discipline a timer to PTP by using timer correction
For instance, there is this library based on Paul Stoffregen's work :
github.com
and this relevant example :
github.com
Although the example seems crude as it continually increments the timer frequency instead of using the timing difference from EthernetIEEE1588.readTimer(tm)
sucessive calls, it seems to give me a general idea of the process :
a framework built-in IntervalTimer is instantiated to run an isr every 1E6 microseconds (non disciplined).
If i am not mistaken, intervalTimer uses the PIT timer module.
The real disciplined interval is calculated from subsequent calls to EthernetIEEE1588.readTimer(tm)
The timing difference could then be used to discipline the intervalTimer, (although the example does not do this as this seems)
Adjustement is done through :
EthernetIEEE1588.adjustFreq(adjustment)
I followed the code down to the low level implementation and based on IMXRT1060M_rev3 reference, it all boils down to the ATCR and ATCOR registers.
That is, adjustable timer control register and timer control register.
What I want to make sure is that these registers operate on the PIT timer counter, not on the ENET timer.
it seems completely implicit and not documented.
It would not make sense for it to operate on the IEEE1588 timer, as it is already disciplined to the ptp server.
The goal would be to use that mechanism to control the PIT outside of any IEEE1588 operation (for instance, through a GPS pps module based pin rising edge interrupt).
The other option to make on the fly adjustments would be to use GPT or PIT load val change register to control the timer compare value on the fly, but the drawback is a one period cycle delay. being able to decrement or increment the timer counter on the fly seems more elegant.
Could anyone confirm my analysis ?
Specifically, the timer correction feature that allows to discipline a timer to PTP by using timer correction
For instance, there is this library based on Paul Stoffregen's work :
GitHub - HedgeHawk/QNEthernet: An lwIP-based Ethernet library for Teensy 4.1
An lwIP-based Ethernet library for Teensy 4.1. Contribute to HedgeHawk/QNEthernet development by creating an account on GitHub.
github.com
and this relevant example :
QNEthernet/examples/TimerAdjustment/TimerAdjustment.ino at ieee1588-2-fix · HedgeHawk/QNEthernet
An lwIP-based Ethernet library for Teensy 4.1. Contribute to HedgeHawk/QNEthernet development by creating an account on GitHub.
github.com
Although the example seems crude as it continually increments the timer frequency instead of using the timing difference from EthernetIEEE1588.readTimer(tm)
sucessive calls, it seems to give me a general idea of the process :
a framework built-in IntervalTimer is instantiated to run an isr every 1E6 microseconds (non disciplined).
If i am not mistaken, intervalTimer uses the PIT timer module.
The real disciplined interval is calculated from subsequent calls to EthernetIEEE1588.readTimer(tm)
The timing difference could then be used to discipline the intervalTimer, (although the example does not do this as this seems)
Adjustement is done through :
EthernetIEEE1588.adjustFreq(adjustment)
I followed the code down to the low level implementation and based on IMXRT1060M_rev3 reference, it all boils down to the ATCR and ATCOR registers.
That is, adjustable timer control register and timer control register.
What I want to make sure is that these registers operate on the PIT timer counter, not on the ENET timer.
it seems completely implicit and not documented.
It would not make sense for it to operate on the IEEE1588 timer, as it is already disciplined to the ptp server.
The goal would be to use that mechanism to control the PIT outside of any IEEE1588 operation (for instance, through a GPS pps module based pin rising edge interrupt).
The other option to make on the fly adjustments would be to use GPT or PIT load val change register to control the timer compare value on the fly, but the drawback is a one period cycle delay. being able to decrement or increment the timer counter on the fly seems more elegant.
Could anyone confirm my analysis ?