<re_irc>
<@firefrommoonlight:matrix.org> Mainly an example for using DMA for fast processing. Circular buffers for both input and output
<re_irc>
<@firefrommoonlight:matrix.org> Uses double-buffering to make sure the DMA buffers have no IO conflicts. (Half transfer and Full transfer DMA interrupts control which half of each buffer to use)
dreamcat4 has quit [Quit: Connection closed for inactivity]
nexos_ is now known as nexos
_whitelogger has quit [Ping timeout: 268 seconds]
_whitelogger_ has joined #rust-embedded
edm has joined #rust-embedded
Ekho has quit [Ping timeout: 260 seconds]
bpye has quit [Ping timeout: 260 seconds]
GenTooMan has quit [*.net *.split]
vancz has quit [*.net *.split]
darknighte has quit [*.net *.split]
cr1901 has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
ni has quit [*.net *.split]
sauce has quit [*.net *.split]
Shellhound has quit [*.net *.split]
nexos has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
jackneilll has quit [*.net *.split]
fooker has quit [*.net *.split]
PyroPeter has quit [*.net *.split]
emerent has quit [*.net *.split]
troth has quit [*.net *.split]
dkm has quit [*.net *.split]
Darius has quit [*.net *.split]
mrkajetanp_ has quit [*.net *.split]
_whitelogger has quit [*.net *.split]
creich has quit [*.net *.split]
Rondom has quit [*.net *.split]
starblue has quit [*.net *.split]
xnor has quit [*.net *.split]
richardeoin has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
unmanbearpig has quit [*.net *.split]
re_irc has quit [*.net *.split]
Rahix has quit [*.net *.split]
inara has quit [*.net *.split]
wose has quit [*.net *.split]
hifi has quit [*.net *.split]
mightypork has quit [*.net *.split]
rektide has quit [*.net *.split]
jasperw has quit [*.net *.split]
Amanieu_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
agg has quit [*.net *.split]
x56 has quit [*.net *.split]
_whitelogger has joined #rust-embedded
PyroPeter has quit [*.net *.split]
emerent has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
troth has quit [*.net *.split]
dkm has quit [*.net *.split]
creich has quit [*.net *.split]
Rondom has quit [*.net *.split]
xnor has quit [*.net *.split]
starblue has quit [*.net *.split]
richardeoin has quit [*.net *.split]
vancz has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
cr1901 has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
darknighte has quit [*.net *.split]
ni has quit [*.net *.split]
sauce has quit [*.net *.split]
Shellhound has quit [*.net *.split]
nexos has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
jackneilll has quit [*.net *.split]
fooker has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
Ekho has quit [*.net *.split]
nohit has quit [*.net *.split]
bpye has quit [*.net *.split]
unmanbearpig has quit [*.net *.split]
re_irc has quit [*.net *.split]
Rahix has quit [*.net *.split]
inara has quit [*.net *.split]
wose has quit [*.net *.split]
jasperw has quit [*.net *.split]
hifi has quit [*.net *.split]
mightypork has quit [*.net *.split]
rektide has quit [*.net *.split]
Amanieu_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
x56 has quit [*.net *.split]
agg has joined #rust-embedded
Ekho has joined #rust-embedded
bpye has joined #rust-embedded
nexos has joined #rust-embedded
emerent has joined #rust-embedded
Amanieu_ has joined #rust-embedded
cr1901 has joined #rust-embedded
inara has joined #rust-embedded
cyrozap has joined #rust-embedded
Lumpio- has joined #rust-embedded
PyroPeter has joined #rust-embedded
nohit has joined #rust-embedded
jasperw has joined #rust-embedded
starblue has joined #rust-embedded
mightypork has joined #rust-embedded
re_irc has joined #rust-embedded
Foxyloxy has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
darknighte has joined #rust-embedded
jackneilll has joined #rust-embedded
dkm has joined #rust-embedded
Rondom has joined #rust-embedded
rektide has joined #rust-embedded
mrkajetanp has joined #rust-embedded
Rahix has joined #rust-embedded
troth has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
fooker has joined #rust-embedded
richardeoin has joined #rust-embedded
wose has joined #rust-embedded
Shellhound has joined #rust-embedded
sauce has joined #rust-embedded
ni has joined #rust-embedded
hifi has joined #rust-embedded
GenTooMan has joined #rust-embedded
xnor has joined #rust-embedded
creich has joined #rust-embedded
edm has joined #rust-embedded
fabic has joined #rust-embedded
Darius has quit [Quit: Bye]
Darius has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@jordens:matrix.org> Looks like stm32h7 v0.13 crashes current nightly. Anyone else see that or have an issue I can track?
<re_irc>
<@adamgreig:matrix.org> as in, the PAC?
<re_irc>
<@adamgreig:matrix.org> crashes the compiler or causes your firmware to crash?
<re_irc>
<@jordens:matrix.org> PAC, compiler ICE
dreamcat4 has joined #rust-embedded
<re_irc>
<@jordens:matrix.org> v0.14 works, nightly-2021-10-12 also works
<re_irc>
<@adamgreig:matrix.org> yea, I'm getting an ICE on currently nightly and 0.13 too, this is the first I've heard of it though
<re_irc>
<@adamgreig:matrix.org> if 2021-10-12 works there can't be too many things to blame at least :P weird that 0.14 is OK, I guess some of the recent svd2rust changes (0.17 in stm32h7 0.13 -> 0.19 in stm32h7 0.14) changed enough to avoid the error
<re_irc>
<@adamgreig:matrix.org> actually I'm getting the ICE on `rustc 1.57.0-nightly (d7c97a02d 2021-10-12)`
<re_irc>
<@jordens:matrix.org> also the changes in around the unwrap are significant.
<re_irc>
<@jordens:matrix.org> `thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', compiler/rustc_typeck/src/coherence/inherent_impls_overlap.rs:242:74`
<re_irc>
<@adamgreig:matrix.org> (also fine with nightly-2021-10-12 / `rustc 1.57.0-nightly (5b210643e 2021-10-11)` for me)
<re_irc>
<@adamgreig:matrix.org> I guess f4 probably captures the same improvement/regression statistics without taking quite as long to run :P
<re_irc>
<@jordens:matrix.org> Yes. Just joking.
<re_irc>
<@adamgreig:matrix.org> hehe, can't complain about the bug being found even before anyone here noticed it thanks to the perf tooling, and then someone also opening a PR to fix it before that too
<re_irc>
<@jordens:matrix.org> yep
fabic has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> Man, the glory that is `syn` and proc-macros is truly wonderful. It's so incredibly easy to programmatically modify codegen. Need to bound generic parameters by a custom trait bound at compile time? 3 lines of code
<re_irc>
<@dngrs:matrix.org> I'm sending raw pixel data to an STM32F103 over USB-UART, slightly processing it for SPI (1 incoming byte turns into 4 outgoing bytes) and DMAing it out when the buffer is full. Inevitably at some point I'm losing incoming bytes and then the pixels become misaligned. Can this be solved without introducing a checksums/packet format (which of course then means dropping corrupt frames)? I'm thinking...
<re_irc>
<@dngrs:matrix.org> total amount of data is tiny I'd think, 7x7 LEDs * 3 (RGB) * 30fps = 4410 bytes (max throughput over that connection is 90kbyte/s as measured by `dd`)
<re_irc>
<@adamgreig:matrix.org> are you double buffering, or could you lose data that comes in while the DMA is ongoing for the previous frame?
<re_irc>
<@adamgreig:matrix.org> adding some kind of 'start of frame' marker might help with reliability in any event but it's a bit tricky with uart bytes without using some kind of framing like PPP's escaping or COBS
<re_irc>
<@dngrs:matrix.org> I'm not double buffering, that's a good point
<re_irc>
<@adamgreig:matrix.org> (at least you can resync to start of frame, even with no CRC or anything)
<re_irc>
<@dirbaio:matrix.org> usb-uart shouldn't lose bytes I think
<re_irc>
<@dngrs:matrix.org> can I post some code?
<re_irc>
<@adamgreig:matrix.org> my guess is you're losing data that comes in while you're blocking on the dma transfer, then
<re_irc>
<@dngrs:matrix.org> I've tried to minimize dma blocking time by starting the transfer fn with "wait for previous transfer if any, then start new transfer"
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: On Windows it can if your buffer is small or your baud rate is high. Windows polls only ever 13ms, and under heavy system loads that can get a lot worse.
<re_irc>
<@dngrs:matrix.org> newam:matrix.org: (I'm on macos)
<re_irc>
<@newam:matrix.org> Should be fine then.
<re_irc>
<@dirbaio:matrix.org> newam:matrix.org: but doesn't the OS block the program that's doing the write() instead of dropping bytes?
<re_irc>
<@adamgreig:matrix.org> baud rate shouldn't be relevant here hopefully
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: Only if there is flow control, which unfortunately may not always apply.
<re_irc>
<@dirbaio:matrix.org> wtf
<re_irc>
<@dirbaio:matrix.org> in linux "virtual" usb uarts always block when writing on buffer full
<re_irc>
<@dirbaio:matrix.org> 🤷
<re_irc>
<@adamgreig:matrix.org> you'd think the default buffer would be plenty big enough too but I guess it depends on how fast the host program is trying to fill it
<re_irc>
<@dngrs:matrix.org> anyway, code if anyone feels like hunting for obvious mistakes (besides, I know, `static mut` meeehhh, I'll be switching this to RTIC "real soon now") https://dpaste.org/oUFx
<re_irc>
<@dngrs:matrix.org> also I'd be interested in whether there's a better approach for making dma-enabled buffers than newtyping them and implementing `Deref` + `ReadTarget` ... I kinda stumbled into that solution, it was never mentioned in any docs
<re_irc>
<@dngrs:matrix.org> (the crate only defines buffer types for array sizes up to 256 and then powers of 2)
<re_irc>
<@newam:matrix.org> > self.yolo();
<re_irc>
<@newam:matrix.org> Love the coding style 😁
<re_irc>
<@dngrs:matrix.org> newam:matrix.org: it's a reminder to rewrite it in (better) Rust :D
<re_irc>
<@dngrs:matrix.org> hmmm now that I think about it maybe the actual bug isn't packet loss but internal overrun since the bytes come in not one by one, but in usb packets
<re_irc>
<@dngrs:matrix.org> so I'm just looping over that buffer all the time while it's being DMA'd out
<re_irc>
<@dngrs:matrix.org> on another note, naw, that wouldn't explain the LED misalignment I'm observing
<re_irc>
<@dngrs:matrix.org> still, probably worth trying out double buffers. Any crate for that?
<re_irc>
<@adamgreig:matrix.org> my guess is probably wrong, you run the DMA from the main loop but process incoming USB data in the USB interrupt handler, so the DMA running shouldn't block, at worst you might expect tearing when the start of the frame is updated before it's written out
<re_irc>
<@dngrs:matrix.org> I am on the same page
<re_irc>
<@dngrs:matrix.org> still ... I'm writing new incoming bytes to the buffer while it's being DMA'd. Should change that. :D
<re_irc>
<@adamgreig:matrix.org> as a super simple check, you could change the computer-side code to send 0xff pixel value as 0xfe, and then send 0xff only at the start of each new frame, and in your firmware detect 0xff and reset dma_idx to 0
<re_irc>
<@adamgreig:matrix.org> yea, worth fixing eventually to stop tearing, but fixing it _probably_ won't help the current problem
<re_irc>
<@dngrs:matrix.org> I was thinking about something along those lines, but then I thought, I have other code that already uses e.g. postcard and I'd just go full proper packet format then
<re_irc>
<@adamgreig:matrix.org> though maybe you'd end up fixing whatever the current problem is anyway, heh
<re_irc>
<@dngrs:matrix.org> double buffering unfortunately did not fix it
<re_irc>
<@dngrs:matrix.org> or I built it wrong
<re_irc>
<@dngrs:matrix.org> checking..
<re_irc>
<@jamesmunns:matrix.org> jordens:matrix.org: I think we've seen this in our CI for stm32f3 as well
<re_irc>
<@dngrs:matrix.org> oh, also: at some point the MCU will hang (not getting interesting stack traces)
<re_irc>
<@jamesmunns:matrix.org> just saw the full conversation
<re_irc>
<@jamesmunns:matrix.org> yeah, looks the same. Passed on to our devs working on the f3 project atm. looks like it should be green in tomorrow's nightly CI
<re_irc>
<@adamgreig:matrix.org> yep! love when these things get caught and fixed before you even notice them...
<re_irc>
<@jamesmunns:matrix.org> :D
<re_irc>
<@jamesmunns:matrix.org> We noticed it this morning, though hadn't posted an issue yet.
<re_irc>
<@adamgreig:matrix.org> updating to stm32f3 0.14 would also fix it btw, but I guess you're using f3xx-hal or something that pins 0.13
<re_irc>
<@jamesmunns:matrix.org> likely!
<re_irc>
<@jamesmunns:matrix.org> (not my project, just in the same chat :) )
<re_irc>
<@adamgreig:matrix.org> i love that perf.rust-lang runs stm32f4 these days
<re_irc>
<@dngrs:matrix.org> let then = DWT::get_cycle_count();
<re_irc>
<@dngrs:matrix.org> let (_, _tx) = self.transfer.take().unwrap().wait();
<re_irc>
<@dngrs:matrix.org> is this a good way to measure time spent?
<re_irc>
<@dngrs:matrix.org> let delta = now.wrapping_sub(then);
<re_irc>
<@dngrs:matrix.org> let now = DWT::get_cycle_count();
<re_irc>
<@jamesmunns:matrix.org> Should be reasonable, while you have a debugger attached
<re_irc>
<@jamesmunns:matrix.org> (may not work or require additional setup steps without the debugger attached)
<re_irc>
<@jamesmunns:matrix.org> are you interested in one-shot timing, or accumulated time in a certain step?
<re_irc>
<@dngrs:matrix.org> one shot
<re_irc>
<@jamesmunns:matrix.org> yup. dwt would be the most accurate.
<re_irc>
<@newam:matrix.org> You need enable trace and enable cycle counter (in that order) to get the cycle counter to work.
<re_irc>
<@dngrs:matrix.org> yup, I meant "in addition to DWT, you also need trace"
<re_irc>
<@dngrs:matrix.org> I did word that poorly though. thx for clarifying :)
<re_irc>
<@dngrs:matrix.org> hrmph, it keeps losing bytes and at some later point just hangs. I'm sure there's a timing problem because I can trigger the hanging much faster by putting defmt calls in the ISR that get called on every interrupt
<re_irc>
<@adamgreig:matrix.org> how many bytes are you getting per usb interrupt, roughly?
<re_irc>
<@adamgreig:matrix.org> ah, 8?
<re_irc>
<@dngrs:matrix.org> I added one more measurement, for the actual main loop, I *may* be getting closer to the actual problem (or it's just defmt buffers taking time...hm)
<re_irc>
<@adamgreig:matrix.org> maybe it would help to send 64 bytes at a time from the computer, if you can
<re_irc>
<@dngrs:matrix.org> mostly 8 it seems
<re_irc>
<@adamgreig:matrix.org> even so, 2560 cycles for 8 bytes is 320 cycles/byte or 1.4Mcycles/second for usb-uart side of things which seems like it should be OK
<re_irc>
<@dngrs:matrix.org> exactly 64 or at least 64? easiest for me would be to send the entire buffer at once, which would be 7x7*3 = 147 bytes
<re_irc>
<@adamgreig:matrix.org> try that too
<re_irc>
<@adamgreig:matrix.org> 64 is probably the packet size being used by usb, one 64-byte packet per millisecond
<re_irc>
<@adamgreig:matrix.org> but if you just dump 147 bytes into it from your computer, it should buffer and drain fine, and the device gets two 64-byte packets and a 19 byte packet
<re_irc>
<@adamgreig:matrix.org> also on L234 maybe you can do `for component in &buf[..count]` instead of `for i in 0..count`
<re_irc>
<@adamgreig:matrix.org> save yourself a bounds check :p
<re_irc>
<@jamesmunns:matrix.org> dngrs (spookyvisiongithub): you could also use postcard w/ cobs (or just cobs) for your message framing
<re_irc>
<@jamesmunns:matrix.org> to at least appropriately delimit messages
<re_irc>
<@dngrs:matrix.org> I was using that `i` in previous versions of the code, not required anymore yeah
<re_irc>
<@adamgreig:matrix.org> usually the way, heh
<re_irc>
<@dngrs:matrix.org> jamesmunns: I'm trying to figure out if I can live without it, mostly I just want to understand the problem here, but yeah, long term goal is postcard etc, have it already in a different project, works fine
<re_irc>
<@dngrs:matrix.org> so with a 64 byte read buffer I get overrun (as in, double buffering not enough). a 32 byte buffer fixes this, both buffer sizes lead to strange flickering and color errors that I didn't observe before though. Another hHeadscratcher.
<re_irc>
<@dngrs:matrix.org> I think I might be measuring my exec timing wrong, as in "still inside a CS"
<re_irc>
<@dngrs:matrix.org> aaah I think I have an idea
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<@dngrs:matrix.org> since I'm writing 147 bytes every 1/30s, that's not a nice multiple of the usb packet size, I should somehow pad this to a multiple of 64 maybe
Rahix has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> roughly how much time should I spend at most inside a CS?
<re_irc>
<@adamgreig:matrix.org> "it depends", but in this case you only have the USB interrupts, so it's probably not going to matter much...
<re_irc>
<@dngrs:matrix.org> interestingly, when I increase the CPU frequency, reading from usb uart now seems to take longer. Some prescalers at play I suppose
<re_irc>
<@jamesmunns:matrix.org> take longer? or more cycles?
<re_irc>
<@adamgreig:matrix.org> the CS you have inside the interrupt doesn't seem necessary, since it can't be pre-empted by anything else anyway (the two USB interrupts are at the same priority)
<re_irc>
<@dngrs:matrix.org> more cycles
<re_irc>
<@dngrs:matrix.org> headdesk, yes, cycles != time
<re_irc>
<@jamesmunns:matrix.org> it would make sense if the cycles were shorter, but you're waiting on the same wall clock time thing
<re_irc>
<@jamesmunns:matrix.org> yeah
<re_irc>
<@dngrs:matrix.org> adamgreig: does it potentially *hurt*?
<re_irc>
<@adamgreig:matrix.org> maybe you could use an AtomicBool for FRAME_READY and drop the CS
<re_irc>
<@adamgreig:matrix.org> doesn't significantly hurt beyond adding a few extra cycles to enter/exit
<re_irc>
<@jamesmunns:matrix.org> Also, fwiw, I've never had to enable double buffering for USB, with single buffering and a queue like bbqueue, it should be pretty straightfoward to keep the line pretty saturated
<re_irc>
<@adamgreig:matrix.org> there's a worry that if you take too long inside the USB interrupt that two more come in while you're working, you'll drop one of them, but that happens regardless of CS
<re_irc>
<@jamesmunns:matrix.org> like, not 100% theoretical rate, but a pretty easy path to 70-80%, which should be WAY more than you need.
<re_irc>
<@adamgreig:matrix.org> jamesmunns: oh, yea, with a queue like bbqueue or something - but the current set up is "USB interrupt writes directly to a buffer, DMA reads from that buffer every time it's filled, but USB immediately starts writing again to the start of the buffer"
<re_irc>
<@adamgreig:matrix.org> so you'll race "how fast is the DMA" with "how long til the next USB packet comes in"
<re_irc>
<@dngrs:matrix.org> jamesmunns:matrix.org: without double buffering I'm potentially writing to the same buffer I'm also DMAing out over SPI, which probably isn't smart. But it also doesn't seem to be the actual problem
<re_irc>
<@jamesmunns:matrix.org> What I would say is:
<re_irc>
<@jamesmunns:matrix.org> Queue out of USB to SPI
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: Try to keep clock ratios at powers of two (generally speaking). Clock domain crossings and very hard to design for. Look up metastability and metastability hardening if you want to learn more of this.
<re_irc>
<@jamesmunns:matrix.org> you can DMA INTO bbqueue (on the usb side) and OUT OF bbqueue (on the SPI side)
<re_irc>
<@jamesmunns:matrix.org> though I think you need to do post-processing
<re_irc>
<@jamesmunns:matrix.org> so you'd need a temp buffer (or a second queue)
<re_irc>
<@jamesmunns:matrix.org> I'd just put the expander in the main/idle function and just chew continuously.
<re_irc>
<@adamgreig:matrix.org> shouldn't need to worry about metastability inside an stm32 though, it takes care of all the relevant clock domain crossing
<re_irc>
<@jamesmunns:matrix.org> what I guess I'm suggesting: doing everything in a single buffer is a *really* "last mile" optimization
<re_irc>
<@jamesmunns:matrix.org> and I bet you have 2K of ram sitting around for a pair of 1k bbqueues :D
<re_irc>
<@dngrs:matrix.org> I can't DMA-into because I need to transform the incoming bytes
<re_irc>
<@jamesmunns:matrix.org> yeah, that's the `expander` step
<re_irc>
<@dngrs:matrix.org> ah ok
<re_irc>
<@jamesmunns:matrix.org> you'd do that in a hot loop in main or something
<re_irc>
<@dngrs:matrix.org> making use of `AtomicBool` now first though, let's see
<re_irc>
<@adamgreig:matrix.org> it might be interesting to see what's "locking up", too, if something's actually getting stuck, or usb interrupts are no longer coming in, or what
<re_irc>
<@adamgreig:matrix.org> could be a bug in the usb driver not clearing some error flag or something, or maybe a consequence of not servicing an interrupt fast enough
<re_irc>
<@dngrs:matrix.org> now that I got rid of the cs in main I'm getting some very interesting and extremely slow behavior, the LED update frame rate dropped to 1 every few seconds and is very erratic. .... HUH.
<re_irc>
<@dngrs:matrix.org> reading over the changes again before dpasting...
<re_irc>
<@dngrs:matrix.org> ah yeah nevermind. Forgot an update to false again.
<re_irc>
<@dngrs:matrix.org> hrmph, still eventually hangs and drops bytes beforehand. *Not* single bytes though! Maybe a hot lead. I've changed it so my host sends padded packets of size 64*3. My read buffer is 32, and it *seems* I am losing "read buffer sized" chunks.
<re_irc>
<@dngrs:matrix.org> gotta go, thanks for all the help so far!
<re_irc>
<@jamesmunns:matrix.org> dngrs (spookyvisiongithub): I wonder if you are in fact getting multiple packets per poll/interval and you are stomping over the old packets?
<re_irc>
<@adamgreig:matrix.org> ooh yea, maybe worth looping over `serial.read()` until it returns 0 bytes?
fabic has joined #rust-embedded
<re_irc>
<@gauteh:matrix.org> Hi, anyone know if it is possible to impl a trait for an associated type: I want to implement From for i2c::Write::Error
<re_irc>
<@thejpster:matrix.org> I always try and use a four wire UART. FIFO fills up, you are not Clear To Send until it has space.
<re_irc>
<@newam:matrix.org> gauteh:matrix.org: Associated types have to be public IIRC, as long as the trait is defined in your crate you can implement it for that.
<re_irc>
<@gauteh:matrix.org> newam:matrix.org: I'm not in the crate that implements the i2c::Write trait, but in a driver crate where I have an Error enum which includes i2cwrite and i2cread errors. with from it would be more convenient to convert to my driver error enum
<re_irc>
<@newam:matrix.org> The associated error type from the `i2c::Write` trait should be public, and the error enum is in your crate so it will work :)
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@gauteh:matrix.org> Yes, but then I implement it fro that specific Error? I want to implement it for whatever i2c hal is supplied to the driver
<re_irc>
<@newam:matrix.org> Oh, I get what you're after now, sorry. One sec, let me see if I can find an example
<re_irc>
<@newam:matrix.org> You are right; I think this is the best you can do
<re_irc>
<@gauteh:matrix.org> That's what I am doing now
<re_irc>
<@gauteh:matrix.org> With From I could skip the map_err, right?
<re_irc>
<@newam:matrix.org> ```rs
<re_irc>
<@newam:matrix.org> Yeah, if you have a concrete type it would be
<re_irc>
<@newam:matrix.org> pin.set_low()?;
<re_irc>
<@gauteh:matrix.org> Ok, thanks
nexos_ has joined #rust-embedded
nexos has quit [Ping timeout: 252 seconds]
nexos_ is now known as nexos
nexos has quit [Ping timeout: 252 seconds]
<re_irc>
<@dirbaio:matrix.org> is it a good/bad practice to have the application call functions from the bootloader?
<re_irc>
<@dirbaio:matrix.org> like, have the bootloader expose some API for the application managing firmware updates
<re_irc>
<@dirbaio:matrix.org> or even share code. For exmaple, if the BL has to do crypto it'll have a copy of all the crypto code which is quite fat. The app could reuse it instead of bundling another copy of it
<re_irc>
<@pinealservo:matrix.org> firefrommoonlight:matrix.org: Nice example! I will have to look at that more closely later; thanks for sharing.
<re_irc>
<@cryptollision:matrix.org> is there a way to store the common functions in a region accessible by both the app and bootloader?
<re_irc>
<@dirbaio:matrix.org> normally the BL is in a different flash region where the app can simply jump to
<re_irc>
<@dirbaio:matrix.org> like, it'd require making all these functions `extern "C"` and put pointers to them at known addresses (like at fixed offsets after the vector table)
<re_irc>
<@dirbaio:matrix.org> but it's doable in principle
<re_irc>
<@cryptollision:matrix.org> would that make PIC impossible, or could you randomize the common region while keeping the function offsets static?
<re_irc>
<@cryptollision:matrix.org> or is PIC/PIE irrelevant for this use case?
<re_irc>
<@dirbaio:matrix.org> PIC is already very broken in embedded arm rust :P
<re_irc>
<@cryptollision:matrix.org> lol nevermind then
emerent is now known as Guest6374
emerent_ has joined #rust-embedded
Guest6374 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
Darius has quit [Ping timeout: 268 seconds]
Darius has joined #rust-embedded
<re_irc>
<@9names:matrix.org> it wouldn't make PIC impossible anyway, but you need to stop the compiler from assuming that the addresses are relative.
<re_irc>
<@9names:matrix.org> easiest way to do that is to store the addresses as ints and do int -> fn ptr conversion at runtime. it's definitely unsafe, potentially unsound, and LLVM sometimes miscompiles such code.
<re_irc>
<@9names:matrix.org> I don't think it's bad practice, but I think it depends on the functions?
<re_irc>
<@9names:matrix.org> like if it's a heavy crypto library I'd likely put it in it's own region so it could be updated without having to update the bootloader and risk bricking it
<re_irc>
<@dirbaio:matrix.org> yeah... in my case I can do brick-free bootloader updates though :D
<re_irc>
<@dirbaio:matrix.org> so it seems simpler to put them there