You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would there be some value in a crate for network layer abstractions (e.g. Ethernet, IP, TCP, etc.) in the same vein as embedded-hal?
This may a naive view, but it seems to me that it would be very useful for building up an embedded networking stack. For example:
A common Ethernet trait implemented by board support and driver crates would allow TCP crates (such as smoltcp) to run on arbitrary hardware.
A common TcpSocket trait implemented by TCP crates (and maybe even std?) would allow higher level abstractions (such as TLS or HTTP) to be built more easily.
hey interesting idea! seems possible, though i suspect we'd need some more examples to extract the commonality and create something generally useful. my suggestion would be that it might be worth developing the networking bits outside the wg with the goal of adoption once it's demonstrated / useful?
also i think an ethernet peripheral trait (if it can be generalised) is definitely in scope for embedded-hal ^_^
Don't forget you need Ethernet at two levels of abstraction, original IEEE 802.3 which can be directly under IP protocol and works today on copper or fibre cable and higher one for everything that mimics Ethernet frames on top of medium like IEEE 802.11 or FrameRelay. The former fits into embedded-hal as would address implementation over physical peripheral of the MCU, but then the latter shall be part of network abstractions. Maybe the one from embedded-hal could directly act as implementation for the one from network abstraction crate (if that would be the case)?
Would there be interest in just embedded networking types to start with? It would not solve the problem; but it would improve portability across existing embedded networking libraries.
Specifically I am thinking there should be types for ipv4/ipv6 addresses and EUI-48/EUI-64 hardware addresses. These have very well defined standards, and in the case of IP address there is a lot to leverage from ip.rs in std::net.
Activity
ryankurte commentedon May 3, 2019
hey interesting idea! seems possible, though i suspect we'd need some more examples to extract the commonality and create something generally useful. my suggestion would be that it might be worth developing the networking bits outside the wg with the goal of adoption once it's demonstrated / useful?
also i think an ethernet peripheral trait (if it can be generalised) is definitely in scope for embedded-hal ^_^
michalfita commentedon Jul 10, 2019
Don't forget you need Ethernet at two levels of abstraction, original IEEE 802.3 which can be directly under IP protocol and works today on copper or fibre cable and higher one for everything that mimics Ethernet frames on top of medium like IEEE 802.11 or FrameRelay. The former fits into
embedded-halas would address implementation over physical peripheral of the MCU, but then the latter shall be part of network abstractions. Maybe the one fromembedded-halcould directly act as implementation for the one from network abstraction crate (if that would be the case)?thejpster commentedon Sep 12, 2019
See also rust-embedded/embedded-hal#146
burrbull commentedon Sep 12, 2019
You can look also here:
https://github.com/japaric/jnet
newAM commentedon Jun 7, 2020
Would there be interest in just embedded networking types to start with? It would not solve the problem; but it would improve portability across existing embedded networking libraries.
Specifically I am thinking there should be types for ipv4/ipv6 addresses and EUI-48/EUI-64 hardware addresses. These have very well defined standards, and in the case of IP address there is a lot to leverage from ip.rs in std::net.
jonas-schievink commentedon Jun 7, 2020
Related: rust-lang/rfcs#2832
ryankurte commentedon Jun 7, 2020
ahh glad to see some progress on the move of types to core! supporting both
stdandno_stdat this time is a right pita without em.ryan-summers commentedon Jun 8, 2020
This is another crate that I've seen used in a few embedded crates: https://github.com/thejpster/embedded-nal
Edit: Just now noticing the original author is in this thread 😄
eldruin commentedon Oct 6, 2020
We agreed in today's WG meeting that
embedded-nalis the place for these abstractions.Further ideas and improvements are welcome over there!