Right now, I don't see the need for control either, maybe if you want to have the object which you configure stuff on and the one you pass around separate. If there is any state involved, it needs to be shared anyway.

I want to add some PDP/PDS setup as I should have some spare time in the week to come. In the end, I would love to be able to have PDP disabled and other things which would need it to get it activated and that you can control it properly.
Not sure what the best way is to communicate such things, for example between devices and also the programmer, which may have both the interest in controlling it.
You could send signals between runners, but I don't know if I like the idea of channels being around for that task.

In the end, I would love to be able to have PDP disabled and other things which would need it to get it activated and that you can control it properly.

I am not completely sure what you mean by this? If I understand you correctly, you want the runner to run the network attach & PDP state-machine, but you don't want it to establish PDP before we e.g. initialized a UbloxStack or whatever we call the sockets service? (Or some other service that needs a PDP context)

Not sure what the best way is to communicate such things, for example between devices and also the programmer, which may have both the interest in controlling it.
You could send signals between runners, but I don't know if I like the idea of channels being around for that task.

I would think a mutex shared state object would suffice, but this is obviously at the expense of always having state for PDP, even though you never need it? Personally, I am not sure if there is an actual use case where you have a cellular device like this, and not ever need PDP? Programming for a scenario like that might not be worth it, unlike the scenarios of more rarely used services like SMS, Voice & Location, where I would think the approach of not paying a toll unless you need it would be nice!
Another approach to that would just be feature gating services of course..

I am not completely sure what you mean by this? If I understand you correctly, you want the runner to run the network attach & PDP state-machine, but you don't want it to establish PDP before we e.g. initialized a UbloxStack or whatever we call the sockets service? (Or some other service that needs a PDP context)

Correct or at times in that no socket is open, the PSD connection would be closed, and you would then reopen it but no one would actually use it. This could save energy in phases you don't have a socket open for a while, or in other scenarios you're not active for a while.

That saying, there also should be a possibility to tell the runner to power off the module and when you want it back, it runs init again and brings it back up and in the meanwhile, just idles. PDP falls in the same area for me, at least I should be able to tell it not to open a PDP connection until further notice. But for this, something like a mutexed shared state which also includes a desired state would be fine, I guess.

Not that it has to be done like that in the beginning, but having it setup to be able to do so would be nice.

For #93 I think you can merge this, then I don't have to incorporate the same changes in my next PR.

Ahh, yeah, I didn't quite have the whole power savings aspect with me, as I am so lucky to have always powered devices :)

Ahh, yeah, I didn't quite have the whole power savings aspect with me, as I am so lucky to have always powered devices :)

That's lucky ^^ I have a quite big battery, but in the end it is battery life....

What would you think about a mutexed shared state which gives a "desired state" and which could be controlled by the controller (or runner) and dictates what in the next loop would try to get to? Signalling that it has work to do again is a bit of the tricky thing, as I would love not check the desired state periodically. That would mean sending some kind of signal to the runner or a method that waits for a state to change and only have those signals/wakers inside of state.

What would be your preferred method?

• A channel/signal into runner
• A kind of waitForDesiredState() which awaits and return whenever that desired state is reached, for example.

For the second, you're basically just waiting for the signal internally and then return, but it all is contained in state. I think I would prefer this. Other opinions?

I think I would prefer this. Other opinions?

I think that sounds reasonable 👍

Next thing I would PR is to have stuff like getting signal strength and this stuff via control or maybe PSD profile and PDP context. This would also need some additions to the config, for APN selection and stuff like IPv4/v6 configuration.

If you have a clever idea for data/network, just chime in :)

In the coming week, I will look into the PSD profile and PDP context.

I think I would look into how much work it would be to implement embassy_net_driver_channel.
I think implementing other sockets may be a nice thing as well, or cleaning up the code. Implementing some socket should show if the design how it is right now works in these cases as well.

I already have a working example on top of this PR that adds embassy-net-ppp using cmux.
I can open a PR with it later today.

EDIT:
See #101

I think implementing other sockets may be a nice thing as well, or cleaning up the code. Implementing some socket should show if the design how it is right now works in these cases as well.

I would still very much see the ublox-socket (offloaded TCP/IP) implemented eventually on the design of this PR, so we can verify the design works for that as well.