Feature gate for smoltcp.

[IamTheCarl]

The Ethernet driver requires smoltcp. This makes perfect sense if you intend to use the smoltcp network stack. I do think you should leave the compatibility in under a feature gate, as I'm sure it's very nice for those users.

I've been wrapping up the FreeRTOS network stack with Rust and having to depend on smoltcp to use this crate's driver for the Ethernet does feel just a bit redundant.

It looks like the only thing smoltcp is used for in this crate is traits and mac addresses. I think it could be put behind a feature gate.

If you think so too, I'd be willing to make a fork and figure it out.

[richardeoin]

I think we would be very happy to support alternatives to smoltcp whilst keeping the current convenience of having the smoltcpphy::Device implementation available within the HAL if wanted. Small breaking changes to the feature gates are acceptable, I guess it would make sense to split it into one feature gate for the basic ethernet support and another for smoltcp that depends on the first.

If you're implementing a general API for the ethernet driver, you could take some inspiration from stm32-eth.

[IamTheCarl]

I'm all for making standardized interfaces! That could even remove the need for this feature gate.

We would need to move MAC addresses, IP addresses, UDP sockets, TCP streams, and TCP connection listeners into traits or more generalized structs.

Should I make an additional crate for generalized Ethernet interfaces?

[IamTheCarl]

Actually reading through more documentation, we need to add pretty much all of smoltcp::phy to a crate. Let me get this FreeRTOS TCP shim functional enough to be confident on what I need before I really commit a plan for building this bridge.

[richardeoin]

Hmm I think you might be over-complicating this a little. It should be as simple as:

• Defining an alternative to smoltcp::wire::EthernetAddress and using it
• Putting these lines behind a feature gate

Then you get the ethernet HAL without requiring smoltcp.

Of course you then need some way for the bottom of your own network stack to talk to the ethernet HAL. I would recommend implementing something very similar to the interface in stm32-eth. This interface is completely unrelated to IP/UDP/TCP/whatever.

[IamTheCarl]

I think you're right, and I think that will work very well for my needs. I'm working toward something like that.

My confusion was caused by the fact that there's really two ends I need to create abstractions for: The hardware and the application. That's a conversation I should have with the SmolTCP team.

I've been working on this still but have been held up by a lot of improvements I felt were necessary for the FreeRTOS wrapper I depend on. It's now much safer to use with interrupts, because you can now tie the interrupt to the lifetime of some scope. This makes it so you don't need to define your own global variables to share resources with the interrupt and an application task.

I'll likely be proposing an interface for that as well when the time comes, although I'm not sure if this is the crate such a proposal should go to.

[ryan-summers]

@IamTheCarl Of relevance to this thread is the embedded-nal as well: https://github.com/rust-embedded-community/embedded-nal

[IamTheCarl]

Thank you. I noticed that and was thinking I'd go for it once I got this working.

I've been distracted with school and made a bit of an overhaul to the FreeRTOS bindings so it'll be a bit before I get back into this.

I'm willing to share what I have though.