<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
<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>
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 (@9names:matrix.org)> 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>
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>
<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>
<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]"
<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>
<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> 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>
<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>
<adamgreig> room meeting time 👋 agenda is https://hackmd.io/q3KglpCRTe-ba-37ndiq8g, 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>
<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?