<re_irc>
<@u007d:matrix.org> : Ok, thanks--that's good to know.
starblue3 has quit [Ping timeout: 246 seconds]
starblue3 has joined #rust-embedded
<re_irc>
<@avery71:matrix.org> : It seems interesting, but unless I'm missing something it doesn't seem that much better than the alternatives shown on the graphs
<re_irc>
<@whitequark:matrix.org> some of you might enjoy this o:3
<re_irc>
<@whitequark:matrix.org> the STM32 DMA can write to its own registers, which means you can potentially write code using just the DMA peripheral
<re_irc>
<@avery71:matrix.org> I finally decided to try to wrap my mind around DMA, and right now I am thinking about use cases and I just can't seem to think of any good use cases. Quite frankly I probably don't really understand it because it feels like most articles I find use a lot of words to say nothing
<re_irc>
<@whitequark:matrix.org> DMA in general?
<re_irc>
<@avery71:matrix.org> yeah
<re_irc>
<@whitequark:matrix.org> DMA is pretty much just hardware accelerated "copy_from_slice"
<re_irc>
<@whitequark:matrix.org> you can use it as literally that, but in most cases your source or destination is a peripheral. consider, for example, Ethernet
<re_irc>
<@whitequark:matrix.org> you could use DMA to make your Ethernet peripheral read packet payload from RAM (or write to RAM) while the CPU is free to do other tasks
<re_irc>
<@whitequark:matrix.org> it's like being able to spawn a thread on your embedded system but the only thing it can do is copy
<re_irc>
<@whitequark:matrix.org> does that make sense?
<re_irc>
<@avery71:matrix.org> Wouldn't you want to actually do something with that ethernet data and not just move it
<re_irc>
<@whitequark:matrix.org> well, yes. however the first thing you have to do is to move it because the peripheral does not have any place to store the _next_ packet
<re_irc>
<@whitequark:matrix.org> so you use DMA to buffer the packet
<re_irc>
<@whitequark:matrix.org> if you're using DMA with ADC or DAC, it's helpful because you can make DMA activate on a timer's tick, and now you have transfers happening exactly each _n_ cycles, without thinking about interrupt latency, priorities, critical sections, etc
<re_irc>
<@avery71:matrix.org> And I'm guessing in a DMA controller you can set a buffer location, size, and that you want it to be a cyclical buffer
<re_irc>
<@whitequark:matrix.org> yep
<re_irc>
<@whitequark:matrix.org> and a half full interrupt, usually
<re_irc>
<@whitequark:matrix.org> +/ half empty
<re_irc>
<@whitequark:matrix.org> a lot of embedded programming boils down to combining a bunch of stuff in your SoC like lego bricks, and DMA makes other peripherals cheaper
<re_irc>
<@whitequark:matrix.org> so in a grown-up system like your typical Intel or AMD PC, every peripheral will realistically have its own DMA capability, but in a microcontroller that translates into cost
<re_irc>
<@whitequark:matrix.org> so you have a few DMA channels, many peripherals, and the designer can combine them in interesting ways
<re_irc>
<@avery71:matrix.org> Oh yeah, I've had some fun combining timers and ADCs, but I ended up using interrupts to get the data from the ADC to a buffer. I can see how DMA would have helped there
<re_irc>
<@whitequark:matrix.org> it's actually not _that_ expensive to add bus initiating capability to a peripheral, but in ARM SoCs, peripherals live on the APB bus, which is so simplified it doesn't let peripherals add that at all
<re_irc>
<@omar_u8:matrix.org> : its useful for applications that have hardware that generates a ton of data and you dont want to bother the CPU to handle until all transactions are done. Otherwise CPU would be force to deal with memory transaction before next event happens.
<re_irc>
Example, if you want to implement a software filter and need x amount of samples before applying your filter algo, everytime the ADC acquires a sample the CPU would have to handle the memory transfer so that the next conversion doesn't overwrite the current sample. The CPU would have to keep doing that until all conversions complete and then apply the filter algo.
<re_irc>
<@whitequark:matrix.org> and using APB vs e.g. AHB does add up
<re_irc>
<@whitequark:matrix.org> it's actually not _that_ expensive to add bus initiating capability to a peripheral, but in ARM SoCs, most peripherals live on the APB bus, which is so simplified it doesn't let peripherals add that at all
<re_irc>
<@whitequark:matrix.org> it's actually not _that_ expensive to add bus initiating capability to a peripheral, but in ARM SoCs, most peripherals live on the APB bus, which is so simplified it doesn't let peripherals initiate memory accesses that at all
<re_irc>
<@omar_u8:matrix.org> +With DMA, you can set it up in a way that everytime an ADC conversion is complete, the DMA would handle the transfer without involving the CPU. When all transactions are done, the CPU can jump in and apply the filter algo.
<re_irc>
<@omar_u8:matrix.org> * forced to deal with memory transactiond
<re_irc>
<@omar_u8:matrix.org> its useful for applications that have hardware that generates a ton of data and you don't want to bother the CPU to handle it until all transactions are done. Otherwise, CPU would be forced to deal with memory transactions before the next event happens.
<re_irc>
For example, if you want to implement a software filter and needs x amount of samples before applying your filter algo, every time the ADC acquires a sample the CPU would have to handle the memory transfer so that the next conversion doesn't overwrite the current sample. The CPU would have to keep doing that until all conversions are complete and then apply the filter algo.
<re_irc>
With DMA, you can set it up in a way that every time an ADC conversion is complete, the DMA would handle the transfer without involving the CPU. When all transactions are done, the CPU can jump in and apply the filter algo.
<re_irc>
<@whitequark:matrix.org> (in other words, the cost is in the interconnect, not in the peripheral itself, somewhat unintuitively)
<re_irc>
<@avery71:matrix.org> Oh goodness, if it wasn't nearly 2am I would be wanting to pull out the datasheets to remember which peripherals were on which bus
<re_irc>
<@whitequark:matrix.org> low-speed stuff like most timers, ADC/DAC, GPIOs lives on APB, Ethernet lives on AHB. some timers are on AHB i think purely because of clock gating reasons?
<Darius>
can't you gate the peripheral clocks separately though?
<re_irc>
<@whitequark:matrix.org> i imagine you can gate the entire APB interconnect
<re_irc>
<@whitequark:matrix.org> i'm just speculating re: timers though
<Darius>
yeah
<Darius>
well I am sure they have various use cases in mind and try and compromise in a way that makes sense to them, but hard to figure it out without a crystal ball
<re_irc>
<@whitequark:matrix.org> sometimes it's possible to narrow it down by looking which things are possible only with timers on AHB, or by reading appnotes
<re_irc>
<@whitequark:matrix.org> I would normally do this before speculating but I feel tired tonight
<Darius>
wild arse speculation is more fun though
<re_irc>
<@avery71:matrix.org> I might break out some C and datasheets tomorrow and write up a little DMA program, but my board is states away so I won't be able to test it out
<re_irc>
<@9names:matrix.org> > which means you can potentially write code using just the DMA peripheral
<re_irc>
if anyone wants a concrete example of this style of programming, this is an interesting read:
<re_irc>
<@jordens:matrix.org> : Also the pros and cons and things to consider when using "serde" traits to implement a given protocol.
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> : Whatcha mean by using serde traits for the protocol? Like trying to impl Serialize for a whole wire format?
<re_irc>
<@jordens:matrix.org> yes.
<re_irc>
<@jamesmunns:beeper.com> Huh. I probably wouldn't recommend that, but maybe you have a counter example :)
<re_irc>
<@jordens:matrix.org> IIRC it was you who at least pointed out the possibility to do so way back when.
<re_irc>
<@jamesmunns:beeper.com> I do think I had someone else ask me about that tho - imo serde isn't a good match for fitting a _protocol_ rather than just a _payload_
<re_irc>
<@jamesmunns:beeper.com> : Ah, it is very possible I was much dumber and more naive on any day before today
<re_irc>
<@jordens:matrix.org> I think a good tl;dr is: "It did work, barely"
<re_irc>
<@jamesmunns:beeper.com> Yeah, that makes sense. I was so preoccupied about what could be done, I never stopped to think about whether it should be done :)
kenny has quit [Ping timeout: 245 seconds]
Dr_Who has quit [Quit: So long and thanks for all the bits.]
<re_irc>
<@ryan-summers:matrix.org> The gist for MQTT was that we had to make custom wrapper types for data types that MQTT has that aren't rust native types, then you have to manually impl serde traits on them. Good examples are variants. MQTT also allows for portions of the packet to be entirely omitted in the happy case, which is weird to represent
<re_irc>
<@ryan-summers:matrix.org> We do support zero-copy deserialization in the end. Don't know if it was worth the overhead
<re_irc>
<@ryan-summers:matrix.org> I'd really like to do a zero-copy serialization process to, where you serialize directly into the socket (there's ultimately a copy in smoltcp, but whatevs). Only problem with MQTT is you have to precalculate the whole packet size, and that's nontrivial
<re_irc>
<@ryan-summers:matrix.org> * too,
<re_irc>
<@jordens:matrix.org> Ha. Why didn't I know about llvm-mca before? So cool for getting a feel for the instruction set/cpu/pipeline/scheduling!
<re_irc>
<@whitequark:matrix.org> long time no see,
<re_irc>
<@whitequark:matrix.org> I wonder if that one is an MCA issue or a more general one in the MC layer?
<re_irc>
<@whitequark:matrix.org> the MC assembly parser doesn't tend to get as much attention as it perhaps should
<re_irc>
<@jordens:matrix.org> It doesn't look like a tool that sees as much usage (and tests) as the rest of LLVM. I can believe that there is a bit of fragility. Still awesome and useful.
<re_irc>
<@almindor:matrix.org> does anyone know how to force-merge a PR skipping checks? We have an gihub action being removed as part of the PR change but github is stuck on "waiting for blobs check" since it still expects it. https://github.com/rust-embedded/riscv-rt/pull/118
<re_irc>
<@almindor:matrix.org> I guess I could merge manually on local and push to master :D
<re_irc>
<@jordens:matrix.org> Change the repo settings and cycle it?
<re_irc>
<@almindor:matrix.org> what setting though? the action is defined (and remove here) in the workflow file
<re_irc>
<@dirbaio:matrix.org> settings -> branches -> edit -> Status checks that are required. -> remove that check
<re_irc>
<@almindor:matrix.org> ah that worked, thanks! I always go looking for this stuff in actions
<re_irc>
<@dngrs:matrix.org> : There's a talk about doing zero copy packets in Rust, you've probably seen it?
jr-oss has quit [Ping timeout: 260 seconds]
duderonomy has quit [Read error: Connection reset by peer]
duderonomy has joined #rust-embedded
duderonomy has quit [Read error: Connection reset by peer]
<re_irc>
<@ryan-summers:matrix.org> : No I haven't! Please do link, would love to see a proposal. My idea was serialize directly into the socket and treat the socket as a buffer
<re_irc>
<@dngrs:matrix.org> : sure, let me search for it