Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Driver: modem helper should make it easier to implement a modem #17922

Closed
mike-scott opened this issue Jul 31, 2019 · 4 comments · Fixed by #18103
Closed

Driver: modem helper should make it easier to implement a modem #17922

mike-scott opened this issue Jul 31, 2019 · 4 comments · Fixed by #18103
Assignees
Labels
area: Modem Enhancement Changes/Updates/Additions to existing features
Milestone

Comments

@mike-scott
Copy link
Contributor

Is your enhancement proposal related to a problem? Please describe.
The current modem receiver driver is pretty bare bones. It does the UART buffering in a ring buffer and allows the modem drivers to pull data in nice chunks. It does not abstract the command parser, sockets to communicate between the modem and Zephyr, pin config settings, etc. What this means is that each modem has quite a lot of copy/paste code atm.

Describe the solution you'd like
I'm proposing to implement a new modem helper driver called "modem context". This would include the majority of the command parser, some pin config and a better abstraction between the offloaded sockets layer and the modem. The release after the modem context is merged, we can depreciate the modem receiver driver.

Describe alternatives you've considered
I considered updating the modem receiver driver, but felt there might be some users who want more time to move to the new modem context helper.

@mike-scott mike-scott added Enhancement Changes/Updates/Additions to existing features area: Modem labels Jul 31, 2019
@mike-scott mike-scott added this to the v2.0.0 milestone Jul 31, 2019
@mike-scott mike-scott self-assigned this Jul 31, 2019
@mike-scott
Copy link
Contributor Author

I plan to submit a PR for this before August 9th feature freeze cut off.

@mike-scott
Copy link
Contributor Author

Adding a few people who have been interested in modem work:
@weinholtendian
@WilliamGFish
@rerickson1
@cybertale

@mike-scott
Copy link
Contributor Author

@Oanerer

@mike-scott
Copy link
Contributor Author

@Swij

mike-scott added a commit to mike-scott/zephyr that referenced this issue Aug 7, 2019
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: zephyrproject-rtos#17922

Signed-off-by: Michael Scott <mike@foundries.io>
mike-scott added a commit to mike-scott/zephyr that referenced this issue Aug 9, 2019
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: zephyrproject-rtos#17922

Signed-off-by: Michael Scott <mike@foundries.io>
ioannisg pushed a commit that referenced this issue Aug 9, 2019
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: #17922

Signed-off-by: Michael Scott <mike@foundries.io>
LeiW000 pushed a commit to LeiW000/zephyr that referenced this issue Sep 2, 2019
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: zephyrproject-rtos#17922

Signed-off-by: Michael Scott <mike@foundries.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Modem Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant