ESP Modem

[DaneSlattery]

trafficstars

Attempt at https://github.com/esp-rs/esp-idf-svc/issues/468

[DaneSlattery]

Right now I'm seeing some events on the IP_EVENT_PPP_GOT_IP or NETIF_PPP_ERRORUSER topics.

This is what my console shows so far, I'm not sure yet if the modem is fully able to connect to the LTE network as I haven't tried to do some network request.

I (7373) esp_idf_svc::modem: connect Some("115200")
D (7383) esp_netif_lwip: LwIP stack has been initialized
D (7383) esp_netif_lwip: esp-netif has been successfully initialized
D (7393) esp_netif_lwip: check: remote, if=0x3fc9fa70 fn=0x420e510c
0x420e510c - esp_netif_new_api
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/lwip/esp_netif_lwip.c:690
D (7393) esp_netif_objects: esp_netif_add_to_list_unsafe netif added successfully (total netifs: 1)
D (7403) esp-netif_lwip-ppp: esp_netif_new_ppp: PPP connection created: 0x3fca7c48
D (7413) esp_netif_lwip: call api in lwip: ret=0x0, give sem
I (7423) esp_idf_svc::netif::driver: Post attach ifconfig: esp_netif_driver_ifconfig { handle: 0x3fca8f14, transmit: Some(0x4200b920), transmit_wrap: None, driver_free_rx_buffer: None }
0x4200b920 - esp_idf_svc::netif::driver::EspNetifDriverInner<T>::raw_tx
    at /home/dane/dev/esp-idf-svc/src/netif.rs:1103
I (7433) esp_idf_svc::netif::driver: Netif config: esp_netif_ppp_config { ppp_phase_event_enabled: true, ppp_error_event_enabled: false }
D (7453) esp_netif_handlers: esp_netif action has started with netif0x3fca7a18 from event_id=0
D (7453) esp_netif_lwip: check: remote, if=0x3fca7a18 fn=0x420e53c8
0x420e53c8 - esp_netif_start_api
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/lwip/esp_netif_lwip.c:1068
D (7463) esp_netif_lwip: esp_netif_start_api 0x3fca7a18
D (7473) esp-netif_lwip-ppp: esp_netif_start_ppp: Starting PPP connection: 0x3fca7c48
D (7473) esp_netif_lwip: check: local, if=0x3fca7a18 fn=0x420e5c88
0x420e5c88 - esp_netif_update_default_netif_lwip
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/lwip/esp_netif_lwip.c:316
D (7483) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3fca7a18
D (7493) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (308043) esp_netif_lwip: esp_netif_internal_dhcpc_cb lwip-netif:0x3fca7a9c
D (308043) esp_netif_lwip: if0x3fca7a18 ip changed=1
D (308043) event: running post IP_EVENT:6 with handler 0x42008c98 and context 0x3fca7a08 on loop 0x3fca2e58
0x42008c98 - esp_idf_svc::modem::EspModem<T>::raw_on_ip_event
    at /home/dane/dev/esp-idf-svc/src/modem.rs:133
I (308053) esp-netif_lwip-ppp: Connected
I (308063) esp_idf_svc::modem: Got event id: 6
I (308073) esp_idf_svc::modem: modem connected to ppp server, info: 0x3fca9660
D (308073) event: running post IP_EVENT:6 with handler 0x420e461c and context 0x3fca8f54 on loop 0x3fca2e58
0x420e461c - esp_netif_action_connected
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/esp_netif_handlers.c:36
D (308083) esp_netif_handlers: esp_netif action connected with netif0x3fca7a18 from event_id=6
D (308093) esp_netif_lwip: check: remote, if=0x3fca7a18 fn=0x420e583c
0x420e583c - esp_netif_up_api
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/lwip/esp_netif_lwip.c:1647
D (308103) esp_netif_lwip: esp_netif_up_api esp_netif:0x3fca7a18
D (308103) esp_netif_lwip: check: local, if=0x3fca7a18 fn=0x420e5c88
0x420e5c88 - esp_netif_update_default_netif_lwip
    at /home/dane/dev/esp-idf-svc/.embuild/espressif/esp-idf/v5.2.2/components/esp_netif/lwip/esp_netif_lwip.c:316
D (308113) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3fca7a18
D (308123) esp_netif_lwip: call api in lwip: ret=0x0, give sem
E (308123) esp_netif_handlers: esp_netif_action_connected 47 connected action: dhcpc failed ret=0x102
D (308133) event: running post NETIF_PPP_STATUS:0 with handler 0x42009350 and context 0x3fca8ee4 on loop 0x3fca2e58
0x42009350 - esp_idf_svc::modem::EspModem<T>::raw_on_ppp_changed
    at /home/dane/dev/esp-idf-svc/src/modem.rs:151
I (308143) esp_idf_svc::modem: Got event id ppp changed: 0

[ivmarkov]

@DaneSlattery because this is a large effort with many moving parts, I hope you don't mind if I merge a portion of the changes already now? What I think is ready for merge is your "nonstatic" enhancements to EspNetifDriver (basically "as-is") as well as the mapping of the PPP event loop events (I'll only rename ModemEvent to PppEvent and move it to inside netif.rs instead of modem.rs as it is kinda sorta Netif stuff too - and - is kinda generic too (who knows what else besides an LTE modem might want to use PPP).

To have you listed as a contributor to this code in GIT history and yet - to save you some time - I'll fork your PR branch, revert the other changes which are still not ready (EspModem) and the ESP-IDF-agnostic modem stuff, and then merge that way, so it would be your changes and then my changes on top and we listed both as contributors.

Once the changes land in master, you should re-base your branch on top.

But please tell me if you prefer with me to wait until we have everything in-place instead. I'm still not sure how I feel specifically about the EspModem struct, but the other changes I enlisted absolutely need to land inside esp-idf-svc as they are very useful stuff which is ESP-IDF specific anyway

[DaneSlattery]

@DaneSlattery because this is a large effort with many moving parts, I hope you don't mind if I merge a portion of the changes already now? What I think is ready for merge is your "nonstatic" enhancements to EspNetifDriver (basically "as-is") as well as the mapping of the PPP event loop events (I'll only rename ModemEvent to PppEvent and move it to inside netif.rs instead of modem.rs as it is kinda sorta Netif stuff too - and - is kinda generic too (who knows what else besides an LTE modem might want to use PPP).

I am happy to get this in so long, go ahead, I'll rebase once the dust is settled. I have started porting stuff to a SimModem crate so that SimModem is generic with embedded_io::Read+embedded_io::Write (now that UartDriver does what we expect, I can actually move away from the TimeOut based code read)

I saw your comments on the PR, and I was only using the timeout to force UartDriver:::read to return the bytes. I was confident that after 1s the modem will have replied, but that is completely arbritrary. I like the solution to feed parts into a Digester that is a state machine searching for some terminator (like '\r\nOK\r\n'.as_bytes(). This can happen after a few read cycles. After the terminator is found, then we can try parse it using the at_commands parser. If the terminator is not found, the digester will keep waiting. It would actually be really useful if at_commands::parser could provide expects_terminator(...) and throw a different error if the terminator is not found.

But please tell me if you prefer with me to wait until we have everything in-place instead. I'm still not sure how I feel specifically about the EspModem struct, but the other changes I enlisted absolutely need to land inside esp-idf-svc as they are very useful stuff which is ESP-IDF specific anyway

Go ahead. I do think EspModem has a place in esp-idf-svc as a glue, but perhaps in a different form. It's serving quite a few functions that might be better suited to EspNetifDriver, where EspModem can just wrap EspNetifDriver. That said, it's still quite specific to the esp-idf, and it will be a challenge for anyone to use a modem with esp-idf-svc without the glue.

[DaneSlattery]

I want to pick this up again, but I've lost the plot.