Issue with math calculations with floats to serial port output

[TimKotowski]

use arduino_hal::I2c;
use bme280_rs::{Bme280, Configuration, Oversampling, SensorMode};
use fixed::types::U16F16;
use micromath::F32Ext;
use ufmt::{uDisplay, uWrite};

#[arduino_hal::entry]
fn main() -> ! {
    let dp = arduino_hal::Peripherals::take().unwrap();
    let pins = arduino_hal::pins!(dp);
    let mut serial = arduino_hal::default_serial!(dp, pins, 57600);
    let mut d2 = arduino_hal::Delay::new();

    let mut d = arduino_hal::Delay::new();
    let i2c = I2c::new(
        dp.TWI,
        pins.a4.into_pull_up_input(),
        pins.a5.into_pull_up_input(),
        50000,
    );
    let mut bme280 = Bme280::new_with_address(i2c, 0x77, d);

    bme280.init().unwrap();
    bme280.set_sampling_configuration(
        Configuration::default()
          .with_temperature_oversampling(Oversampling::Oversample1)
          .with_pressure_oversampling(Oversampling::Oversample1)
          .with_humidity_oversampling(Oversampling::Oversample1)
          .with_sensor_mode(SensorMode::Normal),
    ).unwrap();

    loop {
        let pre = bme280.read_sample().unwrap().pressure;
        if let Some(pressure) = pre {
            let ratio = pressure / 1013.25;
            let exponent = 1.0 / 5.255;
            let a0 = 44330.0 * (1.0 - ratio.powf(exponent));
            let f = ufmt_float::uFmt_f32::Zero(a0);

            ufmt::uwriteln!(&mut serial, "Altitude: {}", f).unwrap()
        } else {
            ufmt::uwriteln!(&mut serial, "NNOE").unwrap();
        }

        arduino_hal::delay_ms(100);
    }
}

seems to be getting error

  = note: /opt/homebrew/opt/avr-binutils/bin/avr-ld: /opt/homebrew/Cellar/avr-gcc@9/9.4.0_1/lib/avr-gcc/9/gcc/avr/9.4.0/../../../../../../avr/lib/avr5/libm.a(addsf3.o): in function `__addsf3':
          (.text.avr-libc.fplib+0x2): multiple definition of `__addsf3'; /Users/tim/bme_test/target/avr-atmega328p/debug/deps/libcompiler_builtins-922b355f64723ac9.rlib(compiler_builtins-922b355f64723ac9.compiler_builtins.a4206a2074977fb4-cgu.1.rcgu.o):/Users/tim/.cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/src/macros.rs:500: first defined here
          collect2: error: ld returned 1 exit status

I did see floats when being print out are an issue but with ufmt_float should solve the issue, but when i include the line ufmt::uwriteln!(&mut serial, "Pressure fixed: {}", f).unwrap() this is where i get an error. I previously added # This is needed because of a known bug https://github.com/Rahix/avr-hal/issues/125#issuecomment-771578390 [profile.dev.package.compiler_builtins] overflow-checks = false but this did not solve it. Unaware of this issue else where, nor do I see how to resolve this.

Here is my cargo.toml file

[package]
name = "bme_test"
version = "0.1.0"
authors = ["Tim Kotowski <tkotowski7@gmail.com>"]
edition = "2021"
license = "MIT OR Apache-2.0"

[[bin]]
name = "bme_test"
test = false
bench = false

[dependencies]
panic-halt = "0.2.0"
ufmt = "0.2.0"
nb = "1.1.0"
embedded-hal = "1.0.0"
micromath = "2.1.0"
embedded-hal-bus = "0.2.0"
bme280-rs = "0.3.0"
fixed = "1.27.0"
ufmt_float = "0.2.0"

[dependencies.arduino-hal]
git = "https://github.com/rahix/avr-hal"
rev = "3e362624547462928a219c40f9ea8e3a64f21e5f"
features = ["arduino-uno"]

# The latest releases of `proc-macro2` do not support the rust toolchain that
# we use.  Thus, we must fix this dependency to an older version where our
# toolchain is still supported.  See https://github.com/Rahix/avr-hal/issues/537
[build-dependencies.proc-macro2]
version = "=1.0.79"

# Configure the build for minimal size - AVRs have very little program memory
[profile.dev]
#overflow-checks = false
panic = "abort"
lto = true
opt-level = "s"

# This is needed because of a known bug https://github.com/Rahix/avr-hal/issues/125#issuecomment-771578390
#[profile.dev.package.compiler_builtins]
#overflow-checks = false

[profile.release]
panic = "abort"
codegen-units = 1
debug = true
lto = true
opt-level = "s"

Does this seem like a dependency version issue?

when i do cargo tree -d
I get

cfg-if v0.1.10
└── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624)
    ├── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624)
    │   └── bme_test v0.1.0 (/Users/tim/bme_test)
    └── atmega-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624)
        └── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)

cfg-if v1.0.0
├── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
├── avr-device v0.5.4
│   ├── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
│   ├── atmega-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
│   └── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
└── half v2.4.1
    └── fixed v1.27.0
        └── bme_test v0.1.0 (/Users/tim/bme_test)

embedded-hal v0.2.7
├── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
└── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)

embedded-hal v1.0.0
├── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
├── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
├── bme280-rs v0.3.0
│   └── bme_test v0.1.0 (/Users/tim/bme_test)
├── bme_test v0.1.0 (/Users/tim/bme_test)
├── embedded-hal-async v1.0.0
│   └── bme280-rs v0.3.0 (*)
├── embedded-hal-bus v0.1.0
│   └── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
└── embedded-hal-bus v0.2.0
    └── bme_test v0.1.0 (/Users/tim/bme_test)

embedded-hal-bus v0.1.0 (*)

embedded-hal-bus v0.2.0 (*)

nb v0.1.3
└── embedded-hal v0.2.7 (*)

nb v1.1.0
├── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=3e362624547462928a219c40f9ea8e3a64f21e5f#3e362624) (*)
├── bme_test v0.1.0 (/Users/tim/bme_test)
└── nb v0.1.3 (*)

but seems _addsf3 is defined both in the AVR, and in the rust compiler_builtins
you cant use both, so I'm lost to getting to have this not have conflicting crates.

[Rahix]

CC @Patryk27

[TimKotowski]

update, adding rustflags = ["-C", "link-arg=-Wl,--allow-multiple-definition"] allows the error to go away and to do calculations. Just heads up i basically just took the template that was generated, i didn't do any thing that I can think of that would cause this to error.

[Patryk27]

I think this is going to be similar to #541, which is stuck on rust-lang/rust#125016 (tl;dr I've added a small fix to compiler_builtins, but we can't bump compiler_builtins within rustc at the moment, because it brings f16 & f128 as well, and those have missing support within the compiler...).

Anyway, I'm watching the compiler_builtins bump and once it's done, I'll revisit this issue here (unless someone has a better lead, but that's my hunch for now).

[tgross35]

I think this is going to be similar to #541, which is stuck on rust-lang/rust#125016 (tl;dr I've added a small fix to compiler_builtins, but we can't bump compiler_builtins within rustc at the moment, because it brings f16 & f128 as well, and those have missing support within the compiler...).

FYI f16 & f128 will be disabled in the distributed version of compiler_builtins by default, with an exception on platforms that are known to work (currently x86 and aarch64). There is also a flag to disable it if you have it as a direct dependency for some reason.

I have a fix for the compiler builtins issue up and waiting for review, hopefully soonish.

[Patryk27]

Status: seems to compile on the latest toolchain, but due to #571 (aka llvm/llvm-project#102436) the entire newest toolchain is unusable for AVR anyway, so the issue's stalled on that.

[Patryk27]

Okie, it should work on the newest toolchain 🙂