00:01 <re_irc> <yruama_lairba> yep, ADC and DAC are very close, and each time Dma transfert is half or full, i spawn a process task that process the half where ADC and DAC are not writing

00:02 <re_irc> <yruama_lairba> but if the process take too long, a collision can happen with ADC writting and DAC reading

00:02 <re_irc> <firefrommoonlight> Clever

00:03 <re_irc> <firefrommoonlight> Same thing with the 2x double-buffer approach

00:03 <re_irc> <firefrommoonlight> If the computation takes longer than it takes to fill half of the buffer, the sound get screwed up

00:04 <re_irc> <firefrommoonlight> In my use case, would happen if I got too greedy with the filters

00:08 <re_irc> <yruama_lairba> on thing i didn't tryed to use yet is a DMA feature allowing to swap half words. when using DMA with a 32bts long i2s channel, MSB and lSB are swapped

00:09 <re_irc> <yruama_lairba> bye

00:25 <re_irc> <firefrommoonlight> Oh weird

00:25 <re_irc> <firefrommoonlight> see ya!

14:27 <re_irc> <yruama_lairba> firefrommoonlight: no so weird, it's because how I2S hardware and DMA works. The I2S data register is 16 bits only, so when using an 32bits channel, you need to read twice the data register to get your 32 bits words. you first get the 16 MSB and then the 16 LSB.

14:30 <re_irc> <firefrommoonlight> Ah gotcha. I'm used to the 32-bit SAI regs

14:30 <re_irc> <yruama_lairba> and dma in direct mode can only write data sequentially. with the endiantness, it's swap MSB and LSB

14:30 <re_irc> <firefrommoonlight> Still a lot of bit-related things to be careful with. 2's complement 24-bit numbers without a rust i24 etc

14:32 <re_irc> <yruama_lairba> is there a way to have the equivelent functionnlity but for only one element ?

14:32 <re_irc> <yruama_lairba> heapless::spsc::Queue

14:33 <re_irc> <ryan-summers> Rust has native endian swapping tools

14:33 <re_irc> <yruama_lairba> i want a lockless way to communicate data across task. but having a queue more than 1 element is completly useless for my application

14:35 <re_irc> <yruama_lairba> ryan-summers: i know, but this is not an endian reverse issue

17:52 <re_irc> <yruama_lairba> wtf ? this doesn't work https://rtic.rs/1/book/en/by-example/resources.html?highlight=shared#only-shared---access

17:52 <re_irc> <yruama_lairba> i get this error "this implementation doesn't support shared ("&-") - exclusive ("&mut-") locks; use "x" instead of "&x""

17:53 <re_irc> <newam> yeah it's a work in progress as far as I know

17:53 <re_irc> <newam> Just lock it or use atomic data types

17:54 <re_irc> <yruama_lairba> how you can share atomic without lock ?

17:56 <re_irc> <newam> Atomics use atomic instructions, which means that hardware interrupt cannot read or store a partial value to the location.

17:56 <re_irc> <newam> * interrupts

17:57 <re_irc> <firefrommoonlight> Atomics are great. You can use them safely without any special management. Try to conbine operations where possible instead of just using store and load

17:57 <re_irc> <firefrommoonlight> However... While memory safe, they can still cause structural complication, as with all global vars

17:58 <re_irc> <newam> https://www.youtube.com/watch?v=rMGWeSjctlY

17:58 <re_irc> if you have a couple hours to kill that's a good in-depth overview of atomics and memory ordering

17:58 <re_irc> <newam> * video

17:58 <re_irc> <yruama_lairba> newam: that doesn't respond to my question, how i can sematically use atomic to share data across task without lock ?

17:58 <re_irc> <firefrommoonlight> So, you may still want to use a struct as an RTIC resource or w/e to keep your code more organized instead of firing off atomic ops from all over the code base

17:59 <re_irc> <firefrommoonlight> yruama_lairba: I don't understand the Q

17:59 <re_irc> <firefrommoonlight> By nature, atomics are safe without locking when used correctly

18:00 <re_irc> <firefrommoonlight> Although you can still get into synchronization trouble

18:00 <re_irc> <newam> yruama_lairba: You can share any atomic type (depends on the platform) across interrupts without locks

18:00 <re_irc> <newam> Atomics use atomic instructions, which means that you cannot read or store a partial value to the location.

18:00 <re_irc> <newam> Atomics use atomic instructions, which means that you cannot read or store a partial value

18:01 <re_irc> <firefrommoonlight> Also, I want a native Atomic enum. Please??

18:01 <re_irc> <newam> Any of these: https://doc.rust-lang.org/std/sync/atomic/#structs

18:01 <re_irc> Most micros don't have AtomicU64 though (and some don't even have atomics at all)

18:02 <re_irc> <firefrommoonlight> I think Cortex M0 doesn't have atomics, right?

18:03 <re_irc> <firefrommoonlight> So, Stm32 F0 and G0 for example

18:03 <re_irc> <newam> Yeah, no atomics on thumbv6 :(

18:04 <re_irc> <yruama_lairba> how i can do that in a task : "let sample = _cx.shared.sample.load(Ordering::Acquire);"

18:05 <re_irc> static SAMPLE: AtomicU32 = AtomicU32::new(0);

18:05 <re_irc> fn my_task() {

18:05 <re_irc> let sample = SAMPLE.load(Ordering::Acquire);

18:05 <re_irc> <newam> You make it a global static (which is safe with atomics), for example

18:05 <re_irc> }

18:08 <re_irc> <yruama_lairba> thank you

18:14 <re_irc> <firefrommoonlight> Check out the various methods in the rust docs like fetch-add, compare_exchange etc

18:14 <re_irc> <firefrommoonlight> They add conceptual overhead, but keep the operations... Atomic?

18:15 <re_irc> <firefrommoonlight> They are uniform, solid, hard, incompressible, and indestructible

18:17 <re_irc> <yruama_lairba> yep, but i guess atomic operation can have side effect on optimisation

18:18 <re_irc> <yruama_lairba> anyway, i was just curious, i think i need to be used to "Ordering" concept before really using Atomics

18:26 <re_irc> <firefrommoonlight> Any C++ mats you find will be relevant

18:27 <re_irc> <firefrommoonlight> You can go far by aping before the understanding arrives

19:43 <re_irc> <James Munns> Update, got "tracing-rs" working _mostly_ in a way that would allow us to use it on embedded (without using "json" as your serialization format). Definitely heavier than "defmt" (no interning), but might be interesting to some of y'all.

19:43 <re_irc> <James Munns> Right now I'm working on a sink that feeds to "bbqueue", but I'll probably make an RTT version of it too.

19:45 <re_irc> <James Munns> Where heavier means most non-trival messages are at least 100 bytes or so

23:55 <re_irc> <dirbaio> Just released "embedded-io" to crates.io. IO traits for no_std, embedded-hal style. Both blocking and async.

23:55 <re_irc> https://docs.rs/embedded-io/latest/embedded_io/

23:58 <re_irc> <dirbaio> * Comes in both blocking and async flavors.

23:58 <re_irc> <dirbaio> Implemented in Embassy HALs for UARTs, and in embassy-net for TCP