-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Async client #91
base: master
Are you sure you want to change the base?
Conversation
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. |
* fix sara-r5 (#89) * fix imports and Features Enum for sara-r5 * update ublox-sockets * implement defmt::format * enable defmt for nb and bump embedded-io,ublox-sockets,atat * rustfmt * Buildable withouth sockets * rustfmt * only use defmt feature not defmt-impl in ci * remove atat feature defmt as default * init module * enable to remove atat from ublox-sockets * make config public * add example * correct version override * add build.rs to embassy-stm32-example * running example * add power up and power down * Add ReverseOutputPin and ReverseInputPin to cope with the switched active state of some boards for pwr_on pin
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. |
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
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! |
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. |
…93) Crucial commit in embassy is embassy-rs/embassy@a39ae12
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?
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 that sounds reasonable 👍 |
* update nightly and embassy-sync * heapless update and first desired state version * make subscriber count a constant * rename PowerState to OperationState * fmt * first state transition state machine * change to TryFrom for State * working example, some timing issues * adjust bootup time to have is_alive work reliable after bootup * update dependencies and make compatible with atat master * fmt * remove things to comply with non nighty; set supply configuration to match old default * add connected state; add utility functions for soft_reset * toolchain stable 1.75 * use ublox-sockets git dependency * remove hash32 dependency
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 :) |
* add operator and signalstrength to control, make operator format controlable * don't overwrite ublox-sockets * update atat * bump e-h to 1.0
In the coming week, I will look into the PSD profile and PDP context. |
* add APNInfo to config as const * change apn settings to enum * update dependencies to new embassy release * can establish psd context and a dns request works * move statemachine out of main runner select loop * a bit of formatting * update to newest atat changes
* add APNInfo to config as const * change apn settings to enum * update dependencies to new embassy release * can establish psd context and a dns request works * move statemachine out of main runner select loop * a bit of formatting * update to newest atat changes * Add RP2040 example --------- Co-authored-by: Tobias Breitwieser <[email protected]>
I think I would look into how much work it would be to implement embassy_net_driver_channel. |
I already have a working example on top of this PR that adds embassy-net-ppp using cmux. EDIT:
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. |
…101) * WIP on adding PPP support through embassy-net-ppp using embassy-at-cmux * Working naive ppp example * TCP working in PPP example * Simplify initialization of both ppp mode and ublox mode, by providing batteries included new functions that sets up ATAT and all related resources * Change feature flag naming * Remove old unused examples * Move ppp and internal-stack to separate modules * Remove async feature * Working PPP + CMUX implementation * Before comparison with ubxlib * Add registration management, meticulously derived from ubxlib * Change modelId to borrowed * Bump embassy-sync to 0.6 * Use git dependencies * Allow setting AT+UEMBPF when using PPP * Rework pwr control and operation state logic. Also add AT command support to control handle * Allow control handle to query firmware version of device * Use online dependency for embassy-at-cmux * Fix logging when using log * Make embassy-at-cmux non-optional * Fix Control by adding ProxyClient, because only two AT/data channels are supported in CMUX * Bump embassy
This PR converts the full library to async only (Sorry, if any of users of the blocking version. Feel free to add a blocking version back in, or fork prior to this PR)
Currently, this PR is only tested with embassy-net/smoltcp based IP stack, but the grounds for using the offloaded Ublox TCP/IP stack is added.
Fixes #48
Fixes #38
Fixes #90
Fixes #87
Fixes #12