zephyr/drivers/modem/modem_shell.c

235 lines
5.5 KiB
C
Raw Permalink Normal View History

/** @file
* @brief Modem shell module
*
* Provide some modem shell commands that can be useful to applications.
*/
/*
* Copyright (c) 2018 Foundries.io
*
* SPDX-License-Identifier: Apache-2.0
*/
#define LOG_MODULE_NAME modem_shell
#include <zephyr.h>
#include <stdlib.h>
#include <string.h>
#include <device.h>
#include <shell/shell.h>
#include <drivers/console/uart_mux.h>
#include <sys/printk.h>
struct modem_shell_user_data {
const struct shell *shell;
void *user_data;
};
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
#if defined(CONFIG_MODEM_CONTEXT)
#include "modem_context.h"
#define ms_context modem_context
#define ms_max_context CONFIG_MODEM_CONTEXT_MAX_NUM
#define ms_send(ctx_, buf_, size_) \
(ctx_->iface.write(&ctx_->iface, buf_, size_))
#define ms_context_from_id modem_context_from_id
#define UART_DEV_NAME(ctx) (ctx->iface.dev->name)
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
#elif defined(CONFIG_MODEM_RECEIVER)
#include "modem_receiver.h"
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
#define ms_context mdm_receiver_context
#define ms_max_context CONFIG_MODEM_RECEIVER_MAX_CONTEXTS
#define ms_send mdm_receiver_send
#define ms_context_from_id mdm_receiver_context_from_id
#define UART_DEV_NAME(ctx_) (ctx_->uart_dev->name)
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
#else
#error "MODEM_CONTEXT or MODEM_RECEIVER need to be enabled"
#endif
static int cmd_modem_list(const struct shell *shell, size_t argc,
char *argv[])
{
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
struct ms_context *mdm_ctx;
int i, count = 0;
shell_fprintf(shell, SHELL_NORMAL, "Modem receivers:\n");
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
for (i = 0; i < ms_max_context; i++) {
mdm_ctx = ms_context_from_id(i);
if (mdm_ctx) {
count++;
shell_fprintf(shell, SHELL_NORMAL,
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
"%d:\tIface Device: %s\n"
"\tManufacturer: %s\n"
"\tModel: %s\n"
"\tRevision: %s\n"
"\tIMEI: %s\n"
"\tRSSI: %d\n", i,
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
UART_DEV_NAME(mdm_ctx),
mdm_ctx->data_manufacturer,
mdm_ctx->data_model,
mdm_ctx->data_revision,
mdm_ctx->data_imei,
mdm_ctx->data_rssi);
}
}
if (!count) {
shell_fprintf(shell, SHELL_NORMAL, "None found.\n");
}
return 0;
}
static int cmd_modem_send(const struct shell *shell, size_t argc,
char *argv[])
{
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
struct ms_context *mdm_ctx;
char *endptr;
int ret, i, arg = 1;
/* list */
if (!argv[arg]) {
shell_fprintf(shell, SHELL_ERROR,
"Please enter a modem index\n");
return -EINVAL;
}
/* <index> of modem receiver */
i = (int)strtol(argv[arg], &endptr, 10);
if (*endptr != '\0') {
shell_fprintf(shell, SHELL_ERROR,
"Please enter a modem index\n");
return -EINVAL;
}
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
mdm_ctx = ms_context_from_id(i);
if (!mdm_ctx) {
shell_fprintf(shell, SHELL_ERROR, "Modem receiver not found!");
return 0;
}
for (i = arg + 1; i < argc; i++) {
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
ret = ms_send(mdm_ctx, argv[i], strlen(argv[i]));
if (ret < 0) {
shell_fprintf(shell, SHELL_ERROR,
"Error sending '%s': %d\n", argv[i], ret);
return 0;
}
if (i == argc - 1) {
ret = ms_send(mdm_ctx, "\r", 1);
} else {
drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:01:00 +02:00
ret = ms_send(mdm_ctx, " ", 1);
}
if (ret < 0) {
shell_fprintf(shell, SHELL_ERROR,
"Error sending (CRLF or space): %d\n",
ret);
return 0;
}
}
return 0;
}
#if defined(CONFIG_GSM_MUX)
static void uart_mux_cb(struct device *uart, struct device *dev,
int dlci_address, void *user_data)
{
struct modem_shell_user_data *data = user_data;
const struct shell *shell = data->shell;
int *count = data->user_data;
const char *ch = "?";
if (*count == 0) {
shell_fprintf(shell, SHELL_NORMAL,
"\nReal UART\tMUX UART\tDLCI\n");
}
(*count)++;
if (dlci_address == CONFIG_GSM_MUX_DLCI_AT) {
ch = "AT";
} else if (dlci_address == CONFIG_GSM_MUX_DLCI_PPP) {
ch = "PPP";
} else if (dlci_address == 0) {
ch = "control";
}
shell_fprintf(shell, SHELL_NORMAL,
"%s\t\t%s\t\t%d (%s)\n",
uart->name, dev->name, dlci_address, ch);
}
#endif
static int cmd_modem_info(const struct shell *shell, size_t argc, char *argv[])
{
struct ms_context *mdm_ctx;
char *endptr;
int i, arg = 1;
/* info */
if (!argv[arg]) {
shell_fprintf(shell, SHELL_ERROR,
"Please enter a modem index\n");
return -EINVAL;
}
/* <index> of modem receiver */
i = (int)strtol(argv[arg], &endptr, 10);
if (*endptr != '\0') {
shell_fprintf(shell, SHELL_ERROR,
"Please enter a modem index\n");
return -EINVAL;
}
mdm_ctx = ms_context_from_id(i);
if (!mdm_ctx) {
shell_fprintf(shell, SHELL_ERROR, "Modem receiver not found!");
return 0;
}
shell_fprintf(shell, SHELL_NORMAL,
"Modem index : %d\n"
"Iface Device : %s\n"
"Manufacturer : %s\n"
"Model : %s\n"
"Revision : %s\n"
"IMEI : %s\n"
"RSSI : %d\n",
i,
UART_DEV_NAME(mdm_ctx),
mdm_ctx->data_manufacturer,
mdm_ctx->data_model,
mdm_ctx->data_revision,
mdm_ctx->data_imei,
mdm_ctx->data_rssi);
shell_fprintf(shell, SHELL_NORMAL,
"GSM 07.10 muxing : %s\n",
IS_ENABLED(CONFIG_GSM_MUX) ? "enabled" : "disabled");
#if defined(CONFIG_GSM_MUX)
struct modem_shell_user_data user_data;
int count = 0;
user_data.shell = shell;
user_data.user_data = &count;
uart_mux_foreach(uart_mux_cb, &user_data);
#endif
return 0;
}
SHELL_STATIC_SUBCMD_SET_CREATE(sub_modem,
SHELL_CMD(info, NULL, "Show information for a modem", cmd_modem_info),
SHELL_CMD(list, NULL, "List registered modems", cmd_modem_list),
SHELL_CMD(send, NULL, "Send an AT <command> to a registered modem "
"receiver", cmd_modem_send),
SHELL_SUBCMD_SET_END /* Array terminated. */
);
SHELL_CMD_REGISTER(modem, &sub_modem, "Modem commands", NULL);