ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <adamgreig> does anyone have any examples to hand of where load/store-only atomics are used in anger? i've got heapless' spsc and bbqueue's cm0 impl, but always hard to find end-application firmwares on github
<re_irc> <James Munns> I mean the simplest example I can think of is something like a tick counter
<re_irc> <James Munns> have one task writing a "tick counter", all other tasks read it atomically
<re_irc> <adamgreig> yea, but can you actually find anyone doing that?
<re_irc> <James Munns> I have... somewhere
<re_irc> <adamgreig> yea, same, I think...
<re_irc> <James Munns> I had a periodic task writing a 10ms tick or something?
<re_irc> <James Munns> I honestly have no idea where tho
<re_irc> <adamgreig> it's convenient that they provide interior mutability and so can be safely used as statics
<re_irc> <adamgreig> though I always feel a tiny bit uneasy about that, lol
<re_irc> <adamgreig> it would certainly be very very easy to introduce a data race
<re_irc> <James Munns> Generally only sound with a single writer
<re_irc> <adamgreig> yea, but usually in rust the type system enforces the single-writer property
<re_irc> <James Munns> I mean, "how could you use atomics w/ only load/stores" and "is that the best way to do X" are not the same question
<re_irc> <adamgreig> for sure
<re_irc> <James Munns> I mean yes
<re_irc> <James Munns> but that's not a single writer
<re_irc> <James Munns> I get it's not unsafe
<re_irc> <James Munns> but it's also not _wrong_.
<re_irc> <James Munns> Throw in a 'yield_now' to get the real fun numbers: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8f4b935c53b0af43af7c9a8590d8f72e
<re_irc> <adamgreig> yea, I think the answer there is that it's "a race", but not "a data race"
<re_irc> <James Munns> Don't get me wrong, it's definitely "footgun territory"
<re_irc> <James Munns> but like, so is a mutex deadlock
<re_irc> <adamgreig> anyway you see why I always feel a tiny bit uneasy, especially when any other way of sharing an int between contexts would require unsafe or a Mutex with a critical sectione tc
<re_irc> <adamgreig> * section etc
<re_irc> <adamgreig> like, I'm not saying it's some terrible bug in rust or whatever, just it's very easy to imagine someone making this mistake
<re_irc> <adamgreig> especially when all the other ways of sharing data are much more cumbersome/scary-sounding...
<re_irc> <adamgreig> (the answer is to use rtic of course :D)
<re_irc> <James Munns> still cortex-m only
<re_irc> <James Munns> so doesn't help msp430 or risc-v
<re_irc> <adamgreig> 💀
<re_irc> <James Munns> and if people are going to keep putting out cores without atomics in the year of our silicon 2022
<re_irc> <James Munns> I'll just have to keep being sad
<re_irc> <adamgreig> how much silicon could an exclusive monitor really have taken, huh
<re_irc> <9names (@9names:matrix.org)> James Munns: and cores with broken atomics, like bl602
<re_irc> <adamgreig> wonder if you can do the risc-v trick of trapping on atomic instructions and emulating them, on the rp2040
<re_irc> <James Munns> probably in some specific way that will not be suitable for everyone :p
<re_irc> <9names (@9names:matrix.org)> afaik the trap will be core-specific? how do you sync across cores?
<re_irc> <adamgreig> on rp2040 there's the hardware spinlocks and fifo, iirc one option is you message the other core, triggering an interrupt on that core which eventually messages back saying "ok i'm in a critical section now", then your core does its thing, then it messages the other core to release it
<re_irc> <adamgreig> dpeending on whatyou're doing maybe you can just use the spinlocks directly, either core can lock/unlock them
<re_irc> <adamgreig> the real problem is how you'd convince the compiler to emit ldrex/strex instructions for a armv6-m target :P
<re_irc> <9names (@9names:matrix.org)> the only advantage this has over disabling interrupts is that C code with atomics works as expected. maybe that's enough to justify the perf impact on the esp side.
<re_irc> <James Munns> adamgreig: Honestly, probably just use the thumbv7m target
<re_irc> <adamgreig> and emulate the other missing instructions while you're at it?
<re_irc> <James Munns> but I guess M3 has a bunch of other extra stuff
<re_irc> <James Munns> yeah
<re_irc> <James Munns> :p
<re_irc> <adamgreig> brutal
<re_irc> <adamgreig> i love it
<re_irc> <adamgreig> the rp2040 is smoking fast, it could pretend to be a pretty fast cortex-m3 i'm sure
<re_irc> <adamgreig> someone surely has already done this
<re_irc> <James Munns> I mean I see all kinds of like z80 emus and stuff
<re_irc> <James Munns> it's probably a pretty fast z80/6501 when it wants to be :p
<re_irc> <9names (@9names:matrix.org)> you spelt 8051 wrong :P
<re_irc> <James Munns> with two cores, why not get the whole gang together!
<re_irc> <James Munns> it can be a mips processor too
<re_irc> <adamgreig> hmm boo, I don't think you can do this
<cr1901> >the real problem is how you'd convince the compiler to emit ldrex/strex instructions for a armv6-m target :P rp2040 is an "armv6 cpu that tolerates some armv7 insns"?
<re_irc> <James Munns> (he's trying to trap the invalid instruction fault, I assume)
<cr1901> ahhh
<re_irc> <9names (@9names:matrix.org)> i should probably apportion blame better here. the core supports atomics just fine, there's just no support for atomics in the memory bus so all atomic instructions yield faults as per riscv spec
<re_irc> <adamgreig> on armv6 there's no invalid instruction fault, all faults are HardFault, and there's no fault status register either, in fact no way to know what sort of hard fault
<re_irc> <James Munns> lolol
<re_irc> <adamgreig> you _can_ read the PC to find what instruction you were trying to run, though
<re_irc> <adamgreig> and you _may_ resume execution from HardFault
<re_irc> <James Munns> yeeeeeeeaaaaahhhhh
<re_irc> <James Munns> trap ad rewiiiind
<re_irc> <James Munns> * and
<re_irc> <adamgreig> so I guess check the PC and if it was an emulated instruction, hope the fault was because of the illegal instruction and not literally anything else
<cr1901> there's just no support for atomics in the memory bus so all atomic instructions yield faults as per riscv spec <-- the CPU core bus "this is an atomic load/store" signal onto the memory bus, and the memory bus auto-fails the xfer?
<cr1901> (but the core itself would handle atomics correctly if the memory bus didn't fail the xfer?)
<re_irc> <9names (@9names:matrix.org)> correct
<cr1901> So... is this treated as a "rv32ia" core or "rv32i" core then from Rust's POV :)?
<cr1901> Because the A is implemented, but it's not functional :P
<cr1901> (through no fault of the core's own)
<cr1901> (And also, which fault is it supposed to yield? I memory-holed the privileged spec tbh)
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
<re_irc> <9names (@9names:matrix.org)> i now treat it as rv32imfc, as the official C SDK does.
<re_irc> Can't find the specific part (maybe in priv spec, everything around it seems very vague) but it's a property of the PMP. it yields AMO access fault.
<re_irc> the spec only talks about this with regards to unaligned atomic accesses though, so maybe i'm getting my wires crossed.
<cr1901> Well maybe it's allow to trigger for aligned access too if the memory bus doesn't support it? Just thinking out loud
<re_irc> <9names (@9names:matrix.org)> the privileged spec seems more clear about this, section 3.6 (and 3.6.3.1 specifically), but it's still not that prescriptive tbh
agg has quit [*.net *.split]
agg has joined #rust-embedded
sknebel has quit [*.net *.split]
sknebel has joined #rust-embedded
<re_irc> <luojia65> If anyone is interested I'm working on a peripheral access crate which is officially provided by chip's company, it would include features C language SDK does not provide
<re_irc> <luojia65> this chip will come into public soon, it's not released yet
<re_irc> <ub|k> Has this been posted here yet? https://github.com/nviennot/stm32-emulator
Amadiro has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 255 seconds]
<re_irc> <yruama_lairba> Hi, who knows about "PCM","DSP" and "TDM" serial audio protocol ? it' seems there is some equivalence between, but i'm really confused with "PCM" implementation of stm32 SPI/I2S peripheral
<re_irc> <yruama_lairba> ideally, i'd like to have an another source describing "PCM" protocol
<re_irc> <chrysn (@chrysn:matrix.org)> yruama_lairba: On an overview level, https://en.wikipedia.org/wiki/I%C2%B2S describes the PCM protocol used by I2S
<re_irc> <yruama_lairba> chrysn, this doesn't help me, this describe the I²S protocol wich deosn't correpond to stm32 "PCM"
<re_irc> <9names (@9names:matrix.org)> sorry, is your question about what PCM is, or about how to use PCM with the SPI/I2S peripheral?
<re_irc> <yruama_lairba> 9names: yes i should reword, i'm trying to know how is supposed to work PCM mode of SPI/I2S peripheral
<re_irc> <yruama_lairba> for that reason, i'd like to know if there is a codec using similar protocol
<re_irc> <yruama_lairba> i found "DSP" and "TDM" that seems to be close, but i don't if it's can be compatible and circumstance
<re_irc> - "PCM" is actually monophonic and correspond to TDM/DSP protocol with one channel
<re_irc> <yruama_lairba> in fact, i'm currently suspect 2 things :
<re_irc> <yruama_lairba> ooops
<re_irc> <yruama_lairba> in fact, i'm currently suspect 2 things :
<re_irc> - "PCM" is supposed to be equivalent of a 2 channel TDM/DSP protocol, but they did it wrong
<re_irc> - "PCM" is actually monophonic and correspond to TDM/DSP protocol with one channel
<re_irc> <firefrommoonlight> 9names: DSP: Digital Signal Processing. General term for modifying signals using a computer. Is often associated with discrete, time-domain signals
<re_irc> PCM: Discrete representation of a signal by using numbers proportional to amplitude. Ie higher amplitude = higher number
<re_irc> I2S: A subset of TDM with exactly 2 signals, and certain specific properties
<re_irc> TDM: Interleave multiple discrete signals in a a single data stream
<re_irc> <firefrommoonlight> * number. An alternative is PDM, wherein amplitude is represented by pulse density
causal has joined #rust-embedded
<re_irc> <firefrommoonlight> For DSP, check out the CMSIS-DSP FFI port if on Arm. For converting to PCM from PDM, look at the stm32 DFSDM peripheral, or do it in software. For TDM, including I2S, use the stm32 SAI peripheral
<re_irc> <firefrommoonlight> +peripheral. If on an older one, use the SPI/I2S
<re_irc> [-1, -.7, 0, 07, 1, .7, 0, -.7, -1]
<re_irc> <firefrommoonlight> For example, you might crudely represent a sign wave like this in PCM:
<re_irc> <firefrommoonlight> * .7,
<re_irc> <firefrommoonlight> If you were interleaving random noise with that same signal, you could use PCM (Maybe I2S specifically):
<re_irc> [-1, 100., -.7, -20., 0, 828., .7, 200., 1., 909., .7, 42., 0, 69., -.7, 0.11, -1, 10.]
<re_irc> <firefrommoonlight> There are some subtleties re how your signal points pair with the clock signal, with a number of valid configs that mainly depend on the devices communicating being on the same page
<re_irc> <firefrommoonlight> If you were interleaving random noise with that same signal, you could use TDM (Maybe I2S specifically):
<re_irc> [-1, 100., -.7, -20., 0, 828., .7, 200., 1., 909., .7, 42., 0, 69., -.7, 0.11, -1, 10.]
dc740 has joined #rust-embedded
<re_irc> <yruama_lairba> firefrommoonlight: you completly miss the context. In my particular context "PCM", "DSP" ,"TDM" refer to different protocol (or protocol variant) for serial transmission of audio data
<re_irc> <yruama_lairba> in particular stm32 SPI in i2s mode have a i2s standard called "PCM" that is, in my opinion,very poorly documented
<re_irc> <Chris [pwnOrbitals]> Is it possible to compile position-independent code for ARM (cortex m7) ?
<re_irc> <dirbaio> Chris [pwnOrbitals]: nope, it's bugged https://github.com/rust-lang/rust/issues/54431
<re_irc> <Chris [pwnOrbitals]> noooooooooooooooooooo
<re_irc> <yruama_lairba> for information, i found "DSP" terminology in wolfson chip. it's seems to be equivelent to a "TDM" protocol with 2 channel
rardiol has joined #rust-embedded
<re_irc> <firefrommoonlight> yruama_lairba: I encourage you to re-evaluate this statement
<re_irc> <yruama_lairba> firefrommoonlight: after reading again the discussion, i realize my initiale question about "PCM" is confuse because of what PCM is is general so 9names may asked for disambiguation
rardiol has quit [Ping timeout: 245 seconds]
Foxyloxy has quit [Ping timeout: 272 seconds]
Foxyloxy has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<re_irc> <chrysn (@chrysn:matrix.org)> It's awesome that there is now embedded-nal-async in the same spirit (as in "parts of the README are copy-pasted") as embedded-hal-async.
<re_irc> <chrysn (@chrysn:matrix.org)> Has there been any progress on the topic of writing middleware components on embedded-hal-async & co once and getting both an "nb" and an "async" version from it?
bjoto has quit [Ping timeout: 244 seconds]
bjoto has joined #rust-embedded