Exposing the Ethernet Media Access Controller (MAC)

[mitchmindtree]

We recently ordered a Teensy 4.1 to test its Ethernet capabilities, so I thought I'd kick off a discussion on how to approach adding support and to track progress!

I asked in the rust-embedded matrix channel and someone mentioned we'd need to expose the MAC. They mentioned the stm32 implementation might make for a useful reference:

there's an example stm32 driver which supports smoltcp here which might be helpful in writing one for imxrt: https://github.com/stm32-rs/stm32-eth

The imxrt106X docs are pretty comprehensive, I think the ENET section is what we're looking for.

I'm happy to have a go at this, though it looks like our "Ethernet Kit" won't arrive for another week or two yet.

[mciantyre]

Sounds good! Let us know how we can help.

We should keep an eye on Teensy core development. Looks like they're building an ethernet stack and aggregating discussions at https://github.com/PaulStoffregen/teensy41_ethernet.

The rest are my rambling "things to consider..."

Ethernet might be an advanced feature that users should depend on as needed. I'll vote for building the driver outside of the imxrt-hal crate, just as the stm-rs team maintains the driver outside of their HAL crate. The alternative is in the HAL, behind a feature flag. Keep up with #56 as we consider new HAL structures.

The driver could still be maintained in this repo (as part of the workspace), or in a separate repo. If we favor a separate repo, I can create that for ya.

The driver could use the RAL, or hand-roll the register access layer. We've done both in the HAL; the DMA driver is notable for not using the RAL, while nearly all other drivers do use the RAL. I've found that a hand-rolled register layer may lend to a cleaner implementation, but you can make that call as you dive in.

[teburd]

If it needs to stay in sync, and buildable with anything in this repo, I'd recommend adding it here, it might be a good first test to have an externalized crate in the workspace provide a peripheral driver. I think given the ideas @mciantyre hammered out in the really nice iomuxc changes it probably makes sense to have peripheral drivers in their own crates which an over-arching chip hal crate can depend on as done so far.

[teburd]

There is now embedded-nal, https://crates.io/crates/embedded-nal which has the goal of allowing networking using smoltcp (or other future tcp/ip stacks) on top of that API

[terrorfisch]

Is there already some code in this direction? I started playing around with it and realized that there is no abstraction layer in smoltcp that allows utilizing the full hardware support. I am currently working on a Device trait implementation that uses no hardware optimizations at all as a start, but I will need a very optimized version in the end.