ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <ryankurte> GrantM11235: often you need a setup time too, but you can jam that in the transaction closure
<re_irc> <ryankurte> GrantM11235: you've also gotta be able twiddle pins, often devices want things like: assert CS -> write CMD -> await BUSY/IRQ -> read DATA -> deassert CS
agg has quit [Ping timeout: 250 seconds]
<re_irc> <ryankurte> so there are always going to be errors to be smuggled out
<re_irc> <ryankurte> (and timeouts on the await BUSY, a hard learned lesson lol)
<re_irc> <dirbaio> oh yeah
agg has joined #rust-embedded
<re_irc> <dirbaio> I guess it's better to do "FnOnce(Bus) -> T" then?
<re_irc> <dirbaio> instead of "FnOnce(Bus) -> Result<T, Bus::Error>"
<re_irc> <dirbaio> I'm trying to write a driver doing error handling properly (no unwrap)
<re_irc> <dirbaio> and it's... a bit cursed
<re_irc> <dirbaio> it's cursed either way
<re_irc> <GrantM11235> Speaking of error handling, I have some concerns about the implementation of ExclusiveDevice
<re_irc> <dirbaio> I _think_ this might be better
<re_irc> <dirbaio> * the better option
<re_irc> <GrantM11235> What about "Result<T, E>"? Perhaps with some kind of bounds on "E"
<re_irc> <dirbaio> for starters, one problem is the Bus error and the Device error are different types
<re_irc> <dirbaio> so your driver's error enum needs to be something like this:
<re_irc> enum Enc28j60Error<SPI>
<re_irc> where
<re_irc> SPI: SpiDevice,
<re_irc> <dirbaio> and I have no idea why that's ambiguous
<re_irc> <dirbaio> but either way it's ugly to have 2 errors, it should be just one
<re_irc> <dirbaio> if we do "FnOnce(Bus) -> Result<T, Bus::Error>", then the SpiDevice impl will convert the errors from SpiBus::Error to SpiDevice::Error automatically, so drivers only have to deal with SpiDevice::Error
<re_irc> <dirbaio> but still, wtf why is that ambiguous
<re_irc> <dirbaio> rust bug, lol
<re_irc> <dirbaio> end result looks like this
<re_irc> enum Enc28j60Error<SPI>
<re_irc> SPI: SpiDevice,
<re_irc> where
<re_irc> <dirbaio> vs with the closure returning the result, it looks like this
<re_irc> <dirbaio> enum Enc28j60Error<SPI> {
<re_irc> }
<re_irc> Spi(SPI),
<re_irc> struct Enc28j60<SPI> {
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901_ has quit [Remote host closed the connection]
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <korken89> Has anyone tried running programs in run with "probe-run"?
<re_irc> I get an error that it tries to set a breakpoint in RAM, where it should just replace the address with a breakpoint instruction directly in RAM.
<re_irc> <korken89> However I am unable to find how to tell "probe-run" how to do this
<re_irc> <jannic> I had similar issues in the past,, but I didn't find a solution.
<re_irc> <korken89> Hmm :/
<re_irc> <korken89> Maybe dirbaio has run into this before, you seem to run a lot of stuff in RAM? :)
<re_irc> <korken89> This here seems to be the issue
<re_irc> <korken89> This should be changed so that if the target is running from RAM the address should be overwritten with a breakpoint instruction instead of using the breakpoint hardware
<re_irc> <9names (> i thought setting a HW breakpoint in RAM was okay? what is the error?
<re_irc> <korken89> Error: A core architecture specific error occured
<re_irc> Caused by:
<re_irc> Unsupported address 0x200004bc for HW breakpoint. Breakpoint must be at address < 0x2000_0000.
<re_irc> <korken89> 9names: ^
<re_irc> <9names (> oh, it's not a RAM specific problem but the HW only allows breakpoints in that range!
<re_irc> today i learned!
<re_irc> <korken89> Seems like it
<re_irc> <korken89> Ah they set breakpoints on main as well
<re_irc> <korken89> That one also fails
<re_irc> <korken89> So it's not supported
<re_irc> <9names (> yeah. breakpoints only in data memory mapping, 0x0 to 0x1FFF_FFFF inclusive.
<re_irc> the breakpoint registers only have 27bits to describe the target location, if you shift that left twice (breakpoints on 4 byte entries) you're left with 0x2000_0000
<re_irc> <9names (> i just realised that the addresses in the breakpoint register are actually not shifted, the lower two bits are used for other purposes. clever!
<re_irc> <korken89> What needs to happen here is to support "software breakpoints"
<re_irc> <korken89> You read out the instruction, write in a breakpoint, after BP you write the original instruction back
<re_irc> <korken89> +and run
<Darius> you have to emulate the instruction too..
<re_irc> <korken89> Nah
<re_irc> <korken89> Just move PC back one step
<Darius> hmm guess so
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
cr1901 has quit [Client Quit]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Client Quit]
cr1901 has joined #rust-embedded
Guest2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 250 seconds]
<re_irc> <Michał Fita> Hello (,
<re_irc> Long ago I started support crates for Atmel/Microchip SAMATx70 (, but never had time to carry on. But recently someone reached me offering some funds get some pieces of it working plus some extra work to do on SAME70 for a prospective IoT device. I agreed to ask around if some could be interested on picking up such contract work. Anyone interested?
* cr1901 is tempted
<cr1901> Michal Fita: In better circumstances, I would say I'm interested. Was this an email convo of someone reaching out?
<re_irc> <Michał Fita> cr1901: The person contacted me making small donation and I have their details on LinkedIn. They want to code a lightning controller on that MCU as it's the only one found within budget with SPI available at the moment due to chips shortage. Anyone interested can drop me LinkedIn profile and I pass it to that gentleman to contact you with the offer.
<cr1901> Oh dear, I haven't kept that up to date. But tyvm for the info
<cr1901> (it == LinkedIn)
<re_irc> <James Munns> Michał Fita: I might be interested! Feel free to DM me w/details :)
<re_irc> <dalepsmith> Michał Fita: "lightning controller" -> "lighting controller" ?
<re_irc> <Michał Fita> * lighting
<re_irc> <Michał Fita> James Munns: Hopefully DM works, as I had issues with encryption keys...
<re_irc> <dirbaio> korken89: it's not supported at all by probe-run. I have it working here manually:
<re_irc> tldr:
<re_irc> - Boot by manually setting initial PC, SP
<re_irc> - Overwrite hardfault handler with a BKPT instruction instead of setting a HW breakpoint
<re_irc> - Set VTOR
<re_irc> <korken89> I came to the same conclusion
<re_irc> <korken89> Talked a bit to Noah, implementing SW breakpoints should not be that hard in probe-rs
<re_irc> <dirbaio> cortex-m supports a "vector catch" thing to break on hardfault
<re_irc> <dirbaio> it'd work independently of running from ram/flash, and without hw breakpoint support
<re_irc> <dirbaio> I don't know why probe-run doesn't use it
<re_irc> <korken89> They break on main as well
<re_irc> <dirbaio> yeah, that's to guarantee they set RTT to blocking before main starts to run
<re_irc> <dirbaio> which only works with defmt-rtt (it initializes RTT before main, as part of the .data init)
<re_irc> <dirbaio> and fails with rtt-target
<re_irc> <dirbaio> * rtt-target, because it initializes it after main
<re_irc> <Noah> how would we initialize before main? would require linkerscript fuckery, no?
<re_irc> <dirbaio> cortex-m-rt initializes it when copying .data from flash to ram
<re_irc> <adamgreig> oh, i assumed probe-run did use it.. it sets a hardware breakpoint on hardfault?
<re_irc> <dirbaio> yep, hw breakpoint
<re_irc> <adamgreig> huh
<re_irc> <adamgreig> vector catch seems neater
<re_irc> <dirbaio> is it available in all cortex-m's?
<re_irc> <adamgreig> are hardware bps?
<re_irc> <adamgreig> on armv6 is the debug extension is implemented then it always supports vector catch
<re_irc> <dirbaio> sounds like vector catch should be strictly more widely available then :P
<re_irc> <adamgreig> i don't think debug extension is optional on armv7, and also always has vector catch
<re_irc> <adamgreig> it's allowed for armv6 BPU to not have any breakpoint comparators
<re_irc> <adamgreig> so yea, vector catch is strictly more available
Guest2 has quit [Quit: Client closed]
gsalazar has quit [Ping timeout: 272 seconds]
jackneill has joined #rust-embedded
jackneilll has quit [Ping timeout: 240 seconds]
<re_irc> <Mehmet Ali> I would like to ask something really basic.
<re_irc> I have an driver which I want to return bytes 1..n of the array that it feeds to the SPI.
<re_irc> I want to return a [u8;7], but [1..7] is a slice.
<re_irc> Is there a zero cost way to return a [u8;7] from a slice?
<re_irc> <Mehmet Ali> In particular in embedded targets.
<re_irc> <dirbaio> let x: [u8;7] = my_slice[1..8].try_into().unwrap()
<re_irc> <dirbaio> that unwrap is guaranteed to not fail if the length matches
<re_irc> <dirbaio> and yes, that'll copy the 7 bytes, but 7 bytes is tiny, I wouldn't worry about it
<re_irc> <Mehmet Ali> There might be a chance that this is called numerous times consecutively, (It drains a buffer 7 bytes at a time)
<re_irc> <Mehmet Ali> Is there a better return signature that I could have thought of?
<re_irc> <dirbaio> a slice is already 8 bytes (ptr+len)
<re_irc> <dirbaio> you could return a "&[u8;7]" which is only 4 bytes, but the caller having to access it through the pointer is not free either
<re_irc> <dirbaio> it seems like premature optimization
<re_irc> <Mehmet Ali> Oh, the dereference.
<re_irc> <dirbaio> just return a "[u8;7]" and let the compiler optimize
<re_irc> <Mehmet Ali> Thanks for being explicit.
<re_irc> <firefrommoonlight> How do y'all usually do exponents? The "num_traits" crate?
<re_irc> <dirbaio> what's "do exponents"?
<re_irc> <dirbaio> pow?
<re_irc> <firefrommoonlight> yea
<re_irc> <firefrommoonlight> The compiler is very explicitly directing me to use "num_traits"
<re_irc> <firefrommoonlight> Maybe I should j ust do that lol?
<re_irc> <firefrommoonlight> "error[E0599]: no method named "pow"found for type"f32" in the current scope"
<re_irc> <dirbaio> std has it
<re_irc> <dirbaio> "powf" for floats
<re_irc> <firefrommoonlight> = help: items from traits can only be used if the trait is in scope
<re_irc> |
<re_irc> help: the following trait is implemented but not in scope; perhaps add a `use` for it:
<re_irc> 19 | use num_traits::pow::Pow;
<re_irc> <firefrommoonlight> but perhaps not "core"?
<re_irc> <firefrommoonlight> Oh....
<re_irc> <firefrommoonlight> Maybe that's it
<re_irc> <firefrommoonlight> Hmm, no "powf" either. Also recommending num_traits
<re_irc> <Mehmet Ali> does this have it?
<re_irc> <Mehmet Ali> it returns approximations though.
<re_irc> <dirbaio> wow core has pow but not powf, wtf?
<re_irc> <firefrommoonlight> Since I'm just squaring for now, and don't want to bring in another dep just for this:
<re_irc> }
<re_irc> fn sq(val: f32) -> f32 {
<re_irc> val * val
<re_irc> <firefrommoonlight> and use cmsis-dsp for sqrt
<re_irc> <dirbaio> "val*val" will be much faster than "val.powf(2.0)"
<re_irc> <firefrommoonlight> Oh nice. The compiler wouldn't optimize it?
<re_irc> <firefrommoonlight> That's the sort of thing I'd hope the compiler would optimize
<re_irc> <jkelleyrtp> Is it possible to make to TWIM interfaces from the same pins? I am trying to read from an accelerometer and a gyro on the same i2c line but TWIM doesn't implement Clone/Copy
<re_irc> <jkelleyrtp> * two
<re_irc> <dirbaio> hmm it might not, there might be rounding issues or NaN/inf issues so theyre not exactly equivalent? id
<re_irc> <dirbaio> * idk
<re_irc> <dirbaio> jkelleyrtp: use shared-bus
<re_irc> <firefrommoonlight> Ok, going with thsis:
<re_irc> fn sq(val: f32) -> f32 {
<re_irc> /// Square a number.
<re_irc> val * val
<re_irc> <dirbaio> also if you want "float ^ integer" you can probably get it faster than powf using the integer fast exponentiation thing
<re_irc> <firefrommoonlight> (CMSIS's native sqrt returns an error code if input is negative, so uses the awk in place mutation, when I want input/output, hence the wrapper)
<re_irc> <dirbaio> gotta love C:D
<re_irc> <dirbaio> * C :D
<re_irc> <firefrommoonlight> Yea, Rust's "Result" type is nicer than using integer codes
<re_irc> <dirbaio> yeeep! and prevents you from accessing the result if it failed :D
<re_irc> <firefrommoonlight> The idiomatic wrapping would return "Result", but I'm just going to make sure I don't put in negative inputs for now
<re_irc> <dirbaio> wow, "x.powf(2.0)" does optimize to "x*x"
<re_irc> <dirbaio> "x.powf(3.0)" does not optimize to "x*x*x", neither do higher exponents
<re_irc> <dirbaio> huh
Rahix has quit [Quit: ZNC -]
Rahix has joined #rust-embedded
<re_irc> <firefrommoonlight> neat
<re_irc> <chemicstry> Is there a way to get endianness of the building platform and not the target? I want to use "u64::from_ne_bytes()" in a const fn, but it selects endianness of the target platform via "target_endian". I guess it would be possible to make a simple const fn that determines endianness of the build platform, but maybe there is some other standard way?
<re_irc> <dirbaio> do it in
<re_irc> <dirbaio> then pass it to the main code via cfg's for example
<re_irc> <dirbaio> but it's such a weird thing to do
<re_irc> <dirbaio> * do, why do you want to do that?
<re_irc> <chemicstry> I need to convert git commit hash to u64
<re_irc> <chemicstry> (part of it)
<re_irc> <dirbaio> it seems less troublesome to treat it as a "[u8;8]"
<re_irc> <dirbaio> +instead
<re_irc> <chemicstry> maybe you're right, I am dealing with some old code, but I guess I could just use "[u8; 8]" on my side
SanchayanMaity has quit [Ping timeout: 240 seconds]
SanchayanMaity has joined #rust-embedded
jackneill has quit [Remote host closed the connection]
jackneill has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded