<cr1901>
nikomatsakis: https://github.com/cr1901/AT2XT Ignore the failing CI, but this is an example of how to write extremely small Rust (disclaimer: my repo)
<cr1901>
< 2kB ROM, around 50 bytes of RAM (+ stack), Result return types for all functions. There's a few things that could be fixed
<cr1901>
But lto=fat, opt-level=s (z is not useful for no_std IME), incremental=false, cgu=1 gets you there
<re_irc>
<James Munns> I have seen z edge out s, size wise
<re_irc>
<James Munns> It's not super common though. I tend to test both when it matters.
<cr1901>
on std MIPS it does IME, it has never edged out s on msp430
<cr1901>
Rust still can't opt out the format bullshit if there's no device to send the stuff off to
<re_irc>
<James Munns> Other than making sure opt levels and lot are set, avoiding formatting saves anywhere from 5-60+KiB, which can be anywhere from 10-90% of the .text size, depending.
<re_irc>
<James Munns> cr1901: -Z build-std with panic immediately will do it, but not stably.
<re_irc>
<James Munns> Other than making sure opt levels and lto are set, avoiding formatting saves anywhere from 5-60+KiB, which can be anywhere from 10-90% of the .text size, depending.
<cr1901>
I will not use panic_immediate_abort on principle, sorry :)
<re_irc>
<James Munns> I had to make my bootloader smol :)
<cr1901>
I tend to do diffs/CTRL+Z/Y to figure out what added the format machinery in, and perhaps replace unwrap!() with a match/"on error resume next"
<cr1901>
this is not a tenable solution in all cases, but sometimes it's okay
<cr1901>
James Munns: Oh yea, nasty surprise... even converting from my Temperature newtype into() a fixed::types::I8F8 brought in fixed's formatting code :(. Like 3000-4000 bytes
<cr1901>
I wasn't even printing it! (I am now). I wish embedded-hal::serial had a ufmt displayer impl
<re_irc>
<James Munns> Yup, I tend to use those, or .whatever().map(|t| t.wherever().whenever());
<re_irc>
<James Munns> cr1901: Probably reasonable behind a feature flag
<cr1901>
Well, I'd have to somehow implement ufmt for fixed, and that doesn't seem all that fun
<cr1901>
Oh I'm sure I just don't understand :P. But I don't think I need 130 digits to format a lone I8F8
<xnor>
6
<xnor>
ha.. oops s/6//
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc>
<Lachlan Sneff> Iām going to be reflowing a 0.8mm bga package in a few days. Is there anything I should know first?
<re_irc>
<gauteh> Hi. I'm using "panic-reset" in the understanding that if I unwrap or panic the MCU will be reset / restarted. However, I noticed rare freezes, and finally managed to catch one and attach a debugger. Turns out the unwrap + panic happened in an RTC interrupt handler, and the MCU was stuck in the HardFault loop {}. Doesn't panic-reset work with interrupts?
<re_irc>
<chrysn (@chrysn:matrix.org)> What's the general experience of Rust unrolling loops of constant-size arrays?
<re_irc>
Concretely, I have static arrays (by construction of constant length, but can't fold them into one array for some are in ROM and some in RAM); in most situation that array's length is 1.
<re_irc>
I iterate over them with "for (&i2cdev, (lsm, reg)) in I2C_DEVICES.iter().zip(lsm.iter_mut().zip(reg.iter_mut())) { ... }"
<re_irc>
Yet, in a build with LTO and opt-level="s", I still see Iter branches in the generated assembly ... why?
<re_irc>
<gauteh> chrysn: Maybe you need opt-level = 3, are the arrays you iterate over sized arrays or slices?
* re_irc
chrysn (@chrysn:matrix.org) tries it out (opt level 3 works so much better once one removes the quotes around the "3"...)
<re_irc>
<chrysn (@chrysn:matrix.org)> Thanks, you're right, now I don't find anything loop-ish around any more.
<re_irc>
<chrysn (@chrysn:matrix.org)> Still, it's larger than it was back when it was all just single instances, which in memory would have been the same as the 1-long arrays, so the "s" optimizer missed an opportunity there :-/
<re_irc>
<gauteh> Sometimes I miss out on optimizations because I pass the data around as unsized slices (even though they are arrays). Otherwise I have usually seen significant gains from structuring data, but mostly in SIMD situations. Don't know if that applies.
<re_irc>
<chrysn (@chrysn:matrix.org)> Yeah I'd like to keep them closer, but one being in RAM and one in ROM makes them necessarily far apart
<re_irc>
<chrysn (@chrysn:matrix.org)> gauteh: Looking around for the SCB sysreset bit that crate uses, there are reports (https://libopencm3-devel.narkive.com/lmOK9Aak/system-reset) of it sometimes not working, but nothing conclusive there
<re_irc>
<adamgreig> gauteh: The HardFault handler is separate to the panic handler, maybe put your own HardFault which also triggers a reset?
<re_irc>
<chrysn (@chrysn:matrix.org)> But other than that, could the hard fault have fired before the panic handler was reached?
<re_irc>
<gauteh> I think you are right, I need a HardFault handler that resets as well
<re_irc>
<adamgreig> I suspect something else is causing a HardFault besides a panic
<re_irc>
<adamgreig> If you are using rtt etc you could try printing some debug information from HardFault to help see what caused it
<re_irc>
<gauteh> Yeah, I luckily got a bunch of RTT defmt output. Something happened with i2c and the i2c module was reset.. maybe resetting one module messed up the other i2c module.
emerent has quit [Read error: Connection reset by peer]
emerent has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc>
<jduchniewicz> Hi, long time no see :D I finally found some time to come back to embedded Rust development and I wish to contribute to the community while porting a small project of mine :)
<re_irc>
<jduchniewicz> at the time being I am dumbfounded by a certain problem:
<re_irc>
I am trying to create an I2C master using "atsamd::hal" on Arduino nano 33 iot where I am using non-standard pins
<re_irc>
<jduchniewicz> shoul I move the discussion there?
<re_irc>
<jduchniewicz> * should
<re_irc>
<sajattack> yes please
<re_irc>
<adamgreig> hi room , meeting time again! agenda is https://hackmd.io/DzkRMbf7Q7ueDwFhH0Q94A, please add anything you'd like to discuss and we'll start in 5min :)
<re_irc>
<therealprof> adamgreig: Seems require logging in.
<re_irc>
<adamgreig> so it is no longer the rewg's responsibility and hopefully can thrive by itself
<re_irc>
<adamgreig> if you are interested in helping maintain it we will shortly be adding new maintainers... check out #cross-rs:matrix.org (https://matrix.to/#/#cross-rs:matrix.org)
<re_irc>
<adamgreig> anyone else have any announcements?
<cr1901>
msp430 releases imminent soon
<cr1901>
I hope
<re_irc>
<adamgreig> nice! good work on the asm stuff too
<cr1901>
Tyvm (forgot to reply when you last said that)
<cr1901>
Not a fun 5 days, but it had to be done
<re_irc>
<adamgreig> šļø
<re_irc>
<adamgreig> onto cortex-m for a few points, first up cortex-m-rt repo has been merged into cortex-m
<re_irc>
<adamgreig> one thing I'd like to look in to as part of that is revamping our READMEs
<re_irc>
<adamgreig> I feel like at the moment the READMEs are... quite terse
<re_irc>
<adamgreig> lots of the groups for embedded chip families have been doing really nice readmes, like https://github.com/rp-rs/rp-hal
<re_irc>
<adamgreig> perhaps we could spruce up the cortex-m repo somewhat, and add more help/introductory text to explain how to glue things together and where to look for stuff
<re_irc>
<adamgreig> it might be interesting to move the cortex-m crate into its own subfolder, too
<re_irc>
<adamgreig> and with 1.59 coming soon, we can remove the "inline/" crate/library/whatever and just put that as a normal part of cortex-m
<re_irc>
<dkhayes117> what was the reasoning behind putting cortex-m-rt in the cortex-m crate? Just wondering if riscv-rt should follow suit.
<cr1901>
I will probably follow suit w/ msp430 soon (but not before another release, b/c there's already too much to document)
<re_irc>
<newam> dkhayes117: it allows for hardware-in-the-loop tests for "cortex-m" without introducing a cycle on "cortex-m-rt"
<re_irc>
<adamgreig> āļø is the primary reason, yea
<re_irc>
<adamgreig> it also means fewer repos to maintain/set up CI/bors/etc, only one xtask to maintain, can make cross-cutting changes at the same time
<re_irc>
<adamgreig> I guess bla bla the usual arguments for monorepos
<re_irc>
<adamgreig> with some plans to revamp cortex-m's PAC parts a bit coming soon too, we'll probably have more crates in play
<re_irc>
<adamgreig> and we'd already moved cortex-m-semihosting and panic-semihosting and panic-itm into the cortex-m repo
<re_irc>
<James Munns> adamgreig: Feature discoverability: It's in the crate you already use!
<re_irc>
<adamgreig> yep! it might even make sense to literally integrate it into the crate, maybe e.g. an "rt" feature on cortex-m that turns on the c-m-rt dependency
<re_irc>
<adamgreig> so you just need cortex-m in your cargo.toml
<re_irc>
<adamgreig> anyway, between all those reasons it seemed like it made sense, and mechanically wasn't too difficult
<re_irc>
<adamgreig> the biggest nuisance was that github interprets all the commits that were merged that referenced commit IDs as closing the same-numbered issues on cortex-m, and closed them automatically
<re_irc>
<adamgreig> and in the future I guess those commit messages will refer to the wrong issues, which will be a bit confusing for anyone going through the history
<re_irc>
<adamgreig> on balance I think still a worthwhile tradeoff for keeping the git and contributor history
<cr1901>
I... might holdoff on merging the repos then
<cr1901>
that sounds like a headache
<re_irc>
<adamgreig> yea, I think if the plus points there aren't compelling then I wouldn't feel any need to move
<re_irc>
<adamgreig> it's not an end-user-visible change at the moment anyway
<re_irc>
<adamgreig> it's solely just that the crates live in the same repo
<re_irc>
<James Munns> Is commit preservation necessary?
<re_irc>
<adamgreig> the biggest nuisance was that github interprets all the commits that were merged that referenced issue IDs as closing the same-numbered issues on cortex-m, and closed them automatically
<re_irc>
<James Munns> git-bfg might be able to script a find and replace
<re_irc>
<adamgreig> find and replace with what, though?
<re_irc>
<adamgreig> the commit message says "#12"
<re_irc>
<James Munns> the merge commit texts?
<re_irc>
<Yuhan Lin> In the case of MSP430 though we don't have very many issues in the first [;ace
<re_irc>
<adamgreig> does markdown work in commit messages š±
<re_irc>
<adamgreig> anyway, too late now for cortex-m
<re_irc>
<James Munns> I imagine on github it will show like that.
<re_irc>
<James Munns> could also just replace with a link
<re_irc>
<adamgreig> yea, I might look in to replacing with a link if I did something like this again
<re_irc>
<adamgreig> ok, next on cortex-m is a brief re-mention of the idea of using the critical-section crate for the mutex, I haven't had any time to look into it in detail though so no updates
<re_irc>
<adamgreig> same deal with a 0.8 alpha, if anyone's particularly interested in this I don't think there's anything stopping us publishing one early but otherwise it's not super high priority
<re_irc>
<adamgreig> finally the qemu/HIL testing PR from newam, https://github.com/rust-embedded/cortex-m/pull/355 is now unblocked by the merge of c-m-rt and so can hopefully go ahead soon, which is exciting!
<re_irc>
<adamgreig> c-m is at 1.4M downloads on crates.io š± so some more testing will go a long way
<re_irc>
<adamgreig> ok, that's all I've got from cortex-m
<re_irc>
<adamgreig> one quick thing about awesome-embedded-rust
<re_irc>
<adamgreig> we currently have a policy of asking for a blog post with each "published driver" entry, to ensure there's at least a little example and documentation
<re_irc>
<adamgreig> I don't think a short post with an example is a huge ask, but wanted to check what people's thoughts are on the matter
<re_irc>
<therealprof> We haven't really enforced the availability of a blog post.
<re_irc>
<thejpster> I agree with the aims of the rule. I think I'd your blog post is in your README then that's fine
<re_irc>
<eldruin> it's the first time somebody was against it
<re_irc>
<thejpster> Blog posts are generally not discoverable
<re_irc>
<thejpster> I agree with the aims of the rule. I think if your blog post is in your README then that's fine
<re_irc>
<therealprof> But we do request that e.g. the crates.io page contains more than a few words explaining at least what it does and how to use it.
<re_irc>
<thejpster> I mean, it's not the released rust list
<re_irc>
<eldruin> the majority of the drivers in the released section do have some sort of blog post / article
<re_irc>
<adamgreig> yea, I think a fleshed-out README can serve
<re_irc>
<thejpster> It's the *awesome" embedded rust list
<re_irc>
<adamgreig> but something basically equivalent to a blog post
<re_irc>
<allexoll> if the README is documented enough, the blog post should only be a few words + copy paste anyway
<re_irc>
<chrysn (@chrysn:matrix.org)> thejpster: +1, if the README is awesome on its own it's fine too
<re_irc>
<thejpster> Non-awesome things are kind of excluded by design
<re_irc>
<newam> allexoll: Even the pull-request could serve as a blog post if you don't want to get too wordy in the README
<re_irc>
<therealprof> The PR will not be visible after the fact.
<re_irc>
<adamgreig> maybe the requirement could be better called out on the awesome-embedded-rust page?
<re_irc>
<adamgreig> so maybe replace link to WDI with something like "To be added to this list, please ensure your driver has a short blog post, article, or explanatory README showing an example of its use"? or something like that?
<re_irc>
<therealprof> thejpster: My point exactly.
<re_irc>
<adamgreig> yea, I think that sort of readme is what we'd like to discourage (not that we can talk, lol)
<re_irc>
<thejpster> Also, eldruin, to be very clear, this is not on you. You were very reasonable and polite.
<re_irc>
<allexoll> yeah i think the decision was reasonable in this case
<cr1901>
eldruin: >it's the first time somebody was against it When you mentioned I needed a blog post for TCN75A (still to-do, btw :P), I was a bit annoyed. HOWEVER >>
<cr1901>
I was burnt out from documenting the library, and after a sufficient cool down, I definitely am willing to write the blog post
<cr1901>
(I haven't read the issue yet)
<cr1901>
when I have free spoons*
<re_irc>
<eldruin> sorry about that. it is indeed a bit more work, but for me the point is to show some cool project done with it so that newcomers can feel excited about embedded rust. the a-e-r list is probably one of the first things that people see
<re_irc>
<therealprof> I think we're fine with a good README. Usually when I approve aer entries I do check for some usable documentation and have a check of all provided links for correctness and a quick glance at the source for obvious non-awesomeness.
<re_irc>
<adamgreig> cool, thanks for the discussion! I think the opinion is quite clear that we should keep the general requirement but make it a bit more clearly expressed, then
<re_irc>
<adamgreig> would anyone like to update the readme?
<re_irc>
<eldruin> I can make a draft proposal
<cr1901>
Yea, I think I missed the requirement when I submitted TCN75A
<cr1901>
My issue wasn't doing the blog post in and of itself. It's that I was burnt out b/c writing docs and making crates is hard lol
<re_irc>
<adamgreig> thanks eldruin
<re_irc>
<adamgreig> ok, finally for the meeting, any embedded-hal PRs to discuss?
<re_irc>
<adamgreig> (or indeed anything else?)
<cr1901>
No PR, but... would a ufmt write impl for Serial be considered?
<cr1901>
Like how one exists for core::fmt::Write?
<re_irc>
<burrbull> embedded-dma new release maybe?
<re_irc>
<eldruin> Yeah I opened a PR I think
<re_irc>
<therealprof> cr1901: Hm, isn't there one in ufmt already? I think adding it to e-h would add a dependency on "ufmt", no?
<re_irc>
<allexoll> it's not the first time i've missed the existence of such a crate (embedded-nal being another), i think they should probably hold a more important place in a-e-r since that's what should be taken into account when somebody is implementing a chip-hal
<re_irc>
<adamgreig> that's a bit less just traits though
<re_irc>
<adamgreig> but it is a whole ecosystem of drivers
<re_irc>
<James Munns> lulf: gotchu
<re_irc>
<allexoll> at some point probably an embedded-crypto
<re_irc>
<therealprof> Yeah, the section structure could use another refresh.
<re_irc>
<chrysn (@chrysn:matrix.org)> embedded-graphics is also traits -- traits with a lot of provided methods, but still performing the same role
<re_irc>
<therealprof> James Munns: Weird that bors didn't like the previous r+.
<re_irc>
<James Munns> it was an "@bors" that got edited
<re_irc>
<therealprof> Ah.
<re_irc>
<James Munns> and ulf was the previous one (who doesn't have perms)
<re_irc>
<James Munns> (unrelated, the fact that "bros r+" gives back š still makes me giggle)
<re_irc>
<chrysn (@chrysn:matrix.org)> (Once we have a list of embedded trait crates I'd also like to have an automated list of which crates provide implementations for traits defined in them, and which have functions that are generic over impls of them, highlighting the awesome ones, but I think we lack a lot of tooling to get there.)
<re_irc>
<therealprof> James Munns: Yeah, I had that typo multiple times. š
<re_irc>
<James Munns> chrysn: I'm imagining a giant matrix :D
<re_irc>
<chrysn (@chrysn:matrix.org)> more like a directed graph. similar to dependency graphs (actually a subgraph of a dependency graph), but with different (and more meaningful) directions
<re_irc>
<lulf> would be nice with a generic rust code search, like haskell's hoogle (search type signatures to discover implementations for instance)
<re_irc>
<lulf> +crates
<re_irc>
<adamgreig> I wonder if you could pull it out of github's new code search too...
<re_irc>
<adamgreig> actually you could grab crates.io index, find all dependents, then download those?
<re_irc>
<adamgreig> crates.io dependency tree + zip source downloads would probably speed it up a bunch
<re_irc>
<chrysn (@chrysn:matrix.org)> This needs really good understanding of the language, not just some rough code search. I'm momentarily looking into whether rustdoc JSON output contains pertinent information (as that should have it around somewhere, at least for "impl X for Y")
<re_irc>
<adamgreig> just listing all the crates that depend on it from crates.io is probably a good 80% start though
<re_irc>
<adamgreig> or, you know, 20% :P
<re_irc>
<therealprof> Pareto style?
<re_irc>
<adamgreig> ok, that's time for this week, thanks everyone!
<re_irc>
<burrbull> i would want to see separate section for repos with templates and project examples in a-e-r
<re_irc>
<adamgreig> burrbull: ah yea, for the various HAL template projects?
<re_irc>
<burrbull> many people have thir own collections which are useful
<re_irc>
<burrbull> also in driver section something like badges about what version of e-hal is used by driver
<re_irc>
<ythgl> allexoll: very interested in this being a thing, and want to help with review/impl
<re_irc>
<allexoll> that was just an idea i had there, i dont intend to work on it in the near future, but to me that seems like something that could definitely be a trait crate with a separate crate for no-peripheral impl
<re_irc>
<allexoll> similar for a embedded-crc
<re_irc>
<ythgl> how much overhead do traits introduce for embedded?
<re_irc>
<ythgl> definitely interested in a non-Trait-heavy lib
<re_irc>
<allexoll> Tons of MCU have aes/crc and so on and unifying those could help with impl for different drivers
<re_irc>
<ythgl> going thru RustCrypto and dalek-crypto crates is a task and a half
<re_irc>
<ythgl> I can work on AES/CRC stuff, done toy impls of both in the past, can definitely take a more serious pass at them
<re_irc>
<chrysn (@chrysn:matrix.org)> ythgl: At run time, none, that's part of their beauty.
<re_irc>
<chrysn (@chrysn:matrix.org)> (As long as they're statically dispatched, but I haven't seen dynamic dispatch used there yet at all, even though it may be possible).
<re_irc>
<ythgl> chrysn: Awesome! so no dynamic dispatch / virt tables like C++?
<re_irc>
<ythgl> ah, yeah dynamic dispatch was my main overhead concern
<re_irc>
<chrysn (@chrysn:matrix.org)> You _can_ do that (with some traits), but I do "fn f(pin: MyPin) { pin.set_high() }" or "fn f(pin: impl OutPin) { pin.set_high() }" boils down to the same binary. (In fact, many pin types don't even have a setter method but just expose their functionality through the traits only).
<re_irc>
<ythgl> I saw a bunch of trait stuff in embedded crates, but didn't fully understand the reasoning. that makes more sense now
<re_irc>
<K900> "impl T" is basically C++ templates
<re_irc>
<K900> "dyn T" is vtable dispatch
<re_irc>
<ythgl> ok, so staying away from those should remove overhead concerns with traits?
<re_irc>
<K900> Staying away from what exactly?
<re_irc>
<ythgl> using "impl T" and "dyn T" usage to avoid dynamic dispatch
<re_irc>
<K900> You can use "impl T"
<re_irc>
<K900> That's dispatched statically, just like C++ templates, or more precisely, C++2x concepts
<re_irc>
<ythgl> ahhh, ok understand now
<re_irc>
<K900> "dyn T" does vtable dispatch
<re_irc>
<ythgl> lol the "dyn" should have made that obvious to me _derp_
<re_irc>
<ythgl> thanks for the clarification
<re_irc>
<ythgl> so, for the embedded-crypto stuff, I have an RV32 device to work with
<re_irc>
<ythgl> can start there, and at least get a CRC impl working
<re_irc>
<allexoll> i'm wondering if CRC is considered crypto or not
<re_irc>
<K900> It's not
<re_irc>
<ythgl> focus on AES first then?
<re_irc>
<K900> I'd say the litmus test is "will you get yelled at by real security people on Twitter if they find out you're using $thing?"
<re_irc>
<K900> If the answer is yes, then $thing is Not Crypto
<re_irc>
<K900> ythgl: What's your actual end goal? Getting hardware acceleration?
<re_irc>
<ythgl> allexoll mentioned an eventual embedded-crypto as a possibility, would like to help make it real
<re_irc>
<K900> I guess my question would be "what's embedded about it"
<re_irc>
<K900> Many crypto crates are no_std already
<re_irc>
<ythgl> targetted at embedded use, not just a "no_std" afterthought
<re_irc>
<allexoll> yes the embedded part would be having a trait that can be used by HALs
<re_irc>
<ythgl> right, but few are focused on no_std support
<re_irc>
<allexoll> no_std crypto crates are doing the computing on CPU, where having a trait would allow a HAL to impl it trough its accelerator
<re_irc>
<K900> So hardware acceleration
<re_irc>
<ythgl> and maybe it becomes a "take X impl of algo Z and tune it for use with embedded HALs", or general support for crypto hw acceleration, yeah
<re_irc>
<allexoll> similar as how embedded-dma exists even though we can do a memcpy
<re_irc>
<allexoll> yes
<re_irc>
<K900> Well yeah but the reason I'm asking is that if you want hw accel, you should probably start with things that most hardware supports
<re_irc>
<K900> And if you want to just do software, you should start with things that are state of the art
<re_irc>
<dirbaio> rust-crypto crates already have traits for all the algos, HALs could impl them for embedded hw accels
<re_irc>
<K900> So like, do you do AES because that's what accelerators exist for
<re_irc>
<K900> Or do you do ChaCha20 because that's what's actually good
<re_irc>
<allexoll> > rust-crypto crates already have traits for all the algos, HALs could impl them for embedded hw accels
<re_irc>
then that answers it.
<re_irc>
<dirbaio> I don't think we need another set of traits specifically for embedded
<re_irc>
<ythgl> K900: and with enought time get ChaCha20 accel
<re_irc>
<allexoll> yes make sense then
<re_irc>
<K900> Do you have friends at STMicro? :)
<re_irc>
<ythgl> lol
<re_irc>
<K900> If you do, you should really invite them here :)
<re_irc>
<dirbaio> nordic's cc310 can do chacha
<re_irc>
<dirbaio> and even chachapoly... but they fucked up the API and disallowed zero-length associated data, which is a perfectly valid thing and required for implementing wireguard... šļø
<re_irc>
<K900> Ouch
<re_irc>
<K900> I think those new Mediatek router SoCs have Wireguard offloading
<re_irc>
<K900> Which implies they can do chachapoly
<re_irc>
<K900> Too bad they don't exist
<re_irc>
<ythgl> for GD32VF103 devices, there aren't any hw accel crypto functions (excluding the Not Crypto CRC)
<re_irc>
<dirbaio> who said CRC is not a crypto algorithm?
<re_irc>
<ythgl> for devices that don't have accel, should the trait still be impl in that hal with a software/default impl?
<re_irc>
<ythgl> dirbaio: will never tell
<re_irc>
<ythgl> ;P
<re_irc>
<dirbaio> mifare desfire uses CRC32 as a MAC š¤Ŗ
<re_irc>
<allexoll> also, anybody familiar with svdtools enough to help me? i'm trying to collect 64 registers named B[0,1]_[0-31] into a cluster B[0,1] of array B_[0-31] with no luck so far
<re_irc>
<allexoll> also, anybody familiar with svdtools enough to help me? i'm trying to collect 64 registers named B[0,1]_[0-31] into a cluster B[0,1] of array B_[0-31] with no luck so far
<re_irc>
<burrbull> allexoll: this is very specific task. not sure it is possible with current syntax
<re_irc>
<allexoll> i'll find another way then, i'm trying to draft a proposal for lpc-rs to switch to svdtools instead of manually editing svd, and i'm trying to add all the edits that were made since then in this proposal
<re_irc>
<allexoll> thanks!
<re_irc>
<allexoll> (amazing tool by the way, i'm always surprised by the low quality svds that vendors provide)
<re_irc>
<burrbull> where can i see those registers?