crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Peter Hansen> I've used the DWT peripheral (provided by ARM, not Nordic) with cycle_count() instead of firing up a Timer, but I'm not sure what all the tradeoffs are.
<re_irc>
< (@dirbaio:matrix.org)> but if you want to benchmark a computation CYCCNT is better, it runs at the same freq as the core (so 64mhz in nrf52), vs the timers run at only 16mhz
<re_irc>
< (@dirbaio:matrix.org)> +nrf
<re_irc>
< (@dirbaio:matrix.org)> so more precise
<re_irc>
< (@dirbaio:matrix.org)> but it doesn't matter much if the computation is long
<re_irc>
< (@dirbaio:matrix.org)> and if you want stuff to go faster on nrf52 don't forget to enable the flash cache: "peripherals.NVMC.icachecnf.write(|w| w.cacheen().enabled());"
<re_irc>
< (@dirbaio:matrix.org)> it's literally a magic "please go faster" big :D
<re_irc>
< (@dirbaio:matrix.org)> * bit
<re_irc>
<Julia> Interesting, I tried using cyccnt, but it doesnt work for one reason or another though.
<re_irc>
<Julia> : let mut core = cortex_m::Peripherals::take().unwrap();
<re_irc>
core.DCB.enable_trace();
<re_irc>
core.DWT.enable_cycle_counter();
<re_irc>
// Enable the monotonic timer (CYCCNT)
<re_irc>
<Julia> Interesting, I tried using cyccnt, but it doesnt work for one reason or another though. It says the method to enable the counter can't be found :P.
<re_irc>
<Julia> digging into cortex-m:
<re_irc>
/// Cycle Count
<re_irc>
#[cfg(not(armv6m))]
<re_irc>
pub cyccnt: RW<u32>,
<re_irc>
<Julia> digging into cortex-m:
<re_irc>
#[cfg(not(armv6m))]
<re_irc>
pub cyccnt: RW<u32>,
<re_irc>
/// Cycle Count
<re_irc>
<Julia> It's also not mentioned in the reference manual, so it must be something they added to newer designs :). So timers it is.
<re_irc>
<Peter Hansen> Julia: Sorry if I led you astray with that... definitely may not be in all cores. If you want to confirm, this might help:
<re_irc>
<Peter Hansen> Not sure if variant(MODE_A::TIMER) is strictly an alias for mode().timer()...
<re_irc>
<Julia> For my purposes the internal timer is honestly good enough. I just want to see the speed of some functions which will run in the order of 500ms to multiple minutes.
<re_irc>
<Julia> Peter Hansen: I tried this as well, but this doesn't seem to work :(.
<re_irc>
<Peter Hansen> bummer... might be another nRF51/52 difference. I'm on 52840...
<re_irc>
<Julia> I'm honestly not sure what the HAL is for at this point, it seems you need to write to all the registers yourself in the end anyways.
<re_irc>
<Julia> This specific one HAL that is.
<re_irc>
<Julia> -one
<re_irc>
<Peter Hansen> For simple stuff like this, I think you could just call it a type-safe thin layer over the PAC. E.g. that's why you need unsafe around bits(), but the other stuff isn't unsafe and the compiler will whine if you get anything wrong.
<re_irc>
<Peter Hansen> I find it rather verbose too, but am getting used to it. Might even appreciate it some day. ;-)
<re_irc>
<Julia> Can you also use the PAC directly? I might honestly just prefer that.
<re_irc>
<Peter Hansen> Hmm... actually, the above things are provided by the PAC. The HAL is a layer on top that provides higher-level functionality on top of the PAC stuff, when needed. The lower level below those sorts of routines would presumably be just fairly raw pointer access and bit shifting etc, which I guess is what the PAC layer lets you avoid.
<re_irc>
<Peter Hansen> The PAC is, I believe, auto-generated by tools from an SVD file provided by the vendor. I find the code in it fairly inscrutable, but the generated docs make it usable. Going full "raw" would probably not be nicer.... manual bit-shifting, ORing and ANDing with masks? Nobody manages to get that correct enough to make it more desirable, I think... I sure don't.
<re_irc>
< (@grantm11235:matrix.org)> It's very hard to write abstractions for timers that cover every possible use case, so it looks like that particular HAL just provides access to the registers from the PAC so that the user can do whatever they want
<re_irc>
<Peter Hansen> Julia: FYI, if you're using the nrf51-pac, it should support that timer() alternative to .variant(MODE_A::TIMER). It has an "fn timer()" that literally returns exactly that.
<re_irc>
< (@grantm11235:matrix.org)> I forgot how bad the docs are for svd2rust pacs lol
<re_irc>
< (@firefrommoonlight:matrix.org)> Timer API in a forked nRF HAL. I'd copy+paste what you need since this is out of sync with the main HAL, and doesn't explicitly support -51:
<re_irc>
< (@firefrommoonlight:matrix.org)> Try line 278
<re_irc>
< (@firefrommoonlight:matrix.org)> And some of the RTIC tasks that bind to a "TIMERx" for handling their timeout
<re_irc>
<bitts> New to rust and trying to write a driver for a one-wire-bus eeprom (ds28e07). While copying from scratchpad to eeprom, I have to switch the pin from open drain output to push_pull output. Is this possible at all within the embedded-hal framework (from what I can tell, not really)?
<Darius>
.
<Darius>
oops
<re_irc>
< (@tmgross:matrix.org)> @bitts there should be a method like "into_push_pull_output()" that would change it, does that work?
<re_irc>
< (@tmgross:matrix.org)> I have my own related question... how do you get pins back from a peripheral like Qspi, Spi etc? Those don't seem to have any "_into" methods, and I don't see any helpful "From"/"Into" impls
<re_irc>
<aja23> is anyone able to help me with the correct syntax for cargo objdump? I keep hitting "missing field 'package'"
<re_irc>
<aja23> this is what I've been trying cargo objdump --release --target thumbv6m-none-eabi --bin lvl2serial_bootloader
<re_irc>
<aja23> I also tried just calling objdump on the file in the target/release directory with the -S flag but got "can't disassemble unknown architecture" or something like that
<re_irc>
<bitts> : So I am able to set it before handing it off to the one-wire-bus peripheral, but then it is moved, and I no longer have access to it. And the one-wire-bus is using InputPin + OutputPin traits, and those do not support into_push_pull_output as far as I can tell. If I could get it back from the one_wire_bus, it would fix the problem. So we are wondering about the same.
<re_irc>
< (@marmrt:matrix.org)> : I think the HALs I've seen mostly don't bother with that functionality. Using the same pins both for SPI and something else at the same time is a pretty niche case
<re_irc>
< (@tmgross:matrix.org)> bitts: Hey, you're running into the same problem as me then. Ironic timing
<re_irc>
< (@tmgross:matrix.org)> : Ick... that's sort of what I feared. I'm in that niche, just need to set the things back to floating for the "fake shared" qspi bus we're working with
<re_irc>
<aja23> I guess more generally and related to my question earlier today, does anyone know how to dig into a project and figure out which functions call which other functions. My problem currently is some part of my code base is using things like core::str::do_count_char and I have no idea what it is (I never import core::str).
<re_irc>
< (@tmgross:matrix.org)> Transmut it is... I'll have to open an issue, it's not common but it's definitely needed
<re_irc>
< (@marmrt:matrix.org)> : If you know what you're doing you can use "Peripherals::steal()" to get a second copy of the peripheral and use that to get a second copy of the Pins. Beware, that
<re_irc>
< (@marmrt:matrix.org)> * it might work or it might break stuff.
<re_irc>
< (@tmgross:matrix.org)> So the same guarantees as writing it in C :) I feel more comfortable with a transmute for those few specific pins since that's the only mess-up-able thing, as opposed to stealing all the perifs and possibly mixing up other pins. But good to know that exists, and I love the naming
<re_irc>
< (@tmgross:matrix.org)> Thanks for the info, I'll see how this goes
<re_irc>
<bitts> : How do you use transmute to get around this? Care to share a bit of syntax?
<re_irc>
<aja23> damn, this looks like exactly what I'm after (japaric the legend) https://github.com/japaric/cargo-call-stack but I can't get over the Failed to get bitcode from object file for LTO error, despite implementing the work around here (https://github.com/japaric/cargo-call-stack/issues/32), has anyone else had the same problem and found a solution? The issue may be complicated by this other issue with workspaces...
<re_irc>
<aja23> I'm not sure exactly what I did (ran cargo clean, changed some opt-levels, moved where the profile.release parameters are maintained) but cargo bloat is showing that I no longer have core::fmt or core::str functions in my binary. The largest functions that aren't my code are now compiler_builtins::memmove and compiler_builtins::memcpy at 770B and 324B respectively. These seem quite large for what they do (total naive...
<re_irc>
... take so correct me if I'm wrong please). Does anyone have experience with avoiding these somehow?
<re_irc>
<denbo1977> So far I've been deploying binaries to my ST Nucleo board using arm-none-eabi-gdb and OpenOCD.
<re_irc>
Now I'd like to deploy for production. How does this work? I couldn't find this information anywhere
<re_irc>
< (@ryan-summers:matrix.org)> Have you used probe-rs before? It's a much more versatile tool than openOCD for flashing etc.
<re_irc>
<denbo1977> I've heard about it but never tried. Will look into it now. Thanks Ryan!
<re_irc>
< (@ryan-summers:matrix.org)> Also it supports gdb, and is really aiming to be an openOCD replacement :)
<re_irc>
<denbo1977> Sounds good. Currently getting an error about a permissions issue on macOS but I'll figure it out somehow :)
<re_irc>
< (@ryan-summers:matrix.org)> Do you have some other program currently using the probe? Could already be open elsewhere
<re_irc>
<denbo1977> Thank you, that's absolutely the solution 👍️
<re_irc>
OpenOCD was still running in another tab.
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has joined #rust-embedded
<re_irc>
<Ablu> Hi all! I am building a simple rust lib as staticlib with nostdlib for thumbv7m-none-eabi. I am then (attempting) to link that into a Zephyr app. It works if my code does not use anything that panics, but it fails linking with: "undefined reference to "core::panicking::panic'"once I mix in stuff that might panic. I do provide a"#[panic_handler]"(that just does"loop {}`, but it does not seem to generate symbols for panic...
<re_irc>
... (checked with readelf). Who/what is supposed to provide this symbol usually?
<re_irc>
<Ablu> : I tried panic-halt, but that yields in the same error. Will try to compare notes and see what I did different
<re_irc>
<Peter Hansen> FYI, I've been using panic_rtt_target until now, but I just tried removing it and sticking this in (shortened from that crate's own version) and it compiles fine:
<re_irc>
<Peter Hansen> maybe your function signature is wrong?
<re_irc>
<Ablu> Peter Hansen: I copy-pasted yours (even though my eyes told me that it was the same signature as mine) and the error persists.
<re_irc>
<Ablu> Do you also build as static_lib?
<re_irc>
<Peter Hansen> No.
<re_irc>
<Peter Hansen> That does sound like a key possible difference...
<re_irc>
<Peter Hansen> Can you try temporarily building as --bin to compare, so you know if that's definitely the cause? Or do you already basically know that?
<re_irc>
<Ablu> I will check... Need to clean out some mess that I introduced while trying... Will take a sec.
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
<Ablu> Peter Hansen: same... ```[package]
<re_irc>
22: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZN4core9panicking5panic17h1c603f743ecadb2cE
fooker has quit [*.net *.split]
fooker has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> Hey, who's teaching a class this semester with the micro bit?
<re_irc>
< (@jamesmunns:beeper.com)> I remember someone saying they were, and there's a couple of students (I think?) that have been asking questions about it lately