[Firmware] ESP32 can't compile because of atomics

[ImUrX]

It seems radium is trying to use atomics in ESP32 and its failing to build

[TheButlah]

> cargo tree -i radium
radium v0.7.0
└── bitvec v1.0.1
    └── deku v0.15.1
        └── firmware_protocol v0.0.0 (/home/ryan/P/slimevr/rust/networking/firmware_protocol)
            └── firmware v0.0.0 (/home/ryan/P/slimevr/rust/firmware)

[TheButlah]

So looking into this, radium will try to use atomics if they are natively available, otherwise will use Cell<T>.

Radium 1.0.0 uses #[cfg(target_has_atomic = width)] to determine if an atomic is supported. This cfg was stabilized in rust 1.60.

Radium 0.7.0 however released before the cfg feature was stabilized. In order to determine if the target supported atomics or not, radium instead used a hack - there was a build.rs script that would actually hard-code which atomics were supported based on strings gotten from the rustc env. Xtensa is not listed in that build script, so it was probably assuming the wrong atomic support.

We could ask the radium maintainers to release a new 0.7.X version of radium that contains the fix for xtensa. I suspect they are unlikely to do that, but who knows.

Instead, if we can have bitvec use radium 1.0.0, either via upstreaming the bump or by patching it ourselves, then assuming that esp-rs rustc does cfg(target_has_atomic) correctly on xtensa, we should be good to go.

[TheButlah]

I opened https://github.com/ferrilab/ferrilab/issues/1

[TheButlah]

Fixed this and others in #193