<re_irc>
<Hexafox> Yeah I'm looking at something more complete than bindings for the C library. Ideally I'd like to see if I can write a Rust replacement to the devkitpro stuff
<re_irc>
<Hexafox> As far as I can tell it's entirely possible
<re_irc>
<dngrs (spookyvision@{github,cohost})> if the CPU/arch is supported, it should be, yeah. Question is how much work that would be… (disclaimer: I have zero DS dev experience, I just did a quick google for what's there and rs-nds seems to be the only game in town right now)
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@CyReVolt:matrix.org)> hello hackers - I derived a log library from the embedded HAL traits, and I'm looking for feedback
<re_irc>
except a bit different. I struggled a lot to end up with something that would at least _compile_, fighting with lifetimes, "dyn", mutable refs etc etc. The goal was to keep this thing simple and comprehensible. I would love some feedback and thoughts. Maybe this or something similar can make its way into the HAL crate itself at some point.
<re_irc>
< (@CyReVolt:matrix.org)> feel free to drop comments on GitHub :)
<re_irc>
< (@grantm11235:matrix.org)> : Your unsafe code is very unsound, you need to put the global logger in some kind of a mutex
<re_irc>
< (@CyReVolt:matrix.org)> Does that mean even more wrapping, or can some wrapping be replaced? Can you explain the need for the mutex?
<re_irc>
For context: This is currently for bringup/initialization firmware, which involves no concurrency.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@CyReVolt:matrix.org)> r9 implements an MCS lock, which looks too complex to my untrained and weary eyes
<re_irc>
I couldn't understand why this would be needed, so I removed it when I worked the above PR, and it still works fine.
<re_irc>
On another SoC, the mutex stuff wasn't working, and I couldn't figure out why. Maybe it was related to the riscv-rt stuff and critical-section.
<re_irc>
All of this still feels hard to understand to me. I am trying to document things as best as I can so that newcomers could work on and with it, too. =)
<re_irc>
< (@CyReVolt:matrix.org)> I've pushed another commit that adds a Mutex.
<re_irc>
In order to implement the allocator, I still have to wrap the mutex though in order to fulfill the orphan rule. Is that a problem?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
steew has quit [*.net *.split]
steew has joined #rust-embedded
<re_irc>
<aja23> anyone have any advice on how to carve down binary sizes? I'm wondering if there are any tricks to quickly see what is taking up so much space in the binary. I've been porting from C to rust and somehow ended up with a binary file that's 2 MB where the C implementation fit into less than 20 kB
<re_irc>
< (@diondokter:matrix.org)> Compile with optimizations (3 or 's' or 'z')
<re_irc>
Enable LTO
<re_irc>
Avoid using rust's formatting
<re_irc>
You can use NM or cargo-bloat to see where your bytes go
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<aja23> thanks that's giving me some insights! This one is a big ooff, I don't even know where I called it: 0.1% 5.5% 740B std core::str::count::do_count_chars
crabbedhaloablut has joined #rust-embedded
<re_irc>
<aja23> Is there any way to work backwards from this list and find out what is calling things like std::core::str::count::do_count_chars?
<re_irc>
<aja23> This is confusing, this is a no-std lib and binary obviously but the biggest thing is std:
<re_irc>
< (@diondokter:matrix.org)> aja23: Std means core here probably
<re_irc>
<Ralph> aja23: isn't this also just 13.2KB? and the rest of the 1.3MB file is stuff which isn't transferred to the device? i've read other messages on here which explained that part of the binary file just contains symbols and other debugger information (e.g. the strings used by "defmt", in caes you're using that)
<re_irc>
< (@adamgreig:matrix.org)> Yea, use "cargo size" from the cargo-binutils crate (or arm-none-eabi-size if you have a c toolchain already) to see what the size on device is, the elf filesize isn't relevant as it contains all the extra metadata and debugging data
<re_irc>
< (@adamgreig:matrix.org)> In your case it's a total of 13kB, much more comparable to the 20kB you had in C
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
<re_irc>
<bitts> Is there a way to recover a pin consumed by the one-wire-bus (which moves the pin)? It has a into_inner which returns the pin, but only as InputPin + OutputPin traits, and those don't support changing from open drain to push_pull_output (which I need to do).
<re_irc>
<Peter Hansen> Also has anyone deciphered what [Unknown] covers or where it comes from?
<re_irc>
0.0% 1.2% 1.2KiB compiler_builtins
<re_irc>
0.1% 3.0% 3.1KiB [Unknown]
<re_irc>
<Julia> I can get QEMU to run my application using: "julia@julia-ubuntu:~/CLionProjects/nrf51822_blinky_rust$ qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel target/thumbv7m-none-eabi/release/nrf51822_blinky_rust". However this produces an error when I add it to cargo.toml and try to execut "cargo run --release": ```toml
<re_irc>
<Julia> I can get QEMU to run my application using: "julia@julia-ubuntu:~/CLionProjects/nrf51822_blinky_rust$ qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel target/thumbv7m-none-eabi/release/nrf51822_blinky_rust". However this produces an error when I add it to cargo.toml and try to execut "cargo run --release": ```toml
<re_irc>
<Julia> I can get QEMU to run my application using: "julia@julia-ubuntu:~/CLionProjects/nrf51822_blinky_rust$ qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel target/thumbv7m-none-eabi/release/nrf51822_blinky_rust". However this produces an error when I add it to cargo.toml and try to execut "cargo run --release":
<re_irc>
<Julia> This is the error "target/thumbv7m-none-eabi/release/nrf51822_blinky_rust: 1: Syntax error: word unexpected (expecting ")")", any ideas what I'm doing wrong?
<re_irc>
<Julia> Also as an aside, I'm trying to emulate a thumbv6m target with 32kb RAM and 256kb ROM. Right now I am using a thumbv7m target and restricting it to these memory constraints. Is there a better solution to this?
<re_irc>
< (@datdenkikniet:matrix.org)> Is the project configured so that cargo spits out "thumbv7m-none-eabi" by default? You may have to run it with "cargo run --release --target thumbv7m-none-eabi" instead
<re_irc>
< (@datdenkikniet:matrix.org)> * uses
<re_irc>
<Julia> Yes
<re_irc>
< (@korken89:matrix.org)> You can copy from RTIC
<re_irc>
<Julia> I am not sure what I changed, but now I get
<re_irc>
I plug the the board into my Mac and it happily runs its default demo, I can see the board in System Information but when I try and run run the setup code it just hangs at "rtt-check":
<re_irc>
I plug the the board into my Mac and it happily runs its default demo, I can see the board in System Information but when I try and run the setup code it just hangs at "rtt-check":
<re_irc>
< (@datdenkikniet:matrix.org)> the "rustflags" there are only applied to "thumbv7m-none-eabi", not "thumbv6m-none-eabi". I'm not certain what that file does, but quite sure you need it for either one. Usually you include it by using something like
<re_irc>
< (@datdenkikniet:matrix.org)> also: cargo is being very picky about when it does or doesn't use the specified runner config, pretty confusing...
<re_irc>
< (@datdenkikniet:matrix.org)> +for me,
<re_irc>
< (@datdenkikniet:matrix.org)> * confusing and annoying...
<re_irc>
<Julia> ohmygod you are a genius
<re_irc>
<Julia> Yeah I added the flags to the thumbv6m target and now it works!
<re_irc>
< (@korken89:matrix.org)> To make it work for all targets
<re_irc>
< (@datdenkikniet:matrix.org)> TIL about the "package.forced-target" (https://doc.rust-lang.org/cargo/reference/unstable.html#per-package-target) key (nightly only). I guess it makes sense, but pretty confusing when you're running "cargo run --target thumbv7m-none-eabi" and it tries to run the "thumbv6m-none-eabi" on your host instead (seemingly ignoring the ".cargo/config" for "thumbv6m-none-eabi")
<re_irc>
<Julia> I have problems with the forced-target key, not sure why.
<re_irc>
<Julia> It works fine in my none-qemu branch though.
<re_irc>
< (@datdenkikniet:matrix.org)> I would fully expect the last line here to be "qemu-system-arm <args> target/thumbv6m-none-eabi...", but instead it ignores the ".cargo/config" and tries to run it on the host
<re_irc>
< (@datdenkikniet:matrix.org)> +second to
<re_irc>
< (@datdenkikniet:matrix.org)> * contain
crabbedhaloablut has quit [Ping timeout: 255 seconds]
<re_irc>
< (@datdenkikniet:matrix.org)> typohaiku: if you run your program like "RUST_LOG=debug cargo embed ..." you'll get debug output for "cargo-embed", it might tell you where/what is hanging. Reference for "RUST_LOG" (https://docs.rs/env_logger/0.10.0/env_logger/#enabling-logging)
<re_irc>
< (@datdenkikniet:matrix.org)> * hanging in the flashing process. Perhaps it is succeeding, but RTT is being iffy?
<re_irc>
< (@datdenkikniet:matrix.org)> * where/what/if it
<re_irc>
<aja23> Thanks for the help with the size stuff guys, is there a way to find what is calling low level functions like core::str::do_count_char?
starblue has quit [Read error: Connection reset by peer]
<re_irc>
<Peter Hansen> aja23: There's likely a much better way, but I've sometimes generated a .lst file with objdump -S and then inspected it to figure that out. It can be awkward and inefficient but also helps me learn more about how Rust works and what my code looks like to the chip...
<re_irc>
<Peter Hansen> e.g. "cargo objdump -- -S >temp.lst"
<re_irc>
<aja23> Thanks, will give it a try
<re_irc>
<Peter Hansen> I eagerly await those with better options for us. ;-)
<re_irc>
< (@CyReVolt:matrix.org)> Let me know if anyone's interested in the BL808 SoC. I got Rust code running on both cores now. :) 🦀
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Jonathan> Thanks, will definitely take a close look at that!
<re_irc>
< (@9names:matrix.org)> : I also have code running on 2 cores. Maybe you should join #pine64-nutcracker:matrix.org, it's not Rust-specific but most of our problems currently are lack of documentation.
<re_irc>
< (@CyReVolt:matrix.org)> : Lack of docs, huh... sounds like firmware development. ^^
<re_irc>
I'll gladly join. :)
<re_irc>
< (@adamgreig:matrix.org)> Jonathan: if you want a super super bare-bones example, https://github.com/adamgreig/rv-playground/ is a small risc-v cpu with a little rust firmware to toggle an io
<re_irc>
< (@adamgreig:matrix.org)> the litex integration is a much more serious/useful endeavour
<re_irc>
but it says there is no such method, even though my ide autocompleted it, what could be going on here?
<re_irc>
dwt.enable_cycle_counter();
<re_irc>
<Julia> +<--- this method
<re_irc>
< (@jamesmunns:beeper.com)> Julia didn't see the end of the conversation, but the nrf51 is a thumbv6m target, not thumbv7
<re_irc>
<Julia> Yeah I know, I set up qemu with a the closest thing that was a cortex-m3 so I had to use backwards compatibility haha.
<re_irc>
<Julia> -a
<re_irc>
< (@jamesmunns:beeper.com)> Cool, looks like y'all got it sorted :)
<re_irc>
<Julia> I am trying to do some measurements now of how long functions take. I think I might just use a regular timer for it since DWT doesn't seem to work.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, not sure about qemu, but on the nrf52 I usually use one of the hardware timers as a dedicated, 32-bit rolling timer
<re_irc>
< (@jamesmunns:beeper.com)> At 1mhz, it gives you 71m of duration, with 1uS precision
<re_irc>
< (@jamesmunns:beeper.com)> which is usually good enough for measuring non-trivial functions. I typically run them hundreds/thousands of times at once, to get more precise measurements.
<re_irc>
< (@jamesmunns:beeper.com)> If your benchmark doesn't last more than 71, you don't have to think about roll-over :D
<re_irc>
< (@jamesmunns:beeper.com)> * 71 mins,
<re_irc>
<Julia> my god I truly don't understand how to navigate a HAL 🙃