Async branch buildble

[tarfu]

As I got sick and concentration is at the bottom just a small thing.
It builds now and excludes all the ublox_stack via #![cfg(feature = "dontbuild")] in all the modules files

I modified your ublox-sockets version again with the derive AtatLen for the SocketHandle and I use atat 0.20 everywhere.

complete diff for ublox-sockets from your branch with my changes:

diff --git a/Cargo.toml b/Cargo.toml
index 94080fd..48dbd4c 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -20,7 +20,6 @@ no-std-net = { version = "0.6", features = ["serde"] }
 hash32 = "0.2.1"
 hash32-derive = "^0.1.0"
 embassy-time = "0.1"
-
 log = { version = "^0.4", default-features = false, optional = true }
 defmt = { version = "^0.3", optional = true }
 
@@ -37,4 +36,4 @@ socket-tcp = []
 socket-udp = []
 
 [patch.crates-io]
-no-std-net = { path = "../no-std-net" }
\ No newline at end of file
+no-std-net = { git = "https://github.com/rushmorem/no-std-net", branch = "issue-15" }

[tarfu]

The init code is basically taken from the blocking version as when cross-checking with the manual that's the steps you have to do, and I don't see that splitting them up further would help.

[MathiasKoch]

This is awesome!
I completely agree on the init part, though this is still a huge improvement, as it now has lots of await points versus the blocking init that could take significant time.

I will just merge your PRs as we go whenever you mark them as ready, and I have read through them.

[MathiasKoch]

It was a bit on purpose that i had removed the atat dependency from ublox-sockets, as it is only needed for the implementation of atatLen, but makes bumping atat a horrible experience because we need to bump ublox-sockets also.

It should be enough to not derive atatLen, and instead mark the socketHandle field in every command struct with ‘#[at_arg(len = 1]‘

[tarfu]

Adding the patch to ublox-sockets for the no-std-net version might be a nice thing, or forking it as it seems pretty unmaintained.

[tarfu]

Added an example so that you always have something you could try to build it for and test it, but it started giving me duplicate symbols errors and some point (I typed the bad words cargo update) because embassy-time 0.1.5 adds links section to its Cargo.toml preventing multiple copies of embassy-time. Unfortunately, some dependencies don't resolve to 0.1.5 and [patch.crates-io] section doesn't seem to be helpful

[tarfu]

Figured out my problem with the patch section (sometimes it is so obvious you can't see it).

The example sends commands and checks successfully it the device is alive. Strangely, the sara-r5 powers down after a few seconds, and I have no clue why right now.

[MathiasKoch]

Figured out my problem with the patch section (sometimes it is so obvious you can't see it).

Hah, I know that feeling! Glad you figured it out.

The example sends commands and checks successfully it the device is alive. Strangely, the sara-r5 powers down after a few seconds, and I have no clue why right now.

Hmm, can't tell you why, but I can try to test it on my LARA-R6 module, when I get a few minutes of spare time :)

[tarfu]

I think the issue is/was that at least the sara-r5 is designed with a floating pwr_on pin. Not defining the power_pin makes it more stable. Maybe need to look into it and if it is possible to have it floating when it is not needed. But should be possible with the design of the config trait. Just forgetting the pin and newly creating it when asked for could perhaps work.

[tarfu]

So now my module can power up and down nicely. The Hardware designer of the module I use for prototyping found it to be a nice idea to have the pin function like a button (which is also connected to the pin) so 1 is pressing the button, 0 is releasing it. It basically reversed the input for that pin.

[MathiasKoch]

Awesome! I'll merge this PR then, so we can try to keep them in kinda "feature" PRs 👍