Migration strategy from v0 to v1

[opencyphal]

Migration strategy from v0 to v1

[thirtytwobits]

I agree that libuavcan should support v1 going forward. V0 support could be provided only on a branch where we could accept critical patches but with no ongoing development.

pyuavcan might be a different story, however. If there is anything that may have value in supporting both it would be in the thing that tools are built on top of. The ability to analyse a bus with both versions running across it using a single tool is a prime example.

[kjetilkjeka]

uavcan.rs, although I recall @kjetilkjeka was planning to skip v0 completely

I think the practical choice is to only support v1 and ignore v0 frames in uavcan.rs. If anyone wants to discuss this further we can open an issue in the uavcan.rs repo.

---

I think the second option is better "if we can get away with it". There should probably be a comment period where users can object if this is catastrophic for them.

[pavel-kirienko]

I think the practical choice is to only support v1 and ignore v0 frames in uavcan.rs. If anyone wants to discuss this further we can open an issue in the uavcan.rs repo.

I think this is perfectly reasonable for uavcan.rs.

I think the second option is better "if we can get away with it". There should probably be a comment period where users can object if this is catastrophic for them.

Seeing as 100% of participants so far are in favor of the second option, I suggest to tentatively choose that unless objections are raised in the coming weeks. Keeping this open for now.

[mjs513]

There are a couple of questions that I have regarding v1, with out reading the spec, these are just generic questions:

1. As a user of v0 will you all be putting together sort of migrating instructions going from v0 to v1?
2. Will the UAVcan website be updated to v1 with appropriate examples?

[pavel-kirienko]

1. I think for end-users the migration process should be documented at the level of implementation. For example, I think we are going to put one together for Libuavcan.
2. The sensor example will probably have to go unless somebody would volunteer to bring it up to date with v1.0 and also to use CAN FD instead of CAN 2.0. I don't really think it's useful anymore because now we have libcanard.

[mjs513]

Apologize for getting back to you sooner on your response.

I think for end-users the migration process should be documented at the level of implementation. For example, I think we are going to put one together for Libuavcan.

Think this is a great idea for end-users especially for libuavcan.

The sensor example will probably have to go unless somebody would volunteer to bring it up to date with v1.0 and also to use CAN FD instead of CAN 2.0. I don't really think it's useful anymore because now we have libcanard.

I would volunteer to update the sensor example unfortunately I am using the Arduino/Teensyduino environment. But I could give it a try at least for CAN 2.0. Unfortunately I don't have any Hardware for CAN-FD to test it on.

Thanks
Mike

[pavel-kirienko]

pyuavcan might be a different story, however. If there is anything that may have value in supporting both it would be in the thing that tools are built on top of. The ability to analyse a bus with both versions running across it using a single tool is a prime example.

I used to completely agree with this. Now, looking at the outcomes of the Stockholm Summit, I am beginning to suspect that the effort required to support both revisions in one implementation might be too great for it to be practical, especially considering the deadlines. Given that, I suggest we drop the support for v0 completely everywhere, including the new web-based GUI tool.

I would volunteer to update the sensor example unfortunately I am using the Arduino/Teensyduino environment. But I could give it a try at least for CAN 2.0. Unfortunately I don't have any Hardware for CAN-FD to test it on.

We would be happy to supply you with CAN FD hardware (probably a Nucleo with STM32H7 and a Kvaser USB CAN adapter) if you could lend us a hand with testing and docs. Perhaps we should move this discussion to the new forum so that other people interested in helping could see it too.

[mjs513]

We would be happy to supply you with CAN FD hardware (probably a Nucleo with STM32H7 and a Kvaser USB CAN adapter) if you could lend us a hand with testing and docs.

Never used a STM product before so I would have a little bit of learning curve on what I need to compile and test. Don't mind that one. Always used Arduino or Teensy boards before. Anyway besides the Kvaser USB CAN Adapter you might want to consider the MCP2542 chip so you can connect right to the development board: https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-expansion-boards-daughter-cards/797?k=mcp2542. I might make a little interface board myself - relatively simple to design.

Perhaps we should move this discussion to the new forum so that other people interested in helping could see it too.

Would agree that this would be a good idea.

EDIT: I ordered 1 of each already but be advised the H7 board seems to be on backorder from both mouser and digikey here in the states.

[pavel-kirienko]

@mjs513 the thread is up https://forum.uavcan.org/t/virtual-plug-fest-looking-for-testers/171

Please let me know what hardware do you need and what is your shipping address. You can either email me at [email protected] or DM on the forum (the latter is better, good chance to check that the forum is functioning properly). Thanks!