[nrf noup] Support intermediary SLM optimized modem UART backend

[bjarki-andreasen]

This noup does the following:

• Adds the modem_backend_uart_slm modem backend which is optimized for UART communication to SLM.

The noup is intended to live until upstream zephyr has proper consistent RTS/CTS flow control support across multiple drivers, and DTR, RTS and CTS support has been added to the upstream modem UART backends, and lastly, SLM has been updated to use DTR, so everything is in sync.

Ask Bjarki Arge Andreasen, Markus Lassila or Seppo Takalo when this noup is to be altered as part of an upmerge for example.

[MarkusLassila]

Pushed the implementation for the SLM specific modem backend.

Removed the cellular_modem changes at this point. They are to be restored when DTR/DSR is implemented.

[MarkusLassila]

@bjarki-andreasen: Please take a look at the changes. I am looking to combine the changes and remove the WIP.

[bjarki-andreasen]

@MarkusLassila many parts of the first commit are missing, like integration with modem_cellular, this PR on its own is not usable without a new cellular driver otherwise. If this change is only neccesary for SLM, and not to be used with the modem_cellular driver, then this can be moved to the SLM application instead :)

[MarkusLassila]

@MarkusLassila many parts of the first commit are missing, like integration with modem_cellular, this PR on its own is not usable without a new cellular driver otherwise. If this change is only neccesary for SLM, and not to be used with the modem_cellular driver, then this can be moved to the SLM application instead :)

@bjarki-andreasen: I only removed the modem_cellular changes, because they are not currently needed. There is no possibility for AT#XSLEEP=2. See below comment:

Removed the cellular_modem changes at this point. They are to be restored when DTR/DSR is implemented.

While this particular change is necessary only for SLM (or at least that is what I think that this point), further development will affect also modem_cellular and possibly other samples, so I would not want this to be part of SLM at this point.

I can restore modem_cellular parts, if that helps proceeding with this.

[bjarki-andreasen]

I can restore modem_cellular parts, if that helps proceeding with this.

No, please don't restore anything not needed :) But the scope of the UART SLM backend must be clear to know if a noup or simply downstream addition is needed. If its just a backend to be used by the SLM application, we can just add the backend to sdk-nrf, no need to touch sdk-zephyr at all.

Removed the cellular_modem changes at this point. They are to be restored when DTR/DSR is implemented.

DTR should be implemented upstream, so when we get there there will be no need for a downstream UART SLM backend to be inserted into modem_cellular anyway right?

[MarkusLassila]

DTR should be implemented upstream, so when we get there there will be no need for a downstream UART SLM backend to be inserted into modem_cellular anyway right?

Given the timetable, it is almost certain that the DTR will be implemented in downstream first and later upstreamed.

ok, then the commits in this PR can be squashed, and the commit can later be modified to have DTR added.

But the scope of the UART SLM backend must be clear to know...

This is difficult at this point. Having this as a noup allows flexibility to use this in samples, which we will need. It also allows for the Apache license, so it can be used with pure-zephyr, if needed by some customers.

If the scope is unknown, then yeah, noup is the safer option.

[MarkusLassila]

@bjarki-andreasen, @nordicjm: Could this be merged?

[tomi-font]

Might be a bit confusing to have MODEM_BACKEND_UART be n when using MODEM_BACKEND_UART_SLM.

[tomi-font]

Maybe instead you could just add a config MODEM_BACKEND_UART_ASYNC_SLM and make use of the existing MODEM_BACKEND_UART_ASYNC as it has all the configs you need? Well, as you want really.

[MarkusLassila]

This allows for a complete split from the MODEM_BACKEND_UART so that modem_backend_uart.c is not included.

That said, there is going to be further development on this area, which means that this will be reconsidered.