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
ugabbel[m] has joined #rust-embedded
ugabbel[m] has left #rust-embedded [#rust-embedded]
IlPalazzo-ojiis1 has quit [Remote host closed the connection]
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
lehmrob has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 255 seconds]
lehmrob has quit [Ping timeout: 268 seconds]
Amanieu has quit [*.net *.split]
Ekho has quit [*.net *.split]
sknebel has quit [*.net *.split]
sknebel has joined #rust-embedded
Ekho has joined #rust-embedded
Amanieu has joined #rust-embedded
lehmrob has joined #rust-embedded
fabic_ has quit [Ping timeout: 256 seconds]
fabic_ has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
fabic_ has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
fabic_ has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
<re_irc> <@n8tlarsen:matrix.org> Hi everyone! I'm working on Rust firmware for a project which has historically been written in C/C++. The MCU doesn't have a HAL but does have a PAC. I've been working on generic peripheral functions but I'm not sure of the best way to structure them. The PAC source (https://github.com/n8tlarsen/efm32tg-pacs/tree/emf32tg11b120_derives/pacs/efm32tg11b/src/efm32tg11b120) has several timer modules all derived from...
<re_irc> ... "wtimer0". The following code compiles but I'm not sure if it's the best way to implement it:
<re_irc> <@yatekii:matrix.org> : I got rtt-target transferred :) Do you have an interest of maintaining it or should I take care of it?
<re_irc> <@n8tlarsen:matrix.org> Hi everyone! I'm working on Rust firmware for a project which has historically been written in C/C++. The MCU doesn't have a HAL but does have a PAC. I've been working on generic peripheral functions but I'm not sure of the best way to structure them. The PAC source (https://github.com/n8tlarsen/efm32tg-pacs/tree/emf32tg11b120_derives/pacs/efm32tg11b/src/efm32tg11b120) has several timer modules all derived from...
<re_irc> pub trait TimerCounter {
<re_irc> ... "wtimer0". The following code compiles but I'm not sure if it's the best way to implement it:
<re_irc> + 9 │ fn ptr() -> *const pac::wtimer0::RegisterBlock;
<re_irc> + 7
<re_irc> + 8 }
<re_irc> + 6 impl TimerCounter for pac::WTIMER1 {
<re_irc> + 5 │ #[inline(always)]
<re_irc> + 4 │ fn ptr() -> *const pac::wtimer0::RegisterBlock {pac::WTIMER1::ptr()
<re_irc> }
<re_irc> }
<re_irc> pub fn start_timer<TC>(_tc: &mut TC) where TC: TimerCounter {
<re_irc> let tim = unsafe { &*TC::ptr() }; => &RegisterBlock
<re_irc> tim.ctrl.write(|w| w.presc().div32()); => &mut W
<re_irc> tim.top => Reg<TOP_SPEC>
<re_irc> .write(|w| unsafe { w.bits((clock::HFCLK_FREQ / 32) - 1) }); => &mut W
<re_irc> tim.ifc.write(|w| w.of().set_bit()); => &mut W
<re_irc> tim.ien.write(|w| w.of().set_bit()); => &mut W
<re_irc> tim.cmd.write(|w| w.start().set_bit()); => &mut W
<re_irc> }
<re_irc> <@n8tlarsen:matrix.org> Hi everyone! I'm working on Rust firmware for a project which has historically been written in C/C++. The MCU doesn't have a HAL but does have a PAC. I've been working on generic peripheral functions but I'm not sure of the best way to structure them. The PAC source (https://github.com/n8tlarsen/efm32tg-pacs/tree/emf32tg11b120_derives/pacs/efm32tg11b/src/efm32tg11b120) has several timer modules all derived from...
<re_irc> ... "wtimer0". The following code compiles but I'm not sure if it's the best way to implement it:
<re_irc> fn ptr() -> *const pac::wtimer0::RegisterBlock;
<re_irc> impl TimerCounter for pac::WTIMER1 {
<re_irc> }
<re_irc> pub trait TimerCounter {
<re_irc> #[inline(always)]
<re_irc> fn ptr() -> *const pac::wtimer0::RegisterBlock {
<re_irc> pac::WTIMER1::ptr()
<re_irc> }
<re_irc> }
<re_irc> pub fn start_timer<TC>(_tc: &mut TC) where TC: TimerCounter {
<re_irc> let tim = unsafe { &*TC::ptr() }; => &RegisterBlock
<re_irc> tim.ctrl.write(|w| w.presc().div32()); => &mut W
<re_irc> tim.top => Reg<TOP_SPEC>
<re_irc> .write(|w| unsafe { w.bits((clock::HFCLK_FREQ / 32) - 1) }); => &mut W
<re_irc> tim.ifc.write(|w| w.of().set_bit()); => &mut W
<re_irc> tim.ien.write(|w| w.of().set_bit()); => &mut W
<re_irc> tim.cmd.write(|w| w.start().set_bit()); => &mut W
<re_irc> }
<re_irc> <@adamgreig:matrix.org> Can it use critical-section so it doesn't need the cortex-m feature flag :o
<re_irc> <@dirbaio:matrix.org> yes. I sent a PR a while ago
<re_irc> <@dirbaio:matrix.org> https://github.com/probe-rs/rtt-target/pull/28
<re_irc> <@dirbaio:matrix.org> +19, -133 :D
<re_irc> <@yatekii:matrix.org> i will take a look at all of them in a bit
<re_irc> <@yatekii:matrix.org> if anyone wants to help me review, more than welcome :)
<re_irc> <@almindor:matrix.org> i'm looking at updating e310x PAC crate for latest riscv, and using svd2rust (v0.19, for some reason using latest breaks the code) everything looks good except it overrides "build.rs" with a completely different setup which now points to "device.x" (we used different names before). Is this something that's expected to be standardized upon?
<re_irc> <@halfbit:matrix.org> anyone trying rust on all the bl808 cores?
<re_irc> <@halfbit:matrix.org> they have a pac now I saw, kind of cool
<re_irc> <@halfbit:matrix.org> for $8 the ox64 is... crazy cheap
<re_irc> <@almindor:matrix.org> I'm going over svd2rust docs to try and decipher all the little nits, could someone explain what "If using the --generic_mod option, the emitted generic.rs needs to be moved to src" is all about? What's the generic.rs for and why all the fuss about it?
<re_irc> <@almindor:matrix.org> i especially like the changelog entry of "Make generic.rs generic" :D
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@jobroe:tchncs.de> Hi, i startet with the pico w and the cyw43 example. I would like implement a simple POST request and therefore I'm looking for a http crate to build https request. I found httparse but as the name says it seems to be only for the parsing. Or I'm wrong ? Any other suggestion ?
fabic_ has quit [Ping timeout: 248 seconds]
<re_irc> <@jobroe:tchncs.de> Yes this example I already found, but it is the server side
<re_irc> <@dirbaio:matrix.org> ah!
<re_irc> <@dirbaio:matrix.org> there's https://github.com/drogue-iot/reqwless
<re_irc> <@lulf_:matrix.org> : there is an example with cyw43 + embassy + reqwless here https://github.com/drogue-iot/drogue-device/tree/main/examples/rp2040/pico-w/app
<re_irc> <@jobroe:tchncs.de> nice, thanks!
<re_irc> <@admin:orangemurker.com> Is it safe to use Relaxed ordering for atomic operations on a single core Cortex-M4 platform?
<re_irc> <@dirbaio:matrix.org> the hardware doesn't reorder memory accesses
<re_irc> <@dirbaio:matrix.org> but the compiler still can
<re_irc> <@admin:orangemurker.com> : Oh. True
<re_irc> <@dirbaio:matrix.org> so it's the same as any other target
<re_irc> <@admin:orangemurker.com> Gotcha. Thanks
<re_irc> <@dirbaio:matrix.org> so you still need the right ordering if you're using atomics to synchronize _other_ memory locations
<re_irc> <@dirbaio:matrix.org> while if you're using the atomic as a "standalone global variable" then Relaxed should be fine
<re_irc> <@admin:orangemurker.com> : I am using them as global variables but the behaviour of the program depends on the value of some atomics to set the value of other atomics so I think that it may matter for my use case.
<re_irc> <@yatekii:matrix.org> : hmm what happens if the core has atomics? are they used to emulate the CS or does it actually disable interrupts?
<re_irc> <@dirbaio:matrix.org> the CS is only used for the global "print channel"
<re_irc> <@dirbaio:matrix.org> so that you can "rprintln!" from anywhere without having to pass the channel around
<re_irc> <@dirbaio:matrix.org> when directly using a channel, hanks to it being owned and you having to pass it around, there's no CS, just atomics
<re_irc> <@dirbaio:matrix.org> it's the same as before
<re_irc> <@dirbaio:matrix.org> that PR only changes the cortex-m-specific critical section with the "critical-section" crate
<re_irc> <@dirbaio:matrix.org> * from a cortex-m-specific critical section to
<re_irc> <@yatekii:matrix.org> But didn't it use an atomic before instead of a CS?
<re_irc> <@dirbaio:matrix.org> CRITICAL_SECTION is an atomic ptr to a func that does the critical-section
<re_irc> <@dirbaio:matrix.org> but the critical section impl was still a "disable all interrupts"
<re_irc> <@dirbaio:matrix.org> and there was also the "set_print_channel_cs" which allowed to pass an arbitrary critical-section func, in case you weren't using cortex-m or riscv
<re_irc> <@dirbaio:matrix.org> now the "critical-section" crate already allows setting any custom cs impl, so there's no need for that anymore
<re_irc> <@yatekii:matrix.org> yeah but disabling interrupts really is not necessary if you have real atomics :)
<re_irc> <@yatekii:matrix.org> well anyways, merged 3 longer standing PRs :)
<re_irc> <@dirbaio:matrix.org> no
<re_irc> <@dirbaio:matrix.org> you need an actual mutex
<re_irc> <@yatekii:matrix.org> and added comments on the other ones :)
<re_irc> <@yatekii:matrix.org> : a mutex is just an atomic?
<re_irc> <@dirbaio:matrix.org> so that an interrupt can't interrupt while the main thread is doing an "rprintln!"
<re_irc> <@yatekii:matrix.org> : why can it not do that tho?
<re_irc> <@yatekii:matrix.org> you cannot do anything funky if you use an atomic to guard it :)
<re_irc> <@yatekii:matrix.org> ah wait maybe not hmm
<re_irc> <@yatekii:matrix.org> idk lol
<re_irc> <@yatekii:matrix.org> I am bad at this stuff
<re_irc> <@yatekii:matrix.org> I should not write software haha
<re_irc> <@dirbaio:matrix.org> you mean, making a "mutex" like
<re_irc> - spin until atomic flag is 0
<re_irc> - do thing
<re_irc> - change flag to 1
<re_irc> - change flag to 0
<re_irc> <@dirbaio:matrix.org> ?
<re_irc> <@dirbaio:matrix.org> that doesn't work, because
<re_irc> - main thread: change flag to 1
<re_irc> <@dirbaio:matrix.org> - main thread: spin until atomic flag is 0 -> cool, it is
<re_irc> - main thread: start doing the thing
<re_irc> - interrupt: spin until atomic flag is 0 -> spins forever
<re_irc> - interrupt: fired! it preempts main and starts running the ISR
<re_irc> <@dirbaio:matrix.org> the way you avoid that is taking a CS
<re_irc> <@yatekii:matrix.org> ahhhh I see, yeah I knew I forgot something
<re_irc> <@yatekii:matrix.org> dang
<re_irc> <@yatekii:matrix.org> but you could do: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicBool.html#method.compare_exchange_weak
<re_irc> <@dirbaio:matrix.org> yes
<re_irc> <@dirbaio:matrix.org> but if the mutex is taken you have to spin
<re_irc> <@yatekii:matrix.org> you could make it fallible
<re_irc> <@yatekii:matrix.org> which sucks
<re_irc> <@yatekii:matrix.org> hmm
<re_irc> <@yatekii:matrix.org> yeah I think all is well :)
<re_irc> <@yatekii:matrix.org> thanks
<re_irc> <@dirbaio:matrix.org> yeah, you don't want your "rprintln!"s in interrupts randomly failing to show up
<re_irc> <@yatekii:matrix.org> so the question is, do we want to release or should I try and fix the two PRs and force push and then release?
<re_irc> <@dirbaio:matrix.org> : it's not, as long as interrupts always restore "mie" to the previous state. Which the critical-section impl always does
<re_irc> <@yatekii:matrix.org> : no what if another contender enabled interrupts after your read?
<re_irc> <@dirbaio:matrix.org> (for example, it's not allowed for an interrupt handler to do MIE=0 and then return, or do MIE=1 and then return)
<re_irc> <@yatekii:matrix.org> so you
<re_irc> - main: enable
<re_irc> - isr: disable
<re_irc> - isr: read as disabled
<re_irc> - isr: cs
<re_irc> <@dirbaio:matrix.org> main can't run while isr is running, isr has strictly higher priority
<re_irc> <@yatekii:matrix.org> ah, kk
<re_irc> <@yatekii:matrix.org> I am retarded lol
<re_irc> <@yatekii:matrix.org> yeah this would only be a hazard if there was multiple hearts I guess but there is not multiple hearts
<re_irc> <@yatekii:matrix.org> from what I understand
<re_irc> <@dirbaio:matrix.org> not that either, each hart has its own MIE flag
<re_irc> <@yatekii:matrix.org> man like I hate this stuff ... how can people argue that C is fine
<re_irc> <@yatekii:matrix.org> it has one million caveats and footguns and stuff you can miss
<re_irc> <@yatekii:matrix.org> : ah, nice
<re_irc> <@yatekii:matrix.org> cool, thanks
<re_irc> <@dirbaio:matrix.org> it's the same as cortex-m actually
<re_irc> <@yatekii:matrix.org> (at least I should not do this lowlevel stuff)
<re_irc> <@dirbaio:matrix.org> the cortex-m implementation also looks like it has that race, but it doesn't
<re_irc> <@dirbaio:matrix.org> what can happen is
<re_irc> - isr: read MIE=1
<re_irc> - main: read MIE=1
<re_irc> - isr: write MIE=0
<re_irc> - isr: run stuff inside CS
<re_irc> - isr: restore MIE=1
<re_irc> - main: write MIE=0
<re_irc> - main: run stuff inside CS
<re_irc> - main: restore MIE=1
<re_irc> <@dirbaio:matrix.org> like, an interrupt fires between read and disable, but since the interrupt always restores MIE to the previous value, it's fine
<re_irc> <@yatekii:matrix.org> ah ok, that sounds good :) thanks for the elaboration :)
<re_irc> <@yatekii:matrix.org> : mind reviewing this: https://github.com/probe-rs/rtt-target/pull/24?
<re_irc> <@yatekii:matrix.org> I fixed my own review and also prepared the release
<re_irc> <@dirbaio:matrix.org> lots of random changes
<re_irc> <@dirbaio:matrix.org> clippy and fmt fixes
<re_irc> <@yatekii:matrix.org> Yeah sorry I was lazy and hijacked the PR
<re_irc> <@yatekii:matrix.org> most of it is clippy and fmt
<re_irc> <@yatekii:matrix.org> should be in separate commits tho
<re_irc> <@dirbaio:matrix.org> if we're gonna bikeshed about that exmaple
<re_irc> <@dirbaio:matrix.org> I think it's even more rusty to write it like
<re_irc> <@dirbaio:matrix.org> let mode = loop {
<re_irc> match read_buf[i] as char {
<re_irc> for i in 0..read {
<re_irc> read = channels.down.0.read(&mut read_buf);
<re_irc> '0' => break 0,
<re_irc> '1' => break 1,
<re_irc> _ => {}
<re_irc> }
<re_irc> }
<re_irc> };
<re_irc> <@dirbaio:matrix.org> but i'm fine with the current code too 😂
<re_irc> <@yatekii:matrix.org> fixed ;)
<re_irc> <@yatekii:matrix.org> hmm OT: does anyone know if there is a specific layer/format for PnP information?
<re_irc> <@dirbaio:matrix.org> lgtm
<re_irc> <@dirbaio:matrix.org> i don't have merge permissions tho
<re_irc> <@dirbaio:matrix.org> if you're gonna release, i'd change the "repository" in "Cargo.toml"
<re_irc> <@yatekii:matrix.org> why do you not have merge perms, wtf
<re_irc> <@yatekii:matrix.org> I fixed the links.
<re_irc> <@yatekii:matrix.org> But I wonder why you cannot merge
<re_irc> <@dirbaio:matrix.org> check the protected branch settings maybe
<re_irc> <@yatekii:matrix.org> nope, the probe-rs core team was not added. I added you now :)
<re_irc> <@yatekii:matrix.org> can you try?
<re_irc> <@yatekii:matrix.org> awezum
<re_irc> <@dirbaio:matrix.org> ohh you enabled the fancy github merge queue
<re_irc> <@dirbaio:matrix.org> github-integrated bors
<re_irc> <@yatekii:matrix.org> yup
<re_irc> <@yatekii:matrix.org> also on the main repo :)
<re_irc> <@dirbaio:matrix.org> oh and cargo-dist 👀
<re_irc> <@yatekii:matrix.org> yup :)
<re_irc> <@yatekii:matrix.org> thanks to
<re_irc> <@yatekii:matrix.org> so rtt-target 0.4.0 is out 🎉. for panic-rtt-target I need rights first :)
<re_irc> <@dirbaio:matrix.org> niiiice 🚀 "critical-section" everywhere
<re_irc> <@yatekii:matrix.org> very epic indeed =)
<re_irc> <@dirbaio:matrix.org> and nice to see "rtt-target" maintainership unstuck too
<re_irc> <@jamesmunns:beeper.com> : Pick and place? What kinda information, like part rotations and locations? Or something else? KiCad supports a couple of export formats that places like jlc and others will accept (tho there is sometimes disagreement which sides are the reference side)
<re_irc> <@yatekii:matrix.org> : I am interested in pad centerpoints and best case net names, but it should not be kicad specific even tho that would work too :)
<re_irc> <@9names:matrix.org> oh i was sure he was talking about plug-n-play
<re_irc> <@jamesmunns:beeper.com> (we talk about this more often in Anachro (https://matrix.to/#/#anachro:matrix.org), feel free to drop by). Most manufacture export stuff doesn't know about net names (at least not that I know).
<re_irc> <@adamgreig:matrix.org> IPC-D-356 is an open standard that kicad supports
<re_irc> <@jamesmunns:beeper.com> : TLA (three letter acronym) collision 💥
<re_irc> <@adamgreig:matrix.org> ODB++ is the most popular format I see with pcba houses, but it's proprietary and so not supported by kicad
<re_irc> <@adamgreig:matrix.org> Both give you stuff like pin numbers and orientations and generally more detail than a CSV of XY positions and rotations, which is the other "standard"
<re_irc> <@yatekii:matrix.org> hmm I wonder how much effort it uses to
<re_irc> <@yatekii:matrix.org> I mean do you need an extra layer or can it do it from the copper layer?
<re_irc> <@jamesmunns:beeper.com> Yeah, CSV/".pos" files I've seen/exported are usually just footprint center point X/Y and rotation in degrees
<re_irc> <@yatekii:matrix.org> oh no, perfect, https://www.ipc.org/TOC/IPC-D-356B.pdf is what i want :)
<re_irc> <@jamesmunns:beeper.com> It's usually separate from the Gerber outputs (not sure about the fancier formats Adam mentioned)
<re_irc> <@yatekii:matrix.org> glad we have a standard that apparently nooone uses :D
<re_irc> <@yatekii:matrix.org> hmm I could also try and get it from the copper layers ^^
<re_irc> <@jamesmunns:beeper.com> You thinking of doing something fancy, dynamic bed of nails style for testing?
<re_irc> <@adamgreig:matrix.org> Gerber is just for photolith artwork, not data like this
<re_irc> <@adamgreig:matrix.org> It's text/binary data exported separately by the cad software from drill and gerber data
<re_irc> <@yatekii:matrix.org> : I know, but I wanna make it easy for the user ...
<re_irc> <@yatekii:matrix.org> most PCB programs suck ...
<re_irc> <@yatekii:matrix.org> and more layouts suck even more
<re_irc> <@yatekii:matrix.org> and we have like 10k standards and people use maybe 5 of them
<re_irc> <@yatekii:matrix.org> soooo :/
<re_irc> <@jamesmunns:beeper.com> That being said, some fabs like aisles support import whole kicad projects now, unsure how much extra info they utilize over gerbers + pos + bom exports
<re_irc> <@yatekii:matrix.org> : oki cool, if it can do it by default I will write a parser :)
<re_irc> <@adamgreig:matrix.org> I don't think it's that bad, everyone has to be able to talk to their pcba house so most software supports a few export formats
<re_irc> <@jamesmunns:beeper.com> * aisler
<re_irc> <@adamgreig:matrix.org> And just the xy CSV is a good lowest common denominator
<re_irc> <@yatekii:matrix.org> : I wanna make automatic test fixtures, aka make a service for it, not export to a manufacturer =)
<re_irc> <@adamgreig:matrix.org> Getting it from copper seems basically impossible, imagine a pad inside a copper pour
<re_irc> <@jamesmunns:beeper.com> Yeah, what im saying is you could take the same approach
<re_irc> <@jamesmunns:beeper.com> Import the kicad project where ALL that data is there (not limited by export formats), so you can get part and pad names.
<re_irc> <@yatekii:matrix.org> : ah sorry, I got that one wrong :) yeah that would be possible, but I think I am gonna shoot myself when I have to write an altium parser :D :D
<re_irc> <@jamesmunns:beeper.com> My guess wasnt too far off :D
<re_irc> <@adamgreig:matrix.org> : People do use ipc-d-365, it's all I generate from kicad for "professional" pcba places and they mostly grumble that it's not obd++ and then find they can use it fine and get on with it lol
<re_irc> <@yatekii:matrix.org> and will be even funnier when it comes to eagle :D
<re_irc> <@jamesmunns:beeper.com> I wonder how good kicad is about importing (nontrivial) altium and eagle projects today, but yeah if it's a built in export feature, that might be the best, until you need to debug N tools' export formatters :D
<re_irc> <@yatekii:matrix.org> : hah! I did not even see that one, sorry =) Yeah, I wanna do a standard test adaptor you can use with forged.dev and then provide standard testrig hardware which does not suck and does not cost 5-6 digit numbers but also does not have 10digits precision on the vtg sources :) but maybe 4
<re_irc> <@jamesmunns:beeper.com> Excited to see what you build :)
Darius has quit [Ping timeout: 248 seconds]
Darius has joined #rust-embedded