Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with math calculations with floats to serial port output #566

Open
TimKotowski opened this issue Jul 14, 2024 · 6 comments · May be fixed by #585
Open

Issue with math calculations with floats to serial port output #566

TimKotowski opened this issue Jul 14, 2024 · 6 comments · May be fixed by #585
Labels
compiler-bug Not a bug in avr-hal, but a bug in the rust compiler/LLVM

Comments

@TimKotowski
Copy link

TimKotowski commented Jul 14, 2024

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 <[email protected]>"]
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.

@TimKotowski TimKotowski changed the title Issue with Floating Point math to serial print out Issue with math calculations with floats to serial port output Jul 14, 2024
@Rahix
Copy link
Owner

Rahix commented Jul 16, 2024

CC @Patryk27

@TimKotowski
Copy link
Author

TimKotowski commented Jul 16, 2024

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
Copy link
Contributor

Patryk27 commented Jul 21, 2024

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
Copy link

tgross35 commented Jul 21, 2024

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
Copy link
Contributor

Patryk27 commented Aug 8, 2024

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
Copy link
Contributor

Okie, it should work on the newest toolchain 🙂

@Rahix Rahix linked a pull request Sep 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler-bug Not a bug in avr-hal, but a bug in the rust compiler/LLVM
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants