embedded-hal

[tristanguerragomez]

Hi,

I'm wondering if any thought has been put in on abstracting out the CAN implementation(s) by making use of the Rust Embedded HAL?

[samcrow]

Part of that would be relatively easy. The interfaces used to send and receive frames are almost the same here and in embedded-can.

The challenging part is configuring the frame reception filters. Canadensis uses an additional function to set up filtering of incoming frames. That minimizes the number of irrelevant frames the software has to handle based on what the node is subscribed to. As far as I know, embedded-hal doesn't have an active proposal for a way to configure those filters.

If someone has a use case for canadensis that does not need frame filtering, or if there is another proposed interface for configuring filters that we can use, that would be worth trying.

[tristanguerragomez]

You're absolutely right, embedded-hal does not expose an interface for filters. It was proposed in the original PR, but it got pushed back... very unfortunate. If memory serves me correctly, it was a "no common denominator" problem: too many different variations/permutations.

I've just recently jumped into this pool so forgive me if I'm missing something. Does Canadensis need to worry about filtering? What might be a reasonable workaround to keep a lid on scope creep would be to:

1. Let the Canadensis consumer instantiate the object implementing the embedded-can Can trait
2. Let the Canadensis consumer configure the filters for that object
3. The consumer then passes that object to Canadensis and the magic begins

In other words, I'm not sure deep diving into the CAN internals of every silicon vendor is a good idea as it would open a Pandora's box.

Just thinking out loud, again, I just recently dove intro this pool, forgive me if I'm off the mark.

[tristanguerragomez]

Apologies if what I said came across the wrong way, I've been deep diving into your code and I must admit your Rust skills are quite impressive.

Here's what I often look at to not get discouraged:

😁

[samcrow]

Correct, frame filtering in hardware is not essential. It just reduces the amount of the time that the software has to spend looking at frames that the node is not interested in.

Having the client code configure the filters at the beginning is a good approach, as long as the filters stay up to date with the topics/services the node uses. Most applications probably don't need to reconfigure the filters while running.

The current architecture is a little more complicated than it needs to be and could use some improvement.

[tristanguerragomez]

I find that reading the code better than me is a great source of inspiration/learning.

Here's my gut feeling on what would be optimal: do the heavy lifting in Rust, and expose the functionality to multiple languages. Signal is a very good example of how to do so: libsignal. Brilliantly elegant.

Thoughts?

[samcrow]

Using FFI with this library is possible. The biggest limitation is that this library uses generic types for almost everything. The FFI functions would need to choose some reasonable values for all the generic parameters.

[tristanguerragomez]

Thanks for your input Sam.

Here's my take on all this Cyphal stuff. In terms of inter-vehicular comms, it's nice in the sense that it's adaptable to change, but not revolutionary. You can see this by the resistance in adoption by the Ardupilot project. Where I think Cyphal could really shine is things like swarm technologies where a CAN bus ain't going to cut it and other transports are a must.

In terms technology stacks, using Pavel's C libraries makes more sense, fact of the matter is 1) the microprocessor world is still in the stone age 😁 and 2) as long as the code base is small, C is manageable if crafted with care ⚠️.

But as soon as you start going up the software stack, C == 💀: the new Linus Trovalds of the world aren't learning C, they're learning Rust.

Ok, I'll stop boring you with my speculation. I'll end this by saying that what I think is needed to make happen what I proposed is finding a way to monetize the work. There's a lot of "give me, give me, give me" in the OSS world, but nowhere near as much giving. Simple economics. Personally, I live on a sailboat which needs parts, fuel and Internet service for my fancy new in-motion Starlink dish, none of which is free 😁

I'll end by saying that yes, you overcomplicated things some, but it's still very nice work, something you should be very proud of. And guess what's worth even more? The knowledge and experience gained, something that's in your head and nobody can take away from you.

It was a pleasure meeting you Sam, closing this off,

Tristán