michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/drivers/modem/Kconfig

132 lines
4.3 KiB
Plaintext
Raw Permalink Normal View History

kconfig: Clean up header comments and make them consistent Use this short header style in all Kconfig files: # <description> # <copyright> # <license> ... Also change all <description>s from # Kconfig[.extension] - Foo-related options to just # Foo-related options It's clear enough that it's about Kconfig. The <description> cleanup was done with this command, along with some manual cleanup (big letter at the start, etc.) git ls-files '*Kconfig*' | \ xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /' Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-01 13:45:29 +01:00
# Modem configuration options
drivers: modem: add modem receiver (tty) driver Modem drivers need a fast buffer-based receiver for passing data back and forth from the UART to the driver. This provides an efficient configuarable driver which merely sends and receives but doesn't process the data, that's left up to the modem driver. Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:01:00 +02:00
# 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
drivers: modem: wistron kconfig separation Separates Kconfig to a separate file. Signed-off-by: Georgij Cernysiov <g.cernysiov@elco-automation.de>
2019-02-14 10:21:27 +01:00
module = MODEM
module-str = modem
source "subsys/logging/Kconfig.template.log_config"
drivers: modem: add modem receiver (tty) driver Modem drivers need a fast buffer-based receiver for passing data back and forth from the UART to the driver. This provides an efficient configuarable driver which merely sends and receives but doesn't process the data, that's left up to the modem driver. Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:01:00 +02:00
config MODEM_RECEIVER
bool "Enable modem receiver helper driver"
drivers: modem: modem receiver dependencies adaptation Moved UART interrupt dependencies from concrete driver to the modem receiver as it uses UART interrupt functions within. This allows developing other UART interrupt based modems without the need to depend on the aforementioned features explicitly. Signed-off-by: Georgij Cernysiov <g.cernysiov@elco-automation.de>
2019-01-25 18:23:20 +01:00
depends on SERIAL_SUPPORT_INTERRUPT
select UART_INTERRUPT_DRIVEN
drivers: modem: receiver: switch to ring buffer from pipe api Replaces used k_pipe with ring_buffer API which is safe for ISR. Signed-off-by: Georgij Cernysiov <g.cernysiov@elco-automation.de>
2019-02-13 22:48:46 +01:00
select RING_BUFFER
drivers: modem: add modem receiver (tty) driver Modem drivers need a fast buffer-based receiver for passing data back and forth from the UART to the driver. This provides an efficient configuarable driver which merely sends and receives but doesn't process the data, that's left up to the modem driver. Signed-off-by: Michael Scott <mike@foundries.io>
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.
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
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.
drivers: modem: interface: introduce UART interface driver layer The UART-based modem interface layer implements the modem context interface for Zephyr's UART APIs. This driver closely resembles the existing modem receiver, but conforming to the modem interface agreements. Example modem driver setup code looks like this: /* create modem context object */ static struct modem_context mctx; /* create uart interface data object and buffers */ static struct modem_iface_uart_data iface_data; static u8_t iface_isr_buf[MDM_RECV_BUF_SIZE]; static u8_t iface_rb_buf[MDM_MAX_DATA_LENGTH]; iface_data.isr_buf = &iface_isr_buf[0]; iface_data.isr_buf_len = sizeof(iface_isr_buf); iface_data.rx_rb_buf = &iface_rb_buf[0]; iface_data.rx_rb_buf_len = sizeof(iface_rb_buf); ret = modem_iface_uart_init(&mctx.iface, &iface_data, UART_DEV_NAME); Signed-off-by: Michael Scott <mike@foundries.io>
2019-08-07 17:02:00 +02: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 17:03:00 +02:00
config MODEM_CMD_HANDLER
bool "Generic modem command handler"
drivers: modem: Support GSM modems and PPP Create a driver for GSM modems that use a standard AT command set and enable Zephyr's own PPP stack for IP traffic. Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
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).
drivers: modem: introduce socket helper layer Many modems implement socket-based APIs to manage data connections. This layer provides much of the groundwork for keeping track of these "sockets" throughout their lifecycle (from the initial offload API calls through the command handler call back layers): - structure for holding socket data like IP protocol, destination, source and incoming packet sizes - configuration to note modem starting socket id and number of sockets - methods to get/put socket structs from/to the pool - function to update the # and size of packets in the modem receive queue - prebuilt modem_socket_poll() method for socket offload poll() API Example modem driver setup code looks like this: /* socket data */ static struct modem_socket_config socket_config; static struct modem_socket sockets[MDM_MAX_SOCKETS]; static int modem_init(struct device *dev) { ... /* setup socket config */ socket_config.sockets = &sockets[0]; socket_config.sockets_len = ARRAY_SIZE(sockets); socket_config.base_socket_num = 0; ret = modem_socket_init(&socket_config); ... } Signed-off-by: Michael Scott <mike@foundries.io>
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().
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.
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
endif # MODEM_CONTEXT
drivers: modem: add modem shell extension Add a set of modem shell commands to support modem development. Start with: modem list: Lists all registered modems and related information modem send <modem receiver index> <command>: Send command to modem Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:03:00 +02:00
config MODEM_SHELL
bool "Enable modem shell utilities"
drivers: modem: migrate modem shell to new shell API Convert modem-shell to use the new shell API. Signed-off-by: Michael Scott <mike@foundries.io>
2018-10-20 00:15:44 +02:00
select SHELL
drivers: modem: add modem shell extension Add a set of modem shell commands to support modem development. Start with: modem list: Lists all registered modems and related information modem send <modem receiver index> <command>: Send command to modem Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:03:00 +02:00
help
Activate shell module that provides modem utilities like
sending a command to the modem UART.
drivers: modem: introduce u-blox SARA-R4 modem driver The u-blox SARA-R4 modem modules are Ultra-compact LTE Cat M1 / NB1 ready: - Configurable with a single hardware version - Flexible mode selection as LTE Cat M1, LTE Cat NB1, EGPRS - only/preferred - Low power consumption and longer battery life - Extended range in buildings, basements, and with NB1, underground This driver introduces support for basic AT commands to query modem information as well as socket connection for TCP/UDP communication. Signed-off-by: Michael Scott <mike@foundries.io>
2019-05-17 19:14:00 +02:00
source "drivers/modem/Kconfig.ublox-sara-r4"
drivers: modem: wistron kconfig separation Separates Kconfig to a separate file. Signed-off-by: Georgij Cernysiov <g.cernysiov@elco-automation.de>
2019-02-14 10:21:27 +01:00
source "drivers/modem/Kconfig.wncm14a2a"
drivers: modem: Support GSM modems and PPP Create a driver for GSM modems that use a standard AT command set and enable Zephyr's own PPP stack for IP traffic. Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
2020-01-02 11:41:07 +01:00
source "drivers/modem/Kconfig.gsm"
drivers: modem: add Wistron WNC-M14A2A LTE-M Modem Driver The WNC-M14A2A (LTE / LTE-M) modem is presented as an Arduino- compatible shield via AT&T's IoT Starter Kit v1.0. It was originally intended to work with the FRDM-K64F board, but in theory as long as the right pins are configured it can work with any board that supports Arduino-compatible headers. The driver utilizes the CONFIG_NET_OFFLOAD setting to avoid the normal handling of IP packets, and instead uses a socket-like UART interface to handle incoming and outgoing data. Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:02:00 +02:00
drivers: modem: add modem receiver (tty) driver Modem drivers need a fast buffer-based receiver for passing data back and forth from the UART to the driver. This provides an efficient configuarable driver which merely sends and receives but doesn't process the data, that's left up to the modem driver. Signed-off-by: Michael Scott <mike@foundries.io>
2018-08-01 22:01:00 +02:00
endif # MODEM
Copy permalink