I'm building a Teensy 3.6 based CAN bus sniffer/splitter/injector and would like a good timestamp solution, but the provided timestamp just doesn't seem up to the task. Could anyone validate my understanding below and comment on possible solutions?
My understanding is that the timestamp is based on a 16-bit free running timer which runs at the baud rate set for the controller. In my case at 500kbps that would mean the timestamp would roll over every 131ms or so, (65535/500000=0.13107). If the controller is capturing every message on the bus that's probably not an issue but if I filter for specific messages that might only be generated every second or so I have no way to time them using the timestamp. (It's a shame that they don't use the full 32-bit register!)
What I've implemented at the moment is my own timestamp using millis(). This doesn't have good enough resolution for a fully running bus so I'm going to switch to micros(). However, I wanted to use the FlexCAN timestamp to ensure message order is maintained. I don't know that message order is definitely an issue as I haven't tested under heavy loads yet, but I'd like to protect myself against the possibility and future projects might run under more demanding scenarios.
Any suggestions as to what else I could do?
My understanding is that the timestamp is based on a 16-bit free running timer which runs at the baud rate set for the controller. In my case at 500kbps that would mean the timestamp would roll over every 131ms or so, (65535/500000=0.13107). If the controller is capturing every message on the bus that's probably not an issue but if I filter for specific messages that might only be generated every second or so I have no way to time them using the timestamp. (It's a shame that they don't use the full 32-bit register!)
What I've implemented at the moment is my own timestamp using millis(). This doesn't have good enough resolution for a fully running bus so I'm going to switch to micros(). However, I wanted to use the FlexCAN timestamp to ensure message order is maintained. I don't know that message order is definitely an issue as I haven't tested under heavy loads yet, but I'd like to protect myself against the possibility and future projects might run under more demanding scenarios.
Any suggestions as to what else I could do?
Last edited: