ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
rardiol has joined #rust-embedded
GenTooMan has quit [Ping timeout: 255 seconds]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
causal has quit [Quit: WeeChat 3.6]
<re_irc> <dkhayes117> I'm having trouble building "tinyrlibc" on my new machine. I installed "gcc-arm-none-eabi" but it still "fails to to find tool." I can't remember how I fixed this. Any ideas?
GenTooMan has joined #rust-embedded
<re_irc> <dkhayes117> I think it is a path issue
rardiol has quit [Ping timeout: 256 seconds]
<re_irc> <Robert Gałat> Hi, I have a quick question, I try to run an example hello world on nrf52840, and I stumbled on issue with defmt. The application compiles and runs successfuly, but I do not see any log outputs. I found out that defmt changed the way log level is set from freature in Cargo.toml to envirnment variable somewere around version 0.3.0. I can not ge tthis to work on windows, I tried "$DEFMT_LOG="info"; cargo run", and...
<re_irc> ... the application has been flashed to the board, but I did not get any log messages :(
<re_irc> so my question is how to enable logs with defmt when I use Windows as a host machine ?
<re_irc> <explodingwaffle101> i think $env:DEFMT_LOG = "info" should work in powershell. you're right that it's annoying on windows
<re_irc> <Robert Gałat> PS C:\Users\Robert\Documents\rust\nrf52840dk-sample> $DEFMT_LOG="info"; cargo run
<re_irc> Finished dev [unoptimized + debuginfo] target(s) in 0.06s
<re_irc> Running `probe-run --chip nRF52840_xxAA target\thumbv7em-none-eabihf\debug\nrf52840dk-sample`
<re_irc> (HOST) INFO flashing program (11 pages / 44.00 KiB)
<re_irc> <Robert Gałat> explodingwaffle101: it helped a little, it compiled defmt-macros
<re_irc> but I got linking with 'link.exe` failed: exit code 1201
<re_irc> <Robert Gałat> Ok i got this to work, when I deleted target directory and rebuild everything it worked
<re_irc> <Robert Gałat> explodingwaffle101: thank You 😍
<re_irc> <ithinuel> If that helps you, you can also set the env bar for cargo in .cargo/config.toml
rardiol has joined #rust-embedded
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
starblue has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <paper101> Hi, i have a question, I'm new to embedded programming and am wondering if I should use rust for it or other more mature ecosystems?
<re_irc> <Robert Gałat> I would say that plain C is a little simpler to grasp at the beginning (if you realize that everything can be simplified to writing some data to some memory :D ). Maybe because I understand C very well, and know how actual hardware works, I'm a little biased toward a language that I already know very well. Having said that, I think that there are a lot of great resources in the Rust community to learn from, and I...
<re_irc> ... always had great experience when asking questions. I think that the main objective would be to get that deep understanding of what is going on under the hood. Unfortunately I do not have a lot of experience with rust, but I think that it is a little high level, and alto it compiles down to efficient machine code, it may be hard to analyze what it does when You try to understand how actual hardware works.
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
starblue has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc> <hartan> I think it also depends on what you're trying to do. If there are crates for all the bits and components you need, rust is a very good choice imo. If you are in a situation where you have to extend existing crates to support new traits or even write your own, from my experience you should have a good grasp of generics and the abstractions involved in programming rust. I've never seen so many generics in rust code before...
<re_irc> ... I started working on the esp32-hal. But that needn't scare you, you'll learn it on the way (I did, and now I do my own magic with generics). Right now I'm personally at a point where I'd rather invest many hours in rust to get a project working (writing libs/drivers, etc.) than implementing it in C with vendor libraries and such. For example: Getting an actual "Error" when something goes wrong is such a wonderful...
<re_irc> ... experience...
dc740 has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
causal has joined #rust-embedded
<re_irc> <paper101> I see, thanks for the advice. I do have some experience of rust on a higher level so I think I will give it a shot for embedded too instead of going to c straight away
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <thebutlah> are global allocators on no_std architecture specific? I'm seeing that the rust embedded book recommends alloc-cortex-m (https://github.com/rust-embedded/alloc-cortex-m) but I am on an esp32c3 (RISC-V)
<re_irc> <thebutlah> +typically
<re_irc> <James Munns> In general - a bit. The allocator needs to be global (and therefore thread safe). alloc-cortex-m achieves this with a critical section (in a cortex-m specific way), but making one for RISC-V should also be possible to do basically the same thing, but with a different critical section.
<re_irc> <James Munns> If you're using "std" on the esp32, I don't think you'll need that, but you will if you aren't using their standard library.
<re_irc> <James Munns> the underlying allocator itself (in this case: linked-list-allocator) is NOT platform specific at all, but it isn't thread-safe, by itself.q
<re_irc> <James Munns> * itself.
starblue has joined #rust-embedded
<re_irc> <thebutlah> does anyone know of a good risc-v global allocator?
<re_irc> <9names (@9names:matrix.org)> I think once pr 56 is merged, alloc-cortex-m will work just fine with riscv. Maybe try using that as a git dependency?
<re_irc> <thebutlah> I think I will use esp-alloc (https://github.com/esp-rs/esp-alloc) for now. I believe it will work not just on the esp32c3 but on _any_ riscv mcu. However, it also supports xtensa mcus like the other esp32 microcontrollers.
<re_irc> <thebutlah> long term though, I think since both "alloc-cortex-m" and "esp-alloc" both use "linked_list_allocator" and critical sections, an allocator build on the "critical-section" crate is a better choice in the future
<re_irc> <thebutlah> * future.
<re_irc> <thebutlah> * built
<re_irc> <thebutlah> +There really is almost no difference between the two crates other than what implementation of "interrupt::free" they use
<re_irc> <aktaboot> thebutlah: what do you use on it ?
<re_irc> <aktaboot> (firmware-wise)
<re_irc> <thebutlah> aktaboot: I don't understand the question. But if you are asking if I use esp-idf, no I'm using esp-hal
<re_irc> <thebutlah> long term though, I think since both "alloc-cortex-m" and "esp-alloc" both use "linked_list_allocator" and critical sections, an allocator built on the "critical-section" crate is a better choice in the future. There really is almost no difference between the two crates other than what implementation of "interrupt::free" they use. Looks like both allocators plan to migrate to "critical-section"
<re_irc> <thebutlah> I don't understand the question. But if you are asking if I use esp-idf, I'm using esp-hal instead
<re_irc> <thebutlah> I cannot seem to access the alloc crate:
<re_irc> #![no_std]
<re_irc> extern crate alloc;
<re_irc> #![no_main]
<re_irc> <thebutlah> I am on nightly via "rust-toolchain.toml", and "rustup show" says I'm using nightlyu
<re_irc> <thebutlah> * nightly
<re_irc> <thebutlah> the crate is not present in my cargo.toml, because I thought that was not what I was supposed to do
<re_irc> <thebutlah> * "alloc"
<re_irc> <newam> thebutlah: Which nightly? IIRC nightly channel sometimes don't build everything.
<re_irc> <thebutlah> newam: nightly-x86_64-pc-windows-msvc (overridden by 'D:\Ryan\Programming\slimevr\rust\firmware\rust-toolchain.toml')
<re_irc> rustc 1.65.0-nightly (e1b28cd2f 2022-08-19)
<re_irc> Nevermind, I am misremembering, it doesn't always have all components, it should always have alloc.
<re_irc> <thebutlah> really lost on why I cannot get alloc. Everything online says this is the way to do it. 😕
<re_irc> <newam> can you use alloc without the "extern crate alloc;"?
<re_irc> <newam> e.g. "use alloc::vec::Vec;"
<re_irc> <thebutlah> --> firmware\src\main.rs:38:15
<re_irc> 38 | let arc = alloc::sync::Arc::new(10);
<re_irc> |
<re_irc> | ^^^^^ use of undeclared crate or module `alloc`
<re_irc> <thebutlah> If I do that, this is what happens:
<re_irc> --> firmware\src\main.rs:38:15
<re_irc> |
<re_irc> 38 | let arc = alloc::sync::Arc::new(10);
<re_irc> <newam> Mmm yup I'm wrong about that.
<re_irc> extern crate alloc;
<re_irc> use alloc::vec::Vec;
<re_irc> I tried this in a project:
<re_irc> with "cargo 1.65.0-nightly (9809f8ff3 2022-08-16)" and it worked (failed to compile due to no global alloc handler)... 🤔
<re_irc> <newam> is it possible to share your repo?
<re_irc> <newam> Oh this is ESP
<re_irc> <newam> There might be an install problem with the toolchain - I know ESP has some custom things for their xtensa targets.
<re_irc> If it's a RISC-V target then it's probably not that
<re_irc> <thebutlah> this is a RISC-V target, and yes I'll push my code so you can take a look :)
<re_irc> <newam> I removed that
<re_irc> <newam> and did "rustup target add riscv32imac-unknown-none-elf" (it wasn't in the "rust-toolchain.toml") and it worked
<re_irc> <thebutlah> newam: OMG THIS SOLVED IT
<re_irc> <newam> Yay! Glad I could help :)
<re_irc> <thebutlah> thank you so so much
<re_irc> <newam> no problem!
<re_irc> <thebutlah> because the "build-std" was suggested by the official esp-hal template, I went ahead and added "alloc" into the list, and that works too.
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded