Start of updating CAN ID header format to match v1.0

[aasmune]

This is a start of updating the ID header to match the new format for v1.0. Note: It could be that I have missed some parts which also must be updated related to the new header format, or that I have made some mistakes. Therefore, I would appreciate that you check my changes thoroughly.

These changes were originally included in #96, but we chose to split it out to a separate PR.

[pavel-kirienko]

This is great. Beware that the library API will also need updating: data type ID will need replacing with subject ID and service ID, new priority limits, etc.

[pavel-kirienko]

The function "canardCleanupStaleTransfers()" must be removed (this affects the API and the demo); see section 4.2.1 for details. This change to the spec was implemented in order to improve deterministic behavior at the cost of somewhat increased average-case memory usage (the worst case is unaffected). The constant CANARD_RECOMMENDED_STALE_TRANSFER_CLEANUP_INTERVAL_USEC is therefore not needed either (there could be other constants which we no longer need).

Data type signature must be removed from everywhere. This includes the callback signature CanardShouldAcceptTransfer.

The API functions still use "data type ID" instead of "subject ID" and "service ID", this should be fixed.

The transfer priority constants require updating. We have proper mnemonic names for the eight priority levels defined in 4.1.4.

The script show_data_type_info.py will no longer be needed, since there are no signatures to worry about.

[aasmune]

The function "canardCleanupStaleTransfers()" must be removed (this affects the API and the demo); see section 4.2.1 for details. This change to the spec was implemented in order to improve deterministic behavior at the cost of somewhat increased average-case memory usage (the worst case is unaffected). The constant CANARD_RECOMMENDED_STALE_TRANSFER_CLEANUP_INTERVAL_USEC is therefore not needed either (there could be other constants which we no longer need).

Data type signature must be removed from everywhere. This includes the callback signature CanardShouldAcceptTransfer.

The API functions still use "data type ID" instead of "subject ID" and "service ID", this should be fixed.

The transfer priority constants require updating. We have proper mnemonic names for the eight priority levels defined in 4.1.4.

The script show_data_type_info.py will no longer be needed, since there are no signatures to worry about.

I would prefer to do this in a separate PR, for the same reason as the other comment, as this one is mainly for updating header format. I would suggest doing it as a part of #98.

[aasmune]

I notice that the travis build has been queued for a long time, could you check that I didn't make any mistakes when updating the travis file? @pavel-kirienko

[pavel-kirienko]

I notice that the travis build has been queued for a long time, could you check that I didn't make any mistakes when updating the travis file?

It's weird. The changes seem benign and I can't imagine why would they cause any problems. I just tried restarting the build but it didn't help, it keeps getting stuck at the stage "Queued". Could be related to this:

• Job waiting to be queued then no update for several hours. travis-ci/travis-ci#9088
• https://www.traviscistatus.com/incidents/my5wm56npf7q

[aasmune]

I notice that the travis build has been queued for a long time, could you check that I didn't make any mistakes when updating the travis file?

It's weird. The changes seem benign and I can't imagine why would they cause any problems. I just tried restarting the build but it didn't help, it keeps getting stuck at the stage "Queued". Could be related to this:

• travis-ci/travis-ci#9088
• https://www.traviscistatus.com/incidents/my5wm56npf7q

It could be. The build is finally finished queueing and has passed now!

[aasmune]

What do you think, are we ready to merge soon?

[pavel-kirienko]

Yes. Is this ready for another review?

[aasmune]

Yes, it is.

[pavel-kirienko]

LGTM, assuming that the CRC handling and #98 will be updated separately.

[aasmune]

LGTM, assuming that the CRC handling and #98 will be updated separately.

Yes.