2019-11-01 13:45:29 +01:00
|
|
|
# Modem configuration options
|
2018-08-01 22:01:00 +02:00
|
|
|
|
|
|
|
|
# Copyright (c) 2018 Foundries.io
|
|
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
|
|
|
|
|
menuconfig MODEM
|
2023-03-27 14:55:23 +02:00
|
|
|
bool "Modem drivers"
|
2018-08-01 22:01:00 +02:00
|
|
|
help
|
|
|
|
|
Enable config options for modem drivers.
|
|
|
|
|
|
|
|
|
|
if MODEM
|
|
|
|
|
|
2019-02-14 10:21:27 +01:00
|
|
|
module = MODEM
|
|
|
|
|
module-str = modem
|
|
|
|
|
source "subsys/logging/Kconfig.template.log_config"
|
|
|
|
|
|
2018-08-01 22:01:00 +02:00
|
|
|
config MODEM_RECEIVER
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Modem receiver helper driver"
|
2019-01-25 18:23:20 +01:00
|
|
|
depends on SERIAL_SUPPORT_INTERRUPT
|
|
|
|
|
select UART_INTERRUPT_DRIVEN
|
2019-02-13 22:48:46 +01:00
|
|
|
select RING_BUFFER
|
2018-08-01 22:01:00 +02:00
|
|
|
help
|
|
|
|
|
This driver allows modem drivers to communicate over UART with custom
|
|
|
|
|
defined protocols. Driver doesn't inspect received data and all
|
|
|
|
|
aspects of received protocol data are handled by application via
|
|
|
|
|
work method provided. This driver differs from the pipe UART driver
|
|
|
|
|
in that callbacks are executed in a different work queue and data is
|
|
|
|
|
passed around in k_pipe structures.
|
|
|
|
|
|
|
|
|
|
config MODEM_RECEIVER_MAX_CONTEXTS
|
|
|
|
|
int "Maximum number of modem receiver contexts"
|
|
|
|
|
depends on MODEM_RECEIVER
|
|
|
|
|
range 1 10
|
|
|
|
|
default 1
|
|
|
|
|
help
|
|
|
|
|
Maximum number of modem receiver contexts to handle. For most
|
|
|
|
|
purposes this should stay at 1.
|
|
|
|
|
|
2019-08-07 17:01:00 +02:00
|
|
|
config MODEM_CONTEXT
|
|
|
|
|
bool "Modem context helper driver [EXPERIMENTAL]"
|
2021-10-15 14:28:18 +02:00
|
|
|
select EXPERIMENTAL
|
2019-08-07 17:01:00 +02:00
|
|
|
help
|
|
|
|
|
This driver allows modem drivers to communicate with an interface
|
|
|
|
|
using custom defined protocols. Driver doesn't inspect received data
|
|
|
|
|
and all aspects of received protocol data are handled by application
|
|
|
|
|
work method provided. This driver combines abstractions for:
|
|
|
|
|
modem interface, command handler, pin config and socket handling each
|
|
|
|
|
of which will need to be configured.
|
|
|
|
|
|
|
|
|
|
if MODEM_CONTEXT
|
|
|
|
|
|
|
|
|
|
config MODEM_CONTEXT_MAX_NUM
|
|
|
|
|
int "Maximum number of modem contexts"
|
|
|
|
|
default 1
|
|
|
|
|
help
|
|
|
|
|
Maximum number of modem contexts to handle. For most
|
|
|
|
|
purposes this should stay at 1.
|
|
|
|
|
|
|
|
|
|
config MODEM_CONTEXT_VERBOSE_DEBUG
|
|
|
|
|
bool "Verbose debug output in the modem context"
|
|
|
|
|
help
|
|
|
|
|
Enabling this setting will turn on VERY heavy debugging from the
|
|
|
|
|
modem context helper. Do NOT leave on for production.
|
|
|
|
|
|
2019-08-07 17:02:00 +02:00
|
|
|
config MODEM_IFACE_UART
|
|
|
|
|
bool "UART-based modem interface"
|
|
|
|
|
select RING_BUFFER
|
|
|
|
|
help
|
|
|
|
|
To configure this layer for use, create a modem_iface_uart_data
|
|
|
|
|
object and pass it's reference to modem_iface_uart_init()
|
|
|
|
|
along with the modem_iface reference from your modem_context object
|
|
|
|
|
and the UART device name.
|
|
|
|
|
|
2022-04-05 08:13:52 +02:00
|
|
|
if MODEM_IFACE_UART
|
|
|
|
|
|
|
|
|
|
choice MODEM_IFACE_UART_BACKEND
|
|
|
|
|
prompt "UART backend to use for modem interface"
|
|
|
|
|
default MODEM_IFACE_UART_INTERRUPT
|
|
|
|
|
|
|
|
|
|
config MODEM_IFACE_UART_INTERRUPT
|
|
|
|
|
bool "UART-based modem interface using interrupt API"
|
|
|
|
|
depends on SERIAL_SUPPORT_INTERRUPT
|
|
|
|
|
select UART_INTERRUPT_DRIVEN
|
|
|
|
|
|
2022-04-05 12:12:56 +02:00
|
|
|
config MODEM_IFACE_UART_ASYNC
|
|
|
|
|
bool "UART-based modem interface using async API"
|
|
|
|
|
depends on SERIAL_SUPPORT_ASYNC
|
|
|
|
|
select UART_ASYNC_API
|
|
|
|
|
|
2022-04-05 08:13:52 +02:00
|
|
|
endchoice
|
|
|
|
|
|
2022-04-05 12:12:56 +02:00
|
|
|
if MODEM_IFACE_UART_ASYNC
|
|
|
|
|
|
|
|
|
|
config MODEM_IFACE_UART_ASYNC_RX_BUFFER_SIZE
|
|
|
|
|
int "Size in bytes of the RX buffers provided to UART driver"
|
|
|
|
|
default 64
|
|
|
|
|
help
|
|
|
|
|
Increasing this value decreases the number of UART interrupts needed
|
|
|
|
|
to receive large packets.
|
|
|
|
|
|
|
|
|
|
config MODEM_IFACE_UART_ASYNC_RX_NUM_BUFFERS
|
|
|
|
|
int "Number of RX buffers available to the UART driver"
|
|
|
|
|
default 2
|
|
|
|
|
help
|
|
|
|
|
This value needs to be twice the number of UART modems using the
|
|
|
|
|
driver to avoid buffer starvation.
|
|
|
|
|
|
|
|
|
|
config MODEM_IFACE_UART_ASYNC_RX_TIMEOUT_US
|
|
|
|
|
int "Timeout for flushing RX buffers after receiving no additional data"
|
|
|
|
|
default 278
|
|
|
|
|
help
|
|
|
|
|
Decreasing this value can help increase data throughput when high
|
|
|
|
|
baudrates are used. 278us is 4 bytes at 115200 baud. Decreasing this
|
|
|
|
|
value too much can result in spurious interrupts. Leaving it too
|
|
|
|
|
high can reduce data throughput.
|
|
|
|
|
|
|
|
|
|
endif # MODEM_IFACE_UART_ASYNC
|
|
|
|
|
|
2022-04-05 08:13:52 +02:00
|
|
|
endif # MODEM_IFACE_UART
|
|
|
|
|
|
drivers: modem: cmd handler: introduce cmd handler driver layer
This is a generic command handler implementation which uses the
supplied modem interface to process incoming data and hand it
back to the modem driver via callbacks defined for:
- modem responses
- unsolicited messages
- specified handlers for current operation
The individual modem drivers define functions as command handlers
via the MODEM_CMD_DEFINE() macro.
To use these handlers, a modem operation defines a series of
modem_cmd structures and passes them to the modem_cmd_send()
function. The modem_cmd includes data for:
- a matching string for when to execute the handler
- # of parameters to parse after the matching string
- delimeters for the parameters
Example modem driver setup code looks like this:
/* create modem context object */
static struct modem_context mctx;
/* net_buf receive pool */
NET_BUF_POOL_DEFINE(mdm_recv_pool, MDM_RECV_MAX_BUF,
MDM_RECV_BUF_SIZE, 0, NULL);
/* modem cmds */
static struct modem_cmd_handler_data cmd_handler_data;
static u8_t cmd_read_buf[MDM_RECV_BUF_SIZE];
static u8_t cmd_match_buf[MDM_RECV_BUF_SIZE];
/* modem response handlers */
static struct modem_cmd response_cmds[] = {
MODEM_CMD("OK", on_cmd_ok, 0U, ""),
MODEM_CMD("ERROR", on_cmd_error, 0U, ""),
MODEM_CMD("+CME ERROR: ", on_cmd_exterror, 1U, ""),
};
/* unsolicited handlers */
static struct modem_cmd unsol_cmds[] = {
MODEM_CMD("+UUSOCL: ", on_cmd_socknotifyclose, 1U, ""),
MODEM_CMD("+UUSORD: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+UUSORF: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+CREG: ", on_cmd_socknotifycreg, 1U, ""),
};
/* setup cmd handler data */
cmd_handler_data.cmds[CMD_RESP] = response_cmds;
cmd_handler_data.cmds_len[CMD_RESP] = ARRAY_SIZE(response_cmds);
cmd_handler_data.cmds[CMD_UNSOL] = unsol_cmds;
cmd_handler_data.cmds_len[CMD_UNSOL] = ARRAY_SIZE(unsol_cmds);
cmd_handler_data.read_buf = &cmd_read_buf[0];
cmd_handler_data.read_buf_len = sizeof(cmd_read_buf);
cmd_handler_data.match_buf = &cmd_match_buf[0];
cmd_handler_data.match_buf_len = sizeof(cmd_match_buf);
cmd_handler_data.buf_pool = &mdm_recv_pool;
cmd_handler_data.alloc_timeout = BUF_ALLOC_TIMEOUT;
ret = modem_cmd_handler_init(&mctx.cmd_handler, &cmd_handler_data);
Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:03:00 +02:00
|
|
|
config MODEM_CMD_HANDLER
|
|
|
|
|
bool "Generic modem command handler"
|
2020-01-02 11:41:07 +01:00
|
|
|
select NET_BUF
|
drivers: modem: cmd handler: introduce cmd handler driver layer
This is a generic command handler implementation which uses the
supplied modem interface to process incoming data and hand it
back to the modem driver via callbacks defined for:
- modem responses
- unsolicited messages
- specified handlers for current operation
The individual modem drivers define functions as command handlers
via the MODEM_CMD_DEFINE() macro.
To use these handlers, a modem operation defines a series of
modem_cmd structures and passes them to the modem_cmd_send()
function. The modem_cmd includes data for:
- a matching string for when to execute the handler
- # of parameters to parse after the matching string
- delimeters for the parameters
Example modem driver setup code looks like this:
/* create modem context object */
static struct modem_context mctx;
/* net_buf receive pool */
NET_BUF_POOL_DEFINE(mdm_recv_pool, MDM_RECV_MAX_BUF,
MDM_RECV_BUF_SIZE, 0, NULL);
/* modem cmds */
static struct modem_cmd_handler_data cmd_handler_data;
static u8_t cmd_read_buf[MDM_RECV_BUF_SIZE];
static u8_t cmd_match_buf[MDM_RECV_BUF_SIZE];
/* modem response handlers */
static struct modem_cmd response_cmds[] = {
MODEM_CMD("OK", on_cmd_ok, 0U, ""),
MODEM_CMD("ERROR", on_cmd_error, 0U, ""),
MODEM_CMD("+CME ERROR: ", on_cmd_exterror, 1U, ""),
};
/* unsolicited handlers */
static struct modem_cmd unsol_cmds[] = {
MODEM_CMD("+UUSOCL: ", on_cmd_socknotifyclose, 1U, ""),
MODEM_CMD("+UUSORD: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+UUSORF: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+CREG: ", on_cmd_socknotifycreg, 1U, ""),
};
/* setup cmd handler data */
cmd_handler_data.cmds[CMD_RESP] = response_cmds;
cmd_handler_data.cmds_len[CMD_RESP] = ARRAY_SIZE(response_cmds);
cmd_handler_data.cmds[CMD_UNSOL] = unsol_cmds;
cmd_handler_data.cmds_len[CMD_UNSOL] = ARRAY_SIZE(unsol_cmds);
cmd_handler_data.read_buf = &cmd_read_buf[0];
cmd_handler_data.read_buf_len = sizeof(cmd_read_buf);
cmd_handler_data.match_buf = &cmd_match_buf[0];
cmd_handler_data.match_buf_len = sizeof(cmd_match_buf);
cmd_handler_data.buf_pool = &mdm_recv_pool;
cmd_handler_data.alloc_timeout = BUF_ALLOC_TIMEOUT;
ret = modem_cmd_handler_init(&mctx.cmd_handler, &cmd_handler_data);
Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:03:00 +02:00
|
|
|
help
|
|
|
|
|
This generic command handler uses a modem interface to process
|
|
|
|
|
incoming data and hand it back to the modem driver via callbacks
|
|
|
|
|
defined for:
|
|
|
|
|
- modem responses
|
|
|
|
|
- unsolicited messages
|
|
|
|
|
- specified handlers for current operation
|
|
|
|
|
To configure this layer for use, create a modem_cmd_handler_data
|
|
|
|
|
object and pass it's reference to modem_cmd_handler_init() along with
|
|
|
|
|
the modem_cmd_handler reference from your modem_context object.
|
|
|
|
|
|
|
|
|
|
config MODEM_CMD_HANDLER_MAX_PARAM_COUNT
|
|
|
|
|
int "Maximum number of params parsed per command"
|
|
|
|
|
depends on MODEM_CMD_HANDLER
|
|
|
|
|
default 6
|
|
|
|
|
help
|
|
|
|
|
This option sets the maximum number of parameters which may be
|
|
|
|
|
parsed by the command handler. This is also limited by the length
|
|
|
|
|
of the match_buf (match_buf_len) field as it needs to be large
|
|
|
|
|
enough to hold a single line of data (ending with /r).
|
|
|
|
|
|
2019-08-07 17:04:00 +02:00
|
|
|
config MODEM_SOCKET
|
|
|
|
|
bool "Generic modem socket support layer"
|
|
|
|
|
help
|
|
|
|
|
This layer provides much of the groundwork for keeping track of
|
|
|
|
|
modem "sockets" throughout their lifecycle (from the initial offload
|
|
|
|
|
API calls through the command handler call back layers).
|
|
|
|
|
To configure this layer for use, create a modem_socket_config
|
|
|
|
|
object with your socket data and pass it's reference to
|
|
|
|
|
modem_socket_init().
|
drivers/modem: Patch fix for sock id and fd
There is is an error in the way that the sock id is
determined. A unique fd is reserved and assigned appropriatly, but
the id, which should correspond to a socket number within the modem,
is set to an invalid, and identical for all sockets, value, and then
not used appropriatly in the drivers, instead, the sock_fd is used,
which can be any value really, it is not related to the socket number
in any way.
This results in the drivers only working if the reserved fd happens
to be between base_socket_num and (socket_len - 1)
This patch assignes the id to the index of the socket + the
base_socket_num, the socket at index 0 will get the id 1 if the
base_socket_num is 1, and the modem_socket_from_id should then
be used to get a pointer to the socket, since the id is not
neccesarily equal to the index.
The FIXME has been solved by adding a note both at the start
of the modem_socket_get function and inside the Kconfig file
for the MODEM_SOCKET option description. It is not an error,
but the user must be aware that it uses the POSIX file
descriptors, for which only 4 are allocated by default.
This patch fixes the bug, without breaking the brittle modem
drivers which currently are built around this bug.
The modem drivers should be updated to use the id as the
socket num instead of the sock_fd after this fix has been merged.
The "socket # needs assigning" has been removed, as that is what
this patch is doing
I also added comments to the id and sock_fd in the modem_socket
structure to help developers use the id and fd appropriately.
Signed-off-by: Bjarki Arge Andreasen <bjarkix123@gmail.com>
2022-07-08 21:28:07 +02:00
|
|
|
Note that the modem socket uses runtime allocated file descriptors
|
|
|
|
|
reserved from the fdtable, for which the max count is set using the
|
|
|
|
|
Kconfig option POSIX_MAX_FDS. Make sure to update this value as both
|
|
|
|
|
the modem sockets and the POSIX_API, if used, share them.
|
2019-08-07 17:04:00 +02:00
|
|
|
|
|
|
|
|
config MODEM_SOCKET_PACKET_COUNT
|
|
|
|
|
int "Maximum number of stored packet sizes per socket"
|
|
|
|
|
depends on MODEM_SOCKET
|
|
|
|
|
default 6
|
|
|
|
|
help
|
|
|
|
|
As the modem indicates more data is available to be received,
|
|
|
|
|
these values are organized into "packets". This setting limits
|
|
|
|
|
the maximum number of packet sizes the socket can keep track of.
|
|
|
|
|
|
2019-08-07 17:01:00 +02:00
|
|
|
endif # MODEM_CONTEXT
|
|
|
|
|
|
2018-08-01 22:03:00 +02:00
|
|
|
config MODEM_SHELL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Modem shell utilities"
|
2018-10-20 00:15:44 +02:00
|
|
|
select SHELL
|
2018-08-01 22:03:00 +02:00
|
|
|
help
|
|
|
|
|
Activate shell module that provides modem utilities like
|
|
|
|
|
sending a command to the modem UART.
|
|
|
|
|
|
2020-04-20 13:51:45 +02:00
|
|
|
config MODEM_SIM_NUMBERS
|
2022-03-09 12:31:16 +01:00
|
|
|
bool "Query the SIM for IMSI and ICCID"
|
2020-04-20 13:51:45 +02:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Query the SIM card for the IMSI and ICCID identifiers. This
|
|
|
|
|
can be disabled if the application does not use a SIM.
|
|
|
|
|
|
2021-06-09 13:28:21 +02:00
|
|
|
config MODEM_CELL_INFO
|
2022-03-09 12:31:16 +01:00
|
|
|
bool "Query for operator and cell info"
|
2021-06-09 13:28:21 +02:00
|
|
|
help
|
|
|
|
|
Query for numerical operator id, location area code and cell id.
|
2020-04-20 13:51:45 +02:00
|
|
|
|
2019-05-17 19:14:00 +02:00
|
|
|
source "drivers/modem/Kconfig.ublox-sara-r4"
|
2020-11-23 15:54:31 +01:00
|
|
|
source "drivers/modem/Kconfig.quectel-bg9x"
|
2019-02-14 10:21:27 +01:00
|
|
|
source "drivers/modem/Kconfig.wncm14a2a"
|
2020-01-02 11:41:07 +01:00
|
|
|
source "drivers/modem/Kconfig.gsm"
|
2023-04-10 18:24:56 +02:00
|
|
|
source "drivers/modem/Kconfig.cellular"
|
2018-08-01 22:02:00 +02:00
|
|
|
|
2020-08-27 22:43:58 +02:00
|
|
|
source "drivers/modem/Kconfig.hl7800"
|
2021-08-27 10:21:14 +02:00
|
|
|
source "drivers/modem/Kconfig.simcom-sim7080"
|
2020-08-27 22:43:58 +02:00
|
|
|
|
2018-08-01 22:01:00 +02:00
|
|
|
endif # MODEM
|