Allow dlc greater than 8.

[nathanaelg]

For what I'm wanting to do it would be useful to have more than the 8 byte data packets that classic CAN allows. I'm not sure if this is the right approach but keen to hear your thoughts on extending the allowed CanMessage length.

[mcbridejc]

I'm definitely interested in supporting CAN-FD. Are you also trying to support 64-byte SDO/PDOs? I'm not sure if this is meant as a preliminary step to more changes, or if you actually just want 64-bytes in the CanMessage type to use elsewhere.

My main concern is that I'd rather not impose the memory penalty on applications that don't use CAN-FD. I think the ultimate solution probably involves splitting into two types, CanMessage and CanFdMessage, and adding a trait for access -- but not sure. It potentially could be enabled by a feature too.

[nathanaelg]

My primary goal was bigger message sizes (to have some space for encryption/authentication nonce / associated data) but I have used this for bigger PDOs too - just added more items to the mappings and it seemed to work fine. I haven't done anything with SDOs yet but want to look at some software update soon so will see how that is impacted (should make it a fair bit faster to have bigger packets available?)

Definitely take your point about the memory penalty, I'll have a look at a separate type and/or feature flag.

[mcbridejc]

Just thinking about this a little bit:

• It should be possible for an application to send/receive longer messages regardless of what zencan supports, right? There is some translation required between the zencan node and the CAN interface anyway, and so I suppose one could map the incoming 0-8 byte CANFD messages to the 8-byte zencan CanMessages to pass on while also doing whatever they want with the long messages from the bus. Does this change really enable anything for you?
• It should be possible to instantiate both a classic node and an FD node in the same application -- e.g. a gateway between two networks. I think this leads to two different types, because you could still want some 8-byte message buffers even when the 'canfd' feature is turned on.

[nathanaelg]

Yes you're right about just using more data outside of the canopen payload - you can just do that in the translation to CAN interface. The main thing it allows is having bigger PDOs (which again is sort of optional because you can just have more PDOs if you need to - just a little bit less clean if you are sending more than 8 bytes every time). I think when I first did this I was using the CanMessage type from zencan in some places but maybe I should try and decouple that anyway. I'll try some refactoring and see where I get to - I do still thinking having more than 8 bytes in PDOs is going to be pretty useful.