<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>
<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
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>
<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 (@9names:matrix.org)> 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 (@9names:matrix.org)> 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>
<9names (@9names:matrix.org)> 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 (@9names:matrix.org)> 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]
<re_irc>
Long ago I started support crates for Atmel/Microchip SAMATx70 (https://github.com/michalfita/atsams70-rust), 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>
<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> 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>
<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 build.rs
<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]