crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@korken89:matrix.org)> : This is why infinite loops are forbidden in RTIC, is something goes wrong you have a never ending priority inversion
<re_irc>
< (@korken89:matrix.org)> * if
<re_irc>
< (@korken89:matrix.org)> The general approach is to somehow have timeout, either programmatically or watchdog
<re_irc>
< (@korken89:matrix.org)> Depending on your real time requirement
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
dequbed has quit [Read error: Connection reset by peer]
dequbed has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
starblue1 has quit [Ping timeout: 260 seconds]
emerent has quit [Ping timeout: 248 seconds]
starblue1 has joined #rust-embedded
DepthDeluxe has joined #rust-embedded
DepthDeluxe has quit [Read error: Connection reset by peer]
<cr1901>
if something goes wrong <-- can you elaborate?
jrgriffiniiieth[ has quit [Quit: You have been kicked for being idle]
<re_irc>
<rjmp> : this is a classic IIC problem. If the clk line is low, master must wait. Some controllers have a transfer timeout error. Some can disable clock stretching. Other wise the driver should have a timeout. Do you not have any pullups when the device is disconnected? Might solve the unplugged device issue to just pull up the line in that case so you quickly get an error from lack of an ack.
<re_irc>
< (@gauteh:matrix.org)> Hi. is f64::round supposed to be missing on thumv7em? and if so, are there any alternatives? micromath has one for f32
<re_irc>
< (@gauteh:matrix.org)> by the way, in perhaps amusing stories I've been using radians where I should have been using degrees for about 7 months now and a bunch of data is probably useless 🙄
<re_irc>
<rjmp> There's the libm crate
<re_irc>
< (@chemicstry:matrix.org)> : A lot of floating point functions are missing in core. I usually use https://docs.rs/libm/latest/libm/ which is supposed to be integrated into core eventually
<re_irc>
< (@chemicstry:matrix.org)> : you could probably do some math reverse-engineering and fix your broken data if the equations are not too exotic
<re_irc>
< (@gauteh:matrix.org)> No.. its gone through a Kalman-filter AHRS algorithm to rotate it to linear acceleration in north-east-down reference frame. Obviously really annoying, but not the end of the world as the instrument is still experimental
<re_irc>
< (@firefrommoonlight:matrix.org)> rjmp: It has HW PUs on SDA and SCL
<re_irc>
< (@firefrommoonlight:matrix.org)> I think the easy button here is to use DMA to the max extent practical, since there are no polling loops in that case
<re_irc>
< (@firefrommoonlight:matrix.org)> And you have control over when the results are collected via interrupt priorities, eg with RTIC
<re_irc>
< (@firefrommoonlight:matrix.org)> Although if you're say, only reading one byte, I don't know
<re_irc>
< (@chemicstry:matrix.org)> if we are talking about stm32 i2c, then DMA does not solve the problem either as there are a few condition checks before/after you initiate the DMA. Generating a start condition is one of them, where you have to wait before initiating DMA and it can get stuck if SCL is shorted to ground
<re_irc>
< (@chemicstry:matrix.org)> so far the only solution I've seen to work is having a timeout in HAL
<re_irc>
<James Zow> Translation helps me understand trust embedded system better, but I'm still inexperienced and I interested in hal.
starblue1 has quit [Ping timeout: 255 seconds]
<re_irc>
< (@firefrommoonlight:matrix.org)> : Interesting. I don't understand that, but with DMA, I can unplug, plug in etc sda, SCL, sensor power etc and it updates or doesn't update readings depending if the sensor is connected
<re_irc>
< (@firefrommoonlight:matrix.org)> Either the TC ISR fires and values update, or it doesn't fire
<re_irc>
< (@firefrommoonlight:matrix.org)> (A timer-based flag here would be good for setting the sensor in a failed state in software if readings aren't fresh.)
<re_irc>
< (@firefrommoonlight:matrix.org)> I'm not using that HAL
<re_irc>
< (@firefrommoonlight:matrix.org)> I'm following the RM recipe
<re_irc>
< (@firefrommoonlight:matrix.org)> There are no loops
<re_irc>
< (@chemicstry:matrix.org)> so you have a state machine inside your driver , which gets updated from IRQ handler? How are you handling things like start bit in status register, which you have to wait before starting DMA transfer?
<re_irc>
< (@chemicstry:matrix.org)> hmm, now that I look at RM and ST HAL code it seems that you don't need to wait for start bit for starting DMA transfer. I wonder why most of the Rust HALs do that though
<re_irc>
< (@dirbaio:matrix.org)> this is i2cv1 or i2cv2? they're very different
<re_irc>
< (@dirbaio:matrix.org)> f1, f2, f4, l1 are i2cv1
<re_irc>
< (@chemicstry:matrix.org)> So far I found that only F4 and H7 HALs implement DMA for I2C and both of them have busy wait for start condition
<re_irc>
< (@dirbaio:matrix.org)> odd
<re_irc>
< (@chemicstry:matrix.org)> ST doesn't have blockign wait in their F4 HAL, it just waits for error flag or transfer complete
<re_irc>
< (@chemicstry:matrix.org)> * blocking wait in their F4 HAL, it just starts DMA and
<re_irc>
< (@dirbaio:matrix.org)> guess we could remove it then
<re_irc>
< (@chemicstry:matrix.org)> did everyone copy pasted it from some wrong example? :D
<re_irc>
< (@dirbaio:matrix.org)> perhaps a separate wait is desirable if you want to timeout faster on bus stuck
<re_irc>
< (@dirbaio:matrix.org)> but otherwise.. probably not
starblue1 has joined #rust-embedded
<re_irc>
< (@firefrommoonlight:matrix.org)> : V2 I think. G4 and H7
<re_irc>
< (@firefrommoonlight:matrix.org)> Steps are set Txadmaen in I2C. (Turns out there is a poll in there until it sets). Configure a few I2C config settings (autoend, num bytes etc), then configure the DMA peripheral using standard DMA stuff like numdata, direction, register pointers etc. In write TC ISR, initiate a similar process but to read. In read TC ISR, handle data A/R
<re_irc>
< (@firefrommoonlight:matrix.org)> The I2C peripheral status flags are great for troubleshooting and fault detection, but you don't need to poll them
<re_irc>
< (@firefrommoonlight:matrix.org)> : No idea lol
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@firefrommoonlight:matrix.org)> *Of note, that multi-step process aboev is what I was trying to dodge in prototyping
<re_irc>
< (@firefrommoonlight:matrix.org)> Since you need to set up 2 ISRs, have one sequence the other, start the sequence elsewhere etc
<re_irc>
< (@firefrommoonlight:matrix.org)> As opposed to an "isr.write_read()" call
<re_irc>
< (@firefrommoonlight:matrix.org)> Since you need to set up 2 ISRs, safely share resources between them, have one sequence the other, start the sequence elsewhere etc
<re_irc>
< (@firefrommoonlight:matrix.org)> Since you need to set up 2 ISRs, safely share resources between them, set up static etc R and W buffs, have one sequence the other, start the sequence elsewhere etc
<re_irc>
< (@firefrommoonlight:matrix.org)> As opposed to an "i2c.write_read()" call
dc740 has quit [Remote host closed the connection]