zephyr/drivers/modem/modem_context.h

140 lines
2.9 KiB
C
Raw Normal View History

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 23:01:00 +08:00
/** @file
* @brief Modem context header file.
*
* A modem context driver allowing application to handle all
* aspects of received protocol data.
*/
/*
* Copyright (c) 2019 Foundries.io
*
* SPDX-License-Identifier: Apache-2.0
*/
#ifndef ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_CONTEXT_H_
#define ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_CONTEXT_H_
#include <kernel.h>
#include <net/buf.h>
#include <net/net_ip.h>
#include <sys/ring_buffer.h>
#include <drivers/gpio.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 23:01:00 +08:00
#ifdef __cplusplus
extern "C" {
#endif
#define MODEM_PIN(name_, pin_, flags_) { \
.dev_name = name_, \
.pin = pin_, \
.init_flags = flags_ \
}
struct modem_iface {
struct device *dev;
int (*read)(struct modem_iface *iface, uint8_t *buf, size_t size,
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 23:01:00 +08:00
size_t *bytes_read);
int (*write)(struct modem_iface *iface, const uint8_t *buf, size_t size);
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 23:01:00 +08:00
/* implementation data */
void *iface_data;
};
struct modem_cmd_handler {
void (*process)(struct modem_cmd_handler *cmd_handler,
struct modem_iface *iface);
/* implementation data */
void *cmd_handler_data;
};
struct modem_pin {
struct device *gpio_port_dev;
char *dev_name;
gpio_pin_t pin;
gpio_flags_t init_flags;
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 23:01:00 +08:00
};
struct modem_context {
/* modem data */
char *data_manufacturer;
char *data_model;
char *data_revision;
char *data_imei;
int data_rssi;
/* pin config */
struct modem_pin *pins;
size_t pins_len;
/* interface config */
struct modem_iface iface;
/* command handler config */
struct modem_cmd_handler cmd_handler;
/* driver data */
void *driver_data;
};
/**
* @brief IP address to string
*
* @param addr: sockaddr to be converted
*
* @retval Buffer with IP in string form
*/
char *modem_context_sprint_ip_addr(const struct sockaddr *addr);
/**
* @brief Get port from IP address
*
* @param addr: sockaddr
* @param port: store port
*
* @retval 0 if ok, < 0 if error.
*/
int modem_context_get_addr_port(const struct sockaddr *addr, uint16_t *port);
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 23:01:00 +08:00
/**
* @brief Gets modem context by id.
*
* @param id: modem context id.
*
* @retval modem context or NULL.
*/
struct modem_context *modem_context_from_id(int id);
/**
* @brief Finds modem context which owns the iface device.
*
* @param *dev: device used by the modem iface.
*
* @retval Modem context or NULL.
*/
struct modem_context *modem_context_from_iface_dev(struct device *dev);
/**
* @brief Registers modem context.
*
* @note Prepares modem context to be used.
*
* @param *ctx: modem context to register.
*
* @retval 0 if ok, < 0 if error.
*/
int modem_context_register(struct modem_context *ctx);
/* pin config functions */
int modem_pin_read(struct modem_context *ctx, uint32_t pin);
int modem_pin_write(struct modem_context *ctx, uint32_t pin, uint32_t value);
int modem_pin_config(struct modem_context *ctx, uint32_t pin, bool enable);
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 23:01:00 +08:00
int modem_pin_init(struct modem_context *ctx);
#ifdef __cplusplus
}
#endif
#endif /* ZEPHYR_INCLUDE_DRIVERS_MODEM_MODEM_CONTEXT_H_ */