wip: embassy-net driver for nrf91.

[Dirbaio]

• nrf: fix wrong order configuring gpios.
• nrf: add try_write to BufferedUarte.
• Add embassy-net-nrf91.

[Dirbaio]

TODO:

• [x] Make open_raw_socket automatic, there should be no need for the user to call it. In somewhat limited testing, it seemed creating it before attach didn't work, but maybe something else was wrong, or maybe there's some flag we can pass so it survives not being attached. If that's not possible then the driver should be smart enough to open it when attached. Also, we should check it survives deattach+reattach.
• [x] Trace should be optional
• [x] Trace should perhaps give the user a TraceReader implementing AsyncRead, instead of requiring the user to pass in a Write. This way the user can spawn a background task flushing trace data over uart, ueb, rtt, whatever.
• [x] The parser that extracts IP out of CGPADDR could be moved from the example to the net-nrf91 crate. Perhaps it could have a nice function that returns the embassy-net config ready to use.
• [x] There's some AT command to get DNS servers, we should add that instead of defaulting to no DNS servers. https://docs.nordicsemi.com/bundle/ref_at_commands/page/REF/at_commands/packet_domain/cgcontrdp_set.html

(Edit: by @lulf updating these as I go)

[lulf]

I think this is ready for review now. I've decided to put the 'control logic' into a separate module 'context' which allows running that control logic for a given context, which is the most common use case. For users that want more control, they can skip using that.

I've 'reversed' the direction of tracing and made it optional. If enabled, a state containing the 'trace buffer' is handed to the driver, and the driver will push data to the trace buffer, while the app can read from the buffer.

[kalkyl]

Now that configure is moved out of run, maybe the +CFUN and %XPDNCFG commands should be moved into run instead?

[lulf]

Now that configure is moved out of run, maybe the +CFUN and %XPDNCFG commands should be moved into run instead?

Your comment triggered me to try configure() multiple times to see the effect, and turns out that didn't work that well. I think we should keep +CFUN inside configure(), because it turns out it needs to run CFUN=0 to change the APN (otherwise it throws an error).

In normal operation I would expect the caller of configure() to only call configure if the configuration has actually changed. (I added a comment to the fn for that though).

[kalkyl]

Now that configure is moved out of run, maybe the +CFUN and %XPDNCFG commands should be moved into run instead?

Your comment triggered me to try configure() multiple times to see the effect, and turns out that didn't work that well. I think we should keep +CFUN inside configure(), because it turns out it needs to run CFUN=0 to change the APN (otherwise it throws an error).

In normal operation I would expect the caller of configure() to only call configure if the configuration has actually changed. (I added a comment to the fn for that though).

Ahh, i mean because CFUN=1 needs to be called even if you don't use a configuration. So CFUN=0 in configure and then CFUN=1 in run? Also IME, calling CFUN=1 multiple times doesn't hurt, so maybe keep it as is now and just add another CFUN=1 in run so you can use it without calling configure?

[lulf]

Now that configure is moved out of run, maybe the +CFUN and %XPDNCFG commands should be moved into run instead?

Your comment triggered me to try configure() multiple times to see the effect, and turns out that didn't work that well. I think we should keep +CFUN inside configure(), because it turns out it needs to run CFUN=0 to change the APN (otherwise it throws an error). In normal operation I would expect the caller of configure() to only call configure if the configuration has actually changed. (I added a comment to the fn for that though).

Ahh, i mean because CFUN=1 needs to be called even if you don't use a configuration. So CFUN=0 in configure and then CFUN=1 in run? Also IME, calling CFUN=1 multiple times doesn't hurt, so maybe keep it as is now and just add another CFUN=1 in run so you can use it without calling configure?

Agreed. I've changed the following:

• Added an enable() and disable()
• Call enable() in run()
• Not calling enable() in configure(), but adding it as a note in the comment.

This way, users will be able to 'activate' the configuration after run has started, without resorting to at commands.

[kalkyl]

Awesome! Just tried it out on my hardware with physical nano SIM without configuration and it works perfectly!

[kalkyl]

Looks great to me!