<re_irc> <@josfemova:matrix.org> does svd2rust support resetMask? I'm specifying that for some registers but seems to just say "ah yeah that's a 0" but idk if that is to be expected, just wanted to confirm
<re_irc> <@adamgreig:matrix.org> hm, I don't think it does, no
<re_irc> <@adamgreig:matrix.org> the underlying svd library does but it doesn't look to me like svd2rust uses it
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
cr1901_ is now known as cr1901
<re_irc> <@dngrs:matrix.org> what's a good way to structure this (using RTIC, fwiw):
<re_irc> <@dngrs:matrix.org> - I have a bunch of memory buffers that should be continuously DMA'd out over SPI, in a round-robin fashion
<re_irc> <@dngrs:matrix.org> - independent of that, every now and then I get some new data that requires me to process + write new content to those buffers. For that I need them *all*, which is kind of at odds with my current pattern, inside the DMA complete interrupt: `let next_buf = next_round_robin(); let (buffer, _) = transfer.next_transfer(next_buf).unwrap();` (in other words, 1 of n buffers is always owned by the transfer, and on...
<re_irc> ... each transfer complete I immediately start the next one)
<re_irc> <@dngrs:matrix.org> oh and - I'd like to minimize copying
<re_irc> <@adamgreig:matrix.org> if you don't care that much about writing to the buffer the DMA is reading, that seems easiest
<re_irc> <@dngrs:matrix.org> and the task receiving new data unfortunately doesn't have a `static` buffer, otherwise I could pass that to the dma interrupt alonside an update flag I guess
<re_irc> <@adamgreig:matrix.org> otherwise perhaps you can wait in a higher-priority task than the DMA complete interrupt for DMA to complete (poll TCIF), then write the final buffer after that
<re_irc> <@dngrs:matrix.org> (hm, I could maybe make it `static` though…)
<re_irc> <@adamgreig:matrix.org> or, yea, if you can arrange for the DMA complete interrupt to know what should be in the buffer once it's done, it can copy that in when it completes, after starting the next transfer....
<re_irc> <@adamgreig:matrix.org> but you'll want to be a bit careful that that doesn't happen while you're halfway done writing to that new data _or_ halfway done updating the dma buffer that's about to be swapped in
<re_irc> <@dngrs:matrix.org> thx! Ok so I'll try to make the data recv buffer `static`, and if that fails I'll just `unsafe{yolo()}`it
<re_irc> <@dngrs:matrix.org> adamgreig: ah, yeah, I'd probably toggle a "new data is ready" static bool; that's served me in the past at least
<re_irc> <@adamgreig:matrix.org> in my sort of similar application I have two framebuffers, one is drawn by the cpu and one is used to compute each of the 10 dma buffers which are then sent out to dma
<re_irc> <@dngrs:matrix.org> although I still have the feeling this should be more elegant since I have RTIC tasks anyway, ho hum
<re_irc> <@adamgreig:matrix.org> so whenever dma finishes one buffer, it can start the next of its 10
<re_irc> <@adamgreig:matrix.org> (the 10 are 10 bcm phases)
<re_irc> <@adamgreig:matrix.org> and whenever I finish drawing a framebuffer, I swap it with the one the dma process can use
<re_irc> <@adamgreig:matrix.org> with a very short lock around the swap
<re_irc> <@dngrs:matrix.org> lock = RTIC resoure lock? or something different
<re_irc> <@adamgreig:matrix.org> when all ten bcm phases are done, the next set are computed from the older framebuffer
<re_irc> <@adamgreig:matrix.org> RTIC lock yea
<re_irc> <@adamgreig:matrix.org> it's a bit more complicated because i only have one dma buffer and compute the next one as soon as that one finishes etc
<re_irc> <@adamgreig:matrix.org> but the gist is: two source buffers from which the four phase dma buffers are derived
<re_irc> <@dngrs:matrix.org> I suppose I can read your source :D if that's the walkclock thing which I suppose it is
<re_irc> <@adamgreig:matrix.org> i can draw the back buffer whenever
<re_irc> <@adamgreig:matrix.org> and when it's done, swap it for the front buffer
<re_irc> <@adamgreig:matrix.org> with a lock to ensure interrupts aren't reading the framebuffer at the moment I swap
<re_irc> <@dngrs:matrix.org> coming to think of it, I have tons of free RAM, maybe I should just do double buffering of those 4 buffers
<re_irc> <@adamgreig:matrix.org> yea, maybe that's simplest in your case, just have a front and back set of 4 buffers
<re_irc> <@adamgreig:matrix.org> write to the back ones when you get new data, and swap them for the front ones when the dma completes
<re_irc> <@dngrs:matrix.org> pretty sure the most simple, I guess I was subconsciously avoiding it because my precioussss memory efficiency
<re_irc> <@dngrs:matrix.org> but since I was able to get rid of the silly power-of-2 size requirement last night it's not so bad anymore
<re_irc> <@adamgreig:matrix.org> sram costs the same electricity whether you're storing useful data in it or not :P
<re_irc> <@dngrs:matrix.org> haha
<re_irc> <@dngrs:matrix.org> yeah I mean, I keep running out of memory. But turns out a lot of those problems came from a really nasty bug in an LCD display crate
<re_irc> <@dngrs:matrix.org> it ships with examples, and for those it needs a `memory.x`, which gets picked up by `flip-link` and reduces my sweet 128kb to a mere 20
<re_irc> <@dngrs:matrix.org> probably PR-fixing that tomorrow
<re_irc> <@dngrs:matrix.org> (also, having done 20+ years of exclusively desktop + huge servers + beefy smartphone development, I find resource constrained envs an interesting challenge/puzzle)
<re_irc> <@adamgreig:matrix.org> wonder why flip-link is getting it, that doesn't sound right
<re_irc> <@adamgreig:matrix.org> perhaps you need your own build.rs to copy your memory.x into OUT_DIR to overwrite one from the lcd driver
<re_irc> <@dngrs:matrix.org> answer from a colleague was
<re_irc> <@dngrs:matrix.org> > I think flip-link searches for memory.x only in the library search path -- like a regular linker does. so, if ssd1331 is generating a memory.x and appending a path to the library search path it could make the regular linker use the wrong size for RAM
<re_irc> <@dngrs:matrix.org> the culprit: https://github.com/jamwaffles/ssd1331/blob/master/build.rs
<re_irc> <@adamgreig:matrix.org> where's your memory.x?
<re_irc> <@dngrs:matrix.org> still strange that it only gets picked up when I enable `flip-link`
<re_irc> <@dngrs:matrix.org> my own `memory.x` is in my package root
<re_irc> <@adamgreig:matrix.org> the linker searches the local working directory first so will pick up your one before anything in OUT_DIR
<re_irc> <@adamgreig:matrix.org> flip-link presumably does not do the same as the linker
<re_irc> <@dngrs:matrix.org> so you're suggesting to copy the correct `memory.x` to `OUT_DIR`?
<re_irc> <@dngrs:matrix.org> I mean, sure I can do that, but that sounds like patching around a dodgy situation
<re_irc> <@adamgreig:matrix.org> though that sounds like https://github.com/knurling-rs/flip-link/pull/22
<re_irc> <@adamgreig:matrix.org> but yea, I would copy your memory.x to OUT_DIR, it's the defacto standard thing people do now (much as I prefer leaving it in the crate root), not least because the latter doesn't work well with workspaces
<re_irc> <@adamgreig:matrix.org> (the linker searches the workspace dir, not the crate dir)
<re_irc> <@adamgreig:matrix.org> having a build.rs do that also lets you set rerun-if-changed on memory.x so it'l rebuild when you change that file which is a little bonus too
<re_irc> <@dngrs:matrix.org> hmm. I'm not in a workspace
<re_irc> <@dngrs:matrix.org> adamgreig: ok, I wasn't aware of that - it still sounds not quite right to me that this needs to be solved separately for every new project; my philosophy is that projects should be as simple to set up as possible, and not recreate effort every time. Not sure which part of the ecosystem I'd hold responsible here though… I'd say the root problem is that no part of `cargo` is semantically aware of `memory.x`
<re_irc> <@adamgreig:matrix.org> hmmm
<re_irc> <@adamgreig:matrix.org> I think https://github.com/knurling-rs/flip-link/blob/main/src/main.rs#L212 is the bug
<re_irc> <@adamgreig:matrix.org> flip-link searches all the configured linker directories _and then_ current directory
<re_irc> <@adamgreig:matrix.org> linker searches current directory then configured directories
<re_irc> <@dngrs:matrix.org> ooooyyyyyyyyyy
<re_irc> <@adamgreig:matrix.org> I mean it's almost 3am here and I'm about to go to bed so I might be completely off the mark
<re_irc> <@dngrs:matrix.org> lemme just quickly try and swap that around
<re_irc> <@adamgreig:matrix.org> but that seems plausible
<re_irc> <@dngrs:matrix.org> 3:40 here!
<re_irc> <@dngrs:matrix.org> :D
<re_irc> <@adamgreig:matrix.org> if so it's a regression of the fix in https://github.com/knurling-rs/flip-link/pull/22
<re_irc> <@dngrs:matrix.org> I'll have a stab at that, it sounds very plausible
<re_irc> <@dngrs:matrix.org> thx for hunting it down!
<re_irc> <@dngrs:matrix.org> will update with findings
<re_irc> <@adamgreig:matrix.org> I think "having a build.rs copy memory.x to some useful place and tell cargo about it" shouldn't be that bad, these days you can also use build.rs to tell cargo to add -Tlink.x to the linker arguments, so you don't need RUSTFLAGS in .cargo/config.toml, which is another win
<re_irc> <@adamgreig:matrix.org> eg we have build.rs in https://github.com/rust-embedded/cortex-m-quickstart
<re_irc> <@adamgreig:matrix.org> still I take your point about minimising how much stuff a new project needs
<re_irc> <@adamgreig:matrix.org> there are other options: some HALs will set up a default memory.x based on the device you select, for example
<re_irc> <@dngrs:matrix.org> yeah, I think the HAL's should be the first go-to, but with configurable override
<re_irc> <@adamgreig:matrix.org> but you still need to pass -Tlink.x to the linker somehow (eg via .cargo/config.toml or a build script) and no other crate can do that for you
<re_irc> <@adamgreig:matrix.org> the configurable override is very easy: have your own memory.x, in the crate dir it'l take priority or use build.rs to copy it into OUT_DIR on top of the HAL's
<re_irc> <@dngrs:matrix.org> aye - again an issue of "as far as cargo is concerned, `-Tlink.x` is just a string of characters" I'd say
<re_irc> <@adamgreig:matrix.org> yea
<re_irc> <@dngrs:matrix.org> not sure I'd want to design a build system that's more aware of those things though :D :D
<re_irc> <@adamgreig:matrix.org> cargo only recently gained the ability for a binary crate to add linker flags via build.rs
<re_irc> <@dngrs:matrix.org> ooh, nice
<re_irc> <@adamgreig:matrix.org> but it doesn't extend to libraries doing it, otherwise cortex-m-rt could add it for you
<re_irc> <@dngrs:matrix.org> mhm yeah, sigh
<re_irc> <@adamgreig:matrix.org> of course I still end up with a .cargo/config.toml to set the default target: https://github.com/adamgreig/walkclock-public/blob/master/firmware/.cargo/config.toml
<re_irc> <@adamgreig:matrix.org> but it's a lot shorter than it used to be
<re_irc> <@adamgreig:matrix.org> there's talk of adding target per-binary to Cargo.toml instead, too
<re_irc> <@dngrs:matrix.org> I guess this discussion will at least lead to me writing some sentences in *some* embedded Rust documentation / crate README
<re_irc> <@dngrs:matrix.org> adamgreig: ooh, very nice indeed
<re_irc> <@adamgreig:matrix.org> bedtime, good luck
<re_irc> <@dngrs:matrix.org> good night!
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@ia0:matrix.org> lkostka:matrix.org: I have a project doing that: https://github.com/ia0/onekibu/blob/05a2b433af8174b87d7d9f2481147e4ba04878c4/firmware/Cargo.toml#L27
<re_irc> <@ia0:matrix.org> But I use xtask to set the correct feature as well as use the correct memory.x
<re_irc> <@ia0:matrix.org> It's making the command line simpler to use
<re_irc> <@gauteh:matrix.org> Hi, I'm working on a small ocean buoy measuring waves and drift for a research project. Firmware is written in rust, and I've written a HAL for the board I am using (Ambiq Apollo3, as mounted on Sparkfun Artemis Nano). I was wondering if you have any suggestions for alternative prototyping/dev-boards that may have similar qualities (low-power, enough SPI peripherals, fast enough to do some simple on-board...
<re_irc> ... processing like FFTs etc), but with more complete Rust support?
<re_irc> <@k900:0upti.me> One of the bigger STM32s?
<re_irc> <@gauteh:matrix.org> Yeah, maybe. Like on the discovery boards from STM?
<re_irc> <@k900:0upti.me> Possibly
<re_irc> <@k900:0upti.me> There's a lot of STM32 boards
<re_irc> <@k900:0upti.me> Like, A LOT a lof
<re_irc> <@gauteh:matrix.org> Yeah! I'm totally lost already!
<re_irc> <@nihal.pasham:matrix.org> So, I've been working on this out (as a side project) - https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials/discussions/139. In case anyone has any pointers, love to know what I might be missing.
<re_irc> <@dngrs:matrix.org> gauteh:matrix.org: The F401/F411 should be plenty fast. Has DSP for FFT, too
<re_irc> <@dngrs:matrix.org> It's one of the most common cheap ones, search for "usb-c pill"
xnor has quit [Ping timeout: 250 seconds]
xnor has joined #rust-embedded
<re_irc> <@gauteh:matrix.org> dngrs:matrix.org: https://therealprof.github.io/blog/usb-c-pill-part1/ ?
<re_irc> <@dngrs:matrix.org> Yup!
<re_irc> <@gauteh:matrix.org> Nice, bought one to test with. Not super-much ram, but there was some extra flash I can use for my queues..
<re_irc> <@lkostka:matrix.org> ia0:matrix.org: thx
<re_irc> <@erdemu:matrix.org> Hi guys
<re_irc> <@erdemu:matrix.org> I have a very very beginner question
<re_irc> <@erdemu:matrix.org> I've been playing around with teensy4-rs
<re_irc> <@erdemu:matrix.org> I saw this error while compiling pwm example, I really can't see why delay or pins are not available, I'm sure it's a silly mistake on my part but
<re_irc> <@erdemu:matrix.org> This is the use statement I copied over from the examples folder
<re_irc> <@erdemu:matrix.org> do you have any idea ?
<re_irc> <@k900:0upti.me> They had a few breaking changes a few hours ago: https://github.com/mciantyre/teensy4-rs/commits/master
<re_irc> <@k900:0upti.me> Might be related
<re_irc> <@erdemu:matrix.org> yes related thanks !!
<re_irc> <@thejpster:matrix.org> I had a go at compiling some relocatable thumbv6m code yesterday. It didn't go that well.
<re_irc> <@thejpster:matrix.org> Found a Rust ticket on vtables not being correct. And a link to a log on here of jamesmunns wanting to fix the same issue for the exact same project
<re_irc> <@dngrs:matrix.org> oh no
<re_irc> <@dngrs:matrix.org> ('eve :) )
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 245 seconds]