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

91 lines
2.6 KiB
Text
Raw Normal View History

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 12: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
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 12:01:00 -08: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 12: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.
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 08:01:00 -07: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 08:02:00 -07: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: 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 08:01:00 -07: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 12:03:00 -08: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-19 15:15:44 -07: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 12:03:00 -08: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 10:14:00 -07: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: 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 12:02:00 -08: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 12:01:00 -08:00
endif # MODEM
Copy permalink