Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    rahix
    @rahix:matrix.org
    [m]
    (but I see you're using ruduino
    ... If you want to tie into the greater embedded-rust ecosystem, switching to avr-hal instead might be worthwhile)
    Laura Demkowicz-Duffy
    @Laura7089
    wow, these are some awesome tools
    thanks very much for pointing me to them (and writing them!)
    rahix
    @rahix:matrix.org
    [m]
    no problem :) if you need any help, let me know
    Carl Peto
    @carlos4242
    Did we ever get to the bottom of all the frame setup/teardown bugs with pseudo instructions?
    Assertion failed: (Imm <= 62 && "Offset is out of range"), function expand, file ../lib/Target/AVR/AVRExpandPseudoInsts.cpp, line 1164
    This kind of thing?
    Ayke
    @aykevl:matrix.org
    [m]
    I've found at least one
    For example:
    https://reviews.llvm.org/D97745
    There are probably more.
    David
    @drmorr0:matrix.org
    [m]
    Hi it's been a long time but I'm slowly plugging away at things and thought you all might like to see my sdcard library that I'm working on: https://github.com/drmorr0/sdfat32-rs
    It only can ls in the root directory of a card and has no batteries included (requires a custom LLVM build, among other things) but it's getting there!
    Carl Peto
    @carlos4242
    Fantastic! I want to do something similar using swift one day. I hadn’t really thought about how complex sd cards are in a way. It’s a whole filing system after all!
    @ayke yeah… I think there’s a bit of a convoluted mix of hacks on hacks that led to this place and they break sometimes. I think the only long term solution is probably re-engineering it. It sounds a bit weird using AVR specific pseudo instructions to write frame lowering? Isn’t it easier to just write the stack frame emission all in C++ code? Anyway I’m just speculating. I’d like to look if I ever get time. For now I’m trying to understand why it happens sometimes and not others, so I can tell users to work around those cases!
    Ayke
    @aykevl:matrix.org
    [m]
    I actually happened to run into that issue yesterday. I believe there is code to deal with this case but apparently not all edge cases are handled.
    Carl Peto
    @carlos4242
    Yeah. I think for now I’m happy to just try and work out what the triggers are. Any thoughts?
    Alexander Vysotsky
    @utlime:matrix.org
    [m]

    Hi all!
    I'm stuck and don't know where is problem.
    When I'm converting f32 to usize in loop I'm always getting 0. Probably I miss some limitations for no_std or something similar.
    I run this on Arduino Nano

    #![no_std]
    #![no_main]
    
    use arduino_hal::prelude::*;
    use panic_halt as _;
    
    #[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 x: f32 = 3.0;
    
        loop {
            x = x + 1.0;
            let b = x as usize;
            ufmt::uwriteln!(&mut serial, "Got {}!\r", b).void_unwrap();
            arduino_hal::delay_ms(1000);
        }
    }

    In serial I see only "Got 0!..."

    If I move it from loop, then I'm getting correct value:

    #![no_std]
    #![no_main]
    
    use arduino_hal::prelude::*;
    use panic_halt as _;
    
    #[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 x: f32 = 3.0;
        x = x + 1.0;
        let b = x as usize;
        ufmt::uwriteln!(&mut serial, "Got {}!\r", b).void_unwrap();
        arduino_hal::delay_ms(1000);
    
        loop {
        }
    }

    Got 4!

    rahix
    @rahix:matrix.org
    [m]
    TL;DR: f32 still has some bugs, don't use it for now
    1 reply
    Jacobtread
    @jacobtread
    Hello everyone I am looking to make some custom firmware for my usb rubber ducky from the original firmware source https://github.com/hak5darren/USB-Rubber-Ducky/blob/master/Firmware/Source/Ducky_HID/Framework.config I have gathered that the chip is a Atmel AT32UC3B http://ww1.microchip.com/downloads/en/DeviceDoc/doc32059.pdf and its avr32. I've tried to build the example avr target project thing (build --target avr-unknown-gnu-atmega328 -Z build-std=core --all --release) but it always fails with the following error
    Compiling compiler_builtins v0.1.49
    Compiling avr-std-stub v1.0.3
    LLVM ERROR: Not supported instr: <MCInst 312 <MCOperand Reg:1> <MCOperand Imm:13> <MCOperand Reg:41>>
    error: could not compile compiler_builtins
    Process finished with exit code 101
    Can someone help me get this setup properly or fix this error
    rahix
    @rahix:matrix.org
    [m]
    you need an older rust compiler, use nightly-2021-01-07
    Alexander Vysotsky
    @utlime:matrix.org
    [m]
    rahix: may be you can suggest any crates which I can use for math methods, e.g. cos, sin and etc?
    tried to use different, e.g. micromath. But they all relay on f32 =/
    rahix
    @rahix:matrix.org
    [m]
    for basic math, I can recommend fixed, but I don't think it has trig functions
    (use the FixedI16 and FixedU16 types)
    Alexander Vysotsky
    @utlime:matrix.org
    [m]
    ok, thank you. Will check
    ㄗㄠˋ ㄑㄧˊ
    @tsao-chi
    I tried to compile blink and it always failed
    error: couldn't allocate input reg for constraint 'w'
      --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/avr_delay-0.3.1/src/lib.rs:34:17
       |
    34 |         unsafe {llvm_asm!("1: sbiw $0,1
       |                 ^
    
    warning: `avr_delay` (lib) generated 1 warning (1 duplicate)
    error: build failed
    Do I need to install an older rust compiler?
    Carl Peto
    @carlos4242
    Hey guys another odd bug. Has anyone had problems with log() and exp()?
    I'm compiling C code using clang and it's doing something weird.
    Here's a simple test case. If I compile this C code...
    #include <math.h>
    
    float _log(float f) {
        return log(f);
    }
    It creates this LLVM IR...
    ; Function Attrs: nounwind readnone
    define dso_local float @_log(float %f) local_unnamed_addr #0 {
    entry:
      %0 = tail call float @llvm.log.f32(float %f)
      ret float %0
    }
    Carl Peto
    @carlos4242
    This gets lowered to the following AVR assembly...
    Disassembly of section .text._log:
    
    00000000 <_log>:
       0:    0e 94 00 00     call    0    ; 0x0 <_log>
                0: R_AVR_CALL    logf
       4:    08 95           ret
    I added the relocation for clarity. It looks like this whole process is special case. I assume there's something in clang that sees a call to the extern log() function and replaces it with an llvm intrinsic. Presumably that makes for efficient back end implementations on some llvm platforms. Very clever.
    However it looks like perhaps our back end is broken here. Because on AVR there is no logf function/symbol in libm.a. Only log is defined in avr-libc, (avr-libm) presumably because double and float are identical on this platform.
    Has anyone seen this and can suggest a fix? Or where in the back end I should go looking for the code to fix?
    jwagen
    @jwagen:matrix.org
    [m]
    It compiles without warnings for me with clang 12. And produces what looks like a valid file. I did not see any calls to logf tough.
    1 reply
    Carl Peto
    @carlos4242
    whats weird is it only happens with log and exp... sin, cos... tan... etc all fine
    Carl Peto
    @carlos4242
    It looks like there's some target specific special casing for sin/cos...
    In lib/Target/AVR/AVRISelLowering.cpp...
    AVRTargetLowering::AVRTargetLowering(const AVRTargetMachine &TM,
                                         const AVRSubtarget &STI)
        : TargetLowering(TM), Subtarget(STI) {
    ...
    
      // Trigonometric rtlib functions
      setLibcallName(RTLIB::SIN_F32, "sin");
      setLibcallName(RTLIB::COS_F32, "cos");
    So it looks like that's fixed for those two.
    Otherwise this function gets called...
    
    static void ReplaceFPIntrinsicWithCall(CallInst *CI, const char *Fname,
                                           const char *Dname,
                                           const char *LDname) {
      switch (CI->getArgOperand(0)->getType()->getTypeID()) {
      default: llvm_unreachable("Invalid type in intrinsic");
      case Type::FloatTyID:
        ReplaceCallWith(Fname, CI, CI->arg_begin(), CI->arg_end(),
                        Type::getFloatTy(CI->getContext()));
        break;
      case Type::DoubleTyID:
        ReplaceCallWith(Dname, CI, CI->arg_begin(), CI->arg_end(),
                        Type::getDoubleTy(CI->getContext()));
        break;
      case Type::X86_FP80TyID:
      case Type::FP128TyID:
      case Type::PPC_FP128TyID:
        ReplaceCallWith(LDname, CI, CI->arg_begin(), CI->arg_end(),
                        CI->getArgOperand(0)->getType());
        break;
      }
    }
    Which outputs logf for 32 bit floats.
    Carl Peto
    @carlos4242
    This patch fixes it...
    diff --git a/llvm/lib/Target/AVR/AVRISelLowering.cpp b/llvm/lib/Target/AVR/AVRISelLowering.cpp
    index eb719415395b..1eff049ba2ea 100644
    --- a/llvm/lib/Target/AVR/AVRISelLowering.cpp
    +++ b/llvm/lib/Target/AVR/AVRISelLowering.cpp
    @@ -227,6 +227,29 @@ AVRTargetLowering::AVRTargetLowering(const AVRTargetMachine &TM,
       setLibcallName(RTLIB::SIN_F32, "sin");
       setLibcallName(RTLIB::COS_F32, "cos");
    
    +  // other functions in llvm rtlib or libc/libm
    +  // these are hard coded different from normal
    +  // libm because avr-libc doesn't have the float
    +  // variants; float and double are identical on avr
    +  setLibcallName(RTLIB::REM_F32, "fmod");
    +  setLibcallName(RTLIB::LOG_F32, "log");
    +  setLibcallName(RTLIB::CBRT_F32, "cbrt");
    +
    +  setLibcallName(RTLIB::FLOOR_F32, "floor");
    +  setLibcallName(RTLIB::CEIL_F32, "ceil");
    +  setLibcallName(RTLIB::EXP_F32, "exp");
    +
    +  setLibcallName(RTLIB::FMIN_F32, "fmin");
    +  setLibcallName(RTLIB::FMAX_F32, "fmax");
    +  setLibcallName(RTLIB::FMA_F32, "fma");
    +
    +  setLibcallName(RTLIB::LOG10_F32, "log10");
    +  setLibcallName(RTLIB::POW_F32, "pow");
    +  setLibcallName(RTLIB::TRUNC_F32, "trunc");
    +  setLibcallName(RTLIB::ROUND_F32, "round");
    +  setLibcallName(RTLIB::LROUND_F32, "lround");
    +  setLibcallName(RTLIB::LRINT_F32, "lrint");
    +
       setMinFunctionAlignment(Align(2));
       setMinimumJumpTableEntries(UINT_MAX);
     }
    Not sure how to submit patches these days. I'm used to github and PRs. :)