Add core address claiming logic

[ad3154]

• Added the basic address claiming logic.
• Adds stub for CANMessage
• Adds stubs for some network manger functionality
• Needs still needs to be attached to the driver so it won't really do anything yet

Questions I have:

• Is there a more idomatic way to do a finite state machine than match ?
• Is there a setting we can adjust so the formatter doesn't make the entire state machine an unreadable blob of newlines?

[github-actions]

File	Coverage	Lines	Branches
All files	26%	26%	0%	✅
src/network_management/can_message.rs	0%	0%	0%	✅
src/network_management/control_function.rs	13%	13%	0%	✅
src/network_management/name.rs	55%	55%	0%	✅
src/network_management/network_manager.rs	22%	22%	0%	✅

Minimum allowed coverage is 0%

Generated by 🐒 cobertura-action against a4b8068

[GwnDaan]

Looks promising 🔥 , for your questions:

• Is there a more idomatic way to do a finite state machine than match ?

I googled around a bit, and like this approach quite a bit. It should also help with the next question.

• Is there a setting we can adjust so the formatter doesn't make the entire state machine an unreadable blob of newlines?

Hmm, In my opinion refactoring the state machine into smaller concrete functions (for example as the state machine linked above, or by using early returns 😛) should be the first priority to battle this issue. Though I agree, it sometimes is unavoidable to have the longer line lengths and it may be increased just slightly (if there is an easy and standardized way to do so)

[ad3154]

I googled around a bit, and like this approach quite a bit.

Oh, hey, that looks pretty nice... could tidy it up a fair bit. I'll experiment with that

[ad3154]

I googled around a bit, and like this approach quite a bit.

Oh, hey, that looks pretty nice... could tidy it up a fair bit. I'll experiment with that

Am I missing something? That approach doesn't seem to compile....

[GwnDaan]

I googled around a bit, and like this approach quite a bit.

Oh, hey, that looks pretty nice... could tidy it up a fair bit. I'll experiment with that

Am I missing something? That approach doesn't seem to compile....

Welp I missed the most important part of the post:

In this post I instead want to focus on ✨ the future ✨. How could we plausibly represent this in Rust by extending the language. In the "future directions" section of the last post we wrote a state machine without the blinky lights. Using enum variants types (not yet a thing) combined with arbitrary self-types (also not yet a thing), we could write the following:

So that suggestion doesn't work hahah, sorry

[ad3154]

So that suggestion doesn't work hahah, sorry

Bummer, it was so clean and nice! Regardless, I'll still try and make it more self-contained by moving logic into AddressClaimingState.

[Thom-de-Jong]

Just want to add to this conversation.

State machines can be modeled in Rust using using enum's, as one would normally do in c++.
State machines however, really shine when combined with Rust's compile-time guarantees, making it impossible to program a transition to a state that we should not be in. (Typestate Programming)

The best example, that i know of, explaining this concept for state machines can be found here (Pretty State Machine Patterns in Rust )

Note however that this relatively requires a lot of code. Luckily most of it will be abstracted away by the compiler.
I would say, if we use Rust for its awesome, safe, compiler, we should build our software so the compiler will check for invalid states.

What do you think?

--edit:
This way you also don't need match statements

[GwnDaan]

@Thom-de-Jong that sounds interesting! I think we should at least try it, though I'm also fine with doing at a later stage with a seperate PR if that's easier for @ad3154

Note however that this relatively requires a lot of code.

Personally that is fine with me, the large switch/match statements for some of the state machines we have over in AgIsoStack++ are hard to gasp IMO. So anything resulting is a somewhat smaller functions of code and especially with the "Rust's compile-time guarantees, making it impossible to program a transition to a state that we should not be in." I'm in for.

[ad3154]

Hmm, that does seem nice, but agreed it's a lot of code. I'd be fine with trying it but yeah maybe I can follow up this PR with a refactor. We have a ton of state machines in AgIsoStack++ so getting a nice pattern figured out will make our lives easier for other parts of the stack as well, so thanks for the suggestion!

[codecov]

Codecov Report

Patch coverage is 15.21% of modified lines.

Files Changed	Coverage
src/driver/can_id.rs	ø
src/network_management/can_message.rs	0.00%
src/network_management/control_function.rs	15.06%
src/network_management/network_manager.rs	16.43%

📢 Thoughts on this report? Let us know!.

[ad3154]

I think this is in a good enough state to merge now so we can keep making progress. Since last time, I rebased and updated all usages of NAME in each commit to match the latest implementation of NAME. Would be nice to get this in before #26, and will give us something I can test the driver layer with