Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added timestamps to CAN messages when receiving #309

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

nesos
Copy link
Contributor

@nesos nesos commented Oct 31, 2019

To implement a time-synchronization mechanism for a CAN network I added a timestamp feature to the CAN driver.
This feature will append the current timestamp to all incoming messages, such that one can read the time of arrival when processing the message.

I'm not sure if this featured is needed or desired in the modm mainline code, but I thought I'd offer it.

@salkinium
Copy link
Member

Is the timestamp a platform-independent CanMessage feature? Otherwise I'd add it like the filter_id:
#226 (comment)

This'll also line up with the FDCAN API that @rleh is preparing in the background.

@nesos
Copy link
Contributor Author

nesos commented Nov 4, 2019

Is the timestamp a platform-independent CanMessage feature?

It is platform independent. It doesn't use any features of the CAN driver itself. It only needs the clock module (and the interriupt of the driver)

@strongly-typed
Copy link
Collaborator

Is the timestamp a platform-independent CanMessage feature?

It is platform independent. It doesn't use any features of the CAN driver itself.

Sadly, the Time Triggered CAN in STM32 is only marketing.

From the STM32F42xx and STM32F43xx Errata sheet:

2.13.1 BxCAN time triggered communication mode not supported

So nothing lost here.

Great to see the feature implemented in this way!

But, is it really required that all CAN messages get the timestamp? I would opt in for an option of the module to enable time stamps, with disabled as default and add a CanStamped data type (with reference to ROS).

IMHO, same is true for the filter_id which is in most my cases irrelevant and increases RAM usage for heavy CAN traffic significantly here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

3 participants