2018-08-02 04:01:00 +08:00
|
|
|
# Kconfig - Modem configuration options
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2018 Foundries.io
|
|
|
|
|
#
|
|
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
menuconfig MODEM
|
|
|
|
|
bool "Modem Drivers"
|
|
|
|
|
help
|
|
|
|
|
Enable config options for modem drivers.
|
|
|
|
|
|
|
|
|
|
if MODEM
|
|
|
|
|
|
2019-02-14 17:21:27 +08:00
|
|
|
module = MODEM
|
|
|
|
|
module-str = modem
|
|
|
|
|
source "subsys/logging/Kconfig.template.log_config"
|
|
|
|
|
|
2018-08-02 04:01:00 +08:00
|
|
|
config MODEM_RECEIVER
|
|
|
|
|
bool "Enable modem receiver helper driver"
|
2019-01-26 01:23:20 +08:00
|
|
|
depends on SERIAL_SUPPORT_INTERRUPT
|
|
|
|
|
select UART_INTERRUPT_DRIVEN
|
2019-02-14 05:48:46 +08:00
|
|
|
select RING_BUFFER
|
2018-08-02 04:01:00 +08: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 23:01:00 +08:00
|
|
|
config MODEM_CONTEXT
|
|
|
|
|
bool "Modem context helper driver [EXPERIMENTAL]"
|
|
|
|
|
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 23:02:00 +08:00
|
|
|
config MODEM_IFACE_UART
|
|
|
|
|
bool "UART-based modem interface"
|
|
|
|
|
depends on SERIAL_SUPPORT_INTERRUPT
|
|
|
|
|
select UART_INTERRUPT_DRIVEN
|
|
|
|
|
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.
|
|
|
|
|
|
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 23:03:00 +08:00
|
|
|
config MODEM_CMD_HANDLER
|
|
|
|
|
bool "Generic modem command handler"
|
|
|
|
|
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 23:04:00 +08: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().
|
|
|
|
|
|
|
|
|
|
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 23:01:00 +08:00
|
|
|
endif # MODEM_CONTEXT
|
|
|
|
|
|
2018-08-02 04:03:00 +08:00
|
|
|
config MODEM_SHELL
|
|
|
|
|
bool "Enable modem shell utilities"
|
2018-10-20 06:15:44 +08:00
|
|
|
select SHELL
|
2018-08-02 04:03:00 +08:00
|
|
|
help
|
|
|
|
|
Activate shell module that provides modem utilities like
|
|
|
|
|
sending a command to the modem UART.
|
|
|
|
|
|
2019-05-18 01:14:00 +08:00
|
|
|
source "drivers/modem/Kconfig.ublox-sara-r4"
|
2019-02-14 17:21:27 +08:00
|
|
|
source "drivers/modem/Kconfig.wncm14a2a"
|
2018-08-02 04:02:00 +08:00
|
|
|
|
2018-08-02 04:01:00 +08:00
|
|
|
endif # MODEM
|