cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
<re_irc>
<@disasm-ewg:matrix.org> It seems that SNR of our WG emails is changing towards -inf
<re_irc>
<@disasm-ewg:matrix.org> I remember only a couple of non-spam emails sent to the riscv team mailbox
<re_irc>
<@therealprof:matrix.org> disasm: Indeed. Those mailing lists were disabled for a while and after enabling them again we exclusively receive spam. 🙄
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<re_irc>
<@hanno:braun-odw.eu> therealprof:matrix.org: By the way, I'm still getting emails sent to the HAL team. Do you know who I need to talk to about that?
crabbedhaloablut has joined #rust-embedded
edm_ is now known as edm
<re_irc>
<@therealprof:matrix.org> The infrastructure team. nastevens or ryankurte.
<re_irc>
<@gauteh:matrix.org> Hi. I am looking for examples of how to share e.g. a delay struct with my i2c implementation so that I can delay there. Is it common to put it somewhere globally available with interior mut?
<re_irc>
<@hargonix:matrix.org> Are you talking about an implementation of an I2C driver or an implementatin of I2C for some HAL?
<re_irc>
<@gauteh:matrix.org> implementing i2c for some hal
fabic has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> I think it's more common to just take ownership of the delay. Then, the user can make the delay shareable or not (e.g. similar in practice to `shared-bus`)
<re_irc>
<@gauteh:matrix.org> Ok
<re_irc>
<@tonygarnockjones:matrix.org> Hi all, is anyone else having trouble with `cross build` on nightly for aarch64-unknown-linux-musl in the last 2-3 days? It's a really recent thing, everything was fine until like yesterday.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@hanno:braun-odw.eu> therealprof:matrix.org: Thanks! Will get in touch.
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> gauteh:matrix.org: You probably want it in a `Mutex<RefCell<Option<Delay>>>`, or RTIC's shared variables, so it's available across interrupt contexts
<re_irc>
<@firefrommoonlight:matrix.org> Then your functions that use I2c will accept an `&mut Delay`
<re_irc>
<@firefrommoonlight:matrix.org> Or use a function to delay that has direct access to the `SYST` reg block or w/e you're using
<re_irc>
<@firefrommoonlight:matrix.org> *Missed this is for a HAL. If you don't mind me asking, what's the delay for?
<re_irc>
<@thejpster:matrix.org> It may be cleaner for the function to return a value indicating how long the caller should wait before calling the next function in the sequence, rather than having the driver use an imply Delay object to busy-wait the CPU. But i guess it depends on how critical the timing is and what else you are doing.
hosewiejacke has joined #rust-embedded
hosewiejacke has quit [Ping timeout: 252 seconds]
fabic has quit [Ping timeout: 245 seconds]
hosewiejacke has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> In general, I think small delays are fine in periph initialization functions. (Although I don't think I've ever had to). In something that gets called regularly or at arbitrary times... Avoid if at all possible
<re_irc>
<@firefrommoonlight:matrix.org> Then again, even in init they can cause trouble. Example: You set up a USB periph. You set up something else that has a ms-order delay. PC etc you have connected to USB connects, then immediately disconnects when the device fails to respond in time due to the delay
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
hosewiejacke has quit [Quit: Leaving]
<re_irc>
<@gauteh:matrix.org> firefrommoonlight:matrix.org: I could do that. The problem is that Delay holds onto `SYST`, presumably to prevent frequency changes. Could avoid that by re-checkig freq all the time. maybe that's ok.
<re_irc>
<@gauteh:matrix.org> firefrommoonlight:matrix.org: It's for blocking i2c, there's a hardware fifo that gets clocked out and need to wait for it
<re_irc>
<@gauteh:matrix.org> maybe there is no advantage to spinning for a bit rather than spinning and checking the register?
<re_irc>
<@theunkn0wn1:matrix.org> diondokter:matrix.org: Im gunna need to take you up on that.
<re_irc>
<@theunkn0wn1:matrix.org> It seems your low-level register API assumes that the "Address" is always an integer. This poses a problem for me when my device has different commands for different registers, and even different commands to get/set the same register.
<re_irc>
<@theunkn0wn1:matrix.org> Im not sure how to model this with your register macro; since it doesn't play nicely with enums being passed as addressies; so im not sure how im supposed to pass these distinctions down to the hardware interface
<re_irc>
<@firefrommoonlight:matrix.org> gauteh: I wouldn't handle this with 3 APIs: Interrupt-based, DMA-based, and polling/blocking
<re_irc>
<@firefrommoonlight:matrix.org> Ie not a hardware delay
<re_irc>
<@firefrommoonlight:matrix.org> Poll until the fifo is ready
<re_irc>
<@gauteh:matrix.org> Ok. Polling: Is there any advantage to looping without checking the register every time?
<re_irc>
<@xiretza:xiretza.xyz> what else would you do?
<re_irc>
<@gauteh:matrix.org> inner loop that just does a nop a couple of times before checking the register again.
<re_irc>
<@firefrommoonlight:matrix.org> No. You're blocking at full CPU speed in either case until the end-poll condition is met