Closed ryan-summers closed 4 years ago
So has there been any further discussion as to how exactly we will proceed with this?
I haven't seem any changes recently, I would assume that it's safe to move forward?
I remember there was some discussion about potentially incorporating stm32h7-ethernet
into stm32-eth
, but I think we could also target that as something for the future. It sounds like it would be a non-trivial change.
Yeah, it'd be great to move this forward.
Integration with stm32-eth
would be nice, but there would still need to be some H7-specific code. I'm happy to support either approach (stm32-eth
or here).
Regarding the smoltcp logging @richardeoin added in the stm32h7-ethernet crate, do we want this to be inside the HAL as well? As of now we do not do any logging so I'm not quite sure whether we need/want it?
We talked a bit about logging in Matrix a bit ago - it might not be a bad idea to add a log
feature flag? But it might also be fine to remove the log messages for now pending a decision on how to log in this crate.
There is only minimal logging in the stm32h7-ethernet crate, so no problem removing it. There's just one call to warn!
in src/ethernet.rs
which could become a debug_assert!
instead.
The examples could then depend on smoltcp/log
, that's not a problem imo.
As per the conversation on Matrix and in https://github.com/stm32-rs/stm32h7xx-hal/pull/76, it has been proposed that the various stm32h7 peripheral drivers should be contained within this crate to prevent many interdependent crates in the h7 ecosystem. Instead, peripherals that are not directly related to the embedded-hal should be placed behind feature gates.
This issue encompasses re-incorporating the
stm32h7-ethernet
crate into this crate.@hargoniX mentioned that he was planning on getting to this in the near future.