Keeping this as a draft for some time -- the SAUL server has learned GET and PUT with CBOR objects equivalent to those of phydat's JSON, but for them to be easily available a few maintenance releases all around need to happen (e.g riot-wrappers wrapping phydat_unit_to_str_verbose, and coap-handler-implementations providing the glue code for the minicbor crate that replaces the deprecated serde_cbor).

I'd say this is ready for review now. I'll still hope to advertise the resources better (with details on the kind of SAUL device), but to get that I'll need to make a bit of progress on the CoRAL side of things to make sure we don't run into difficulties when migrating away from link-format.

(And I'll yet need to extend the board exclusion list, for it's running into RAM limits -- and/or make progress where it comes to finding which components blow up in resource use).

Rebased onto master as #17591 (fixed in master now) impeded diagnostics run on this that'd bring more light to exactly why the stack requirements are as they are.

This will need to be rebased after #17704 (swallowing two commits).

Possibly it should also consider the new SenML additions that have been made.

Rebased; disabled CI readiness until the original questions around this are answered.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

This just needs the patches refreshed and decisions on the two open questions; pulling in reviwers for those before doing the updates.

[edit: The updating is a bit stalled on this branch having sen me on a yak shaving tour through static stack size assessment, which when turned on on LLVM starts producing countless linker errors, possibly because some code in RIOT pulls in code from headers of undeclared module dependencies and then relies on the linker GC to not scream earlier.]

I had to run rustup target add thumbv7em-none-eabihf first before I could attempt to compile it. The issue with that is, that the helpful message telling me to do so was hidden behind a wall of compilation errors. If you happen to have an idea on how to improve that situation...

I still can not compile this tho:

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/teufelchen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/coap-message-0.2.2/src/lib.rs:2:1
  |
2 | #![feature(generic_associated_types)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
  |
  = help: the feature `generic_associated_types` has been stable since `1.65.0` and no longer requires an attribute to enable

Probably a version mismatch? Can you check up on it?

The version mismatch comes from that when this was written, we still had nightly as a default and in our CI, and now don't have it any more. Merging in master will solve that, WIP…

Murdock results

✔️ PASSED

48d4e8a Merge branch 'master' into rust-gcoap-add-saul

Artifacts

I think you need to blacklist some boards... :D

The previous Makefile.ci was regenerated while I was doing some last fix. The latest version has a regenerated Makefile.ci, and merges in master once more resolving Cargo.lock conflicts.