can_tsync同步原理

整體來說，can的時間同步還是比較簡單的，如下圖所示，整個過程如下（tips：時間戳自1970年1月1日00:00:00經過的時間，是由秒+納秒組成的。）：

1time master在t01時刻以廣播的形式發送一個sync報文，并把時間秒部分的時間放到報文上，發送到time slave；使用can confirmation的機制，記下sync報文實際從can驅動發送出去的時間，t1r.

1. time slave在t2r時刻接收到sync報文
2. time master在sync發送完之后，隨后發送follow up報文，并把t1r的納秒通過報文發送出去，即t4r = t2r-s(t0r)。這里有一個潛在條件，那就是sync報文由can timesync模塊組裝好報文后調用發送接口，直到從can driver上出去，整個時間是不會超過1s的。所以t4r實際上就是從can timesync報文發送出去直到can driver發送出去的一個延時。
3. time slave在t3r接收到follow up報文。
4. 因此在t3r時刻，master此刻真正的時間t(master_now) = t3r - t2r + t4r

注意：實際上，上面的時間大多都是不精確的：

1. 時間戳是軟件加上的，并不是由硬件加上的
2. 沒有考慮can總線上的延遲
3. 沒有考慮到從t3r到adjust時鐘這段時間的誤差。

1. SYNC和FOLLOW_UP消息分為兩種格式，Type=0x10為不安全的不帶CRC校驗的報文格式，對應FUP消息類型為0x18；Type=0x20為帶CRC校驗的安全報文格式，對應FUP消息類型為0x28。
2. Byte0：時間同步類型：0x20代表當前發送的是帶CRC校驗的TSync同步消息， 0x28代表當前發送的是對應0x20 SYNC消息的FUP同步消息；0x10代表當前發送的是不帶CRC校驗的TSync同步消息， 0x18代表當前發送的是對應0x10 SYNC消息的FUP同步消息；
3. Byte1：byte0為0x20或0x28時,Byte1為該消息的CRC校驗值；
4. Byte2：高4位為時間同步域Time Domain；低4位為Sequence Counter，隨發送次數循環累加；
5. Byte3：byte0為0x10或0x20時，Byte3為UserByte0；同步類型為0x28或0x18時，高5位保留， bit3 SGW為時間同步狀態（0：SyncToGTM， 1：SyncToSubDomain），bit1-bit0 OVS為時間同步溢出時間overflow of seconds；
6. Byte4-Byte7為同步時間，同步類型為SYNC消息時為32bits 秒時間，同步類型為FUP消息時為30bits ns時間。