Guest7282 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent_ is now known as emerent
Guest7282 has joined #rust-embedded
<jessebraham[m]>
FYI, it seems that the `svdtools@0.3.5` release had a breaking API change (`svdtools::patch::process_file` now takes an additional argument). Not the end of the world, but was surprised to see an error after running `cargo update` in my automation task 😀
<jessebraham[m]>
I imagine I'm likely in a pretty small minority of people using it as a library, thought 😅
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
<burrbull[m]>
<jessebraham[m]> "FYI, it seems that the `svdtools..." <- Did not know someone uses svdtools as library. Will be more careful in future
<jessebraham[m]>
Thanks, again not a huge deal just wanted to mention it haha
IlPalazzo-ojiisa has joined #rust-embedded
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
Bergmann[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901_ is now known as cr1901
<spinfast[m]>
imxrt also uses svdtools as a library
<spinfast[m]>
s/imxrt/Imxrt-rs/
<Ecco>
Has anyone ever toyed with STM32's Touch Sensing Controller in Rust? I can't seem to find any sample code
andresovela[m] has quit [Quit: Idle timeout reached: 172800s]
JonathanDickinso has quit [Quit: Idle timeout reached: 172800s]
<Ecco>
Hmm, I'm getting a weird "unsatisfied trait bound" when using Embassy's SPI with an embedded-hal library
<Ecco>
= note: the following trait bounds were not satisfied:
<Ecco>
`<embassy_stm32::spi::Spi<'_, embassy_stm32::peripherals::SPI3, NoDma, NoDma> as embedded_hal::spi::FullDuplex<u8>>::Error = _`
<thejpster[m]>
> yeah especially when they crippled the debug port :P but a nifty littly thing!
<thejpster[m]>
On RP2040? I was talking about OG Raspberry Pi 1s!
<thejpster[m]>
maybe any of us could go from "making a PCB using someone else's chips" to "making our own chips"
<JamesMunns[m]>
<thejpster[m]> "maybe any of us could go from "..." <- with 10s of millions of investment, and 100s of millions of revenue per year, anything is possible :D
<JamesMunns[m]>
like - not to discount the progress and success the rpi folks have made, it's very cool to see them level up into full IC design, but the NREs and MOQs required for custom tapeout is still a HUGE barrier to entry, though thinks like https://tinytapeout.com/ definitely give me hope for a future of "like jlcpcb, but for ICs" :D
<JamesMunns[m]>
s/thinks/things/
<vollbrecht[m]>
tinytapeout is made with the help of the guy who makes wokwi. Interesting how its done through a simulator that at first glance looks more like a toy for guys in that Business :D
<vollbrecht[m]>
* its done partially through a
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
> with 10s of millions of investment, and 100s of millions of revenue per year, anything is possible
<thejpster[m]>
you certainly have to sell a few PCBs first
<ryan-summers[m]>
Anyone know of a nice way to embed a post-build CRC into an elf?
<ryan-summers[m]>
* an elf without converting it to a bin or hex file first?
<ryan-summers[m]>
Best idea I've seen so far is linking twice with a redefine of the CRC value which you calculate from the first link
<thejpster[m]>
just parse the elf and edit it
<thejpster[m]>
they don't have checksums. Read the symbol table, it'll tell you where the value lives relative to the start of the file, edit it.
<thejpster[m]>
Or if it doesn't give you the file offset, take the segment offset, then go and file the file offset for the segment in the program header table
<thejpster[m]>
(I wrote an ELF parser from scratch, it wasn't even that hard)
<ryan-summers[m]>
Yeah I've seen some python examples doing it, was just hoping for some off-the-shelf solutions to parse it
<thejpster[m]>
can't fault the crate name - doesn't seem to have the best documentation...
<ryan-summers[m]>
Doesn't seem like that crate would let me modify the actual contents though
<ryan-summers[m]>
I.e. embed my CRC at a specific section
<JamesMunns[m]>
I would be fairly nervous about patching, if llvm decided to inline your crc32
<JamesMunns[m]>
might want to make it an explicitly extern variable :p
<ryan-summers[m]>
I have specific linker segments set up for it. This is also for a C project
<ryan-summers[m]>
* C project not using llvm
<JamesMunns[m]>
fair!
<ryan-summers[m]>
Sorry, I realize that is very not obvious in the rust-embedded chat ;)
<ryan-summers[m]>
On a related note, I suspect that's why things like panic-persist use raw linker symbols and extern variables to access the panic metadata instead of specific linker section placement?
<ryan-summers[m]>
I was wondering that, as I just added panic-persist support to another project
<JamesMunns[m]>
ryan-summers[m]: fwiw, I've started using a slightly different structure than linker exported variables lately
<thejpster[m]>
Then walk the program header table to find the segment with the address in it. That'll give you the offset from the start of the file. Then just patch the file.
<thejpster[m]>
ELF isn't magic. There are some headers, then all the data that goes into Flash is just in the ELF file in a big lump.
<JamesMunns[m]>
Instead of using extern regions
<ryan-summers[m]>
Yeah I know ELF files aren't too bad, thanks for the pointers
<thejpster[m]>
I'd just EXTERN the symbol in the linker script, tbh/
<thejpster[m]>
s///./
<thejpster[m]>
I see no real reason to stick it in its own section.
<ryan-summers[m]>
Mainly because I want to put it at a specific memory address
<ryan-summers[m]>
I.e. in the last bytes of all of flash
<JamesMunns[m]>
Yep, I do the same for bootloader/app shared mem regions.
<thejpster[m]>
ah, I see.
<ryan-summers[m]>
That way it has a consistent location regardless of the flash image size and is consistent between firmware versions
<ryan-summers[m]>
Yeah it's pretty common for medical devices etc.
<thejpster[m]>
then yeah, got to label it so the linker knows where to put it. I was thinking it was more like a random global variable you wanted to have a magic number in it known only after link time.
<thejpster[m]>
If it exists as a known place then you don't even need to look up the symbol - you already know where it is. It's a straight walk through the program header table.
<thejpster[m]>
s/as/at/
<ryan-summers[m]>
Yeah that's probably true, just means I have to parse the ELF, which again, was hoping a tool could just do for me
<ryan-summers[m]>
I think python's bincopy will parse it as an input, but it doesn't generate an elf output format
<thejpster[m]>
honestly I'd rather write a tool that have to script using binutils ...
<ryan-summers[m]>
thejpster[m]: Yeah, especially since the whole build process for this project is abstracted behind an IDE and magically created dynamic Makefiles....
<ryan-summers[m]>
I don't think I can even tell it to invoke the linker twice
<ryan-summers[m]>
I'll probably opt for the custom elf parsing then, thanks for the tips
<thejpster[m]>
CSR build system used to pipe makefiles through perl
<thejpster[m]>
and then into make
<ryan-summers[m]>
It does indeed look pretty trivial. Just parse the headers and access text, modify the blob, and be done with it
<thejpster[m]>
so it could do variable replacement inside the makefiles
<ryan-summers[m]>
It indeed is an eclipse-based makefile tool, and I believe it does pipe variables etc. But I honestly CBA to try and figure out how to make it all work
<dirbaio[m]>
obligatory @room ping for meeting time
<dirbaio[m]>
@room
<adamgreig[m]>
we had embedded-hal and friends release v1.0.0-rc.2 with the latest tweaks, now only a few weeks away from release
<adamgreig[m]>
@room :p
<dirbaio[m]>
I can't ping room? or it just doesn't render specially when you're the one pinging?
<adamgreig[m]>
hmm it doesn't pill it?
<spinfast[m]>
I saw the ping
Mebus[m]1 has joined #rust-embedded
<Mebus[m]1>
✌️
<barnabyw[m]>
it’s pinging just fine lol
theeppicjr[m] has joined #rust-embedded
<theeppicjr[m]>
I got pinged
<adamgreig[m]>
weird, I just updated element, wonder if it's a new rendering bug
<dirbaio[m]>
well that was 3 pings to make sure people don't miss the meetings then ⚡️
<dirbaio[m]>
s/meetings/meeting/
<adamgreig[m]>
there's also been a svdtools 0.3.5 and 0.3.6 release, and svd2rust 0.31.2 🚀
<adamgreig[m]>
23 days until e-h 1.0! we triaged a lot of recent issues and comments last week, I think the only thing outstanding is this question about the name of DelayNs
<thejpster[m]>
I have a question about svd2rust ... why is the repo so busy?
emilgardis[m] has joined #rust-embedded
<emilgardis[m]>
thejpster[m]: what do you mean with busy?
<thejpster[m]>
I don't mind that stuff gets better, I just wasn't sure why this repo seems to have a ton of PRs on it when the others are fairly quiet
<dirbaio[m]>
too many features 💀
<adamgreig[m]>
you might well ask why the others are so quiet :p
<adamgreig[m]>
happy to put it on the agenda, why does it need to be resolved before e-h 1.0?
<adamgreig[m]>
it wouldn't be part of the e-h crate itself (?), presumably, so isn't included in the release
<adamgreig[m]>
the conclusion last time iirc was more or less "if enough people in the HAL team are keen to take it over, that's an option, but it didn't sound like they were"
<dirbaio[m]>
decision was if a member of the HAL team is in favor of it, they can start a vote
<Ralph[m]1>
adamgreig[m]: fair enough, it isn't part of the crate but i think part of the discussion was about releasing it at the same time from the same repo. either way, don't want to hijack the current topic, just wanted to drop it in here before i have to log off again (currently on the road)
<newam[m]>
I was added as a maintainer of embedded-hal-mock, feel free to @ me on any issues/PRs. I don't have release permissions, but for everything else I can help out.
<adamgreig[m]>
ok, I think the main point for discussion is the Delay naming then, unless anyone wants to discuss anything else first?
<mabez[m]>
I have a small RISCV announcement, I've submitted the platform support docs (previously filled out by adamgreig in a seperate PR) along with the rv32imafc target: https://github.com/rust-lang/rust/pull/117874
<emilgardis[m]>
the cargo-binutils point has been on the agenda a while, I'll add that I'll do a release soon (tm)
<mabez[m]>
I will follow up with another PR and MCP for making the imafc and remaining tier 3 bare metal riscv targets tier 2
<adamgreig[m]>
ah great, and that includes bumping the missing rv32 target to tier 2?
<adamgreig[m]>
nice work, thanks
<adamgreig[m]>
hopefully uncontroversial given imc/imac are already tier 2 right
<mabez[m]>
adamgreig[m]: Unfortunately I couldn't do it one go, but the MCP process seems quite straight forward :)
<adamgreig[m]>
now if only they'd also merge the updated thumb platform support files :P
<thejpster[m]>
> now if only they'd also merge the updated thumb platform support files :P
<newam[m]>
Seriously, WOOOO!
<thejpster[m]>
s///?/
<adamgreig[m]>
there's been a whole bunch of activity in the riscv repo, too
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
I have to logout, but wanted everyone to know that I'm still working on getting my head around probe-rs to update the tooling documentation. I'll continue to work with James Munns and Noah on that.
<adamgreig[m]>
the riscv stuff we wrote for that PR is in mabez's new PR that's getting merged, but the msp430 and thumb* is still waiting
<thejpster[m]>
ah, a PR from a fork to a fork
<dirbaio[m]>
i'm pretty sure the "good Duration" type we want will require associated consts or associated types
<dirbaio[m]>
we can't add that backwards-compatibly to the Delay trait
<dirbaio[m]>
* Delay trait, it'll need a new trait
<dirbaio[m]>
so I think we should rename DelayNs to Delay if either
<dirbaio[m]>
- we give up on the idea of ever having the good `Duration` type
<dirbaio[m]>
- we're OK with the "Delay with the good Duration type" trait being named something other than Delay.
<adamgreig[m]>
yea, now that fact has sat in my head for the last week I think I agree, it ruins the chances of later adding delay(Duration) to the existing trait
<thejpster[m]>
I assume we ruled out core::time::Duration at some point? For being too big?
<adamgreig[m]>
yea, it's huge
<thejpster[m]>
Because that seems too obvious
<adamgreig[m]>
it's a u32+u64
<dirbaio[m]>
too big, and expensive maths required (mul/div by 1e9)
<adamgreig[m]>
even on a cm7 you'd spend more time working out how many cycles to delay than you'd spend doing a short delay
<adamgreig[m]>
so it's especially mean to 8/16 bit platforms :p
<cr1901>
Hah...
<adamgreig[m]>
I mean, they will probably struggle with delays specified in µs anyway, but the hypothetical future Duration might be able to convert to cycles at compile time or something, tbc
<cr1901>
I thought some HAL impls _do_ calculate old Durations at compile time (require const fn)
<adamgreig[m]>
a lot of hals won't know the clock freqs at compile time which makes it hard, but some could I guess
<thejpster[m]>
:star: PLLs :star:
<adamgreig[m]>
we could conceivably add a method to delay for core Duration that does the conversion to ns
<cr1901>
AVR uses a env var, I thought STM32 uses const fns for calculation Durations. Maybe I misremember
<adamgreig[m]>
just delay for Durations.nanos and then by 1e9 of them for each of Duration.seconds, lol
<dirbaio[m]>
then it's the caller (the driver) who chooses the timebase
<dirbaio[m]>
the driver can't know the hardware timebase, so it'll just pick any random one
<dirbaio[m]>
it's slightly better than DelayNs, because the driver can now pick any instead of only ns/us/ms
<adamgreig[m]>
so ideally the driver is given a Delay where NOM/DENOM matches up with the clock/timer frequency so the delay is in ticks
<dirbaio[m]>
but there's still rounding and conversions going on
<adamgreig[m]>
but now the driver still has to compute how long to delay for given the generic timebase it's provided with?
<adamgreig[m]>
presumably Duration<u32, NOM, DENOM> has some methods like from_millis and from_micros that do that
<dirbaio[m]>
yea
<cr1901>
Doesn't this mean you can't impl Delay more than once in an application?
<dirbaio[m]>
but imagine if a driver needed to do something like
<adamgreig[m]>
how so cr1901?
<dirbaio[m]>
- measure T = the time a pin is low with a timer
<dirbaio[m]>
- delay for T, with the same timer
<dirbaio[m]>
with ms/us/ns it'll be converting from timer ticks to us, and then back again
<cr1901>
adamgreig[m]: Actually wait, disregard. It would be "one Delay per type", since associated const/types will lock you in
<dirbaio[m]>
with Duration associated type/consts it could use the timer's timebase for everything
<dirbaio[m]>
never converting
<cr1901>
which is fine
<dirbaio[m]>
even if it had to do maths, like "delay for T*2", it could do it in the timer's timebase
<adamgreig[m]>
yea, that's nice, but it seems more likely it either needs to just measure it and turn that into seconds, or just delay by some constant number of seconds
<adamgreig[m]>
I think the big advantage is that if NOM/DENOM are const then for constant duration the compiler can presumably work it out?
<adamgreig[m]>
so even on your AVR or something it's not ruinous to try and delay "12 milliseconds, given a timebase of 8MHz"
<adamgreig[m]>
I feel like it's rare to get a time already in the timebase and then use it in that timebase, compared to either measuring something and turning it into seconds, or turning seconds into that timebase
<dirbaio[m]>
yeah
<dirbaio[m]>
maybe it's all a pipe dream
<dirbaio[m]>
and the giant generics spam complexity this'd require is not worth it
<adamgreig[m]>
adamgreig[m]: but isn't this still the compelling point?
<dirbaio[m]>
if the delay is constant, the compiler can already inline and optimize out the conversion maths
<dirbaio[m]>
* conversion maths with the current DelayNs
<adamgreig[m]>
hmm
<dirbaio[m]>
the compelling reason imo is that the driver can now do maths in the hardware's timebase, instead of ns/us/ms
<dirbaio[m]>
or if there's 2 timers A, B with different timebases, it can convert A -> B instead of A -> us -> B
<adamgreig[m]>
how compelling is that, I wonder
<dirbaio[m]>
yeah, I dunno
<dirbaio[m]>
I'm allergic to complex generics, and no matter how we design this, it'll end up with complex generics
<adamgreig[m]>
like, we could make that a new trait in the future if some useful use-case comes up, but it seems less useful or commonplace than things we've already said no to, like runtime spi config
<dirbaio[m]>
this is not just for the delay traits though, there's also the timer, capture, etc traits
<dirbaio[m]>
currently with e-h you can only delay for a duration, you can't measure a duration
<dirbaio[m]>
so if we did a Timer or Capture trait, would it also work in ms/ns/us? :P
<adamgreig[m]>
maybe we keep DelayNs and add DelayTicks in the future
<adamgreig[m]>
(or Delay + DelayTicks..)
<adamgreig[m]>
I think if you were measuring time with a timer you'd mostly want to convert that to seconds, not later delay by it
<dirbaio[m]>
maybe you want to get how much time a pin is high, how much time is a pin low, then calculate high / (high + low)
<dirbaio[m]>
to get duty cycle fraction
<dirbaio[m]>
if you're forced to convert high, low to us/ns/ms upfront you lose precision
<adamgreig[m]>
true
<dirbaio[m]>
it's these kinds of things where I meant "do maths"
<adamgreig[m]>
might be simpler to solve that by letting the timer driver return unitless "ticks" only useful for ratios, or possibly with some way to postpone conversion ticks->seconds
<dirbaio[m]>
yeah
<adamgreig[m]>
like if you were doing benchmarking you probably want to grab the time in ticks regularly and at the end you might convert all the deltas to seconds
<dirbaio[m]>
then you also need the timer to tell the driver the timebase
<dirbaio[m]>
otherwise the timer has no idea what to do with "number of ticks" if it does want to convert to seconds
<adamgreig[m]>
not if the timer trait has a method for get_ticks and another for ticks_to_nanos
<dirbaio[m]>
so you add some const NOM: u32; const DENOM: u32;
<dirbaio[m]>
and then why not add a type `Duration<NOM, DENOM>` to make it a bit more typesafe and converting between tick rates, or to/from seconds/ns/us/ms
<dirbaio[m]>
and next thing you know you've reinvented fugit :D
<adamgreig[m]>
it ends up sounding complicated enough that perhaps the simple DelayNs should be the normal default Delay, and this can be the slightly weirder added-later one
<dirbaio[m]>
hah, that's true...
<adamgreig[m]>
I still guess (without any research) that most uses of delay in drivers are just by some constant read from a datasheet
<adamgreig[m]>
idk, does anyone here have any examples where the e-h delay (or a HAL provided delay) is used for other things, especially things calculated at runtime?
<thejpster[m]>
and these are power-sapping spin-loops, right?
<dirbaio[m]>
not with async 🙃
<adamgreig[m]>
the hal could even implement it as "sleep until a timer wakes us up", or in async it's just "don't bother this task again until later", whatever
<adamgreig[m]>
but probably a lot are also done with a loop waiting on a timer or systick or something, yea
<thejpster[m]>
SD card stuff has a bunch of delays in the spec
<adamgreig[m]>
if it's like 1µs that's probably fine though...
<thejpster[m]>
and I think you have to read them from the card?
<dirbaio[m]>
adamgreig[m]: async delays are a bit more general purpose, they can be used as timeouts with `select`
<adamgreig[m]>
interesting, so they're "constants" but they're not known until runtime?
<dirbaio[m]>
but yeah I agree most delays will be constants
<dirbaio[m]>
but there's timer, countdown, capture... that we'd have to add back sometime
<dirbaio[m]>
this Duration thing would be targeted at all of them, not just Delay
<adamgreig[m]>
but maybe not the end of the world to be add a delay method to the current trait that converts the new duration to seconds first, and could conceivably add a new trait for the exact delay
<adamgreig[m]>
once we reach the future with this new Duration (probably just like fugit's, so about a couple years ago), I wonder if that's actually the interface we want for the boring delay
<adamgreig[m]>
but we'll still have DelayNs at that point anyway, which presumably is what most drivers will use?
<thejpster[m]>
(ok so it turns out embedded-sdmmc only ever delays for 10us at a time, because it's polling for SD card status, and the bigger delay loop is handled internally)
<adamgreig[m]>
interesting, makes sense
<adamgreig[m]>
almost out of time, my other idea was to add a delay() that does take core Duration, since we can pretty efficiency chop that into a nanos+seconds delay now
<adamgreig[m]>
I dunno if that makes the whole thing moot though, heh. it'd be annoying for drivers to use it by default
<thejpster[m]>
I usually er on the side of "do the nice thing first, worry about performance later"
<dirbaio[m]>
I don't think there's much advantage over us/ns/ms
<dirbaio[m]>
* much advantage of core Duration over us/ns/ms
<adamgreig[m]>
I don't want to worry about it after we release 1.0 and realise it was a terrible idea :p
<dirbaio[m]>
sure it's in core so it's "official", but nobody uses it in embedded right now because it's huge
<adamgreig[m]>
I think if duration was specified to always be "u64 seconds + u32 nanoseconds" we could fairly happily add a conversion, but if it later changed to something more troublesome (???) it'd be pretty annoying
<adamgreig[m]>
yea, ok, we can always add it later
<adamgreig[m]>
and if a driver does somehow end up with a Duration and really wants to use it, it's just delay.delay_ns(duration.subsec_nanos()); for _ in 0..duration.as_secs { delay.delay_ms(1000) }
<adamgreig[m]>
no maths involved beyond whatever the impl has to do for delay_ns/delay_ms
<adamgreig[m]>
ok, we're pretty much out of time, dunno where that leaves us with the DelayNs name :p
<adamgreig[m]>
I'll leave the issue open anyway...
<dirbaio[m]>
me neither 😅
<dirbaio[m]>
maybe just leave it as DelayNs?
<dirbaio[m]>
it's not that bad of a name
<dirbaio[m]>
vs if we rename to Delay, I can't think of a good name for the "good" Delay
<adamgreig[m]>
yea, I don't hate it
<thejpster[m]>
i'll agree to that if it means we don't spend a whole other meeting talking about it
<adamgreig[m]>
the "good" delay can be DelayTicks or DelayDuration or DelayTimer or something weird I guess, even if it wasn't just Delay
<adamgreig[m]>
but then what will we talk about instead :P
<thejpster[m]>
on another topic entirely, adamgreig did you see my ping about the wg-binary-size stuff?
<dirbaio[m]>
someone doesn't like how crates.io renders quotes
<adamgreig[m]>
it does look a bit funny
<adamgreig[m]>
thejpster[m]: oh, yep, but wasn't sure if you wanted specific assistance, it seems like your comment had it under control? I haven't read the thread again since
<thejpster[m]>
I just offer it as an example of what happens if you don't have the right people in the right place
<adamgreig[m]>
ok, that's all the time for the meeting, thanks everyone / apologies for a long bikeshed :p
<dirbaio[m]>
the shed's going to look beautiful tho
<adamgreig[m]>
in 23 days
<thejpster[m]>
nuclear powerstation is a bazillion pounds over and five years late, but the shed is A1
<adamgreig[m]>
they decided to riir 😎
<dirbaio[m]>
at some point we'll have to decide how durations work 👻
<dirbaio[m]>
when we add Timer, Capture..
<adamgreig[m]>
once 1.0 is out we can't just cover our ears and say it's for after 1.0, huh
<adamgreig[m]>
maybe Timer will just have a delay() method
<adamgreig[m]>
since it probably has nom/denom assoc consts anyway
<Ralph[m]1>
i'm sure that i missed the obvious and that this has been discussed a hundred times over, but out of interest: what's the reason to not just use the fugit units in e-h?
<dirbaio[m]>
yeah that's a very viable option
<dirbaio[m]>
use Fugit directly, or add it (or something like it) to the embedded-hal crate
<dirbaio[m]>
it's just that the stakes are high because once you use some Duration in embedded-hal 1.0 you can't make any more breaking changes to it
<dirbaio[m]>
like, what happens if fugit 0.4 gets released
danielb[m] has joined #rust-embedded
<danielb[m]>
you can always call 1.0 a trial run and call 2.0 the True Stable Release 🙃
<thejpster[m]>
fugit can just pub use embedded_hal::Duration ;)
Guest7282 has joined #rust-embedded
<Ralph[m]1>
thanks for the explanation!
crabbedhaloablut has quit []
zaven[m] has quit [Quit: Idle timeout reached: 172800s]
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Is there a way to have something like cargo build print the path to the build image? I'd like to script something, and not just look for things in target.
<dirbaio[m]>
no :(
<dirbaio[m]>
you can use --out-dir to make it place the binary in a known location instead, though
<thejpster[m]>
The location in target is well defined though. I don’t expect files to move in a future release.
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
<d3zd3z[m]> "Is there a way to have something..." <- You could set your script as the cargo runner, then `cargo run` would rebuild the image if necessary and then call your script with the image filename as an argument
<GrantM11235[m]>
You could also write your own cargo subcommand, but I think that is a lot more complicated
<d3zd3z[m]>
That would work, although in my case that would break my normal use of cargo run, which I'd like to use to run the program. Right now, I just kind of hard-code the path. I did end up doing something with cargo test, but I'm not sure where that was or if it is the same.
<JamesMunns[m]>
cargo build --release --message-format=json prints the information