<re_irc>
So afaik, defmt-test doesn't do all of what you described, but does do some.
<re_irc>
<@jamesmunns:beeper.com> Hey Phil :)
<re_irc>
<@shakencodes:matrix.org> : Hey James! Long time!
<re_irc>
<@jamesmunns:beeper.com> Generally: defmt test will run individual tests on the target, returning stdout (more or less), as well as an overall pass/fail for each test
<re_irc>
<@jamesmunns:beeper.com> you could use it to load multiple test binaries, which may or may not exercise real hardware, and will report back whatever you "print" in the test. It doesn't really include a "stdin" channel for you - though if you have other interfaces (serial, ethernet), those will still work - if you set them up during the test.
<re_irc>
<@jamesmunns:beeper.com> however it is much more aimed at "unit testing" rather than "integration or system testing"
<re_irc>
<@jamesmunns:beeper.com> Which you seem to be hinting at for certain modes of operation, that might be more reasonably set up as instrumentation/test-mode commands in a "more real" firmware image.
<re_irc>
<@dirbaio:matrix.org> so, for factory testing, or for firmware testing in CI? they're very different
<re_irc>
factory testing is "assume the firmware works, test if the hardware works"
<re_irc>
firmware testing is "assume the hardware works, test if the firmware works"
<re_irc>
<@shakencodes:matrix.org> I am not looking to execute tests on the hardware (but will keep defmt-test in mind if I do). I am looking to do integration/system testing as you suggest. And my intention is to leave the test-modes in the production system, with a private (RTT) channel to enable/disable them.
<re_irc>
<@shakencodes:matrix.org> Firmware testing in CI.
<re_irc>
<@jamesmunns:beeper.com> Ah! In that case you probably can just use "cargo test" :D
<re_irc>
<@dirbaio:matrix.org> for factory testing I'm building one firmware per test, then a Rust binary in the PC loads+runs them with probe-rs and defmt-decoder as a lib, and also programmatically controls the other stuff
<re_irc>
<@dirbaio:matrix.org> for CI testing "probe-run" should do
<re_irc>
<@dirbaio:matrix.org> you can use "defmt-test" too, but you don't have to
<re_irc>
nope, misunderstood
<re_irc>
<@jamesmunns:beeper.com> ~Ah! In that case you probably can just use "cargo test" :D~
<re_irc>
<@dirbaio:matrix.org> just bare "probe-run" can already work
<re_irc>
<@dirbaio:matrix.org> do "cortex_m::asm::bkpt()" to exit with success, "panic!()" to exit with failure
<re_irc>
<@jamesmunns:beeper.com> * ~~Ah! In that case you probably can just use "cargo test" :D~~
<re_irc>
<@dirbaio:matrix.org> though if you want custom rtt channels etc you'll probably have to go the "custom" route using probe-rs+defmt-decoder as a library :S
<re_irc>
<@dirbaio:matrix.org> you could do shell pipe spaghetti with "rtthost" and "defmt-print" but that'll probably be more fragile :D
<re_irc>
<@shakencodes:matrix.org> How do I let the test framework interact with the probe-rs RTT channel? When I use probe-rs, it ends up with a terminal suited to human interaction. I feel like there is a command line flag I am missing!
<re_irc>
<@jamesmunns:beeper.com> You could use "probe-rs" as a library, not "probe-rs-cli", or there might be a way to open (or pipe?) rtt channels to a named pipe or something instead of stdin/stdout
<re_irc>
<@shakencodes:matrix.org> Thank you! I will play with probe-rs as a library then. (I kind of hoped for a small "attach to CLI" step now, and then bite off using the library in a few months.)
<re_irc>
<@jamesmunns:beeper.com> not sure if you can get a "clean pipe" of one up and one down channel, but if not, that project is a very good starting point for using probe_rs as a library to talk rtt
<re_irc>
<@jamesmunns:beeper.com> : (this is the "rtthost" dirbaio was referring to here ^)
<re_irc>
<@jamesmunns:beeper.com> but yeah, I'd probably agree "don't do rtt AND defmt-over-rtt"
<re_irc>
<@jamesmunns:beeper.com> but "one rtt up/down pair" should work pretty well
<re_irc>
<@shakencodes:matrix.org> Is rtthost a case where I build this locally and run rtthost out of its target directory? Or is there a "cargo install" target?
<re_irc>
so "cargo install rtthost" should also work
<re_irc>
<@shakencodes:matrix.org> Thank you to both for your help! (I'm going to open source the framework that comes out of this. I'm tired of building this anew when moving from company to company...)
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc>
<@frank10:matrix.org> "I'll help anyone interested on how to earn 100k in just 72hours from the crypto market. But you will have to pay me my commission! when you receive your profit! if interested send me a direct message https://t.me/victormarck by asking me HOW
<re_irc>
<@k900:0upti.me> lmao
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Hey FYSA for anyone using RTIC: "Shared" and "Local" are now no longer private. This has an important implication for code structure: The "init" fn content can be delegated to a diff module. (https://github.com/rtic-rs/rtic/pull/730)
<re_irc>
<@firefrommoonlight:matrix.org> (Github only pending release)
<re_irc>
<@firefrommoonlight:matrix.org> Hey FYSA for anyone using RTIC: "Shared" and "Local" are now no longer private. This has an important implication for code structure: The "init" fn content can be delegated to a different module. (https://github.com/rtic-rs/rtic/pull/730)
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@larunite:matrix.org> Hello! I have a question about DMA on embedded - What (if anything) do I need to do to mark the destination array as potentially changing at arbitrary times?
<re_irc>
<@ryan-summers:matrix.org> But in general, the answer is that what you are asking is not safe in rust code because it violates mutability semantics. If DNA can mutate a mut variable, there would be two logical owners of the buffer
<re_irc>
<@ryan-summers:matrix.org> * DMA can mutate a `mut`
<re_irc>
<@larunite:matrix.org> Yeah that's fine, I'm happy to manage the safety
<re_irc>
<@larunite:matrix.org> cos it's DMA, it's a mutability nightmare :P
<re_irc>
<@larunite:matrix.org> I just don't want the compiler to do anything like "Oh no one ever writes through this pointer so I can optimise it all out"
<re_irc>
<@ryan-summers:matrix.org> We use DMA with the H7 in double buffered mode just fine in safe rust
<re_irc>
<@ryan-summers:matrix.org> If you want a sample of DMA traits, you can take a look at the STM32H7 Hal as well :)
<re_irc>
<@larunite:matrix.org> ok cool. Out of curiosity do you know how those manage volatility under the hood?
<re_irc>
<@larunite:matrix.org> to avoid the compiler optimising it out?
<re_irc>
<@jamesmunns:beeper.com> Fences will inhibit some optimizations, if you have data that can be changed "magically" it should almost certainly be inside an UnsafeCell (imo)
<re_irc>
<@larunite:matrix.org> Is UnsafeCell appropriate for this kind of thing? I thought that was for interior mutability
<re_irc>
<@jamesmunns:beeper.com> Fences are also used to make sure certain sequencing is respected, e.g. writes to a data region occur BEFORE you start DMA
<re_irc>
<@jamesmunns:beeper.com> Imo, DMA is another "thread" mutating a buffer for you. If you hold a mut ref to a slice, this should be impossible in safe rust
<re_irc>
<@dngrs:matrix.org> I think the question goes in the direction of "how to say in Rust: this is volatile, don't optimize out consecutive reads" for example
<re_irc>
<@jamesmunns:beeper.com> Fences and pointer escaping GENERALLY allow this to work with normal slices, but imo it isn't as correct as always making sure DMA writes happen to an unsafe cell
<re_irc>
<@dngrs:matrix.org> (ptr has "read_volatile" for that)
<re_irc>
<@larunite:matrix.org> It's that sort of thing - but kind of more annoying? Because I want to be able to assert "yes I am _sure_ the DMA is not going to alter the content of this buffer during this section"
<re_irc>
<@jamesmunns:beeper.com> How to do DMA/MMIO correctly is currently "vibes", it isn't super well specified in rusts memory model
<re_irc>
<@larunite:matrix.org> Like for example if I'm responding to the DMA half complete interrupt, I might want to copy the first half of the buffer out somewhere "safe". I don't want every single read of the buffer to be gated because that will be slow. I am relying on that interrupt finishing before the DMA overwrites the data
<re_irc>
<@dngrs:matrix.org> "ptr::vibe()"
<re_irc>
<@jamesmunns:beeper.com> But this is more theoretical opinion than practical fact ATM :)
<re_irc>
<@jamesmunns:beeper.com> : What do you mean by gated?
<re_irc>
<@larunite:matrix.org> as in during that interrupt, I don't require every single read of the buffer to be treated as volatile
<re_irc>
<@jamesmunns:beeper.com> UnsafeCell is just a container with different llvm attrs that says "don't assume this won't magically change"
<re_irc>
<@larunite:matrix.org> I am asserting that data is not volatile _during that interrupt_
<re_irc>
<@larunite:matrix.org> But globally, I do need that assertion to hold
<re_irc>
<@larunite:matrix.org> But globally, it is volatile
<re_irc>
<@jamesmunns:beeper.com> Honestly I'm not sure if you can correctly mix volatile and non volatile access like that, but it's been a while since I tried to understand the volatile parts of C and Rusts memory models
<re_irc>
<@larunite:matrix.org> I guess once you ".get()" the unsafe cell, then the pointer you get back
<re_irc>
<@larunite:matrix.org> because it's a *mut, it now assumes exclusive access
<re_irc>
<@larunite:matrix.org> which is the correct model
<re_irc>
<@jamesmunns:beeper.com> *mut is not exclusive
<re_irc>
<@jamesmunns:beeper.com> &mut is
<re_irc>
<@jamesmunns:beeper.com> Once you make mut ref, yes, you must guarantee exclusive access as long as that ref exists
<re_irc>
<@jamesmunns:beeper.com> (even with an UnsafeCell)
<re_irc>
<@larunite:matrix.org> Yes okay
<re_irc>
<@larunite:matrix.org> So the approach might be to have an "UnsafeCell" containing the array, then when I know I have exclusive access (because I'm sure I will be done by the time the DMA comes around) I can obtain a reference to the contents, copy it out and then discard the reference and return
<re_irc>
<@jamesmunns:beeper.com> That sounds right! You do also need the fences to make sure the DMA start/stops are not reordered relative to your data accesses of the UnsafeCell contents
<re_irc>
<@jamesmunns:beeper.com> e.g.
<re_irc>
- Write to buf
<re_irc>
- Start DMA
<re_irc>
- Fence
<re_irc>
- Stop DMA
<re_irc>
- Fence
<re_irc>
- Read from buf
<re_irc>
<@larunite:matrix.org> I will probably never stop the DMA, it'll be circular and I'll respond to its interrupts to shovel out the data
<re_irc>
<@larunite:matrix.org> but yes point taken for starting it (y)
<re_irc>
<@jamesmunns:beeper.com> : I'm honestly not sure THEORETICALLY if this could be sound, but if you do the above it'll PRACTICALLY work imo
<re_irc>
<@larunite:matrix.org> Sound under what model?
<re_irc>
<@jamesmunns:beeper.com> Rust's model. Like, if DMA wrote to a region you held a slice of, I'm pretty sure they would be ub
<re_irc>
<@jamesmunns:beeper.com> (if your interrupt was delayed and you missed the "safe" copy window)
<re_irc>
<@jamesmunns:beeper.com> I'm being pedantic now tho, probably not practically useful for what you are trying to do.
<re_irc>
<@larunite:matrix.org> yes, indeed. But that's what the unsafety assertion is I suppose
<re_irc>
<@larunite:matrix.org> When I ".get()" the UnsafeCell I am saying that I'm sure I've checked my interrupt fires in time and so forth
<re_irc>
<@jamesmunns:beeper.com> Seems reasonable if you can guarantee that!
<re_irc>
<@firefrommoonlight:matrix.org> : Not a complete answer, but you can use static arrays as a default to ensure they never go out of scope
<re_irc>
<@larunite:matrix.org> On a core that supports double buffering you can do better, I think. Because you know the DMA will never come back and write over your "first half" unless you let it. And so you can guarantee safety
<re_irc>
<@larunite:matrix.org> But my lowly F3 does not :'(
<re_irc>
<@firefrommoonlight:matrix.org> Then evaluate when it will change. Ie, what does *arbitrary* mean. The general case is hard. A specific cases for a given application is usually not
<re_irc>
<@dngrs:matrix.org> : There are existing abstractions on top of DMA, might wanna check them out
<re_irc>
<@larunite:matrix.org> I believe for the F3 the DMA support is limited to single shot, and only tied to a peripheral
<re_irc>
<@larunite:matrix.org> which is comparatively neat
<re_irc>
<@larunite:matrix.org> I would like to get circular dma working :)
<re_irc>
<@dngrs:matrix.org> Ah ok
<re_irc>
<@dngrs:matrix.org> I'm also interested in circular (F4 though), haven't yet checked if the hal does it
<re_irc>
<@firefrommoonlight:matrix.org> What are you trying to use DMA for?
<re_irc>
<@firefrommoonlight:matrix.org> We can have a discussion on general uses and end with no satisfying conclusion
<re_irc>
<@larunite:matrix.org> : has given me an answer I am happy to progress with :)
<re_irc>
<@firefrommoonlight:matrix.org> But if you have a specific requirement, we can give specific recommendations
<re_irc>
<@larunite:matrix.org> But I am using DMA for interface bridging
<re_irc>
<@larunite:matrix.org> IE streaming serial communications from one peripheral over to a second peripheral
<re_irc>
<@firefrommoonlight:matrix.org> Oh interesting. I think some MCUs like stm32 can do peripheral-to-peripheral xfers directly, but I've never tried
<re_irc>
<@firefrommoonlight:matrix.org> Of course you could put it in memory as an intermediate if not
<re_irc>
<@larunite:matrix.org> The F3 and F0 cannot which are our cores of choice
<re_irc>
<@firefrommoonlight:matrix.org> I would replace with G4 and G0 to dodge this
<re_irc>
<@larunite:matrix.org> To maybe whet the whistle even more, we couldn't do p-to-p DMA regardless.
<re_irc>
This application requires switching various serial lines. IE we have serial controllers A/B/C and we need to be able to connect A to B, B to C, A to C, whatever
<re_irc>
<@larunite:matrix.org> But if you use hardware flow control to disable one of the peripherals, it usually doesn't stop sending you data for a handful of bytes
<re_irc>
<@firefrommoonlight:matrix.org> Sounds like you have a plan. This should be straightforward. I guess the play now is get hacking and post back if it doesn't work
<re_irc>
<@larunite:matrix.org> So even after you switch, you need to be ready to buffer incoming data from inactive serial peripherals
<re_irc>
<@larunite:matrix.org> Yeah I am just messing about with this really - We are doing this at work, in C, on existing hardware and with existing code. So there's no world where it ends up in Rust.
<re_irc>
<@larunite:matrix.org> But in the spirit of long term converting them all into rustaceans i want to know how hard it _would_ have been ;P
<re_irc>
<@larunite:matrix.org> Thank you for your help everyone that was very useful
<re_irc>
<@jpc:ejpcmac.net> Hello folks, I am getting curious today, and I’m trying to find traces of early Rust support on embedded. I’ve found the initial commit of "xargo" being on 2016-03-26, but does anyone know when was the first Rust code run on an embedded target?
<re_irc>
<@bitslinger:matrix.org> I definitely remember people trying it pre-1.0, crazy how long ago that was
<re_irc>
<@bitslinger:matrix.org> zinc rings a bell for sure, maybe I saw a hacker news post on it
<re_irc>
<@jamesmunns:beeper.com> yeah, zinc-rs was the most active thing when I got started with embedded+rust around 2016
<re_irc>
<@jpc:ejpcmac.net> : With the main function returning an "int". Seems pretty exotic :)
<re_irc>
<@jpc:ejpcmac.net> I’ve never heard about "zinc". I started to look into Rust in spring 2017, but actually got to write some Rust code in 2018.
<re_irc>
<@dngrs:matrix.org> yeah, who'd do _that_
<re_irc>
<@jpc:ejpcmac.net> False: I have a star on it on GitHub apparently. My memory is not good ^^
<re_irc>
<@jamesmunns:beeper.com> If is around, it was doing Rust pretty early, and does a lot of embedded stuff
<re_irc>
<@whitequark:matrix.org> i was the one who introduced volatile read/write to rust :)
<re_irc>
<@jamesmunns:beeper.com> Hey! Do you happen to know of any working "rust on a microcontroller" projects that predate April 2014?
<re_irc>
<@jamesmunns:beeper.com> I honestly can't remember if your work on Rust introduced me to you, or if following you is one of the things that got me into Rust :D I definitely remember some of your posts (or seeing your PRs/issues?) in the 2014 and before sorta time
<re_irc>
<@jpc:ejpcmac.net> : Pretty important feature to do MMIO indeed! Is it even possible without that?
<re_irc>
<@whitequark:matrix.org> i don't think i've actually published anything though
<re_irc>
<@jamesmunns:beeper.com> : there's always FFI (to C or asm)
<re_irc>
<@whitequark:matrix.org> i think it likely that i was one of the first to ever put rust on a microcontroller and it happened in early 2014
<re_irc>
<@jamesmunns:beeper.com> Yeah, Catherine, farcaller (from Zinc), and Jorge were the first three I saw actively doing MCU stuff back then, Maybe also Simon Sapin (a bit later?) and maybe Simonas as well?
<re_irc>
<@jamesmunns:beeper.com> The latter two might have been post-1.0 tho, so 2015-2016
<re_irc>
<@jpc:ejpcmac.net> Thanks very much :) Do you have any blog post or such from that time?
<re_irc>
<@whitequark:matrix.org> i don't think i wrote anything personally
<re_irc>
<@whitequark:matrix.org> but farcaller definitely did
<re_irc>
<@jpc:ejpcmac.net> I cannot find any article older than 2020 on farcaller’s blog, and both Zinc’s and Hack&Dev’s websites are down.
<re_irc>
<@jamesmunns:beeper.com> Logbot's history of the old irc rust-embedded room only goes back to 2018
<re_irc>
<@jamesmunns:beeper.com> And the main rust channel only back to 2017
<re_irc>
<@jamesmunns:beeper.com> But yeah, seems like the timeline generally was:
<re_irc>
- mid-2014 - first proof of concepts
<re_irc>
- feb 2018 - embedded wg is founded
<re_irc>
- mid 2016 - mid 2017 - some more tooling and guides are written, becomes hard but not impossible
<re_irc>
- mid 2017 - feb 2018 - definite uptick in interest
<re_irc>
- mid 2014- mid 2016 - life was pretty hard, but there were some projects
<re_irc>
- late 2018 - 2018 edition ships, cortex-m support is stable
<re_irc>
<@larunite:matrix.org> : is this gonna form a blog post or something?
<re_irc>
<@jpc:ejpcmac.net> Thank you for digging into the archives 🙂
<re_irc>
<@jpc:ejpcmac.net> : Actually I’m currently preparing a short presentation about Rust for inside my company, and while I can find the general timeline for Rust, the embedded part before the Embedded WG is a bit more difficult to find. I won’t include information as is, but it was part of my personal curiosity.
<re_irc>
<@jpc:ejpcmac.net> I definitely remember having watched closely the stabilisation of Embedded Rust in 2018, but I think my first embedded Rust project was in early 2019 or so.
<re_irc>
<@jpc:ejpcmac.net> But I didn’t know that first PoCs dated back to prior 1.0.
<re_irc>
<@jpc:ejpcmac.net> I wasn’t Rust-born at the time.
<re_irc>
<@jpc:ejpcmac.net> But yeah, writing an article about the history of Rust on Embedded could be a good idea ! Since it does not exist yet.
<re_irc>
<@thejpster:matrix.org> That timeline checks out. I met Jorge at RustFest Zurich in October 17. I presented the first version of Monotron in May 2018 at RustFest Paris.
<re_irc>
<@thejpster:matrix.org> I forked mdaffin’s Teensy 3 rust crate in April 2016 and updated to work with the TI LM4F120. That project became the Monotron.
<re_irc>
<@thejpster:matrix.org> volatile-load was unstable 🤪
<re_irc>
<@thejpster:matrix.org> So anyway, I remember zinc predates my work, and evidently as does mdaffin’s teensy stuff.
<re_irc>
<@jamesmunns:beeper.com> : That's where I ran my nightmare tock-os workshop :D
<re_irc>
<@jamesmunns:beeper.com> the uh, preparation did not go as planned (my collaborator got really sick, so I had to do the other half in like a week), and then there was a breaking tock-os change or something like the day before the workshop, which broke all of the examples I had prepared
<re_irc>
<@jamesmunns:beeper.com> it was pretty packed, I think about half the folks left when things were obviously not going well, the other half (including Jorge and JP) stuck around and it turned into an actually pretty fun "learn about rust and tock os while debugging" exercise
<re_irc>
<@jamesmunns:beeper.com> In retrospect, that was a positive experience, but it was NOT FUN the week(s) before and during
<re_irc>
<@thejpster:matrix.org> I don’t remember any issues. I just remember we met, and I kept a really handy guide to cross compiling to a Raspberry Pi using a Debian bootstrapped chroot
<re_irc>
<@jamesmunns:beeper.com> : It was a "run these steps to get a hello world blinky, and we'll move on from there". Loading the blinky example made the bootloader panic lol
<re_irc>
<@jamesmunns:beeper.com> I _think_ we got the blinky working like an hour and a half later, which involved a lot of GDB stepping and version bisecting IIRC
<re_irc>
<@k900:0upti.me> I'm not sure this counts as embedded, but I had some Rust running on top of Debian on one of those exceptionally cursed Intel Quark SoCs in like 2015
<re_irc>
<@k900:0upti.me> Never published it because it was very useless
<re_irc>
<@k900:0upti.me> But it did blink an LED
<re_irc>
<@k900:0upti.me> By writing to the sysfs files
<re_irc>
<@thejpster:matrix.org> Ha. I got one of those as a prize in 2017. An Intel Edison.
<re_irc>
<@k900:0upti.me> It was basically me and a couple friends playing around with a Quark dev kit and seeing how many languages we could now blink an LED with
<re_irc>
<@thejpster:matrix.org> I didn’t use it for five years then gave it to a museum.
<re_irc>
<@k900:0upti.me> I think someone did elisp
<re_irc>
<@k900:0upti.me> I still have at least one of those in the Junk Drawer(tm)
<re_irc>
<@jamesmunns:beeper.com> oh, there was that rust dev board that was out for a while, that was a MIPS CPU running linux with an AVR (?) coprocessor?
<re_irc>
<@k900:0upti.me> Possibly more than one
<re_irc>
<@k900:0upti.me> We got a bunch of samples from Intel for a kids summer coding camp
<re_irc>
<@k900:0upti.me> That we were supposed to return
<re_irc>
<@k900:0upti.me> But they never told us where or how
<re_irc>
<@k900:0upti.me> So I think my mate still has like 10 of those
<re_irc>
<@k900:0upti.me> They were honestly pretty cool boards, except the part where the SoC barely worked correctly
<re_irc>
<@k900:0upti.me> But they could have fixed that in a hardware revision, if only they committed to it
<re_irc>
<@k900:0upti.me> But it's Intel so they didn't
<re_irc>
<@jamesmunns:beeper.com> I had to go looking, it was called the "Tessel"
<re_irc>
<@adamgreig:matrix.org> That was enough to get an led flashing on an stm32 or whatever, though it used an external linker for final linkage
<re_irc>
<@lambdafriend:matrix.org> 👋 I'm looking for a place to hang out and ask random beginner to intermediate embedded questions. Is this a place for that, or is there somewhere more suited to that type of conversations?
<re_irc>
<@henrik_alser:matrix.org> lambdafriend: This is a great place for that! Welcome!
<re_irc>
<@9names:matrix.org> : i remember tessel, they were javascript dev boards! but i couldn't remember the specs so I had to look them up.
<re_irc>
the original was an LPC1830(cortex-m3) and the tessel 2 was MT7620n(MIPS-LE) + SAMD(cortex-m0+)