search

OpenCyphal / specification

The Cyphal specification documents are maintained here.
https://opencyphal.org/specification
Creative Commons Attribution 4.0 International
42 stars 13 forks source link

Migration strategy from v0 to v1 #25

Closed pavel-kirienko closed 5 years ago

pavel-kirienko commented 6 years ago

While the two versions of the protocol can co-exist successfully on the same bus (thanks to the Toggle bit measures we've taken), supporting both versions in the same implementation concurrently can be challenging, especially after our big redesign of the standard data type definitions has landed (it's not even proposed yet, working on that).

With that in mind, I would like to revisit the question of migrating deployed nodes from v0 to v1. As I see it, we have two options:

Seeing that the set of fielded nodes is still relatively small and that the old and the new sets of standard data type definitions are likely to end up drastically different, I am inclined to prefer the second option. Its advantage is that it requires much less workload from the library maintainers (us). The disadvantage is that the memory footprints will rise considerably until v0 is phased out completely (although for some this could be a motivation for speedier migration to v1).

kjetilkjeka commented 6 years ago

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 commented 6 years ago

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.

thirtytwobits commented 6 years ago

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.

mjs513 commented 6 years ago

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 commented 6 years ago
  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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 pavel.kirienko@zubax.com or DM on the forum (the latter is better, good chance to check that the forum is functioning properly). Thanks!