Embedded-hal: Socket API

Created on 4 Jul 2019  路  6Comments  路  Source: rust-embedded/embedded-hal

Having worked with a few different modems lately (nRF9160, Quectel BC68, ESP8266) I note they all have APIs to open sockets, and read/write, etc, but they're all different. The nRF9160 uses a BSD-like library, the BC68 uses AT+NSOCR AT commands while the ESP8266 uses AT+CIPxxx AT commands.

I wonder if we could implement some traits for:

  • An object which lets you open UDP sockets
  • An object which lets you open TCP sockets
  • A socket object, which lets you read, write, poll, flush, close, etc (so like the core::io traits we don't yet have I guess, with some extra functions)

We can then write, for example, an HTTP client which works on desktop Linux (we'd have an implementation which uses std::net / mio), or an embedded system with an ESP8266 plugged into a UART, or an embedded sytem with a BC68 plugged into a UART, or on an nRF9160.

Does anything like this exist? If not, I'll see if I can knock up a prototype.

discussion

Most helpful comment

Here's what we call a "starter for ten".

https://github.com/thejpster/embedded-nal

All 6 comments

Did you reach any conclusion on this?

I would be very interested in this exact thing! I am currently writing driver crates for the entire uBlox wifi series of host-based (AT command) devices and the uBlox GSM host based devices, both of which could benefit greatly from implementing a common trait for networking on TCP and UDP sockets.

They are both already based on the only requirement being an embedded-hal layer beneath, as well as a common AT parser crate.

I would end up using MQTT ontop of TCP, and am planning on using the mqtt-rs crate, which could also benefit from OP's suggestion of a shared socket layer.

How about we start with a network-hal package? Given it's kindof a different level of abstraction / function I think it'd make sense to have different crates (and I've just done this with a radio hal).

And this could either be outside the WG and transferred later, or created here depending on what people favour?

I think that would be a great start!
Just out of curiosity, how do you define a radio? Do you have any examples? It looks good though, and if we can make something similar for network, i think it would be of great benefit to the community, now that we start seeing more and more network driver crates popping up.

how do you define a radio? Do you have any examples?

Yeah good question, the abstraction I've focused on is for digital packet radios, where you send and receive _messages_ that are byte arrays, which ime you can implement most other simple protocols on top of. Much lower level than say, a WiFi modem that takes AT commands, but, hoping to extend it up enough that BLE and LoRaWAN etc. can be built on it easily.

A few examples:

On the network-hal front, it's probably also worth looking at smoltcp.

Cool! Great work!

Regarding the smoltcp i do agree that it is worth both mentioning and looking at, but it seems to me like it is hard to use for host-based devices where SSL and the TCP/IP stack is offloaded to a co-processor, like in the AT cases.

Perhaps a network-hal could be more like the embedded-hal where it is just a number of high level traits, that could then be implemented both by my AT based devices, other networking crates and the smoltcp stack?

Here's what we call a "starter for ten".

https://github.com/thejpster/embedded-nal

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dbrgn picture dbrgn  路  3Comments

japaric picture japaric  路  8Comments

tib888 picture tib888  路  3Comments

Rahix picture Rahix  路  5Comments

hargoniX picture hargoniX  路  10Comments