ESP Modem for Rust (LTE / GSM / Sim Card)

[DaneSlattery]

The ESP-Modem Component is not supported.

It would enable SMS+GSM +LTE connections to work with the current Netif interface.

I have started calling into the the esp-modem component, and figured it would be good to wrap this up for use in esp-idf-svc.

The code in [netif.rs](https://github.com/esp-rs/esp-idf-svc/blob/bf47d2bcee6e1bc71530a23264eae63a7af84aae/src/netif.rs#L34C5-L36C9) suggests support for PPP mode, but currently there are no ways to create that interface.

I am happy to start development, but I think this may be a pretty big project and would appreciate some help fitting this into current components. The official esp-modem component is quite chunky: https://github.com/espressif/esp-protocols/tree/master/components/esp_modem.

[ivmarkov]

Unfortunately I haven't played with these modems yet, so below my very limited understanding:

• First of all, you need to talk to the modem via some peripheral. Most often than not, that's via UART, so your future modem (let's call the Rust wrapper of it for now EspModem) needs to take a Uart peripheral and TX+RX pins and/or an instantiated UartDriver. Probably the former, as you are wrapping a native component which would like to take raw pins and UART number (i.e. a "peripheral")
• If communication via other protocols than UART is also supported, we need to support it in future as well, but I don't see that in the C code
• Seems that EspModem would need to have a public API for configuring the modem (as in LTE/GSM pin code, APN etc.); I assume the C esp modem exposes a similar API that you need to wrap, that talks to the modem over UART with "AT" commands
• Once the modem is configured successfully and the LTE/GSM connection is up, I guess you need to somehow (with an API/AT command) switch it to "data" mode, where you can start sending/receiving PPP packets over UART. How exactly this is done is unclear to me, and you probably need to check the ESP Modem C examples
• Also unclear to me how to switch back to AT commands mode

Probably this is a start?

Also, are you only interested in modems for internet connectivity? I assume modems can also be used for simple SMS send/receive? Not sure how calling / receiving voice calls work over these, if supported at all... Anyway, these are probably corner cases...

Yes the project is large-ish, but maybe not that much after all...

[ivmarkov]

Oh. One more thing but maybe important - given that ALL communication with the modem is basically over a UART channel (sending and receiving bytes of data) - is there any pure-Rust crate that implements this? Even if this crate (obivously) does not talk to ESP Netif's PPP out of the box, it can be made to do so.

I'm mentioning this because if there exists a well-supported Rust crate that does the AT comm with the modem, it might be easier and cleaner to integrate with it instead, rather than going down the ESP IDF C route again.

[ivmarkov]

Interesting. And sounds rather simple.

[ivmarkov]

Also this is interesting. Given that @diondokter is active in the Embassy Matrix channel, why don't you ping him in there? Given his library, I'm sure he had dealt with a modem or two and their pesky AT-command interface. :)

@diondokter Sorry maybe even better to also ping you here (as I actually already did, from above):

The TL;DR is - we are contemplating wrapping in Rust an ESP IDF C library called "ESP Modem" that does the heavy lifting of configuring a modem via AT commands so that eventually it is switched to PPP at the end (this always happens, right?) and then once the UART channel is in "PPP mode" so to say, we we can further hook it up with the ESP IDF networking layer (this is not embassy-net but this is not really important) so that we can do IP networking.

However - this all might be unnecessary, and might just bring more unsafe C code and a lot of work for us, I fear.

• Given that we already have a UART HAL driver (of course)
• We'll surely figure out how to "plug" the PPP stream flowing on top of UART into ESP IDF so that its networking stack powers up

... the one remaining challenge is how to configure the modem via AT commands. Given your crate I referenced above, you've surely dealt with this in the past. Do you have any link / example code how this is typically done? (Ideally, with your "at-commands" crate :) ?

If the example is with - say - embassy-net + embassy-net-ppp we can still understand that, and we'll translate it all to the ESP IDF context. It is the "AT part" which is interesting to us...

[diondokter]

Hi, it really depends on your modem!
I used the at-commands crate in https://github.com/diondokter/nrf-modem which is a library that wraps the Nordic libmodem C library. I believe you can do the thing you propose here where you can setup the modem and then drop into a uart stream for TCP data or something lower level.

With nrf-modem however, there are actual APIs that you can use. So a socket is just a socket and that doesn't use the at commands. At-commands are used only for things where no API is available.

Example for building a command: https://github.com/diondokter/nrf-modem/blob/ec738c3762974bfd3559becdc785907cafff07e4/src/lib.rs#L305-L314
Example for parsing a command: https://github.com/diondokter/nrf-modem/blob/ec738c3762974bfd3559becdc785907cafff07e4/src/lib.rs#L178-L184

I'm not familiar with the ESP modem though, so the only tip I can give is to make your interface to the modem nice to use. Modems are already notoriously frustrating at times, so don't add to that with a cumbersome interface. I'm not quite sure what the embassy-net-ppp interface is like, but I'd try to make the modem device struct be able to split into two channels:

• An AT command channel
• The raw PPP channel

The AT channel you can then use to setup the modem and query it for information. The PPP channel can then be handed to the embassy-net-ppp library. The channels themselves then coordinate the state of the uart and the switching of modes of the modem.

Not sure what else I can add... But feel free to ask anything

[ivmarkov]

Not sure what else I can add... But feel free to ask anything

That was already plenty, thanks a lot!

Regarding PPP, this is just a way to tunnel IP traffic (IP packets) over a point-to-point connection, which in our case would be between the host (The ESP MCU) and the modem itself (which is whatever modem is connected over UART to the ESP).

I was imagining that's all there is to it (1- AT commands to setup the modem and then 2- a PPP channel for encapsulating the IP traffic/packets)... but then, looking at your Nordic modem wrapper, you have a lot of code in there, including stuff like TCP socket struct, UDP socket struct and whatnot.

... which brings the question...
Why is any of that necessary actually? If indeed the IP traffic between the modem and the host (ESP or whatever it is, could be even Linux) is just flowing over a PPP tunnel, then you can use any IP/TCP/UDP library that can packetize/depacketize IP over PPP. As in:

• embassy-net (or even smoltcp barebones)
• LwIP (the one used in ESP IDF)
• Linux
• etc. etc.

... so in a way you won't need to model your own TCP or UDP socket. That would come from whatever IP/TCP/UDP stack library you choose to use over the PPP tunnel...? So where is the complexity in your case coming from?

[diondokter]

I was imagining that's all there is to it (1- AT commands to setup the modem and then 2- a PPP channel for encapsulating the IP traffic/packets)... but then, looking at your Nordic modem wrapper, you have a lot of code in there, including stuff like TCP socket struct, UDP socket struct and whatnot.

In your case that is indeed all there is to it.

... which brings the question... Why is any of that necessary actually? If indeed the IP traffic between the modem and the host (ESP or whatever it is, could be even Linux) is just flowing over a PPP tunnel, then you can use any IP/TCP/UDP library that can packetize/depacketize IP over PPP.

Yep, you're right

... so in a way you won't need to model your own TCP or UDP socket. That would come from whatever IP/TCP/UDP stack library you choose to use over the PPP tunnel...? So where is the complexity in your case coming from?

While it's possible to use PPP on the nRF91, it's not needed. It provides its own socket APIs with which you can do TCP, UDP and more. This TCP/IP stack then runs on the modem itself. This has two advantages:

• The modem core is already running, so why not offload the compute to it?
• The modem has its own flash memory, so you get the TCP/IP stack for free.

If I ran the TCP/IP on the host core, then that takes away compute and it makes the firmware bigger. There still might be good reason to want to run your own stack, for example when the built-in stack is buggy or lacks some feature, but I've seen no issue in using the existing socket APIs.

For you though, you don't seem to have a choice since the ESP modem doesn't list anything about a built-in TCP/IP stack.

[ivmarkov]

@diondokter Crystal clear, thanks a ton!

@DaneSlattery I am somehow leaning towards seriously evaluating first if we can implement the modem in pure Rust. (I'm already regretting a bit that for the one-wire we did not instead expose the new RMT driver in Rust and then just write on top a pure-Rust one-wire impl that can simply operate on top of two APIs: send_bit and recv_bit. As that would've allowed us to easily re-target the pure Rust code to operate over - say - UART, as you can do send_bit / recv_bit over UART as well.)

Also in general, my feeling w.r.t. ESP IDF is that:

• The lower-level code works OK (as in drivers, the IP stack and so on). It also gets a lot of banging as ESP IDF is very popular and the base stuff is used a lot in the open
• But the higher you climb the stack... maybe better to implement in Rust itself because its equivalent in C (if it exists) is either usually not used so much because it is... higher level and thus more of niche use case OR is often not a good fit for Rust. Hence why for example I'm pushing edge-net as an alternative for the built-in ESP-IDF app-level networking protocols (HTTP client, server, mDNS etc.)

[DaneSlattery]

@ivmarkov I agree that the onewire rmt approach could be based on this API, and I would like to get to deprecating the IDF-v4 RMT driver in favour of IDF-v5, that would have simplified my approach. That said, working code is better than analysis paralysis 👍 , and I wanted this feature for my own projects. Nothing wrong with refactoring later. (I do wonder if this project has an overall direction and who is steering the wheel, would love to hear more about that working group).

As for a pure-rust implementation, I think given the information:

1. The existing esp-idf-hal UART is a suitable base
2. AT commands can be written in pure rust in a similar fashion to this: https://github.com/espressif/esp-protocols/blob/master/components/esp_modem/include/generate/esp_modem_command_declare.inc . I think even a small subset of these can be supported. I would use https://github.com/diondokter/at-commands as a base
3. I would ignore cmux and vfs support for now (mostly because I can't test them, and they seem like an advanced edge case).
4. PPP Mode should probably be based on the idf-lwip stack for now, although I agree that edge-net is a really solid library.

[ivmarkov]

@ivmarkov I agree that the onewire rmt approach could be based on this API, and I would like to get to deprecating the IDF-v4 RMT driver in favour of IDF-v5, that would have simplified my approach. That said, working code is better than analysis paralysis 👍 , and I wanted this feature for my own projects. Nothing wrong with refactoring later.

If I recall correctly, the approach where the new RMT driver needed to be exposed was simply deemed much more effort to implement by you. Hence why we ended up where we are. Which is OK, we still did a good progress! But we definitely did not have analysis-paralysis, I believe.

(I do wonder if this project has an overall direction and who is steering the wheel, would love to hear more about that working group).

There is no "steering committee" of sorts, because Espressif is taking a rather opportunistic / tactical approach towards its Rust-related portfolio. This is also valid for the bare-metal crates which do have paid developers working on those.

esp-idf-* is a community effort, and I guess I'm the most active one here, who historically contributed the largest portion of the code, but we also now have @Vollbrecht as an active committer and a few (now inactive) committers who contributed large portions as well (as in the esp-idf-sys "native" build and components that you are using - these originally came from @N3xed).

Do I miss a more "architectural" / "bigger-horizon" approach which can be discussed among more community members? I certainly do, but this requires a lot of prior exposure to the esp-idf-* crates (a huge time investment) and in the absence of Espressif steering it, it is what it is - i.e. the ones who sticked around for the longnest (and are vocal) tend to define the direction.

As in, there are bi-weekly meetings of the esp-rs community (this include both bare-metal and ESP-IDF crates) which are open for everyone that you might want to attend. But I fear these are more of a "sprint ceremony" "what was done last sprint" kind of a thing - primarily for the bare-metal team, rather than a forum where direction is being discussed. We can change that of course, but to change it, there must be more people that feel the change is useful and necessary, and I feel I'm in the minority there. :)

Anyway, I digress.

As for a pure-rust implementation, I think given the information:

1. The existing esp-idf-hal UART is a suitable base
2. AT commands can be written in pure rust in a similar fashion to this: https://github.com/espressif/esp-protocols/blob/master/components/esp_modem/include/generate/esp_modem_command_declare.inc . I think even a small subset of these can be supported. I would use https://github.com/diondokter/at-commands as a base
3. I would ignore cmux and vfs support for now (mostly because I can't test them, and they seem like an advanced edge case).

Can you elaborate what cmux and vfs support in the ESP Modem C driver is about, if you've looked into it?

4. PPP Mode should probably be based on the idf-lwip stack for now, although I agree that edge-net is a really solid library.

I did not mention edge-net as an alternative to the ifd-lwip stack as these are two different animals:

• edge-net is "application" protocols that sit above IP/TCP/UDP, like http server and client, dhcp server and client, mdns responder and so on. It is just I have found out that the native "C" ESP IDF http, wensockets, mdns etc. services to be suboptimal in certain aspects
• lwip (and esp-netif) is your IP(/TCP/UDP) stack and is the right place we need to plug the esp modem

[DaneSlattery]

Thank you for the detail on the management structures. It is interesting to see. It seems like no_std is a key focus for espressif, and I wonder at what point it will supercede the rust-idf approach.

Here's what I have on cmux, which seems useful for keeping the UART in AT and PPP mode simultaneously.
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/serial_lte_modem/doc/CMUX_AT_commands.html

And VFS:
/* The VFS terminal is just a demonstration of using an abstract file descriptor
* which implements non-block reads, writes and selects to communicate with esp-modem.
* This configuration uses the same UART driver as the terminal created by create_uart_dte(),
* so doesn't give any practical benefit besides the FD use demonstration and a placeholder
* to use FD terminal for other devices
*/

Here are some more relevant crates:

• https://github.com/embassy-rs/ppproto/tree/main
• https://github.com/FactbirdHQ/atat/tree/master (usage here : https://github.com/atlas-aero/rt-esp-at-nal/blob/main/src/commands.rs) going to start here.
• https://github.com/technocreatives/sim7000/blob/main/samples/nrf52840/src/main.rs

[ivmarkov]

Thank you for the detail on the management structures. It is interesting to see. It seems like no_std is a key focus for espressif, and I wonder at what point it will supercede the rust-idf approach.

It is. The ESP-IDF is viewed as a stop-gap solution, and obviously the solution if you already have a large C codebase that you can't or don't want to migrate - in one go or at all.

With that said, it's been like that for many years.

What I'm personally doing is trying to abstract from the underlying "OS" as much as possible - with e-hal, or by rolling your own traits etc. And by using async IO as much as possible as no other embedded platform besides esp-idf-* has threads (and STD). So that I can migrate between ESP-IDF and baremetal, or even to other MCUs.

Hence - the more code we have in Rust itself - the better for everyone!

Here's what I have on cmux, which seems useful for keeping the UART in AT and PPP mode simultaneously. https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/serial_lte_modem/doc/CMUX_AT_commands.html

And VFS: /* The VFS terminal is just a demonstration of using an abstract file descriptor * which implements non-block reads, writes and selects to communicate with esp-modem. * This configuration uses the same UART driver as the terminal created by create_uart_dte(), * so doesn't give any practical benefit besides the FD use demonstration and a placeholder * to use FD terminal for other devices */

Agreed that none of these is essential. Even CMUX - at least initially.

Here are some more relevant crates:

• https://github.com/embassy-rs/ppproto/tree/main

Yes this is the PPP impl for embassy. If your AT-commands code is in pure Rust (you can even abstract the UART by using just the async IO Read/Write traits), we can even write connectors for your code to embassy-PPP.

https://github.com/FactbirdHQ/atat/tree/master (usage here : https://github.com/atlas-aero/rt-esp-at-nal/blob/main/src/commands.rs) going to start here.

Sounds like a plan!

See, if everything goes the way we hope it goes, we might not even have to PR anything in esp-idf-svc. It might turn out that your code can live as an external crate, and just needs 3 lines of code or so for the PPP glue!

[DaneSlattery]

I have started writing out some AT commands over a UART device and getting replies. I will borrow a few commands from https://github.com/technocreatives/sim7000/tree/main but implement them using the atat traits.
I think it makes sense to impl atat::blocking::AtatClient and atat::asynch::AtatClient for the esp-idf-hal uart.
I do think that whatever code we write here should also target something that impls embedded_io::Read + Write , that way it can be quite general.

What I am not sure of is how to glue the modem when it is in ppp mode to a netif.
The docs say the general flow is:

Create a DCE instance (using esp_modem_new())

Call specific functions to issue AT commands (Modem commands)

Switch to the data mode (using esp_modem_set_mode())

Perform desired network operations (using standard networking API, unrelated to ESP-MODEM)

Optionally switch back to command mode (again esp_modem_set_mode())

Destroy the DCE handle (sing esp_modem_destroy())

I see this in the c-api: and this)