<re_irc>
<@ian_rees:matrix.org> is there a good chat room for general embedded development, not Rust specific?
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
SomeWeirdAnon has quit []
<re_irc>
<@u007d:matrix.org> Question for folks with RISC-V experience. I am using a SiFive Unmatched (U74-MC).
<re_irc>
<@u007d:matrix.org> I have `MSEL` set to 0b0_0000 and `gdb` is showing my program is loaded into L2-LIM.
<re_irc>
<@u007d:matrix.org> I can single-step through instructions just fine, until I hit a `csrw` statement. `csrr` works fine. I believe I am in Machine mode on the S7 Monitor core. Any ideas what I could have missed?
<re_irc>
<@u007d:matrix.org> Was writing to an S-register on a core without S-mode.
<re_irc>
<@lachlansneff:matrix.org> Any of you familiar with the stm32f446?
<re_irc>
<@lachlansneff:matrix.org> I was going to buy a couple since it’s like the only stm32f4 available, but it seems like stm32-rs doesn’t support it
<re_irc>
<@lachlansneff:matrix.org> Actually nevermind, turns out I can’t read
<re_irc>
<@lachlansneff:matrix.org> Doesn’t support sdio :(
<re_irc>
<@9names:matrix.org> there are definitely f446's that support SDIO, is it just the one you've found that doesn't?
<re_irc>
<@lachlansneff:matrix.org> 9names: Well, it’s actually just the hal doesn’t enable the sdio feature for that series it seems
<re_irc>
<@lachlansneff:matrix.org> The data sheet definitely has sdio
Lumpio- has quit [Ping timeout: 256 seconds]
Lumpio- has joined #rust-embedded
dcz has joined #rust-embedded
<re_irc>
<@mathias_koch:matrix.org> Does anyone have an example of linkers + preinit of using and initializing the RAM2 block of an STM32 for statics using #[link_section]? specifically the bss part in a correct and sound way?
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@jkristell:matrix.org> Lachlan Sneff: If I recall correctly: When I wrote the sdio driver, looking at the SVD for the F446, it didn't match the other F-series SVDs. So I wasn't sure it had the same controller.
<re_irc>
<@adamgreig:matrix.org> mathias_koch:matrix.org: Not sure I've seen this. cortex-m-rt doesn't have any way to initialise multiple sections and we determined it probably must be done in assembly.... one possibility that comes to mind is using a custom linker script (just copy link.x to your project directory) and changing sdata and edata to cover your new section, but then all statics will go there
fabic has joined #rust-embedded
<re_irc>
<@mathias_koch:matrix.org> adamgreig: Hmm.. What i have now is basically
<re_irc>
<@mathias_koch:matrix.org> Then i am using it with `#[link_section = ".ram2"]`
<re_irc>
<@adamgreig:matrix.org> oh, sorry, I thought you wanted to initialise data
<re_irc>
<@mathias_koch:matrix.org> No, just zero initialize
<re_irc>
<@adamgreig:matrix.org> zero-init is somewhat simpler
<re_irc>
<@adamgreig:matrix.org> what you're doing unfortunately falls into this annoying rust memory model problem where it's not technically allowed to use rust code to create pointers from nothing that point to existing statics and then turn them into &mut references, because it means there's mutable aliasing going on
<re_irc>
<@adamgreig:matrix.org> which is why the r0 crate is deprecated, as it stands there's no way to do it soundly in rust (probably)
<re_irc>
<@adamgreig:matrix.org> although, uh
<re_irc>
<@adamgreig:matrix.org> is this in a bootloader distinct from the actual application, or are they linked together?
<re_irc>
<@mathias_koch:matrix.org> That is in a destinct bootloader, seperate binary
<re_irc>
<@adamgreig:matrix.org> unusually, if the rust paplication with this code in it doesn't actually itself have any statics in RAM2, then it would completely bypass the problem, lol
<re_irc>
<@adamgreig:matrix.org> well that's convenient
<re_irc>
<@adamgreig:matrix.org> assuming it doesn't have any statics placed in ram2
<re_irc>
<@mathias_koch:matrix.org> bootloader doesn't use ram2 at all
<re_irc>
<@adamgreig:matrix.org> that should work fine then
<re_irc>
<@adamgreig:matrix.org> you could inline the four lines of code from r0 that you're using and save having it as a dependency if you wanted, this part isn't complicated
<re_irc>
<@adamgreig:matrix.org> but yea, the only reason it's a problem is initialising statics that are accessible to the same program (which is usually always the case, for initialising the normal bss), but not an issue here
<re_irc>
<@mathias_koch:matrix.org> Alright, that sounds good..
<re_irc>
<@mathias_koch:matrix.org> It also seems to work great, only reason im questioning it, is that im seing what appears to be random system resets that i cannot figure out where is coming from. I have ruled out panics and stack overflows, i am currently investigating if it could be BOR based.. Are there any other reasons an STM32 would suddenly reset after having run some code for days, that i need to investigate?
<re_irc>
<@adamgreig:matrix.org> ugh, that's annoying to debug
<re_irc>
<@mathias_koch:matrix.org> i have just wrote up a patch to check RCC_CSR flags for a reset reason, just waiting for it to happen again :( Can't seem to find a way to force a replication
<re_irc>
<@adamgreig:matrix.org> do your panic and/or hardfault handlers reset?
<re_irc>
<@mathias_koch:matrix.org> Both do, but i am using panic_persist, and that one is empty on following reboot. I am also using flip_link, and yet hardfault is never hit
<re_irc>
<@adamgreig:matrix.org> if you can, leaving it hooked up to a debugger with a breakpoint set on panic, hardfault, and reset, so it will at least stop the moment it resets, might be instructive
<re_irc>
<@mathias_koch:matrix.org> I have tried that, but i have not been lucky enough to replicate it with a debugger in yet. Not that don't think it will happen, just that it is kinda rare.. Super annoying!
<re_irc>
<@mathias_koch:matrix.org> UB stuff of any kind wouldn't result in a system reset, would it?
<re_irc>
<@mathias_koch:matrix.org> eg `.._unchecked()` calls, or reading uninit memory, etc?
<re_irc>
<@adamgreig:matrix.org> _unchecked and the like will call the panic handler
<re_irc>
<@mathias_koch:matrix.org> Okay, so that should be covered
<re_irc>
<@adamgreig:matrix.org> reading uninit memory will just work I expect
<re_irc>
<@adamgreig:matrix.org> doing anything that the cpu core doesn't allow (reading invalid memory address etc) causes a fault, by default all faults escalate to hardfault unless you've installed memfault etc handlers
<re_irc>
<@mathias_koch:matrix.org> It escalates to hardfault? i though it would call the DefaultHandler in cortex-m-rt? Isn't that an empty loop?
<re_irc>
<@adamgreig:matrix.org> no, all interrupts and exceptions except hardfault default to defaulthandler, but hardfault has its own default for some reason (either can be overridden by the user)
<re_irc>
<@adamgreig:matrix.org> hardfault does default to an infinite loop, though
<re_irc>
<@mathias_koch:matrix.org> Yeah, i have kinda hacked a solution for hardfault handling that seems to work, as all cases should result in system reset anyways i don't really care i i break my stack.
<re_irc>
<@adamgreig:matrix.org> in that specific case it might make more sense to set that as BusFault which should catch any out-of-bounds memory access like a stack overflow when using flip-lld, and then you can have a separate panic message for hardfault
<re_irc>
<@mathias_koch:matrix.org> Huh, cool! I didn't know flip-link was actually causing a BusFault, being escalated to a HardFault.. TIL
<re_irc>
<@adamgreig:matrix.org> you'd also need to call `scb.enable(Exception::BusFault)` to have it used instead of hardfault, iirc
<re_irc>
<@mathias_koch:matrix.org> Thanks 👍️ Will give it a shot
<re_irc>
<@adamgreig:matrix.org> I doubt it's what you're hitting now though, since it would already turn into a hardfault -> into a panic
<re_irc>
<@adamgreig:matrix.org> (annoyingly I think panicking inside hardfault is often not OK though, because it can cause re-entrancy to your panic handler, which is likely not thread safe)
<re_irc>
<@mathias_koch:matrix.org> Which is why i move my MSP first
<re_irc>
<@adamgreig:matrix.org> (at one point we had c-m-rt default to panic in those handlers because it seemed like a really nice way to handle it, but because a hardfault can pre-empt a panic, it isn't in general sound)
<re_irc>
<@adamgreig:matrix.org> sure, that helps avoid stack overflow related problems in the panic handler, and maybe for your panic handler it's enough
<re_irc>
<@mathias_koch:matrix.org> Ah , in the non overflow hardfault cases?
<re_irc>
<@adamgreig:matrix.org> in principle a panic handler might be like, sending something out UART, or writing to some reserved RAM for panic-persist, or anything like that
<re_irc>
<@mathias_koch:matrix.org> So this should be valid in my case, assuming i enable the busfault exception?
<re_irc>
<@mathias_koch:matrix.org> #[no_mangle]
<re_irc>
<@adamgreig:matrix.org> I'd keep the link_section tags to ensure RealBusFault is placed nearby to BusFault in flash, otherwise the difference could end up outside the range of the branch instruction
<re_irc>
<@adamgreig:matrix.org> I'm not sure if you can use the normal #[exception] macro here too but I guess there's no need
<re_irc>
<@adamgreig:matrix.org> anyway it should be pretty easy to test that it's working, just read an invalid pointer somewhere
<re_irc>
<@adamgreig:matrix.org> (alas not 0x0 because that's valid 🙃)
<re_irc>
<@mathias_koch:matrix.org> i am just getting `no memory region specified for section '.BusFault.user`?
<re_irc>
<@mathias_koch:matrix.org> Is it called something else?
<re_irc>
<@adamgreig:matrix.org> stick it in hardfault
<re_irc>
<@adamgreig:matrix.org> there's no region specified for BusFault because it wouldn't in general be needed
<re_irc>
<@mathias_koch:matrix.org> ahh, okay
<re_irc>
<@adamgreig:matrix.org> the reason it's in the linker file for hardfault is because the real hardfault handler (HardFaultTrampoline) is defined in assembly and uses `b HardFault`, so HardFault needs to be placed close-by
<re_irc>
<@mathias_koch:matrix.org> That makes sense 👍️
<re_irc>
<@mathias_koch:matrix.org> One other quick question.. Reading out the SCB_CSR reset reason flags, it seems like the `PINRSTF` is always set, even if i just do an `SCB::sys_reset()`.. Anyone who can tell me why that is the case? I read it, and then set the `RMVF` bit afterwards to clear the flags
<re_irc>
<@adamgreig:matrix.org> could your debugger be asserting nrst?
<re_irc>
<@mathias_koch:matrix.org> Hmm.. Not sure, give me 1 minute and i'll try without debugget
<re_irc>
<@adamgreig:matrix.org> I'm not sure how it tells because iirc the nrst pin gets driven for anything, but maybe that's why this is a "simplified" diagram
<re_irc>
<@mathias_koch:matrix.org> even without a debugger attached, a sys_reset call results in both `PINRSTF` and `SFTRSTF` asserted..
<re_irc>
<@adamgreig:matrix.org> maybe it really is how the diagram looks (this is for an f4 in particular but I think it's widespread) and the software reset (via `sys_reset()`) drives nRST low for 20µs so is detected as a PINRSTF too
<re_irc>
<@adamgreig:matrix.org> I can't say for sure
<re_irc>
<@mathias_koch:matrix.org> Hmm.. That might make sense.. A bit strange though, but it would explain it
<re_irc>
<@adamgreig:matrix.org> maybe BORRSTF wouldn't generate PINRSTF? could try undervolting it til BOR kicks in
<re_irc>
<@adamgreig:matrix.org> though it's a pain and probably not that informative
<re_irc>
<@mathias_koch:matrix.org> I checked with `IWDGRSTF` and that asserted all 3.. (the `SFTRSTF` in that case was probably caused by the way my bootloader works, as it always does a sys_reset())
<re_irc>
<@mathias_koch:matrix.org> Damn.. I just OTA'ed this to my devices that has been restarting sporadically, and the `BORRSTF` bit is set :(
<re_irc>
<@mathias_koch:matrix.org> Any suggestions to debugging BOR issues?
<re_irc>
<@adamgreig:matrix.org> That might be a good clue at least! Perhaps you can put a scope on vcc and set the trigger point to the BOR level and check it's happening or getting close... what hardware is it? Perhaps not enough decoupling or too high pdn inductance or... anything like that
<re_irc>
<@mathias_koch:matrix.org> its an STM32L475VGT
<re_irc>
<@mathias_koch:matrix.org> I guess the scope trigger would be a good start, just to confirm
<re_irc>
<@adamgreig:matrix.org> Maybe you can disable brownout detection and see what happens instead lol
<re_irc>
<@adamgreig:matrix.org> I mean, is it on a custom PCB that conceivably could have power supply issues?
<re_irc>
<@mathias_koch:matrix.org> I don't think it's possible to disable? "The device has an integrated power-on reset (POR) / power-down reset (PDR), coupled
<re_irc>
<@mathias_koch:matrix.org> with a brown-out reset (BOR) circuitry. The BOR is active in all power modes except
<re_irc>
<@mathias_koch:matrix.org> Shutdown mode, and cannot be disabled."
<re_irc>
<@mathias_koch:matrix.org> adamgreig: Yeah, it is :(
<re_irc>
<@adamgreig:matrix.org> the option bytes have a BOR_LEVEL that configures the voltage where BOR trips, but I think the default is the lowest at 1.7V
<re_irc>
<@mathias_koch:matrix.org> exactly :/
<re_irc>
<@adamgreig:matrix.org> what vcc are you at?
<re_irc>
<@mathias_koch:matrix.org> 3.3
<re_irc>
<@mathias_koch:matrix.org> Soo its a long drop to 1.7..
<re_irc>
<@mathias_koch:matrix.org> I do have a 4G modem on the same supply though, so im thinking if the sporadic power draw from that one might cause voltage drops
<re_irc>
<@adamgreig:matrix.org> yea....
<re_irc>
<@adamgreig:matrix.org> oh, yea, definitely a possible culprit, those things can draw multiple amps on tx
<re_irc>
<@adamgreig:matrix.org> maybe a good place to start measuring anyway, or looking to see if tx activity correlates with resets
<cr1901>
adamgreig: I won't be here for the meeting today. Like last week. But this time I remembered to tell you :P
<re_irc>
<@adamgreig:matrix.org> no worries! I actually forgot it's a tuesday since we had a national holiday yesterday, lol
<re_irc>
<@mrbraindump:matrix.org> If I take and unwrap peripherals inside the main function, but my interrupts are outside of main, how do I access registers to reset them, like the ISFR?
<re_irc>
<@richarddodd:matrix.org> Also I don't know enough about ARM arch to say whether primask_r and cpsid interact.
<re_irc>
<@dirbaio:matrix.org> cpsid/cpsie do set/clear primask
<re_irc>
<@dirbaio:matrix.org> the purpose of that primask read is to allow nested critical sections: the inner one doesn't have to reenable interrupts, because they were already disabled. if it does, it'd break the outer one
<Lumpio->
If interrupts were disabled when entering that function there's no race condition
<re_irc>
<@dirbaio:matrix.org> it's never a race
<Lumpio->
What if there's an interrupt after primask read and cpsid *and* the interrupt disables interrupts
<re_irc>
<@dirbaio:matrix.org> yes, an interrupt can happen between `register::primask::read();` and `interrupt::disable();`
<Lumpio->
That's the only race I can think of
<re_irc>
<@dirbaio:matrix.org> and that interrupt handler might have a critical section too, yup
<Lumpio->
I mean between primask read and cpsid
<re_irc>
<@dirbaio:matrix.org> but it's supposed to "end" within the handler
<Lumpio->
I don't mean a critical section
<Lumpio->
What if the interrupt handler calls interrupt::disable()
<re_irc>
<@dirbaio:matrix.org> so the handler is supposed to leave PRIMASK as it was before
<Lumpio->
Nesting these critical sections works fine yes
<Lumpio->
Who says the handler must do that
<Lumpio->
It's probably a very weird thing to do, but is it a race still
<re_irc>
<@dirbaio:matrix.org> ah yeah, then the CS wouldn't see that and would reenable it
<re_irc>
<@dirbaio:matrix.org> PRIMASK is only supposed to be used for critical sections though..
<re_irc>
<@dirbaio:matrix.org> i'd argue doing a stray `interrupt::disable()` like that is wrong
<re_irc>
<@dirbaio:matrix.org> I don't think the architecture has a way to "set PRIMASK and get the old value atomically" at all...
<re_irc>
<@dirbaio:matrix.org> so this is the way you do it
<re_irc>
<@richarddodd:matrix.org> The error that I'm trying to debug is that rtt (with defmt-rtt and probe-rs-rtt) randomly stops working after a large number of SPI writes using easy-dma on nrf (using embassy)
<re_irc>
<@richarddodd:matrix.org> The number of writes required is always different but similar (in the range 400-420)
<re_irc>
<@dirbaio:matrix.org> what probe are you using?
<re_irc>
<@richarddodd:matrix.org> It's a very wierd problem, as all race conditions are :(
<re_irc>
<@richarddodd:matrix.org> I'm using the nrf52 discover/evaluation board
<re_irc>
<@richarddodd:matrix.org> I've ordered one of the new probe-rs ones, looking forward to seeing if that fixes the problem/proves it is a probe problem
<re_irc>
<@dirbaio:matrix.org> nrf52-dk? so nrf52832+jlink?
<re_irc>
<@richarddodd:matrix.org> nrf52-dk
<re_irc>
<@richarddodd:matrix.org> it just feels like it isn't going to be a probe problem though, because it is unrelated to the number of rtt writes - the problem occurs even if I don't write anything during the spi loop (it doesn't work after)
<re_irc>
<@dirbaio:matrix.org> strange
<re_irc>
<@richarddodd:matrix.org> Because I'm using embassy, other things happen during the DMA write - that's where there could (in theory) be a race between it and the rtt
<re_irc>
<@richarddodd:matrix.org> I hate these kinds of bugs
<re_irc>
<@dirbaio:matrix.org> and you know 100% sure the program keeps running? it's just that you stop seeing logs?
<re_irc>
<@richarddodd:matrix.org> Yeah, I've put some code in to write to a screen peripheral, and it continues to change after the rtt stops
<re_irc>
<@richarddodd:matrix.org> (which means the executor is definitely still working)
<re_irc>
<@richarddodd:matrix.org> It also responds to some input (a button I press)
<re_irc>
<@dirbaio:matrix.org> could the core be rebooting? defmt gets angry if it reboots
<re_irc>
<@richarddodd:matrix.org> hmm, can I trap/record that somehow?
<re_irc>
<@dirbaio:matrix.org> dunno, flash some led or something at start of main()
<re_irc>
<@richarddodd:matrix.org> ok good idea I can do that
<re_irc>
<@dirbaio:matrix.org> defmt has no framing, so if the core reboots in the middle of writing some message, it can corrupt the stream
<re_irc>
<@dirbaio:matrix.org> and probe-run doesn't catch that
<re_irc>
<@richarddodd:matrix.org> hmm
<re_irc>
<@richarddodd:matrix.org> it's worth a look, I will report back
<re_irc>
<@dirbaio:matrix.org> and the stream can sometimes corrupt in a way that makes the defmt decode think it's a loooooooong message, so it never finishes reading it so that it looks like it "stops"
<re_irc>
<@dirbaio:matrix.org> something to try too is to patch probe-run to print whether there are still bytes coming from RTT or not
<re_irc>
<@dirbaio:matrix.org> to check if that's the case
<re_irc>
<@jorgeig:matrix.org> jamesmunns: QQ: in postcard, when deserializing a struct that contains enums, is there a way to get a different Error for each field, in order to know which field failed deserialization? e.g. if an u8 in a packet is out of the valid ranges, I want to know that it was that field and log it with defmt
<re_irc>
<@jamesmunns:matrix.org> IIRC, error handling in postcard is pretty minimal (read: bad) at the moment. If you can find a way to change postcard to get that kind of info out, I am very open to PRs!
<re_irc>
<@jamesmunns:matrix.org> I don't THINK today that is possible, but likely because I've never tried :)
<re_irc>
<@jorgeig:matrix.org> sure, will explore! just wanted to see if there was already a way
<re_irc>
<@jamesmunns:matrix.org> for enums, you are going to need to look at the varint (read: variable sized integer) code, which is what I use to encode the enum variant
<re_irc>
<@jamesmunns:matrix.org> Then we give that varint, changed to a u32, to serde, to pick the right variant.
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@jamesmunns:matrix.org> (thinking about this a bit more): this might actually be a bigger serde question
<re_irc>
<@jamesmunns:matrix.org> They have the `expected` field, but that prints a runtime generated debug string
<re_irc>
<@jorgeig:matrix.org> so in serde there are visitors, and you can print errors out from the visitor
<re_irc>
<@jorgeig:matrix.org> yeah
<re_irc>
<@jorgeig:matrix.org> so for embedded and defmt, not great, as far as I can tell
<re_irc>
<@jamesmunns:matrix.org> Yeah, that makes sense, I'm not sure how to get something like `foo.bar.baz failed, because negative`
<re_irc>
<@dirbaio:matrix.org> can't you return your own error type? then inspect directly or impl defmt::Format for it or whatever
<re_irc>
<@jamesmunns:matrix.org> Yeah, I could probably error out with "failed in a u8 visitor"
<re_irc>
<@jamesmunns:matrix.org> but maybe not which field (which isn't available in the visitor or deserializer, afaik)
<re_irc>
<@jamesmunns:matrix.org> even in the more stringy serdes, like json, I don't think the FIELD knows the KEY it is associated with
<re_irc>
<@jamesmunns:matrix.org> it just knows "oh, this key is going to visit this kind of struct"
<re_irc>
<@jamesmunns:matrix.org> and even then, by the time you get to the visitor, you're working with primitives
<re_irc>
<@jamesmunns:matrix.org> BUT! That doesn't mean it's not possible. Just that I have no idea how :D
<re_irc>
<@jamesmunns:matrix.org> you could (maybe) get the INDEX of the input that caused it to fail?
<re_irc>
<@jamesmunns:matrix.org> then dump the whole message over defmt, for post-analysis?
<re_irc>
<@jamesmunns:matrix.org> not sure if that is reasonable/helpful though
<re_irc>
<@jorgeig:matrix.org> definitely better than nothing!
<re_irc>
<@jamesmunns:matrix.org> Right now, postcard usually just sub-slices the input to smaller and smaller parts, taking bytes/slices at a time
<re_irc>
<@jamesmunns:matrix.org> (`take_byte` and `take_n` or something like that in the code)
<re_irc>
<@jamesmunns:matrix.org> that could probably figure out the offset from (original size - current size)
<re_irc>
<@jamesmunns:matrix.org> But yeah, that's the only thing I could think of, atm
<re_irc>
<@jamesmunns:matrix.org> lemme know if you find a better way!
<re_irc>
<@adamgreig:matrix.org> room meeting time again! agenda's at https://hackmd.io/7rvzKk_wSP6Hl-SZqQ22Kg, please add any announcements or topics you'd like to discuss, and we'll start in 5min :)
<re_irc>
<@hargonix:matrix.org> I've nailed the micro:bit magnetometer stuff down to it not being properly calibrated for where I am (when I calibrate it with the micropython stuff from the BCC the heading angle is like 40 degree off...)
<re_irc>
<@hargonix:matrix.org> And a person who goes by caemor made an PR + issue on the discovery book rewrite so its not only me working on it now \o/
<re_irc>
<@hargonix:matrix.org> im gonna keep my distance from them after this if i can
<re_irc>
<@adamgreig:matrix.org> just use loads of gps receivers 🙃
<re_irc>
<@adamgreig:matrix.org> ublox have a 'heading-only' slightly cheaper receiver now that does dGPS RTK to your main receiver just to work out heading
<re_irc>
<@adamgreig:matrix.org> you just wire their serial ports together and it spits out heading, kinda cute. also like 50x the price of a magnetometer, so...
<re_irc>
<@hargonix:matrix.org> I considered for a moment to do the calibration procedure as described by STM but thats 3 pages of MATLAB vs like 400 lines of C++ from the microbit ....so I hope STM will forgive me for the betrayl
<re_irc>
<@adamgreig:matrix.org> heh
<re_irc>
<@adamgreig:matrix.org> ok, let's get started! I couldn't think of any announcements from the last week, does anyone have anything?
<re_irc>
<@adamgreig:matrix.org> well, shout later if you think of any, next up is just a quick revisit of the discovery book rewrite, I think we basically covered everything we needed to last week, was there anything else to discuss hargonix?
<re_irc>
<@therealprof:matrix.org> adamgreig: What's the plan for the newsletter?
<re_irc>
<@hargonix:matrix.org> Nope, I'm just gonna try to get this calibration thingy going this week and then the last chapter should be ready to merge and we can proceed as discussed
<re_irc>
<@adamgreig:matrix.org> oh, good reminder therealprof, I'll stick that on the agenda
<re_irc>
<@dirbaio:matrix.org> if so, if I impl them in embassy-nrf and embassy-stm32, would that count? :)
<re_irc>
<@eldruin:matrix.org> sure
<re_irc>
<@eldruin:matrix.org> not sure if that should count as 1.5 or something haha
<re_irc>
<@lulf_:matrix.org> someone needs to write another async hal
<re_irc>
<@adamgreig:matrix.org> i'd have thought the important thing is it's two totally different mcu peripherals
<re_irc>
<@eldruin:matrix.org> drivers using the async traits would also be needed
<re_irc>
<@adamgreig:matrix.org> I guess also embassy for that :P
<re_irc>
<@lulf_:matrix.org> eldruin:matrix.org: fwiw, drogue-tls and drogue-device have drivers that will migrate to these traits when merged
<re_irc>
<@therealprof:matrix.org> Are we fine with promoting things which only work on unstable and might have to change if unforeseeable stabilisation problems show up?
<re_irc>
<@adamgreig:matrix.org> they have to be behind a feature gate anyway due to being nightly, it seems like on balance better to have something in e-h that people can start using and getting experience with?
<re_irc>
<@adamgreig:matrix.org> since it has to be feature gated it's should be ok to make it clear it may have to change if rust stabilises something else, right?
<re_irc>
<@lulf_:matrix.org> as long as its behind some feature flag, I think it's ok, and that we should be open to change them based on feedback
<re_irc>
<@therealprof:matrix.org> Well, I guess there're two questions in there.
<re_irc>
<@adamgreig:matrix.org> it seems like both driver writers and hal writers want to see async traits in e-h asap because it will be immediately and practically useful, and they seem to be on the way to stabilisation in rust now too
<re_irc>
<@therealprof:matrix.org> One is about promoting unstable. The other was: how confident are we that the features stabilise as-is and don't require later changes.
<re_irc>
<@adamgreig:matrix.org> my read on the rustc side of things is that they don't expect any serious changes and hope to get more and more GAT-related stuff stable soon? I'm not fully plugged in to that though, so I might be mistaken
<re_irc>
<@lulf_:matrix.org> thats my impression as well, but it's hard to predict the future
<re_irc>
<@therealprof:matrix.org> I would rather hope that we can finally wrap up e-h and ship it rather sooner than later.
<re_irc>
<@ryan-summers:matrix.org> Having a very rudimentary understanding of the async ecosystem - is it feasible to implement async e-h traits without GATs?
<re_irc>
<@newam:matrix.org> ryan-summers:matrix.org: Not without `alloc`.
<re_irc>
<@adamgreig:matrix.org> therealprof: agreed, but I don't see in principle a reason we couldn't have an async feature-gate in 1.0 that we later turn into a no-op once it's stable?
<re_irc>
<@adamgreig:matrix.org> I understand the worries about the previously bad `unproven` gate, but the motivations are somewhat different here - it would already be proven, it's instead that it needs nightly
<re_irc>
<@adamgreig:matrix.org> I guess it's also fair to worry about what it means to make breaking changes to something behind a nightly-only feature-gate...
<re_irc>
<@therealprof:matrix.org> I don't have a problem with the feature gate. I don't think this is like unproven at all.
<re_irc>
<@dirbaio:matrix.org> yeah IMO the traits are quite proven
<re_irc>
<@dirbaio:matrix.org> they mirror the existing blocking traits
<re_irc>
<@burrbull:matrix.org> I've already proposed to use `async` feature
<re_irc>
<@thejpster:matrix.org> Agreed
<re_irc>
<@lulf_:matrix.org> what was bad with the unproven gate? (sorry for distracting the conversation, just curious) All features being put there and people relying on it too soon?
<re_irc>
<@eldruin:matrix.org> I suggested if we merge it, this feature would _not_ be covered by the semver guarantees, since it is based on nightly
<re_irc>
<@adamgreig:matrix.org> I think that's fair
<re_irc>
<@thejpster:matrix.org> lulf: nothing ever got proven, so it became basically required
<re_irc>
<@ryan-summers:matrix.org> If we want to do that though, what's the difference between just shipping it in a separate async-embedded-hal crate?
<re_irc>
<@eldruin:matrix.org> so it would just be for people that are fine with nightly shenanigans
<re_irc>
<@therealprof:matrix.org> I think I would be a lot more confident if someone could summarize which unstable features are needed and include their upstream tracking status.
<re_irc>
<@dirbaio:matrix.org> ryan-summers:matrix.org: it can be a separate crate too, but then why are the `nb` traits in main e-h and `async` traits separate?
<re_irc>
<@dirbaio:matrix.org> therealprof:matrix.org: just GATs
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: Just a single feature? What's the exact name? And what's the upstream stabilisation tracking issue?
<re_irc>
<@dirbaio:matrix.org> on the implementor side you might want `type_alias_impl_trait` too if you want to impl them with `async fn` or `async{}`, but you can do without if you manually do `struct FooFuture; impl Future for FooFuture`
<re_irc>
<@dirbaio:matrix.org> for *defining* the trait you just need GATs
<re_irc>
<@grantm11235:matrix.org> adamgreig: Yeah, it looks like it does. That only covers serial, spi, and i2c though.
<re_irc>
<@eldruin:matrix.org> I think requiring `Debug` everywhere should be fine.
<re_irc>
<@grantm11235:matrix.org> I will probably open PRs for both of those Eventually ™️ unless someone else does it first
<re_irc>
<@adamgreig:matrix.org> I can't think of any reason it would be bad to provide impls for references, but maybe there's something sneaky...?
<re_irc>
<@grantm11235:matrix.org> Currently, a HAL could impl the traits differently for `SpiStruct` vs `&mut SpiStruct`, but I'm not sure if there is any good reason to do that. A blanket impl would disallow that.
<re_irc>
<@dirbaio:matrix.org> Commented on the errors PR:
<re_irc>
<@dirbaio:matrix.org> > Maybe this PR should enforce that the Error associated types impl the Error trait? The original proposal does so.
<re_irc>
<@eldruin:matrix.org> dirbaio:matrix.org: I don't understand this, the PR does require the associated types to implement the `Error` traits
<re_irc>
<@grantm11235:matrix.org> Has anyone bikeshedded `i2c::Error` vs `i2c::I2cError` yet?
<re_irc>
<@dirbaio:matrix.org> grantm11235:matrix.org: then the traits should be `i2c::I2cWrite`
<re_irc>
<@dirbaio:matrix.org> `i2c::Error` is the consistent one
<re_irc>
<@eldruin:matrix.org> we have `i2c::Write`, `spi::Write`,... so I figured `i2c::Error` would be more in line with that
<re_irc>
<@dirbaio:matrix.org> eldruin:matrix.org: how? it just adds Error/ErrorKind, but doesn't change the associated types to `type Error: Error`
<re_irc>
<@eldruin:matrix.org> ach sorry I redid the whole PR today due to inside-out and missed adding the bounds
<re_irc>
<@dirbaio:matrix.org> ah OK :)
<re_irc>
<@eldruin:matrix.org> the whole point is requiring that
<re_irc>
<@eldruin:matrix.org> thanks for noticing!
<re_irc>
<@firefrommoonlight:matrix.org> This distinction depends on how you imagine users importing. For example, `i2c::Error` makes more sense if you assume the person imports mainly modules. If you assume the user imports data structures, `i2c::Error` causes conflicts. I've been going with the latter for flexibility and avoiding name confusion and collisions. Eg `dac::DacMode`, `adc::AdcChannel`, `timer::TimInterrupt` etc. Potentially...
<re_irc>
... redundant, but makes it obvious what item you're using if importing directly
<re_irc>
<@newam:matrix.org> You can always let the user do `use embedded_hal::i2c::Error as I2cError;`
<re_irc>
<@adamgreig:matrix.org> sadly I don't think the rust api guidelines say much about it, but rust stdlib is pretty consistent in having things like `std::io::Error`, `std::fmt::Error`, etc
<re_irc>
<@firefrommoonlight:matrix.org> True. I was using that approach before switching to explicit names
<re_irc>
<@hegza:matrix.org> I feel like i2c::I2cError is anti-DRY. I'm sure I've seen it as a convention somewhere that you should avoid including duplicate names in paths. If the module makes it clear what it is, it needs not be repeated. But that's my opinion and I will refrain from futher bikeshedding :D
<re_irc>
<@adamgreig:matrix.org> ok, we're pretty much out of time so I've updated a few points on the agenda to discuss next week, though a quick reminder that the newsletter is open for anything you'd like to add and we'll probably publish the next edition in a couple of weeks :)
<re_irc>
<@adamgreig:matrix.org> and that's all for this week, thanks everyone!
<re_irc>
<@sparky:matrix.possumlodge.me> apparently its old tech from the 70s thats seeing a revival cause of low powered computing devices. looks like they are aiming for 5v 0.7uA based on their data sheet...
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> 0.7uA average is pretty hard to hit unless you're sleeping most of the time. I could see some uses for ultra low power implantables, but anything with wireless connectivity gets a bit harder. From what I remember, they aren't very good at providing pulsed high amperage currents either (e.g. short 20mA pulse for radio usage), but I don't remember anymore