<re_irc>
<@burrbull:matrix.org> I've compiled `blinky` example from `stm32f1xx-hal` (0.5.3) in release mode with default flags and with different rust versions. This is binary sizes:
<re_irc>
<@diondokter:matrix.org> But what's the actual change? Do the newer version just do more aggressive inlining?
<re_irc>
<@therealprof:matrix.org> Nope, rather the opposite.
<re_irc>
<@therealprof:matrix.org> One of the changes leading to bigger code is caller tracking for panics which requires addional information to be embedded in callers.
<re_irc>
<@burrbull:matrix.org> rust 1.52: Upgraded the default LLVM to LLVM 12.
<re_irc>
<@therealprof:matrix.org> Yeah, but new LLVM is not necessarily bad. It certainly means that some optimisation heuristics might be worse than before. Also upstream doesn't really have an eye on embedded usecases so optimisation targets are different.
fabic has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> Extreme size changes are somewhat rare for the cases I'm monitoring.
<re_irc>
<@therealprof:matrix.org> Also cortex-m functions now seem to be outlined now, not sure why.
<re_irc>
<@therealprof:matrix.org> Last time I checked the GH action didn't quite work. I checked back a few times in the meantime but there was very little progress.
<re_irc>
<@windfisch42:matrix.org> hey therealprof, I am interested in getting https://github.com/stm32-rs/stm32f1xx-hal/pull/358/ merged where burrbull asked you for your opinion. Is there anything I can do to help you?
<re_irc>
<@therealprof:matrix.org> Windfisch: Sorry about the delay. I left a note. Can't look at the details now but in principle that change looks good to me. 👍️
<re_irc>
<@windfisch42:matrix.org> thank you very much! :)
<re_irc>
<@windfisch42:matrix.org> From my understanding of the refman, it simply does not matter at all to the peripheral since the output mode is set at the driver stage; it's only very few peripherals where an actual limitation would make sense to protect users from misuse, like USB where OpenDrain would likely not work at all due to the...
<re_irc>
... slew rate, or I2C where push-pull can damage other participants on the bus.
troth has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
<re_irc>
<@therealprof:matrix.org> Yes, I agree. Totally makes to do allow this.
fabic has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic_ has quit [Ping timeout: 268 seconds]
fabic_ has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> therealprof: feel free to r+ that cortex-m-rt pr
fabic_ has quit [Ping timeout: 240 seconds]
ni has quit [Quit: WeeChat 2.8]
ni has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> cortex-m-rt 0.7 is finally released
<re_irc>
<@adamgreig:matrix.org> probably PACs will need to update first of all
<re_irc>
<@adamgreig:matrix.org> I think PACs should be able to depend on `>=0.6,<0.8` to cover existing 0.6 users and new 0.7 users though
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 240 seconds]
<re_irc>
<@adamgreig:matrix.org> @room meeting time again (after a skip week!), agenda's https://hackmd.io/2xeTcSN7S-W2Y2OFXKvRfw and please add anything you'd like to discuss; we'll start in about 5min
<re_irc>
<@lachlansneff:matrix.org> Did you all decide whether to merge the PR that flips the modules paths?
<re_irc>
<@therealprof:matrix.org> adamgreig: Uhm, I thought you'd update the CHANGELOG.md first....
<re_irc>
<@adamgreig:matrix.org> I guess I did too back when I opened the pr :p
<re_irc>
<@therealprof:matrix.org> That's the reason why I didn't r+ earlier. 😉
<re_irc>
<@adamgreig:matrix.org> well, now I know
<re_irc>
<@adamgreig:matrix.org> first up is some quick announcements, if you didn't see earlier then support for esp32 landed in std recently which is pretty exciting: https://github.com/rust-lang/rust/pull/87666
<re_irc>
<@adamgreig:matrix.org> and, cortex-m-rt 0.7 is now released, if you maintain a PAC perhaps look in to bumping your cargo.toml for it, you can support both with `>=0.6,<0.8`
<re_irc>
<@adamgreig:matrix.org> anyone else have anything from the last two weeks?
<re_irc>
<@dkhayes117:matrix.org> I think it would be interesting to add a RISC-V discovery repo, or possible append it to the existing one. Thoughts?
<re_irc>
<@adamgreig:matrix.org> interesting! there's already an ongoing rewrite to use the micro:bit instead of the f3 discovery board, I wonder if all three could live alongside each other
<re_irc>
<@adamgreig:matrix.org> is there a single risc-v dev board that would be suitable?
<re_irc>
<@adamgreig:matrix.org> a big part of the promise of the discovery book is to introduce people who have no embedded experience, so I don't know if it would be better placed as a separate book that's more of a risc-v introduction in rust
<re_irc>
<@hargonix:matrix.org> I've actually made some progress on the microbit thing recently, there are two prs open fro chapter 8 and 9 and im working on 10 and 11 but my microbits magnetometer seems to be miscalibrated....at least it believes north is only 20 degrees next to west....
<re_irc>
<@adamgreig:matrix.org> yea, the new chapters look good!
<re_irc>
<@dkhayes117:matrix.org> I'm not sure about the dev board as the HiFive1 Rev B doesn't have an onboard ADC, the Longan Nano does. On the other side, Longan Nano doesn't have PMP or privilege modes which I think is a shame to leave out.
<re_irc>
<@adamgreig:matrix.org> magnetometers are just crap lol, so long as it's vaguely self-consistent i'd just go with it...
<re_irc>
<@hargonix:matrix.org> yeah its pretty fun, it can accurately point out north east south but west is just weird xd
<re_irc>
<@adamgreig:matrix.org> dkhayes117: would you imagine a book that's "an introduction to embedded, using risc-v and rust", or "an introduction to rust on risc-v"?
<re_irc>
<@dkhayes117:matrix.org> adamgreig: I would say the former since RISC-V is also relatively new
<re_irc>
<@adamgreig:matrix.org> maybe evne "an introduction to risc-v, using rust" :P
<re_irc>
<@dkhayes117:matrix.org> Sure
<re_irc>
<@dkhayes117:matrix.org> I think RISC-V is a great opportunity to get Rust more prominent in industry
<re_irc>
<@adamgreig:matrix.org> maybe ponder how such a thing would fit alongside/within the discovery book, I certainly think it's good to see more books and more focus on risc-v
<re_irc>
<@dkhayes117:matrix.org> I'm working on the getting some higher level functionality in the `riscv` crate, so that will feed into the risc-v discovery book materials
<re_irc>
<@adamgreig:matrix.org> ok, moving on with the agenda, in embedded-hal last time we basically concluded that merging https://github.com/rust-embedded/embedded-hal/pull/298 makes sense, though looks like it needs a rebase now; otherwise just pinging it up for people to see
<re_irc>
<@adamgreig:matrix.org> otherwise I don't think there's been much embedded-hal activity last week?
<re_irc>
<@adamgreig:matrix.org> so, just for the hal team to keep working through the PRs, I guess!
<re_irc>
<@adamgreig:matrix.org> this RFC about moving backtrace to core to allow Error to also move to core has been mentioned in the minutes too: https://github.com/rust-lang/rfcs/pull/3156
<re_irc>
<@adamgreig:matrix.org> not sure who added it, did you want to say anything else about it?
<re_irc>
<@jduchniewicz:matrix.org> Yes, I added it. I have been working on it on and off recently
<re_irc>
<@therealprof:matrix.org> adamgreig: Two PRs at least were merged in the last 2 weeks.
<re_irc>
<@jduchniewicz:matrix.org> How inclined is the embedded community to have these two traits in core?
<re_irc>
<@jduchniewicz:matrix.org> For now maybe just backtrace
<re_irc>
<@adamgreig:matrix.org> therealprof: oh, yea, indeed! I meant just "no new things for us to talk about", good to see stuff getting merged in
<re_irc>
<@adamgreig:matrix.org> in fact 0.2.6 was released which is worth a mention!
<re_irc>
<@therealprof:matrix.org> I was just about to say... it was so long ago I totally forgot. 😉
<re_irc>
<@jduchniewicz:matrix.org> There is a discussion on Zulip regarding this as well
<re_irc>
<@adamgreig:matrix.org> jduchniewicz: Error seems like it would be really good, I don't know how much use backtrace is likely to get in embedded contexts just because it can be a pain to collect? though there was some discussion recently about collecting the call stack here...
<re_irc>
<@grantm11235:matrix.org> Would the backtrace trait be compatible with defmt?
<re_irc>
<@jduchniewicz:matrix.org> The idea is to just expose a common backtrace capturing mechanism and for example allow the caller to provide their own memory location for the frames
<re_irc>
<@jduchniewicz:matrix.org> I am not that familiar with defmt
<re_irc>
<@jduchniewicz:matrix.org> I will dig around that and answer here :)
<re_irc>
<@grantm11235:matrix.org> I don't know how defmt's backtraces work under the hood, but they are very nice
<re_irc>
<@dirbaio:matrix.org> the backtrace is from probe-run, not defmt
<re_irc>
<@jduchniewicz:matrix.org> formatting could be added
<re_irc>
<@dirbaio:matrix.org> probe-run does the unwind on the host, reading the target's ram through SWD
<re_irc>
<@jduchniewicz:matrix.org> By the implementer of backtrace trait
<re_irc>
<@jduchniewicz:matrix.org> The main idea is that you can provide your own implementation of backtrace capture and if not it will be provided by the core implementation (basic one)
<re_irc>
<@jduchniewicz:matrix.org> It may change though if there are objections
<re_irc>
<@dirbaio:matrix.org> the RFC is quite light on details
<re_irc>
<@jduchniewicz:matrix.org> Yes, it is still being filled by me (not having much time lately)
<re_irc>
<@dirbaio:matrix.org> when you `capture()`, where is the backtrace allocated? it's of a variable length, potentially big
<re_irc>
<@jduchniewicz:matrix.org> In two weeks time it will probably be more fleshed out
<re_irc>
<@dirbaio:matrix.org> I don't think it should use alloc
<re_irc>
<@dirbaio:matrix.org> also, will the backtrace frames have symbol strings?
<re_irc>
<@dirbaio:matrix.org> that could be quite a lot of bloat
<re_irc>
<@dirbaio:matrix.org> ideally it should be possible to collect just a `[usize]` slice of PC values and then convert that to symbols off-device
<cr1901>
I guess it makes sense, but I didn't know backtraces could be done w/o alloc
<re_irc>
<@jduchniewicz:matrix.org> That’s a valid argument (Lokathor in Zulip raised a similar question but about the actual symbols being the bloat)
<re_irc>
<@grantm11235:matrix.org> dirbaio: Does that mean that the backtrace trait wouldn't be useful to probe-run?
<re_irc>
<@dirbaio:matrix.org> probe-run does the backtrace with zero "help" from the target
<re_irc>
<@jduchniewicz:matrix.org> At the same time we discussed that this idea of PC collection is viable
<re_irc>
<@dirbaio:matrix.org> it doesn't need backtracing code *in* the target
<re_irc>
<@jduchniewicz:matrix.org> so not much bloat would be induced here
<re_irc>
<@dirbaio:matrix.org> it works like GDB and co
<re_irc>
<@dirbaio:matrix.org> which is way superior, it's literally zero cost
<re_irc>
<@dirbaio:matrix.org> zero code size
<re_irc>
<@dirbaio:matrix.org> the downside is it only works when running a firmware in a dev's desk with SWD plugged in
<re_irc>
<@dirbaio:matrix.org> with a backtrace API we could have devices in the field capture the backtrace themselves when they crash and upload it somewhere which is quite nice
<re_irc>
<@dirbaio:matrix.org> at the cost of needing *some* code in the device, vs zero code for probe-run
<re_irc>
<@adamgreig:matrix.org> sure beats uploading the last 4kB of stack instead huh
<re_irc>
<@dirbaio:matrix.org> yeah 🤣
<re_irc>
<@dirbaio:matrix.org> I'm doing that in my current firmware
<re_irc>
<@dirbaio:matrix.org> hey, some stack frames are smaller than the symbol name though
<re_irc>
<@adamgreig:matrix.org> hah, indeed
<re_irc>
<@jduchniewicz:matrix.org> Long symbol name is a valid argument
<re_irc>
<@adamgreig:matrix.org> storing symbol names on the device seems like it would be too much bloat
<re_irc>
<@adamgreig:matrix.org> and mostly pointless because the device probably can't use them?
<re_irc>
<@dirbaio:matrix.org> it's likely still more compact than strings like `"core::ops::function::FnOnce::call_once at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/ops/function.rs:227:5"` :P
<re_irc>
<@adamgreig:matrix.org> I suppose I'm still thinking of tiny devices but actually something a bit bigger with enough flash or running code from removable storage might still benefit
<re_irc>
<@grantm11235:matrix.org> adamgreig: Unless the backtrace was being displayed on an lcd or something
<re_irc>
<@adamgreig:matrix.org> indeed
<re_irc>
<@adamgreig:matrix.org> maybe more useful for wasm no-std too
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@adamgreig:matrix.org> (I don't know very much about wasm...)
<re_irc>
<@dirbaio:matrix.org> displaying a backtrace in an LCD is a very niche use case imo
<cr1901>
>it's likely still more compact than strings like
<cr1901>
So the code uploaded to the micro wouldn't store the strings?
<re_irc>
<@dirbaio:matrix.org> if a dev is present, they can use SWD
<cr1901>
Just enough code to regenerate a backtrace on the host?
<re_irc>
<@therealprof:matrix.org> dirbaio: Finally a bluescreen...
<re_irc>
<@dirbaio:matrix.org> if a dev is not present, a backtrace is gibberish to the poor user
<re_irc>
<@jduchniewicz:matrix.org> Yes, just upload it
<re_irc>
<@adamgreig:matrix.org> cr1901: right, you'd just capture the flash address of each function in the call stack instead, for example
<re_irc>
<@jduchniewicz:matrix.org> To the devs
<cr1901>
ahhh
<re_irc>
<@jduchniewicz:matrix.org> So, maybe just have a separate implementation of backtrace for every device family
<re_irc>
<@grantm11235:matrix.org> dirbaio: You wouldn't even need to collect it to a slice, would you? Just make an iterator
<re_irc>
<@jduchniewicz:matrix.org> And have a basic one which just allocates the strings
<re_irc>
<@jduchniewicz:matrix.org> Which might not be ideal but will just work(tm)
<re_irc>
<@dirbaio:matrix.org> IMO for a backtrace api to be useful in cortex-m's it'd have to expose soooo many arch details that it'd be super hard to stabilize
<re_irc>
<@dirbaio:matrix.org> the current backtrace api is intentionally secretive with its inner workings
<re_irc>
<@dirbaio:matrix.org> you get a slice of frames, each frame just impls Debug
<re_irc>
<@dirbaio:matrix.org> that's it
<re_irc>
<@dirbaio:matrix.org> that's all you can do with it, just print it
<re_irc>
<@dirbaio:matrix.org> vs what we want which is "expose some data that can then be shipped to a server and decoded there, like an iterator of PC values"
<re_irc>
<@cuno555:matrix.org> Having the PC values of all stack frames is essential, with off-device mapping to function names. In contrast, complete stack dumps are often too large.
<re_irc>
<@cuno555:matrix.org> In my experience with an older language, there is a very useful intermediate approach though: in addition to the PC value for a stack frame, also save the values of all scalar values of that function: u8, bool, i32, etc. - but no arrays, structs etc. Mapping to symbols would be done off-device as well, which...
<re_irc>
... would allow compact storage. Such breadcrumbs are often surprisingly useful for debugging, and usually not add up to much memory.
<re_irc>
<@cuno555:matrix.org> Could this somehow fit into the overall embedded Rust debug story? I don't know enough about Rust to check that.
<re_irc>
<@jduchniewicz:matrix.org> Just FYI, the main reason behind introducing backtrace is to have error in core
<cr1901>
error should be in core, but not at the cost of mandating backtraces (which are too heavy on small micros)
<cr1901>
I think upstream is working on that
<re_irc>
<@adamgreig:matrix.org> yea, getting error in core seems a real prize
<re_irc>
<@adamgreig:matrix.org> sure makes it easier to write libraries that can be as happy on std as no-std
<re_irc>
<@jduchniewicz:matrix.org> A lot of input, will need to yet again pass all the info to the Zulip folks :)
<re_irc>
<@adamgreig:matrix.org> a backtrace with a swappable implementation so you could have a nop backend or a collect-pc-only backend would be cool, and having some mechanism to get the PCs from the stack would be slick for post-mortem debugging for sure
<re_irc>
<@adamgreig:matrix.org> I'm not sure who added this one either, is there anything you'd like to say about it?
<re_irc>
<@therealprof:matrix.org> That was me.
<re_irc>
<@adamgreig:matrix.org> definitely cool to see some development on cortex-a though, and maybe consider joining the cortex-a team at some point? i think it's been v quiet recently
<re_irc>
<@adamgreig:matrix.org> 👋
<re_irc>
<@adamgreig:matrix.org> well i won't suggest you join the c-a team, lol
<re_irc>
<@adamgreig:matrix.org> but anyway there was some chat about this work in here a little while back, iirc
<re_irc>
<@therealprof:matrix.org> The plan was to discuss how their efforts could be merged back into our Cortex-A stuff.
<re_irc>
<@therealprof:matrix.org> stu_ wanted to discuss. 😉
<re_irc>
<@stu_:matrix.org> Hello 👋
<re_irc>
<@stu_:matrix.org> I'm silently following this meeting until this point, but I'm one of the people working on Saturnus. We wanted to write something up with more content, as a "plan" for new APIs in the cortex-a crate. However, I was on vacation last week so there was no time. But now I'm back and actively working on it again. Right...
<re_irc>
... now the crate is just a cleaned up version of the original `cortex-a` crate but I'm already working on proper APIs for paging and cache abstractions.
<re_irc>
<@stu_:matrix.org> We also planned to create `cortex-a-rt` and semihosting (`crates/semihosting` already contains the semihosting one) crates similar to the cortex-m ecosytem
<re_irc>
<@adamgreig:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> sounds good
<re_irc>
<@adamgreig:matrix.org> ok, that's about all the time for the meeting, does anyone have anything else they'd like to bring up before we finish?
<re_irc>
<@stu_:matrix.org> I will open an issue until the next meeting on the `cortex-a` repo which contains all of the information and a summary of our `cortex-a` crate, and then we can talk about upstreaming it
<re_irc>
<@adamgreig:matrix.org> ok, thanks everyone for attending!
<re_irc>
<@almindor:matrix.org> anyone ever do anything with the ILI9486 display chip? (preferably the SPI version)
<re_irc>
<@adamgreig:matrix.org> I used the ILI9342 iirc...
<re_irc>
<@adamgreig:matrix.org> hm, but I was using the 24-bit RGB interface, not SPI
<re_irc>
<@almindor:matrix.org> yeah, we should probably abstract that away into a separate crate
<re_irc>
<@grantm11235:matrix.org> It should be possible to write one crate that supports every DCS display
<re_irc>
<@almindor:matrix.org> i wonder if I just plug this in and use my ST7789 if it'll just work(tm) with possibly size issues
<re_irc>
<@grantm11235:matrix.org> Probably
<re_irc>
<@grantm11235:matrix.org> A universal crate would need to handle different framebuffer sizes, different display sizes, and maybe some other quirks or missing commands
<re_irc>
<@almindor:matrix.org> ahh the instruction hexes differ tho
<re_irc>
<@almindor:matrix.org> they're same e.g. MADCTL is still MADCTL but their addresses are off
<re_irc>
<@almindor:matrix.org> oh wait no, that's some READ version of this hmm, the addresses are ok
<re_irc>
<@therealprof:matrix.org> Yeah, as discussed we can very likely use one driver for pretty much all displays.
<re_irc>
<@almindor:matrix.org> i just wished it worked heh, can't get this display to do anything but blink on init
<re_irc>
<@therealprof:matrix.org> Well, the init sequence will still have to be custom for the display type and size.
<re_irc>
<@almindor:matrix.org> thing is, it doesn't use size at all except for scroll definition
<re_irc>
<@almindor:matrix.org> which is kinda optional, I can "off and on" the display in SW so basic commands seem to work
<re_irc>
<@almindor:matrix.org> ugh, C with no constants heh I'll have to reverse the numbers to see what they're doing
<re_irc>
<@almindor:matrix.org> well at least I know the DISPON and DISPOFF register writes work fine, I have it as a glorified blinking LED right now :D
<re_irc>
<@therealprof:matrix.org> Just fire off the values and in case it works, figure out later why... 😉
<re_irc>
<@almindor:matrix.org> oooh I see some power controls on the start, might be related
<re_irc>
<@lachlansneff:matrix.org> adamgreig: Got that board ordered from jlcpcb!
<re_irc>
<@adamgreig:matrix.org> yay! any pics?
<re_irc>
<@adamgreig:matrix.org> got all the parts shipped? :P
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@lachlansneff:matrix.org> Not yet, but I’ve ordered all the ICs that could possibly go out of stock.
<re_irc>
<@adamgreig:matrix.org> hopefully that's the same list as "all the ICs" :P
* re_irc
@adamgreig:matrix.org looks forlornly at his list of ICs "that won't go out of stock" from july 😭
<re_irc>
<@lachlansneff:matrix.org> Just things like caps and resistors left :P
<re_irc>
<@adamgreig:matrix.org> on the bright side digikey just shipped me some 3v3 LDOs so I can undo the incredible bodge wire and solder the real ldo to these boards
<re_irc>
<@adamgreig:matrix.org> which means they do a via, then they fill it with a conductive material, then they plate over the top of it to make a flat surface
<re_irc>
<@adamgreig:matrix.org> (JLC don't do this)
<re_irc>
<@adamgreig:matrix.org> the worry is that otherwise the solder on the BGA ball will get sucked through the via by capillary action and not make a good solder joint
<re_irc>
<@lachlansneff:matrix.org> It seemed like the jlcpcb vias weren’t small enough to be between the pads
<re_irc>
<@lachlansneff:matrix.org> Ah, yes I saw people talk about that
<re_irc>
<@lachlansneff:matrix.org> I’ll see how it goes