Commit graph

16 commits

Author SHA1 Message Date
Benjamin Cabé db53c3fd2c doc: Drop asterisk from Doxygen @param
The name for Doxygen params that are pointers should not include an
asterisk.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
2023-07-13 13:25:28 +00:00
Bjarki Arge Andreasen aa6ecc59d1 drivers/modem/modem_cmd_handler: Update API
There is currently not a clear separation between
user configuration and internal context when using the
modem_cmd_handler library. This update adds a clear
separation, placing user configuration in a seperate
struct passed to modem_cmd_handler_init alongside the
internal context modem_cmd_handler_data.

There is also a lack of documentation of the user
configurations, these have been added to the new config
struct.

The new API function modem_cmd_handler_process has been
added to remove the need for the user to directly access
the process member of the internal context. This ensures
that the user is not encouraged to access any internal
context members.

Some whitespace errors exist in the modem_cmd_handler.c
file, these are outside of the scope of this PR. These
can be addressed in a later PR as they are not functional
changes.

Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
2023-04-11 11:42:00 +02:00
Bjarki AA ab00842e42 drivers/modem: add user_data to modem_cmd_handler_data
added user_data field to modem_cmd_handler_data

this allows for multiple instances of modem drivers which use
the modem cmd handler. currently, the only identifiable
parameter passed to the modem command handlers is the
modem_cmd_handler_data struct.

The added user_data variable allows for the a modem driver to
pass its dev or data pointer to the modem_cmd_handler_data
struct to be retrieved from within the modem command callbacks.

Signed-off-by: Bjarki AA <baa@trackunit.com>
2022-06-06 17:59:35 +02:00
Gerard Marull-Paretas fb60aab245 drivers: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:58:21 +02:00
Yong Cong Sin b2dd782879 drivers: modem: modem_cmd_handler: Fix missing documentations
Fix missing documentations.

Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2022-02-28 11:05:06 +01:00
Marcin Niestroj 1a4cb7e0e3 drivers: modem: add modem_cmd_send_ext()
There are currently modem_cmd_send() and modem_cmd_send_nolock()
functions, each with slightly different behavior regarding acquiring (or
not) sem_tx_lock. Introduce a generic function that will allow caller to
select behavior using flags.

While at it, add possibility to disable setting and unsetting command
handlers. This will be useful in situations when there are multiple
replies expected one after the other coming as a response to single
command. This is the case for example with ESP-AT driver, which expects
following data as response to AT+CIPSEND command:

  OK
  >

where 'OK' is handled by static CMD_RESP (so releasing response
semaphore right away), while '>' is handled by dynamic
CMD_HANDLER (which is releasing another semaphore). Keeping command
handlers in place allows to receive '>' without race condition because
of small period of time where command handlers are not set.

Convert modem_cmd_send_nolock() and modem_cmd_send() to static inline
functions, as they are just a specific invocation of
modem_cmd_send_ext() function.

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
2021-07-28 21:08:51 -04:00
Xavier Chapron 3d61989bc7 drivers: modem: modem_cmd_handler: Allow dynamic number of commands args
This is necessary to allow parsing of commands with dynamic number of
arguments.

Signed-off-by: Xavier Chapron <xavier.chapron@stimio.fr>
2020-12-03 17:37:48 -05:00
Marcin Niestroj 1d25e9c6ae drivers: modem: constify modem_cmd and setup_cmd structures
modem_cmd and setup_cmd structures are used only to store static
information about commands to be sent and replies to be
received. Reference it as const, so that it is possible to define const
instances and save some RAM space by placing those definitions entirely
in ROM.

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
2020-11-24 12:59:50 +02:00
Marcin Niestroj 318cbe649a drivers: modem: cmd_handler: rework reading from interface
So far a dedicated buffer was used for data read from modem
interface. New net_bufs were allocated and filled later, which means
that data was lost when no more net_bufs were available in the pool.

Prevent data loss by allocating net_buf before attempting any read on
modem interface. Process incoming data in a loop as long as reading from
interface results in new data. Also remove dedicated buffer
(data->read_buf) and directly fill net_buf content instead. As a side
effect there are less memory copy operations and RAM usage is reduced.

Pre-allocated net_buf is now always appended to data->rx_buf. When there
was no (more) data read from interface to such net_buf, then this empty
net_buf will be on the end of data->rx_buf fragment list. Update
skipcrlf() and findcrlf() implementations to explicitly check for each
net_buf length, instead of blindly assuming them to have at least single
byte.

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
2020-10-27 09:24:38 -05:00
Benjamin Lindqvist 820bb07c81 drivers: modem: cmd_handler: Allow locking TX
A semaphore is used by modem_cmd_handler to protect against concurrent
UART access. This is only used for the duration of sending a command,
but there are cases when one wants to prevent UART access for other
reasons, such as when powering off the modem.

This commit exposes functionality for hogging this semaphore without
having to send a command. Furthermore, a non-locking equivalent for
modem_cmd_handler_setup_cmds is added which was previously missing.

Signed-off-by: Benjamin Lindqvist <benjamin.lindqvist@endian.se>
2020-10-21 10:15:45 +03:00
Kumar Gala a1b77fd589 zephyr: replace zephyr integer types with C99 types
git grep -l 'u\(8\|16\|32\|64\)_t' | \
		xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g"
	git grep -l 's\(8\|16\|32\|64\)_t' | \
		xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g"

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-06-08 08:23:57 -05:00
Carles Cufi 94861a438b drivers: modem: Port to new timeout API
Port the internal modem API to the new timeout API, using the native
k_timeout_t.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2020-05-07 11:01:55 +02:00
Tobias Svehagen 990ab00e30 drivers: modem: Add support for commands that don't have a line ending
Some commands need to be processed before a "\r\n" is available and
there might also be commands that have "\r\n" as data but doesn't mean
the end of the command.

To solve this a MODEM_CMD_DIRECT has been added. cmd_handler_process()
will look for matching direct commands before checking if a whole line
is available for matching the normal commands.

A direct command can return either -EAGAIN, meaning that more data is
needed or it will return the number of bytes to skip forward, ie the
length of the command that was handled.

Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
2020-03-11 23:48:06 +02:00
Michael Scott 90c6dc5e7f drivers: modem: cmd_handler: add return value to modem commands
Some modem commands can determine if they have enough data pulled from
the modem to continue or not.  Let's allow those functions to return
EAGAIN which means there's more data needed from the modem.

Signed-off-by: Michael Scott <mike@foundries.io>
2020-02-10 12:29:41 +02:00
Tobias Svehagen 8a9c9d43bf drivers: modem: Add support for different line endings
This makes it possible to handle devices that use different line
endings.

Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
2020-02-05 23:31:56 +02:00
Michael Scott 02abddccd6 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-10 00:03:39 +02:00