Proposed Modification to UAVCAN Specification to Support CAN-FD

[Scott Dixon]

We would like to propose a slight modification to the UAVCAN specification that would allow it to work over CAN-FD:

 

 

Figure 1 – Elimination of the Tail-Array Optimization (TAO) for DLCs Greater-Than Eight

 

In the UAVCAN specification, section » 3.0 Data Structure Description Language » Data serialization » Serialized data format » Dynamic Arrays, we propose the following change (lines added indicated by the +++, all other lines are existing and provided for context)

 

The transport layer provides a data length for every received data transfer (with an 8-bit resolution); thus, in some

cases, the array length information would be redundant as it can be inferred from the overall transfer length reported

by the transport layer. Elimination of the dynamic array length field is called tail array optimization, and it can be

done if all the conditions below are satisfied:

 

1. The minimum bit length of an item type is not less than 8 bits - because the transport layer reports the transfer

   length with an 8-bit resolution.

2. The array is the last field in the top-level data structure - because, otherwise, a much more complicated logic

   would be required to derive the length.

 

+++ 3. The array does not run past the 7th byte in the message - because dlc values greater-than 8 do not have an 8-bit resolution.

 

 

We believe this one change would allow the standard to work without further modifications on a CAN-FD bus. We furthermore expect this change to be backwards compatible for CAN 2.0 busses.

 

Please let us know if this googlegroup is an appropriate and adequate means to request a modification to the core standard.

 

Sincerely,

- Scott A Dixon

[Scott Dixon]

After discussing this with my colleagues I have a clarification to the proposed language:

+++ 3. The array start nor the maximum end (start + max-length) run past the 7th byte in a frame - because dlc values

greater-than 8 do not have an 8-bit resolution.

Note that this does allow for the TAO to apply to dynamic arrays that meet all three criteria where the third criteria is satisfied by : dynamic_array.start % 64 < 8 ∧ dynamic_array.start + dynamic_array.maxlen % 64 < 8

[Pavel Kirienko]

Thank you for the proposition. My week-long silence was due to my other commitments, not due to the lack of interest.

The proposed wording breaks binary compatibility with multi-frame transfers over CAN 2.0B.

While simply disabling TAO allows one to work around the low granularity of DLC in CAN FD, it creates two problems:

1. Alignment.

Some standard data types are designed on the assumption that the tail array optimization takes place. For example, consider the following instances:

- https://github.com/UAVCAN/dsdl/blob/master/uavcan/equipment/gnss/1063.Fix2.uavcan#L110

- https://github.com/UAVCAN/dsdl/blob/master/uavcan/protocol/file/48.Read.uavcan#L23

- https://github.com/UAVCAN/dsdl/blob/master/uavcan/navigation/2000.GlobalNavigationSolution.uavcan#L77

- https://github.com/UAVCAN/dsdl/blob/master/uavcan/tunnel/2010.Broadcast.uavcan#L9

Disabling TAO will make these arrays misaligned, which greatly impairs serialization performance.

2. Leaky abstraction.

Currently, the transport layer (which defines how large chunks of data are exchanged over the bus) is well isolated from the presentation layer (which defines how data structures are encoded). This makes the standard simple and aids in its development, usage, and maintenance.

If we were to implement special treatment for TAO with CAN FD, that would create undesirable coupling between the two layers: now the presentation layer would need to know which transport is going to be used underneath, and encode/decode data accordingly.

---

I think this is the perfect occasion to share a revelation I had some time ago, a few years after announcing the first draft of the standard:

TAO was a mistake.

It is probably not too late to remove it without breaking backward compatibility with existing systems out there. The fact that the first release of the specification has not yet taken place makes this possible.

This is what I suggest:

1. Require all new implementations to decode transfers assuming that the TAO is not used, both for CAN 2.0B and for CAN FD. Transfers encoded by older implementations will be incompatible with that, and it will be reliably detected by new implementations because they will be running out of data before reaching the expected end of the stream. When that happens, new implementations will have to make another attempt, this time assuming that the TAO is used. The logic is easy to implement both in libuavcan and in pyuavcan; here's the relevant place in libuavcan: https://github.com/UAVCAN/libuavcan/blob/8bb62cdbcc0e2d6c98ce3a85e768b8b593c34a07/libuavcan/include/uavcan/node/generic_subscriber.hpp#L263

2. When broadcasting via CAN 2.0B, require all new implementations to use TAO. This will make the emitted transfers compatible both with old and new implementations. Eventually, when the majority of the fielded systems have upgraded, new implementations will switch to not use TAO.

3. When broadcasting via CAN FD, require all implementations to not use TAO. Old implementations are not affected by this because they do not support CAN FD in the first place.

4. Implement new alternatives to the existing data type definitions that are optimized for non-TAO serialization. For a few years from now existing systems will have to support both, until the old ones are phased out.

If we were to implement the above, no special steps will be needed to support CAN FD.

Comments are welcome.

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/17532341-422d-4c82-98e1-5b8b795265ba%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Scott Dixon]

I think disabling the TAO for FD is acceptable for us. We would support this modification. We don't have a strong opinion on how to handle the 2.0 deprecation at this time (I am unclear how your proposal to "[have] new [,fielded] implementations ... switch to not use TAO" would work, however).

This then makes our core proposal for FD support to be simply:

+++  3. CAN 2.0 frames are in use - because the complexity of the TAO for CAN-FD frames outweighs the benefits.

Any other changes to the standard to address the TAO for CAN 2.0 should be handled as a different modification proposal, perhaps?

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

[Scott Dixon]

An additional problem that falls out of using FD-frames is where to put the tail byte. We'd like to propose that the standard require the tail byte to be on a DLC boundary for FD messages. For example (see image) for a 9-byte message the tail byte would be located in the 11th byte (i.e. DLC=12) with the 9th and 10th bytes being ignored; similarly, for a 50 byte message the tail byte would be the 63rd byte (i.e. DLC=64) with the 50th - 62nd bytes being ignored; etc.

 

We also propose that the standard specify: unused bytes in FD messages are ignored. Implementations can put any data pattern in these bytes without breaking compatibility with any other UAVCAN implementation.

[Pavel Kirienko]

Scott,

Thank you, the tail byte at the DLC boundary sounds sensible. I am going to submit a pull request to the UAVCAN specification soon (don't have time right now, sorry) with these and related changes concerning TAO and CAN FD.

I believe you should be unblocked by now to go ahead and implement these changes in your own fork while being reasonably assured that your implementation will be compatible with the standard once it gets updated.

On a highly related note, is there any chance for the UAVCAN project to secure a bit of open source C++ development help from Amazon?

Thanks,

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/d02fc755-8183-4167-aa0c-1e8f4307b78a%40googlegroups.com.

[Scott Dixon]

I can't commit to helping for Amazon in-general but I will try to submit back to the libuavcan and pyuavcan projects as I have time (I don't have the time to help with the rust or libcanard implementations at this point, sorry). 

One problem I'm running into when implementing the tail byte for FD is that there is a bit of asymmetry between multi-frame transmission and reception. When transmitting, the transport CRC is calculated without any specific knowledge of the message framing which makes ignoring unused bytes trivial. This seems somewhat natural albeit, perhaps, a layering violation. When receiving, the transport CRC is calculated without any specific knowledge of the datatype in the payload which makes ignoring unused bytes impossible. 

I see two solutions and would like to hear what your take is:

1) Standardize the content of unused bytes to be 0xAA – You have an implicit rule (unless I missed in) that padding bits are 0 but for FD we want unused byte padding to be 0xAA to avoid extra bit-stuffing for unused frames.

2) Consume the transport CRC up in the data-layer where there is enough knowledge to discard the unused bytes – This could be a layering violation depending on how you squint at the problem but makes it easer to ensure interoperability between implementations that just use 0s or 1s for padding and avoids standardization of the unused bytes.

I'm honestly waffling between the two but I'm still learning how the transport layer of libuavcan works so I don't fully have my head around this yet. I also want to be sure that I'm not making suggestions based on this one reference implementation which is why I proposed that the core standard mark the unused bytes as ignored. That said, libuavcan may be teaching us something about how these unused bytes should be handled by the specification.

[Scott Dixon]

I forgot how great GitHub is and that the UAVCAN website is just another repo. I'll post issues for changes to the standard there so we can track modifications properly.

[Pavel Kirienko]

I am going to share some thoughts on the subject of CRC checking here, which are in no way final.

Unfortunately, the multi-frame transfer CRC field ended up being situated at the beginning of the data packet. If I were to design this today, I would have definitely put it at the end of the packet, in order to make CRC residual checks possible (the CRC remainder converges to the same constant value which is dependent on the chosen polynomial and byte order once the CRC algorithm is fed the correct remainder computed over the preceding data stream). Sadly we can't take advantage of this property because that would require us to relocate the CRC to the end of the stream, which seems to complicate the transition between CAN 2.0 and CAN FD unnecessarily. Or does it?

We could instead accept your first suggestion (require a fixed bit pattern for unused bytes) and implement the following CRC checking algorithm. Suppose we have a multi-frame CAN FD transfer of length L. The data carried by the last frame of the transfer occupies at most the last 63 bytes of the packet (maximum size of a CAN FD frame minus the tail byte). Before checking the CRC, the implementation should backtrack the packet from the last byte of it until the first byte which is not 0xAA is found, or until the byte index (L - 63) is reached; the index of the resulting location should be stored. The CRC check should now commence as usual from the beginning of the transfer until the previously stored index is reached. From that point on, the CRC algorithm should continue consuming the data, while checking after every consumed byte whether the current CRC value matches the reference provided at the beginning of the transfer.

Obviously, the above approach somewhat increases the likelihood of CRC collision, but my quick estimates suggest that the overall strength of the check is still acceptable.

Does any of that sound sensible?

Pavel.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/14e4e48e-1e66-42f2-8b51-202a77fd4406%40googlegroups.com.

[Kjetil Kjeka]

> If I were to design this today, I would have definitely put it at the end of the packet

Funny that you say this, I was wondering why it wasn't placed at the end when implementing this in uavcan.rs

I'm going to bring up two suggestions in this post. Let's call the first one Future Proofing.

What I'm throwing out here might be a bit drastic, but I still think it's something worth thinking about, so hear me out. Some less than ideal choices have been made (TAO, CRC placement), but really nothing we can't live with. But what if one of the design choice becomes a blocker for the next generation CAN (or Uavcan over ethernet or other advances) at a later point. I think it would be valuable having some strategy for deprecation and change in place, and perhaps essential if we want the protocol to be "future proof".

What I'm suggesting is possible without breaking anything over night (allow deprecation time):

1. (ASAP) We deprecate 2 bits of the priority part of the header (2 rightmost bits to let priority field set frame priority). The protocol always write 00. Ignore on Read (to not break anything)

2. (ASAP) We add a protocol version variable. This could either be sent as part of the NodeStatus frame or (perhaps preferably) as `GetSet` service read only parameter.

3. (When deprecation period is over) We assert the protocol bits to be 00.

4. Then we up the protocol version, remove TAO and put CRC at the end of the frame (and other tweaks we would like to see). This new version supports CAN-FD.

    - In the start old frames should be sent and old+new one should be accepted (as default, you should be able to set a switch to send new frames instead)

    - At some point we start sending new frames as default

    - After a long time we stop accepting old frames.

Even though this will take a bit of time, there is no problems with starting using the updated protocol ASAP for new systems that doesn't need to be compatible with older units. This includes anything sent over CAN-FD as it was never compatible with the old protocol in the first place. If we decide early on how priority/version/TAO/CRC fields should be dealt with this will not halt CAN-FD support at all.

The reason i suggest 2 bits for versioning is that it allows 4 version numbers (0, 1, 2, 3). When version 4 arrives (if ever) it have been ages since version 0 was deprecated and version number 0 would mean 4 (modulo 4 arithmetics).

Together with the individual versioning/stabilizing/deprecation of DSDL messages, this will hopefully make Uavcan suited for years to come.

The next suggestion is a lot less impact-full. Let's call it a generalized TAO criteria.

 - Every protocol already have a `MAX_DATA_LENGTH` associated with it (8 for CAN 2.0B, 64 for CAN-FD)

 - Also let every protocol have a `DATA_LENGTH_BIT_RESOLUTION` associated with it. More specifically, this is the worst case data length resolution. This will be 8 for CAN-2.0B and 128 for CAN-FD.

 - Change the first criteria for TAO to: "The minimum bit length of an item type is not less than `DATA_LENGTH_RESOLUTION`.

The problem with this solution (and every other solution that effectively removes TAO for CAN-FD) is that it becomes impossible to reason about whether a byte would be split or not.

On a general basis I think the Uavcan protocols strength is in it's simplicity and ease of providing basic support, yet being flexible and powerful enough to transfer files and doing firmware updates. I think TAO is a nice feature as CAN bitrate is often a constrained resource, but my first instinct is that I would rather see it removed that making the protocol harder to support by backtracking 0xAA and checking multiple CRC's before deciding if it was a correct transfer.

I highly support sending 0xAA for padding in reference implementations, and encourage sending 0xAA for padding in all implementations. But i don't think it's much value in enforcing it (unless the CRC checking method Pavel suggested is implemented of course).

Kjetil

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/CAD6GmdARUeRKMNCzWmWdEquTNoF8KSjJdS2AyTMOZu__Qai_XA%40mail.gmail.com.

[Scott Dixon]

I'm not sure this will work if the data ends with 0xAA as part of the payload or am I not understanding this proposal? I think the decode simply needs to know the data-length first. See my PR for libuavcan. I just moved the transport CRC check to happen after the decode and used the number of bytes read as the valid datalength. Note that this continues to consume unused bits included in the CRC but that's simply how the standard works today.

[Scott Dixon]

I like the idea of a protocol version but 2 bits in every message seems like something that really needs to be thought about pretty hard before committing to. As for the NodeStatus, that message is already fully allocated. What would you lose to add protocol version to this message and how is this different then the two version bits?

Another inflection point is that we can make FD-only changes since FD frames are already uniquely defined. It may make sense to keep a 1.0 version as a more efficient version for 8-byte CAN2.0 busses (including the TAO). When FD is in use we could add protocol version to the datapayload using an extended tail-byte. The extended tail-byte can also be used to optimize transport CRC calculations.

[Kjetil Kjeka]

> I like the idea of a protocol version but 2 bits in every message seems like something that really needs to be thought about pretty hard before committing to

Thanks, I agree. And my suggestions were pretty rudimentary so if Pavel like the idea as well we should take the time and sketch out what it would look like.

My reason for suggesting the version number is that if this is meant as future proofing the most important feature is that it buys time to deprecate old features in favor of new ones. And if several protocols are to co-exist on the same bus, they will need to know what messages is of what protocol type.

My reason for putting it in the message itself is that it will not require any keeping track of states of other nodes, i think 1 or 2 bits is worth this. It doesn't really need to be in the header, it might be more suited to put in the tail bytes.

If we were to use the NodeStatus frame, we would have to eat some bits from other fields to keep the message from using more than 7 bytes. But I think it would be better to use a read only GetSet service variable. The idea is that this service will give the protocol version as a number, and the 1-2 bits sent with every message show compatibility.

The advantage of using 2 bits is that an old protocol would need to be completely out of use only after 4 new releases. If we were to use 1 bit it would have to be completely out of use after 2 releases (which i guess can be acceptable since we don't expect the new releases to happen often).

If we were to use only 1 bit and decide to keep it out of the header I see a "hack" we could leverage. If we say that the toggle bit starts on 0 for even versioned protocols (lets code the current as 0) and 1 for odd versioned protocols (the next one will be coded as 1). This might actually require minimal changes with a lot of advantages, we should think some more about this.

The one thing that we will not be able to change easily is how this version compatibility is encoded. If we put it in the tail byte, some of it's format is frozen and if we put it in the header some of the headers format is frozen. This is still better than having everything frozen, but it's still something we will need to be aware of.

> Another inflection point is that we can make FD-only changes since FD frames are already uniquely defined. It may make sense to keep a 1.0 version as a more efficient version for 8-byte CAN2.0 busses (including the TAO). When FD is in use we could add protocol version to the datapayload using an extended tail-byte. The extended tail-byte can also be used to optimize transport CRC calculations.

With this solution the extended tail byte could simply have some bits (5 i guess) that tells how much shorter the data length is than the frame length. This would allow us to keep TAO. In return, it would waste 5-8 bits, and this is probably more than ditching TAO would cost us in the first place.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/165d518c-7307-4e32-bf6b-356717991beb%40googlegroups.com.

[Scott Dixon]

Some meta-questions here (remembering I'm pretty new to this project, sorry if these are dumb questions):

1. Is it a requirement that UAVCAN coexist on a given bus with other protocols?
   
2. Is it a requirement that UAVCAN coexist with older versions of UAVCAN?
   
3. If (2) then does "coexist" mean that multiple versions of UAVCAN can be in use simultaneously?
   
4. If (3) then do the devices using different UAVCAN versions need to communicate with each other (as opposed to just ignoring each other)?

Here are some assumptions I have been making about UAVCAN:

• UAVCAN is in-use and therefore has a de-facto "v1" of the protocol that must be considered when making any changes to the standard.
  
• UAVCAN does not provide any guarantee or definitions for coexisting on a bus with non-UAVCAN traffic. It is up to the network designer to ensure that CAN message identifiers are properly segmented between UAVCAN messages and any other message generators on the bus. (We could add, in support of such requirements, ways to reserve address spaces in the DSDL compiler and ways to export address space manifests from DSDL compilation steps).
  
• UAVCAN has some desire to support interoperability with existing devices. How this is accomplished depends on (3) and (4).
• If neither (3) nor (4) then we are simply talking about compatibility modes baked-in at compile-time. 
• If (3) but not (4) then a protocol version in the message helps newer nodes ignore old-style messages but doesn't help existing nodes ignore newer versions of the protocol.
• If (4) then adding a protocol version cannot be allowed.
• Since CAN-FD messages cannot be received by CAN2.0 devices then (4) cannot be achieved and is therefore not a requirement when FD is in-use. This allows us to make otherwise breaking changes like elimination of the TAO when sending UAVCAN messages in CAN-FD frames.

Back to the thread:

Actually, putting message identifier in an extended tail-byte is a bad idea. I'm sorry I suggested it. The version has to be part of the identifier to allow hardware filters to ignore protocols the current node doesn't understand. 

This means we can't actually implement any versioning without breaking compatibility with the existing devices out there. The only way to version the protocol would be to make a breaking change that included a versioning scheme in the identifier. This takes us back to my questions on the requirements governing UAVCAN's specification.

[Pavel Kirienko]

Hello everybody,

I apologize for my poor participation in this critical discussion, am traveling. Let me share my thoughts here on the discussed; if I missed something you should blame that on the distracting ambient noise in this Starbucks I'm writing this from.

First, on the subject of TAO: we should remove it while it's not too late. As Scott said (correctly), the de-facto v1 release has already taken place because there are implementations out there in the field that are leveraging it. However, there are certain advances underway which are expected to increase the number of fielded devices significantly in the coming months, so it seems like a good opportunity to weed out the remaining issues in the specification before its adoption rates have increased. One of the reasons why I haven't announced v1 formally yet is because I expected that something is likely to be in need of fixing.

The advantage of having the TAO is evident: we save several bits per message, which allows us to achieve better overall bus utilization. However, seeing as CAN FD is slowly gaining traction, and considering the likelihood that it is probably going to eventually displace CAN 2.0B in robotic applications (where bandwidth requirements are often higher, but that's a separate story), we can predict that the positive effects of TAO are going to be diminished over time. Yet we'll be left with the disadvantages of TAO, which are at least the following:

- Complicates the protocol. Several recent bug reports related to PyUAVCAN are related to improper handling of array length fields.

- Promotes different treatment of top-level data structures and nested data structures (because remember, we can apply TAO to only one array in the transfer).

- Complicates data type design. An overly attentive reader will spot a byte alignment problem in the new GNSS Fix2 message which we overlooked when decided to accept it. This is in part because of the rather complex optimization rules one has to keep in mind when designing DSDL definitions.

I think that the above was quite hard to foresee when I came up with the idea of TAO several years ago, so this is a learning experience.

On the subject of versioning: I think the Kjetil's idea of sacrificing one bit of the priority field for the needs of versioning is a sound one. Shall there ever be a need to define a second revision of the protocol, we could either take another bit of the priority field (see how UTF8 encoding is done), or we could adopt the Toggle bit hack Kjetil described (although I am no fan of that idea because it is very stateful - the toggle bit as a version identifier is only observable in the first frame of the transfer, so implementations would have to memorize the bit from the first frame of the transfer and apply the version handling policies to the following frames of the same transfer; this is not cool).

Using one bit of the priority field as a version ID is not going to break any backward compatibility because the priority information has no useful semantics on the application layer. The downside of freezing the bit for version identification purposes at the beginning of the CAN ID is probably tolerable because the nature of data prioritization in CAN guarantees that the meaning of the first bits of the message is not going to change ever as long as we stay with CAN.

With the TAO fix in place, we'll need to provide replacements for certain standard data types. For a while, we're going to need to live with several definitions in the standard DSDL set (we already have Fix and Fix2, or MagneticFieldStrength and MagneticFieldStrength2).

On the subject of CRC verification - not a lot of people are watching that repo, so everybody who would like to follow up with that conversation should subscribe to this: https://github.com/UAVCAN/uavcan.github.io/issues/36.

> I'm not sure this will work if the data ends with 0xAA as part of the payload or am I not understanding this proposal?

The method I proposed initially does not care what data is at the end of the payload because it re-checks CRC after every byte of the last frame, although it doesn't matter anymore because I proposed a better method which leverages the properties of the CRC algorithm we use with no noticeable downsides (unless I'm missing something). Let's continue that conversation on the linked Github thread.

Scott:

> Is it a requirement that UAVCAN coexist on a given bus with other protocols?

No, but it's nice to have.

> Is it a requirement that UAVCAN coexist with older versions of UAVCAN?

Yes.

> If (2) then does "coexist" mean that multiple versions of UAVCAN can be in use simultaneously?

Yes.

> If (3) then do the devices using different UAVCAN versions need to communicate with each other (as opposed to just ignoring each other)?

Devices conformant to the same major version of the specification should be able to communicate with each other. UAVCAN v2 might lose its backward compatibility with v1.x, or maybe not, who knows.

> UAVCAN does not provide any guarantee or definitions for coexisting on a bus with non-UAVCAN traffic.

That's not true; we openly state in the specification that UAVCAN does not care about CAN 2.0A (11-bit ID) - all CAN 2.0A frames are ignored; therefore any CAN 2.0A based protocol can be used concurrently with UAVCAN on the same bus. When it comes to CAN 2.0B, however, the UAVCAN specification provides absolutely no guarantees. The set of valid UAVCAN CAN ID covers almost the entirety of the set of all possible CAN ID values, so interoperability with CAN 2.0B protocols is challenging to achieve, but not impossible.

That said, UAVCAN might start using CAN 2.0A at some point in the future; we don't care about backward compatibility with third-party protocols.

Pavel.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/db7707c0-ee45-4011-ab4f-88272ab56079%40googlegroups.com.

[Pavel Kirienko]

In order to unblock the pending PRs and move the discussion forward, I would like to see if there are any objections to the following direct proposals for UAVCAN v1.0:

- As proposed by Kjetil: Reduce the Priority field of the CAN ID field down to 4 bits long; use the freed up bit as a protocol version identifier.

- As proposed by Scott: In the case of CAN FD, put the tail byte at the DLC boundary.

- Remove TAO.

- Put the CRC field at the end of the transfer byte stream. In the case of CAN FD, the padding bytes (which are always zero) are to be inserted after the CRC field. Details explained at https://github.com/UAVCAN/uavcan.github.io/issues/36.

Pavel.

[Kjetil Kjeka]

I'm on board with this. Except i feel like if the CRC convergance property vs being able to pad with 0x55 (or 0xaa) have not been discussed to the end yet. If my calculations are correct we could end up with ~30 extra stuff bits for a frame, it feels like this is a potential mistaked. I agree that it feels elegant to be able to parse as much padding bytes as you want. But I'm not sure if it would really help implementations, without TAO wouldn't the parser know when the data structure was depleted and it was time for the CRC bytes anyway?

I'm not familiar with how these CRC algorithms work on anything else than a shallow level, but would it be possible (as a best of both worlds) to find a CRC algorithm that have this property for a value that do not contain more than 4 repeating bits?

> As proposed by Scott: In the case of CAN FD, put the tail byte at the DLC boundary.

Just to be clear, this means after data and padding bytes, right?

[Scott Dixon]

I think the CRC should be before the tail-byte on the DLC boundary. This is how I have it implemented in my libuavcan-FD PR and it works well that the transport layer can count backwards from the DLC boundary to find things. If you put it after the end of data then you need to know the data-length to find it which seems like a layering violation to me.

Just to be clear, this means after data and padding bytes, right?

 Yes but more importantly, because it's the last byte in the frame the transport layer can always find it without knowing about the padding when parsing frames.

[Kjetil Kjeka]

> I think the CRC should be before the tail-byte on the DLC boundary. This is how I have it implemented in my libuavcan-FD PR and it works well that the transport layer can count backwards from the DLC boundary to find things. If you put it after the end of data then you need to know the data-length to find it which seems like a layering violation to me.

What you're saying makes sense. I've inspected the uavcan.rs code and similar to the libuavcan library the received crc payload is indexed and calculated without calling the serializer. It will also allow for leaving the padding byte undefined, while also allowing to CRC the whole transfer + CRC and get 0x0000.

Parts of this discussion is in https://github.com/UAVCAN/uavcan.github.io/issues/36 I've asked Pavel some follow up questions here to find out if there are some parts we're missing. I'm mentioning here in case people want to follow the discussion.

On a side note, we're currently discussing changes in multiple places. It would perhaps be easier to contribute if some RFC process, or at least the correct place to propose these things was clearly defined.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/acdd0c41-1024-4877-8633-747f4d0af0de%40googlegroups.com.

[Scott Dixon]

Agreed about a better defined RFC process but this will have to do for now. 

A bit of a detour, again apologies that I'm new to the standard but, what is the purpose of the transport CRC given that CAN frames each include their own CRC and the completeness of the transmission can be determined by the data layer? Can the CRC simply be omitted?

...

[Pavel Kirienko]

The discussion is getting quite haphazard, indeed. Please let's move all CRC-related talks to this ticket, where I just posted an update: https://github.com/UAVCAN/uavcan.github.io/issues/36

So far there seem to be only two points pending confirmation:

- The CRC issue - see the linked ticket.

- The Versioning issue - see this ticket: https://github.com/UAVCAN/dsdl/issues/35

I am going to post an update on the mailing list once the decision has been made. Everyone is welcome to comment on this.

Pavel.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/21aed668-9e92-43c3-b0ab-e38f1aa5e345%40googlegroups.com.

[Pavel Kirienko]

Members who are interested in UAVCAN v1.0 should read (subscribe to) the following conversation: https://github.com/UAVCAN/dsdl/issues/35

Pavel.