ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <yruama_lairba> hello i need to measure a time execution for debugging an interrupt, how i can to that ? i need a high resolution timing, my event occurs at ~ 200khz
<Darius> do you have access to an instruction cycle counter?
<Darius> ARM debug cores have one
<Darius> (DWT_CYCCNT)
<re_irc> <yruama_lairba> i'm using stm32f411, it's a cortex arm
<Darius> should be available then
<re_irc> <yruama_lairba> where in found that ?
<re_irc> <yruama_lairba> * ind
<re_irc> <yruama_lairba> * find
<Darius> although watch out, apparently the compiler can reorder things so you might have to put some fences in
<Darius> I'm only used it in C
<re_irc> <yruama_lairba> Darius, normally, register access is always volatile
<Darius> sure but I don't know if Rust semantics turn that into a fence or not
<re_irc> <yruama_lairba> in other word, there is no possible reorder across the register access
<Darius> <shrugs> I have seen compilers do very odd things that are supposedly perfectly legal according to language standards so I am cautious
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc> <yruama_lairba> Darius, what is the precision of this counter ?
<Darius> it counts CPU cycles
<re_irc> <yruama_lairba> so if my sysclk run a 100 Mhz, it as a precision of 10 ns ?
<re_irc> <James Munns> Volatile access doesn't mean instructions can be reordered across them, btw.
<re_irc> <James Munns> it means the volatile operations can't be reordered relative to each other
<re_irc> <James Munns> there's no such guarantee that OTHER code is also not required to be reordered.
<re_irc> <James Munns> This is why we use compiler fences around DMA triggering, for example.
<re_irc> <James Munns> > Volatile operations are intended to act on I/O memory, and are guaranteed to not be elided or reordered by the compiler across other volatile operations.
<re_irc> <yruama_lairba> ooops misunderstood this detail
<re_irc> <James Munns> Volatile access doesn't mean instructions cant be reordered across them, btw.
<cr1901> Two volatile accesses cannot be reordered wrt each other, and they cannot be optimized out. I think everything else is fair game
<re_irc> <James Munns> yup
<re_irc> <yruama_lairba> so to do my meausur i need to add compiler fence ?
<re_irc> <James Munns> Yes
<re_irc> <yruama_lairba> how? i never used compiler fence
<re_irc> <James Munns> You can probably use "Ordering::SeqCst" for everything here
<re_irc> <yruama_lairba> lol, i get slightly lower time when using compiler fence :p
<re_irc> <yruama_lairba> i think i'm not measuring at the right place anyway, execution time of interrupt is 10 time lower than it's frequency
<re_irc> <yruama_lairba> i think it's always the same issue, doing rprint delay execution of interrupt
<re_irc> <yruama_lairba> insane, spawning a task cost arount 60 apparently
<Darius> you might find some variance due to flash read caching etc
<Darius> it could also be quite sensitive to code alignment and other magic
<re_irc> <yruama_lairba> but here, just adding my task spawn doubled the execution time
<re_irc> <yruama_lairba> now, i understand why reordering some instruction make it work, i initially supossed spawning task didn't have a relevant overhead
fabic has joined #rust-embedded
<re_irc> <nihal.pasham> Has anyone used the "log" crate as their logging facade in an embedded setup. I'm using it to log a bare-metal app built for the rpi4. The entire app is single threaded (with interrupts disabled) i.e. we're running on a single core with just one main thread to ensure there aren't any races.
<re_irc> The current impl uses a simple UART-based logger, which works, but when I add the logging facade, I get some inconsistent results. More info here (
<re_irc> So, I was wondering if anyone knows of a working impl that uses the "log" crate or if there is "another logging facade" that's worth trying out.
<re_irc> I maybe wrong but its my understanding that "defmt" is a bit more involved for this scenario, where I would need to
<re_irc> <9names (> Your setup seems complex but as long as the "client" has access to the bare-metal elf you should be able to pipe the received serial data through defmt-print to recover the logs
bjc has left #rust-embedded [ERC 5.4 (IRC client for GNU Emacs 28.1)]
<re_irc> <nihal.pasham> actually its a simple UART-based logger. Here's UART driver ( and the corresponding logging implementation ( built atop the driver.
<re_irc> So, to clarify - I will need to write a standalone client that can handle serial-data along with access to the "bare-metal elf binary" to recover the logs - right?
<re_irc> <reitermarkus> Can someone review/merge Thanks.
emerent_ has joined #rust-embedded
emerent is now known as Guest8966
emerent_ is now known as emerent
<re_irc> <Christof Petig> nihal.pasham: I really recommend to take a closer look at defmt 0.3, the way it handles panics, on wire framing and derive macros is well designed. Right now it defaults to mutex instead of atomic in the backend, so guess some superiority of your current approach there, but storing format strings in debug symbols and handling a large variety of data structures automatically is a feature I don't want to miss.
<re_irc> I wish there was a more straightforward way to extract only the defmt symbols into an elf file to pass to defmt-decode
<re_irc> <nihal.pasham> I agree, I actually prefer"defmt" especially when working in conjunction with "probe-run" i.e. it works out of the box.
<re_irc> But in this scenario, where I'd like to keep complexity to a minimum and am pressed for time, I was hoping to get away with simplest possible "logging api or facade".
<re_irc> <nihal.pasham> +the
<re_irc> <ryan-summers> I use "log" facades with a USB-CDC/ACM serial terminal as an asynchronous output point, but it's still in a single app
<re_irc> <ryan-summers> To accomplish it, I do the formatting at log time and then just push the formatted text into a FIFO, which the USB task then asynchronously drains as it sends data over the wire
<re_irc> <ryan-summers> Ultimately, you need to avoid any kind of race on the underlying output resource because log may be invoked in any context
<re_irc> <ryan-summers> In my case, the FIFO operates as that synchronization primitive
<re_irc> <ryan-summers> The downside of this approach is obviously inclusion of format bloat for micros that are more flash-constrained (we have 1MB), but I'm sure you could still make this work sans formatting
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
<re_irc> <monacoprinsen> Hello,
<re_irc> Im noticing it's not that simple.
<re_irc> To get it to work i need to concatenate the string but have not found any useful way of doing it in std environment.
<re_irc> Im trying to send a byte string over serial that includes a value from a variable.
<re_irc> <monacoprinsen> +a no
gsalazar has quit [Ping timeout: 260 seconds]
gsalazar has joined #rust-embedded
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 248 seconds]
fabic has quit [Ping timeout: 248 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <ryan-summers> Why would doing two serial writes "cost bits"? The flash cost of an additional functional call is negligible compared to adding code to concatenate two byte slices into a different one
<re_irc> <ryan-summers> I guess theoretically you could implement some kind of iterator chain, but that would require that the serial implementation accepted something like "impl Iter<u8>" instead of "[u8]"
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <James Munns> monacoprinsen: Check out
<re_irc> <James Munns> you can either push bytes into a "Vec", or if you are formatting a string, you can do something like:
<re_irc> let mut buf: String<1024> = String::new();
<re_irc> write!("The temp is: {}C", 32u32).unwrap();
<re_irc> serial.send(buf.as_bytes()).unwrap();
<re_irc> <James Munns> (or similar)
<re_irc> <James Munns> you can either push bytes into a "Vec", or if you are formatting a string, you can do something like:
<re_irc> let mut buf: String<1024> = String::new();
<re_irc> write!(&mut buf, "The temp is: {}C", 32u32).unwrap();
<re_irc> serial.send(buf.as_bytes()).unwrap();
<re_irc> edit: fixed code
<re_irc> <monacoprinsen> Thanks!
<re_irc> <James Munns> Heapless::String implements "core::fmt::Write", which is the trait you need to use the "write!()" and "writeln!()" macros.
<re_irc> <monacoprinsen> I will try it out.
<re_irc> Thanks a lot!
<re_irc> <James Munns> Does anyone have a no-std friendly "curses" style library? JP's console library is great for CLI/REPLs, but I'd like to do a little text-based window thingy
<re_irc> <James Munns> like with dialog boxes and input windows and stuff
<re_irc> <James Munns> ( is what I'm using for the CLI stuff, btw, highly recommend it)
<re_irc> <K900> Oooh shiny
fabic has joined #rust-embedded
lcbit has joined #rust-embedded
<re_irc> <monacoprinsen> Another stupid question,
<re_irc> When I send a serial byte string.
<re_irc> b"123"
<re_irc> It prints put fine on the serial console.
<re_irc> <dirbaio> if you format the integer into a heapless String with "format!" then send that, it should show up as decimal, yes
<re_irc> <dirbaio> can you paste some code?
<re_irc> <monacoprinsen> let number = 2i32.to_ne_bytes();
<re_irc> block!(tx.write(*n)).ok();
<re_irc> for n in &number {
<re_irc> }
<re_irc> <dirbaio> ah yeah, that'll be sending "b"\x00\x00\x00\x02"" which is not what you want if you want it to be human readable
<re_irc> <monacoprinsen> Prints out:
<re_irc> ^B^^^
<re_irc> <dirbaio> * "b"\x02\x00\x00\x00""
<re_irc> <dirbaio> James Munns: if you want it as text, format it like this ☝️
<re_irc> <monacoprinsen> Is .as_bytes available in no_std?
<re_irc> <dirbaio> yes
<re_irc> <dirbaio> also that's a heapless::String, not a std::string::String
<re_irc> <monacoprinsen> What crate has as_bytes?
<re_irc> <dirbaio> heapless
<re_irc> <ryan-summers> It's a primitive of str: Heapless just derefs into a &str
<re_irc> <monacoprinsen> Great, tnx again!
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <corpsecoder> Can you use rust on aurduno
<re_irc> <K900> Depends on the exact flavor of Arduino
<re_irc> <K900> But very likely yes
<re_irc> <ryan-summers> Hmmm... So I'm now noticing that cargo will continue using a "cache"'d dependency even if that dependency no longer exists upstream (e.g. git commit got removed). I _think_ I'd consider this a bug? Any thoughts?
<re_irc> <ryan-summers> For context: We made our CI give us false-positive results using "rust-cache" to cache build dependencies and speed up the process. A patch made it into our cache, got merged upstream, and the rev got deleted
<re_irc> <dirbaio> I think it's by design, so it can avoid doing network access at all if everything is cached
<re_irc> <ryan-summers> So a clean build failed
<re_irc> <ryan-summers> Hm, also a good point
<re_irc> <dirbaio> or still letting you build if the server is down
<re_irc> <ryan-summers> But still, a CPU cache requires an eviction if the underlying memory is changed
<re_irc> <ryan-summers> But that's a good point re:network connectivity
<re_irc> <ryan-summers> The issue I'm having is I'm unsure how you can leverage the cache, but also making sure CI gives you valid results
<re_irc> <ryan-summers> Since using the cache bypasses normal dependency acquisition processes
<re_irc> <dirbaio> like a "revalidate, but if still valid don't redownload/rebuild" mode? I don't think that exists :S
<re_irc> <ryan-summers> Yeah, or just do some type of low-connectivity hash check
<re_irc> <ryan-summers> But yeah, I don't think that exists either
<re_irc> <ryan-summers> Might be worth a feature request in cargo?
<re_irc> <dirbaio> maybe you can script something that mucks with "~/.cargo/git/", that deles stuff no longer in the upstream repo
<re_irc> <ryan-summers> Ah, good point. You can also just manually delete "~/.cargo/git" to force a refetch of all git dependencies
<re_irc> <dirbaio> I don't think that'll cause a rebuild though, Cargo doesn't fingerprint stuff in "~/.cargo", it assumes nobody else touches it
<re_irc> <dirbaio> oh if you outright delete it then maybe, but then I think it'll _always_ rebuild 🤣
<re_irc> <dirbaio> maybe fork all repos into your org, then point deps to that
<re_irc> <dirbaio> that's even better, because it _prevents_ the build from breaking
<re_irc> <dirbaio> instead of _notifying_ you when it does
<re_irc> <ryan-summers> We had that originally actually, and developed a local path on the fork. We then got the PR merged into upstream, and I thought it was safe to delete our forked branch
<re_irc> <dirbaio> oops D"
<re_irc> <dirbaio> * =D
<re_irc> <ryan-summers> However, deleting the forked branch with the patch had the side effect of removing the git rev
<re_irc> <ryan-summers> And tbh I'
<re_irc> <ryan-summers> * I'd rather point upstream after the patch landed anyways
<re_irc> <ia0> Anyone knows if there's a way to access the callstack in no-std? I'd like to generate a flamegraph of allocations
<re_irc> <newam> Just with a probe.
<re_irc> Some chips have an HSSTP (high speed serial trace) that can do 20GBps so you can generate real-time flamegraphs, but those are only on really high end SoC's usually.
<re_irc> Don't know of what is out there for non-HSSTP, but someone must have done that before.
<re_irc> <ryan-summers> If you want static analysis, check out - although it takes a bit of work to get going
<re_irc> <ryan-summers> I think it generates output in dot format, but I imagine you could rejig it for whatever you'd like
<re_irc> <Christof Petig> ryan-summers: Git reflog might still be able to give you access to the code. (it can restore previous states of the work area)
<re_irc> <ryan-summers> To be clear, I don't mind that it got lost. That was the goal. I'm upset my CI didn't tell me that I broke the build
<re_irc> <newam> cargo is working on making the index faster, zero-state rust CI should be faster in the future :D
<re_irc> great read if anyone wants to dive into the details of cargo's index, I had no idea it was using github as a CDN.
fabic has joined #rust-embedded
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
<re_irc> <Tatu Pesonen> Hello! I recently got myself an Arduino Uno WiFi Rev2 that has an ATmega4809. If I understand correctly there's no support for 4809 yet in avr-hal?
<re_irc> <Tatu Pesonen> But AVROxide should work?
<re_irc> <newam> I don't have any first-hand experience with that chip + rust, but that matches my understanding.
<re_irc> <Tatu Pesonen> Well atleast I've got myself a challenging case then :D I'll try setting up AVROxide and report back. Getting wifi to work is propably next to impossible though
<re_irc> <James Munns> ryan-summers were you referring to a "branch" or a "rev" spec?
<re_irc> <ryan-summers> rev-spec
<re_irc> <James Munns> hmmm
<re_irc> <James Munns> (does github actually GC dead commits?)
<re_irc> <ryan-summers> The issue arose because the commit got deleted when the branch did, after the PR to the original maintainers repo got merged
<re_irc> <ryan-summers> And no, I explicitly hit a button
<re_irc> <James Munns> ahhh
<re_irc> <ryan-summers> Which helped in triaging what was going on
<re_irc> <James Munns> Yeah, I was going to suggest running "cargo update -p YOUR-GIT-DEP" foreach git dependency
<re_irc> <James Munns> but with a rev sha, I'm not sure if that would actually trigger a network check...
<re_irc> <James Munns> since like... it's not like a sha should ever change :p
<re_irc> <riskable> FYI: If any of you were having issues with USB devices not enumerating/working properly in Windows the latest "usbd-hid" added a new function to "UsbDeviceBuilder" (when you call "UsbDeviceBuilder::new()"), "composite_with_iads()" that fixes it (well, it did for me). The problem arises when you try to have a single device show up as a keyboard+mouse or whatever+whatever (aka a composite device). Linux didn't care and...
<re_irc> ... happily lets you use the device without issue but Windows requires a special recipe of, "device class, subclass, and protocol" for composite devices to work. That little function takes care of it! Here's how to use it:
<re_irc> let usb_device = UsbDeviceBuilder::new(unsafe { USB_BUS.as_ref().unwrap() }, usb_vid_pid)
<re_irc> .manufacturer("Riskable")
<re_irc> <riskable> Note that it overrides things like ".device_class(0xEF) // misc" that oh-so-much code has copy-pasted. You can get rid of that line (and "device_sub_class()" and "device_protocol()" while you're at it)
<re_irc> <riskable> I just realized that "composite_with_iads()" was added a while ago. Apparently I just noticed it while looking at the latest "usbd-hid" code haha. Well anyway, _that's how you fix the composite device enumeration issue_ 🤷
<re_irc> <newam> I'm looking for a "cargo" command that allows you to vendor all dependencies of a crate, but also allows you to edit them. Essentially "cargo vendor", but without checking hashes.
<re_irc> I seem to recall something like this exists, does anyone have suggestions?
<re_irc> <newam> Aha, found it!
<re_irc> <adamgreig> room meeting time 👋 agenda is, please add anything you'd like to announce or discuss and we'll kick off in 5min :)
<re_irc> <adamgreig> I always double check the day and time just before pressing enter, one day i'm going to announce the meeting at like 2am sunday or something
<re_irc> <adamgreig> ok, let's start! I don't have much to announce this week, just that it looks like CTCFT will be going ahead with an embedded topic for the may meeting (mon 16th iirc) which might be fun and interesting to people here, and that svd2rust 0.23.1 is out
<re_irc> <adamgreig> anything else fun happen this week?
<re_irc> <d3zd3z> My talk at the Zephyr dev summit (Jun 9ish) has been approved, for my topic of "Using non-C languages with Zephyr".
<re_irc> <d3zd3z> So, I'll need to be collecting what's been done so far, and where things are at with those projects.
<re_irc> <adamgreig> cool! hope it goes well :)
<re_irc> <Christof Petig> I will see you on the CTCFT, where I present about the state of Rust in automotive together with skade
<re_irc> <Christof Petig> (is there a voice element to this meeting?)
<re_irc> <dirbaio> no
<re_irc> <adamgreig> not much to report on the cortex-m front, we discussed the outstanding PRs last week and I think the way forward is fairly clear
<re_irc> <therealprof> Weren't there new PRs?
<re_irc> <adamgreig> I mean, some of those conclusions need reporting on the PR threads, which I had hoped to do and didn't 💀
<re_irc> <adamgreig> hmm, I don't think so since last week?
<re_irc> <adamgreig> 433 is still the newest and we discussed that
<re_irc> <therealprof> Weird, I thought I saw some notification flying by.
<re_irc> <adamgreig> fairly quiet week on the whole I think. anything from embedded-hal, therealprofeldruin?
<re_irc> <therealprof> adamgreig: Didn't pay much attention I'm afraid.
<re_irc> <adamgreig> I implemented a little driver with the new e-h 1.0 alpha SPI traits for my new car charger last week, they seem to work nicely
<re_irc> <eldruin> nothing from my side
<re_irc> <eldruin> thanks for trying it out. glad to hear it worked well
genpaku has quit [Ping timeout: 240 seconds]
rektide has quit [Ping timeout: 248 seconds]
<re_irc> <adamgreig> step two is actually sharing the bus between two devices with it so i'll see how that works pretty soon
<re_irc> <dirbaio> just yesterday, I ported my NFC stack to EH1.0 alpha SPI, wrked nicely
<re_irc> <adamgreig> for some bizarre reason this car charger has an energy monitor IC and a SPI-to-UART chip on the rpi SPI bus
<re_irc> <adamgreig> you'd think you'd just use the rpi UART
<re_irc> <dirbaio> only snag I found is ExclusiveDeviceError doesn't impl defmt::Format
<re_irc> <thejpster> svd2rust has been busy. Maybe we should poke the PAC authors to try it.
<re_irc> <dirbaio> not sure how we feel about making EH depend on defmt..?
<re_irc> <therealprof> thejpster: I would hope not a lot has changed for established PACs.
<re_irc> <dirbaio> or maybe move ExclusiveDevice to a new "shared bus impls" crate as we've discussed in the past, then make _that_ depend on defmt
<re_irc> <thejpster> Ah, the not your type, not your trait problem.
<re_irc> <Christof Petig> thejpster: I used 23.1 (?) today, compiled fine, source code is smaller
<re_irc> <adamgreig> there's also the new pascal case thing for enums which burrbull mentioned, i.e.
<re_irc> <eldruin> dirbaio: exactly, that. that crate will probably depend on many things
<re_irc> <James Munns> Marcus was asking about that critical section pr, btw (wanted to make sure it got mentioned)
<re_irc> <dirbaio> problem with svd2rust is PAC updates break absolutely everything, so people don't update unless there's a good reason
<re_irc> <dirbaio> updates break everything because you can't mix major versions due to the singletons
<re_irc> <adamgreig> James Munns: yea, I need to post a comment on the PR for that
<re_irc> <thejpster> The only thing that depends on a PAC should be the HAL though, right?
<re_irc> <therealprof> thejpster: In an ideal world...
<re_irc> <dirbaio> PAC major bump requires HAL major bump requires major bump in ALL crates that depend on PAC/HAL
<re_irc> <adamgreig> I wish the rev-deps there distinguished dev dependencies
<re_irc> <adamgreig> many/most crates that depend on a pac or hal do so as a dev dep for test builds, I think
<re_irc> <newam> Ah, that's true, I didn't consider some of those may be dev
<re_irc> <thejpster> I was just wondering why the MIDI support used the F4 PAC…
<re_irc> <newam> dirbaio: delete the singletons? ☠️
<re_irc> <adamgreig> ot
<re_irc> <adamgreig> * it's just for the examples
<re_irc> <adamgreig> newam: oh no, dirbaio's trap card
<re_irc> <dirbaio> my PACs don't have singletons 😂
<re_irc> <thejpster> I’ll put 50 pence in the swear jar for you.
<re_irc> <adamgreig> I think the accepted consensus by now is yes, delete the singletons
<re_irc> <dirbaio> but i think that was offtopic, sorry 🙈
genpaku has joined #rust-embedded
<re_irc> <dirbaio> I just wanted to point out that even though svd2rust has been adding a lot of cool stuff lately, I think that's the reason for slow adoption
<re_irc> <adamgreig> I also have some blame there, I really hope to get back on top of stm32-rs PRs in the next couple of weeks and cut a release soon after
<re_irc> <therealprof> I think the main reason for "slow adoption" is that there's not enough visible improvements to common HALs to justify the enormous pile of work.
<re_irc> <adamgreig> I've been saying that for a while but I've run out of money to pour into the house so I can't imagine house distractions can last much longer 💀
<re_irc> <Christof Petig> dirbaio: I was wondering why I never saw them, as I use embassy with a non-official pac
<re_irc> <adamgreig> 👋 reitermarkus
<re_irc> <dirbaio> stm32-rs's pacs are not "official" either
rektide has joined #rust-embedded
<re_irc> <adamgreig> I'm not sure how to feel at the idea of official stm32 PACs from ST
<re_irc> <dirbaio> they'd be crap! :D
<re_irc> <adamgreig> but probably it will be a while until we need to imagine it, heh
<re_irc> <dirbaio> autogenerated from SVDs with mistakes
<re_irc> <dirbaio> or worse, OCRd from their RM PDFs
<re_irc> <dirbaio> stm32u5's SVD looks OCRd from the PDFs
<re_irc> <newam> dirbaio: or worse, generated from their HAL by C-to-rust
<re_irc> <adamgreig> a more naive person might wonder why they'd need to OCR their own PDFs but...
<re_irc> <adamgreig> anyway 😅
<re_irc> <kelleyk> How else do you programmatically extract what the intern stuck in there?
<re_irc> <jdswensen> To throw even more pain into the mix, it would probably be generated with a GUI tool on windows only. :D
<re_irc> <adamgreig> to their credit I'm glad the new stuff they have on github exists and they do publish a bunch of raw data
<re_irc> <Christof Petig> jdswensen: … written in Java
<re_irc> <adamgreig> maybe they could just publish perfect SVD files instead of PACs :P
<re_irc> <dirbaio> for example: why only 0, 1, 15?
<re_irc> <enumeratedValue>
<re_irc> <name>B_0x0</name>
<re_irc> <enumeratedValues>
<re_irc> <adamgreig> oh no... is it because the SVD only has 0, 1, ... 15
<re_irc> <adamgreig> haha
<re_irc> <dirbaio> because the PDF has a "..." 😂😂😂
<re_irc> <adamgreig> oh no... is it because the PDF only has 0, 1, ... 15
<re_irc> <burrbull> It is all fun, but do we need to change case of enum values?
<re_irc> <adamgreig> I'm not sure "B_0x1" is a great enum name
<re_irc> <dirbaio> adamgreig: ALL enums in stm32u5 are named like that
<re_irc> <adamgreig> "spi_trg0" was right there...
<re_irc> <burrbull> adamgreig: We already have "_clear" for this
<re_irc> <dirbaio> * that, in ALL peripherals 😭
<re_irc> <adamgreig> yea, all their new SVD files have enums, that's why svdtools gained the ability to remove all enums from the source SVD
<re_irc> <dirbaio> only new from scratch peripheral is GPDMA though, so I just take all peripherals from other chips in stm32-data..
<re_irc> <Christof Petig> Sadly I can't state that NXP has better quality SVDs, I was happy to have found them inside the .jar of the IDE
<re_irc> <adamgreig> burrbull: I don't know if emilgardis is around but I'll let him finish the review there
<re_irc> <adamgreig> OK, I guess that's about it for this meeting / complain-about-SVDs-session, thanks all!
starblue has quit [Ping timeout: 276 seconds]
fabic has quit [Ping timeout: 248 seconds]
diagprov has quit [Ping timeout: 272 seconds]
<re_irc> <firefrommoonlight> adamgreig: Tangent: Any chance of getting STM32-RS / PACs to compile on Windows?
<re_irc> <firefrommoonlight> It's been a few months since I've dove in, but I remember it being a bit fragile to set up on Win
<re_irc> <firefrommoonlight> Ie, set up WSL, make sure the CRSF/LRF doesn't get messed up, and a few other steps
<re_irc> <firefrommoonlight> I sent in an issue lately instead of a PR because I couldn't remember how I'd set up the environment
<re_irc> <firefrommoonlight> I think also there were/are a lot of silent failures if you typed something wrong
<re_irc> <firefrommoonlight> Addressing those 2 issues would IMO reduce the friction and take some of the work off Agg's shoulders
<re_irc> <firefrommoonlight> +for PRs
<re_irc> <newam> > make sure the CRSF/LRF doesn't get messed up
<re_irc> > That's always going to be a problem no matter what you do on Windows :P
<re_irc> <newam> ->
<re_irc> <firefrommoonlight> I don't remember having that issue in recent history outside of STM32-RS patches
<re_irc> <firefrommoonlight> Although I don't remember enough to speak to why
<re_irc> <firefrommoonlight> If you don't do a certain step in a specific way, you end up with the whole repo converted to a diff format
<re_irc> <newam> Are there open issues for any of these?
<re_irc> <firefrommoonlight> No. I'll post one once I remember teh details
<re_irc> <firefrommoonlight> Wish I did when they were fresh!
diagprov has joined #rust-embedded
creich has joined #rust-embedded
creich has quit [Remote host closed the connection]