feat(esp_modem): Make some CMUX params compile-time configurable

* bool flag to defragment CMUX payload (useful for devices that send longer messages)
* int flag to force a delay between creating virtual terminals (useful for chatty devices that send some requests)
This commit is contained in:
David Cermak
2022-09-30 12:01:50 +02:00
parent ce175df376
commit 25ac2d98c6
3 changed files with 48 additions and 3 deletions

View File

@ -0,0 +1,28 @@
menu "esp-modem"
config ESP_MODEM_CMUX_DEFRAGMENT_PAYLOAD
bool "Defragment CMUX messages internally"
default y
help
If enabled (default), the esp-modem automatically defragments CMUX messages
to only pass the completed CMUX message to higher layers.
This is useful for messages in command mode (if they're received fragmented).
It's not a problem for messages in data mode as the upper layer (PPP protocol)
defines message boundaries.
Keep the default to true for most cases (as most devices use simply 1 byte CMUX
length, as the internal Rx buffer of size >= 256 bytes won't overflow)
Set to false if your devices uses 2 byte CMUX payload (e.g. A7672S).
The operation would work without an issue in data mode, but some replies
in command mode might come fragmented in rare cases so might need to retry
AT commands.
config ESP_MODEM_CMUX_DELAY_AFTER_DLCI_SETUP
int "Delay in ms to wait before creating another virtual terminal"
default 0
help
Some devices might need a pause before sending SABM command that creates
virtual terminal. This delay applies only to establishing a CMUX mode.
The typical reason for failing SABM request without a delay is that
some devices (SIM800) send MSC requests just after opening a new DLCI.
endmenu

View File

@ -69,10 +69,24 @@ after creating multiple virtual terminals, designating some of them solely to da
### DTE's
Currently we support only UART, but modern modules support other communication interfaces, such as USB, SPI.
Currently, we support only UART (and USB as a preview feature), but modern modules support other communication interfaces, such as USB, SPI.
### Other devices
Adding a new device is a must-have requirement for the esp-modem component. Different modules support different commands,
or some commands might have a different implementation. Adding a new device means to provide a new implementation
as a class derived from `GenericModule`, where we could add new commands or modify the existing ones.
## Configuration
Modem abstraction is configurable both compile-time and run-time.
### Component Kconfig
Compile-time configuration is provided using menuconfig. Please check the description for the CMUX mode configuration options.
### Runtime configuration
Is defined using standard configuration structures for `DTE` and `DCE` objects separately. Please find documentation of
* :cpp:class:`esp_modem_dte_config_t`
* :cpp:class:`esp_modem_dce_config_t`

View File

@ -17,15 +17,18 @@
#include <cxx_include/esp_modem_cmux.hpp>
#include "cxx_include/esp_modem_dte.hpp"
#include "esp_log.h"
#include "sdkconfig.h"
using namespace esp_modem;
#ifdef CONFIG_ESP_MODEM_CMUX_DEFRAGMENT_PAYLOAD
/**
* @brief Define this to defragment partially received data of CMUX payload
* This is useful if upper layers expect the entire payload available
* for parsing.
*/
#define DEFRAGMENT_CMUX_PAYLOAD
#endif
#define EA 0x01 /* Extension bit */
#define CR 0x02 /* Command / Response */
@ -290,7 +293,7 @@ bool CMux::on_cmux_data(uint8_t *data, size_t actual_len)
actual_len = term->read(data, data_to_read);
#else
data = buffer.get();
actual_len = term->read(data, buffer_size);
actual_len = term->read(data, buffer.size);
#endif
}
ESP_LOG_BUFFER_HEXDUMP("CMUX Received", data, actual_len, ESP_LOG_VERBOSE);
@ -390,7 +393,7 @@ bool CMux::init()
}
}
if (i > 1) { // wait for each virtual terminal to settle MSC (no need for control term, DLCI=0)
usleep(100'000);
usleep(CONFIG_ESP_MODEM_CMUX_DELAY_AFTER_DLCI_SETUP * 1'000);
}
}
return true;