modem: cellular: baudrate update from devicetree

[JordanYates]

Move baudrate updates from a global kconfig to a devicetree property.

Implemented by extending the modem chat API to support requests to be provided from a callback instead of being statically specified.

Tested on an OOT modem using the same implementation as applied for the LARA_R6.

[bjarki-andreasen]

Scripts are designed to be prepared in advance, they can be hardcoded to save RAM, or they can be stored in RAM and prepared at runtime.

[JordanYates]

Scripts are designed to be prepared in advance, they can be hardcoded to save RAM, or they can be stored in RAM and prepared at runtime.

And this PR was designed to preserve that capability to the greatest extent possible.
For the LARA_R6 driver, this PR doesn't result in any ROM strings moving to RAM, and only adds 4 bytes RAM overhead (the pointer in the data struct) and whatever the modem_baudrate_cmd command costs in ROM.

In return, this allows moving hardware configuration to devicetree, which is where it should be. More generally, it allows tailoring any AT commands which should be configured on a per device basis, rather than the hardcoded configuration currently.

The current behaviour of CONFIG_MODEM_CELLULAR_NEW_BAUDRATE makes little sense, Kconfig has no way of knowing which baudrates should be used for a given board, it is intrinsically tied to the hardware configuration.

[rerickson1]

Isn't baud rate dependent on host capabilities? Might a more conservative default of 1000000 be better?

[JordanYates]

Absolutely, and this was the primary motivation for the change. The value of 3000000 was chosen to match the deprecated kconfig option, but I can drop it back to 921600 or something if that is preferable.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
12.4% Duplication on New Code

See analysis details on SonarQube Cloud

[bjarki-andreasen]

Scripts are designed to be prepared in advance, they can be hardcoded to save RAM, or they can be stored in RAM and prepared at runtime.

And this PR was designed to preserve that capability to the greatest extent possible. For the LARA_R6 driver, this PR doesn't result in any ROM strings moving to RAM, and only adds 4 bytes RAM overhead (the pointer in the data struct) and whatever the modem_baudrate_cmd command costs in ROM.

Simplicity is the key here, not saving a few bytes. The simplest way to achieve this is to just define a custom baudrate request script for the instance of the lara_r6.

#define U_BLOX_LARA_R6_SET_BAUDRATE_CHAT_SCRIPT_DEFINE(inst)					\
	MODEM_CHAT_SCRIPT_CMDS_DEFINE(u_blox_lara_r6_set_baudrate_chat_script_cmds##inst,	\
		MODEM_CHAT_SCRIPT_CMD_RESP("ATE0", ok_match),					\
		MODEM_CHAT_SCRIPT_CMD_RESP(							\
			"AT+IPR=" STRINGIFY(DT_INST_PROP(inst, target_speed)),			\
			ok_match								\
		)										\
	);											\
												\
	MODEM_CHAT_SCRIPT_DEFINE(u_blox_lara_r6_set_baudrate_chat_script##inst,			\
		u_blox_lara_r6_set_baudrate_chat_script_cmds##inst,					\
		abort_matches,									\
		modem_cellular_chat_callback_handler,						\
		1										\
	);

...

	U_BLOX_LARA_R6_SET_BAUDRATE_CHAT_SCRIPT_DEFINE(inst)                                       \
                                                                                                \
	MODEM_CELLULAR_DEFINE_INSTANCE(inst, 1500, 100, 9000, 5000, false,                         \
				       &u_blox_lara_r6_set_baudrate_chat_script##inst,          \
				       &u_blox_lara_r6_init_chat_script,                           \
				       &u_blox_lara_r6_dial_chat_script,                           \
				       &u_blox_lara_r6_periodic_chat_script,                       \
				       NULL)

and if this is common to all modems, which it looks like it is, a helper can be created which is a bit more general.

A more complex way would be to add a mutable script and use that across all modems like we do for apn requests but those cost quite a bit of RAM and complexity.

In return, this allows moving hardware configuration to devicetree, which is where it should be. More generally, it allows tailoring any AT commands which should be configured on a per device basis, rather than the hardcoded configuration currently.

The current behaviour of CONFIG_MODEM_CELLULAR_NEW_BAUDRATE makes little sense, Kconfig has no way of knowing which baudrates should be used for a given board, it is intrinsically tied to the hardware configuration.

I agree with the problem, I just don't agree with the proposed solution

[JordanYates]

Simplicity is the key here

I guess the question is, simplicity for who, and where.

Your proposal works, but basically doubles the size of the device creation macro. I am skeptical of turning it into a generic macro, if configuration could be generalized in that way, we probably wouldn't be duplicating every chat script for every modem.

The second optioned mentioned, the mutable scripts used by the APN configuration, is a ridiculous amount of boilerplate and code for what essentially boils down to sending a compile time const string.

But even ignoring those two points above, the changes to modem_chat enable a whole new class of functionality.

1. Query a configuration value in one step of a chat script (the result is stored in the data struct by the handler)
2. Send one of multiple commands in the next step of the script, depending on the previous result.

That's completely trivial with the ability to pull the string from a function, but I don't even want to think about the headache of doing it with dynamic scripts, and flat out impossible with the constant scripts.

My follow up question would be, what part of this proposal has the complexity you are arguing against?
Because to be honest, I don't see it in either the extra branch inside modem_chat_send_script_request_part or the 14 line diff in modem_cellular.c.