Add support for no_std environments
#17
Conversation
It was only used in one place, and since it may conflict with other logging frameworks (e.g. defmt), it likely should be gated behind a feature.
This is the same hash algorithm as used by std::collections::hash_map aka hashbrown, but configured with a fixed seed to remove the dependency on the OS RNG (and thus std). The seed is unimportant because we do not rely on any security properties of the hash function.
In addition to being no_std friendly, this significantly reduces code size. speedate also has a faster/smaller DateTime parser compared to chrono, but speedate's parser only supports microsecond precision.
The std functions and types are aliases of the ones from core, so this causes no functional change.
Barring the few exceptions covered in the following commits, the library doesn't depend on anything in std itself, only String/Vec/collections re-exported from alloc. So supporting no_std mostly requires switching the imports over to alloc, and ensuring dependencies do not pull in any features that depend on std.
std::collections::HashMap has no equivalent in alloc.
The equivalent function is available on recent rustc versions behind an unstable feature, but is not part of the f64 impl. Use a wrapper trait to provide the function on no_std without affecting the std build.
|
Hi @smaeul, thanks for the PR! Please allow me the question: Why do need nostd for embassy on esp32? Is it a limited device? I do have a small esp32 project (BLE Keyboard emulator exposed via homie) that also uses embassy but with std. It works just fine. |
Sure, no worries! There's no hurry.
I'm assuming you use tokio + rumqttc on top of esp-idf-svc? Do you use TLS? It's a combination of a few factors:
|
2 participants
I'd like to use this library in a
no_stdenvironment (embassy on esp32), so here's an attempt at getting it to build. It at least builds for the target platform, and I can runcargo test --no-default-featureson my desktop.extensions::meta_extis compiled out, because changing it fromstd::collections::HashMapwould affect the API, and I don't currently need that module.I'm marking this as a draft because it depends on a speedate release containing pydantic/speedate#96. I'm happy to adjust anything as needed.