This commit references modem_pin() and modem_shell()
modem_pin(): use new gpio api
The existing pin driver does not respect gpio
configuration in device tree for active high / low
This commit allows for the device tree to determine the
active logic level.
modem_shell(): use correct string length
The ms_send macro uses iface.write() to send a string.
iface.write() requires the length of the string not the
size of the string.
This commit corrects the string length.
drivers: ublox-sara-r4: fix vint polling
This eliminates the implication that the enable and disable values can
be something other than 1 and 0, and fixes the code so it won't enter
an infinite loop if the GPIO read returns an error.
Signed-off-by: Steven Slupsky <sslupsky@gmail.com>
pin is an unsigned variable so there is no meaning check if it is less
than zero.
CID :208407
CID :208408
CID :208410
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Compile errors because of missing include file and typos
when accessing variables in the modem_pin struct.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
After startup ublox-sara-r4 code sets the MDM_POWER signal to input
using a deprecated configuration macro. This was the only use of the
modem context API to configure a pin.
Refactor the API to not take the flags as an input but instead select
between the flags to be used when the pin is active and a disconnected
state. Use this API instead of a separate direct configure call when
initializing the modem pins.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Convert to the new API using raw access, since it's a common access
layer shared by multiple (right now only ublox-sara-r4) modems.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
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>
Kumar Gala