<re_irc> <@adamgreig:matrix.org> josfemova: in your example with the faulty bitRange, is it a copy-paste mistake that the bitRange has the wrong indentation, or could that be the problem?
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc> <@nihal.pasham:matrix.org> just checking - has anyone worked on booting Aarch64 (i.e. arm64-bit) `linux` via a rust-based bootloader for any type of SBC? If yes, I'd like to know if the hand-off from the bootloader to linux is written in rust or in assembly.
<re_irc> <@nihal.pasham:matrix.org> and do we have a separate `element.io room` for `single board computers` or this the right place?
<re_irc> <@9names:matrix.org> https://github.com/oreboot/oreboot apparently can boot aarch64 linux in qemu, no idea how complete it is
<re_irc> <@9names:matrix.org> we don't have a separate room for Rust on SBCs that I know of, so I think here is the right place to discuss such things
<re_irc> <@jamesmunns:beeper.com> Hey, are there any (native) Japanese speakers here? There seems to be an increasing amount of japanese embedded rust usage, and I'd love to be able to post a japanese version of https://twitter.com/rustembedded/status/1467149953072078852 (politely asking people to tag `rustembedded` so we can share)
<re_irc> <@jamesmunns:beeper.com> Also, I'm open to any other language as well!
<re_irc> <@jamesmunns:beeper.com> Put up a request here, if there are any non-english native speakers out there!
<re_irc> <@jamesmunns:beeper.com> Indonesian! https://twitter.com/kotakmakan/status/1476826744996851712
<re_irc> <@jamesmunns:beeper.com> Five languages now :D https://twitter.com/rustembedded/status/1467149953072078852/retweets/with_comments
chrisb has left #rust-embedded [#rust-embedded]
<re_irc> <@nihal.pasham:matrix.org> 9names: thanks for this. They have an example that's using `emulation` (not a real SBC). But yeah, from what I gather, the hand-over looks like a mix of `assembly and rust`.
<re_irc> <@nihal.pasham:matrix.org> However, as you said, I cant tell if this is really complete.
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> Up to 13 languages now :)
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> <@unrelentingtech:mozilla.org> in https://docs.rs/embedded-hal/1.0.0-alpha.6/embedded_hal/i2c/blocking/trait.TransactionalIter.html this kind of thing, is the impl expected to execute commands on the fly as the iterator emits them?
<re_irc> <@dirbaio:matrix.org> if the trait says nothing then it's implementation defined
<re_irc> <@dirbaio:matrix.org> like, it'd be legal for an implementation to drain the entire iterator into a Vec first, then execute all the ops
<re_irc> <@dirbaio:matrix.org> but I guess the reasonable thing is `loop { let op = i.next(); run(op); }` yeah
<re_irc> <@unrelentingtech:mozilla.org> oh the linux one does that, yeah
<re_irc> <@dirbaio:matrix.org> or maybe a DMA impl could call `.next()` while the previous op is still running, to double-buffer them or whatever
<re_irc> <@unrelentingtech:mozilla.org> hm there has to be a double buffer because there is behavior specified for the *last* operation
<re_irc> <@unrelentingtech:mozilla.org> or not, there are explicit "send a stop" things, it's just awkward with a linux style api
<re_irc> <@adamgreig:matrix.org> preparing for cortex-m 0.7.4 with all the backwards compatible chery-picks I could think of, if you're interested please check https://github.com/rust-embedded/cortex-m/pull/375
<re_irc> <@adamgreig:matrix.org> can think about a 0.8 alpha after that
<re_irc> <@firefrommoonlight:matrix.org> I'd imagine that lib is a foundation for much of the Rust embedded code out there
<re_irc> <@firefrommoonlight:matrix.org> Sure is for all of mine
<re_irc> <@adamgreig:matrix.org> I love when bors wishes me a happy new year
<re_irc> <@adamgreig:matrix.org> newam: getting your automated testing into c-m is high on my hit list too but I still want to get c-m-rt into the same repo first I think... maybe
<re_irc> <@adamgreig:matrix.org> there's a lot I'd like to change about cortex-m/-rt
<re_irc> <@newam:matrix.org> adamgreig: If you want help let me know.
<re_irc> <@newam:matrix.org> cortex-m-rt in cortex-m would be a good idea before the automated testing
<re_irc> <@adamgreig:matrix.org> yea, it seems like a good idea both in general and also specifically for the automated testing
<re_irc> <@adamgreig:matrix.org> I think the foundation for any future c-m plans is getting this stupid PAC going which can probably be distributed between people quite effectively once started
<re_irc> <@adamgreig:matrix.org> but ideally I'd think hard about how best to represent registers/fields an dhow to generate a pac from them... I have a skeleton of a armv6/7/8-m svd, but I'm not 100% convinced svdtools' current yaml format is best for describing entire peripherals from scratch, or that svd2rust is the best resulting API for a PAC
<re_irc> <@adamgreig:matrix.org> but should probably get started _somewhere_
<re_irc> <@newam:matrix.org> adamgreig: is the SystemRDL from ARM public? 🤔
<re_irc> <@newam:matrix.org> Hmmm doesn't look like it
<re_irc> <@adamgreig:matrix.org> alas
<re_irc> <@adamgreig:matrix.org> unlike even a single stm32 or something at least it's tractable to imagine transcribing it by hand over time
<re_irc> <@newam:matrix.org> That would be a monster of a project to parse SystemRDL anyway. It's like systemverilog, everyone has their own flavor of the standard.
<re_irc> <@adamgreig:matrix.org> but it would be nice to think of a good way to represent the differences between v6/v7/v8
<re_irc> <@adamgreig:matrix.org> without just cheaping out and only implementing the superset
<re_irc> <@dirbaio:matrix.org> about the yaml format: chiptool's look like this https://github.com/embassy-rs/stm32-data/blob/main/data/registers/usart_v2.yaml
<re_irc> <@dirbaio:matrix.org> more verbose than svdtools, but maybe cleaner?
<re_irc> <@adamgreig:matrix.org> yea
<re_irc> <@adamgreig:matrix.org> svdtools is now a somewhat more elegant rust project btw and perhaps could be extended to support some of the chiptool stuff, dunno
<re_irc> <@adamgreig:matrix.org> not sure if I want to use chiptool as-is or take inspiration from it or what, really
<re_irc> <@adamgreig:matrix.org> and once we have a text format to write down the registers in (and write them all down... or extract from svds/other sources), the resulting pac api is the next q :p
<re_irc> <@adamgreig:matrix.org> I've been idly wondering if you could easily allow using both the ral-style macro access and the svd2rust-style closures from the same crate but I fear you'd pay heavily in compile time
<re_irc> <@dirbaio:matrix.org> hehe, the `dereferenceable` issue
<re_irc> <@adamgreig:matrix.org> yea, you'd have to fix that too of course
<re_irc> <@adamgreig:matrix.org> and probably once you were done you'd have the framework for an improved stm32 pac
<re_irc> <@newam:matrix.org> I avoiding SVD's is the right choice; they are made for concrete implementations and cannot represent elements of the CPU that are implementation defined.
<re_irc> <@adamgreig:matrix.org> I'd like to resolve the sorts of issues encountered by use cases outside our current common "single application that has exclusive and priv access to the whole single core"
<re_irc> <@adamgreig:matrix.org> at least in the PAC
<re_irc> <@adamgreig:matrix.org> yes, agreed
<re_irc> <@adamgreig:matrix.org> but we have tooling now that basically goes from yaml through some svds to various forms of rust, and whatever we end up with should probably be able to ingest svds (much like embassy's stm32 stuff took the stm32-rs svds, turned them into yaml, and builds the yaml direct to rust)
<re_irc> <@firefrommoonlight:matrix.org> Stm32 seems to be an outlier in terms of SVD patching complexity. Complex, overlapping product line; many errors. But so popular you can't treat it as such
<re_irc> <@adamgreig:matrix.org> yea. I guess it's a mix of ST's SVDs being quite variable quality and just the sheer immense size of the product line
<re_irc> <@adamgreig:matrix.org> over a hundred svds, and many of those cover 2-5 stm32 part numbers
<re_irc> <@newam:matrix.org> it's also a bit of GIGO (garbage-in garbage-out), I can see the patterns of heavy perl pre-processing in their register layouts, which is wonderful if you're an ASIC design, not as wonderful if you're writing firmware.
<re_irc> <@dirbaio:matrix.org> 1200 chips total, 400 if you ignore flash/ram size variants
<re_irc> <@adamgreig:matrix.org> there are like 10 nRF variants?
<re_irc> <@adamgreig:matrix.org> yea, a lot of the svd patching work is to undo that and turn it into well-structured SVDs, heh
<re_irc> <@adamgreig:matrix.org> I think embassy's approach is on the whole better and more maintainable
<re_irc> <@dirbaio:matrix.org> only a few nrf51s, 6 nrf52s, 1 nrf53, 1 nrf91. and they STILL have SVD inconsistencies
<re_irc> <@adamgreig:matrix.org> but in my defence I don't think that was obviously true in 2017 :P
<re_irc> <@adamgreig:matrix.org> and I'd want to be very careful migrating stm32-rs itself, it's over a hundred people's work
<re_irc> <@adamgreig:matrix.org> I like to imagine with cortex-m you could get it right from the start and only have to make feature additions thereafter, too, since it's sort of small enough? but that's probably wishful thinknig
<re_irc> <@adamgreig:matrix.org> but like, "include every field from the armv7 reference manual correctly" feels a lot more achievable than "include every field from every stm32f0 reference manual correctly"
<re_irc> <@dirbaio:matrix.org> in my experience "Extract YAML from every SVD, then manually diff" is super effective at finding mistakes/inconsistencies
<re_irc> <@dirbaio:matrix.org> then you fix them manually to get a "golden" YAML then commit that
<re_irc> <@adamgreig:matrix.org> yea, I think with the approach of defining each basic version of the peripheral once and then including them you get a lot closer a lot quicker, sure
<re_irc> <@adamgreig:matrix.org> but you trade off not having entirely accurate descriptions for each part, too, right? i.e. you include more fields than are necessarily present?
<re_irc> <@adamgreig:matrix.org> it's fine, it's probably even a better idea
<re_irc> <@adamgreig:matrix.org> all I mean is that cortex-m seems like a smaller target than stm32
<re_irc> <@dirbaio:matrix.org> adamgreig: yeah, but it's quite rare in practice. Mostly in GPIO
<re_irc> <@dirbaio:matrix.org> oh, and RCC: it merges all RCCs that are identical except in xxENR/xxxRSTR registers
<re_irc> <@dirbaio:matrix.org> so you do end up with a USART5ENR in a chip that doesn't have USART5
<re_irc> <@dirbaio:matrix.org> but it's not been an issue, because "which chip has which peripherals" is autogenerated
<re_irc> <@dirbaio:matrix.org> it might be a bit annoying in HALs that don't autogenerate that, but IMO *not* autogenerating it is insanity
<re_irc> <@dirbaio:matrix.org> same with GPIO maps lol
<re_irc> <@firefrommoonlight:matrix.org> Of note: Something that would make the SVD2Rust current implemention significantly easier to use: Explicit failures
<re_irc> <@firefrommoonlight:matrix.org> IIRC many things will cause it to fail silently
<re_irc> <@firefrommoonlight:matrix.org> "fail" in this case, meaning the change not working etc
<re_irc> <@adamgreig:matrix.org> do you mean svdtools (the yaml patching stuff) rather than svd2rust?
<re_irc> <@adamgreig:matrix.org> the new rust version is a fair bit stricter in what it will accept, but there is some lenience to make it more convenient to share patches between slightly different SVDs
<re_irc> <@firefrommoonlight:matrix.org> Haha I'm not sure. Whatever it is that turns YAMLs into fixed SVDs
<re_irc> <@firefrommoonlight:matrix.org> The stuff you PR `stm32-rs` for
<re_irc> <@firefrommoonlight:matrix.org> that turns into PACs and nightlies
<re_irc> <@newam:matrix.org> svdtools turns the YAMLs into SVDs, it just got a re-write to change from python to rust
<re_irc> <@firefrommoonlight:matrix.org> *Sounds like it, yuea
<re_irc> <@firefrommoonlight:matrix.org> Oh interesting. So maybe the explict errors is already addressed? Rust loves explicit errors!
<re_irc> <@dirbaio:matrix.org> how often does ST release updated SVDs? And when they do, how often do they fix mistakes that haven't already been found and fixed in stm32-rs?
<re_irc> <@newam:matrix.org> Yeah, I think it should be a lot better in that regard. I played around with it a bit and found it was better at handling negative-path.
<re_irc> <@newam:matrix.org> Still room to improve though
<re_irc> <@adamgreig:matrix.org> I don't think ST have a fixed schedule
<re_irc> <@adamgreig:matrix.org> typically we see new SVDs because they have added a new SVD to the family zip file, and at the same time there are a few updates for older parts
<re_irc> <@adamgreig:matrix.org> hard to say what the typical update is... often we can delete some fixes from stm32-rs, there are sometimes some new fixes, and often there's some reorganisation or other changes that aren't really "fixes" but are annoying to integrate
<re_irc> <@dirbaio:matrix.org> hmm
<re_irc> <@dirbaio:matrix.org> it seems to me the value of maintaining patches (instead of the registers themselves) is that you can integrate updates with fixes
<re_irc> <@dirbaio:matrix.org> but maintaining patches is more work, plus you have to maintain the patching tool too heh
<re_irc> <@dirbaio:matrix.org> but if updates are rare, or not necesarily better..
<re_irc> <@dirbaio:matrix.org> then just maintaining the registers directly is less work
<re_irc> <@adamgreig:matrix.org> there's some advantage to being able to apply the same patches to lots of SVDs
<re_irc> <@adamgreig:matrix.org> (obviously moot if you instead try to extract whole peripherals and combine them to make devices, instead of using per-device SVDs)
<re_irc> <@adamgreig:matrix.org> mainly though, maintaining XML files by hand is even more hateful, especially a hundred of them
<re_irc> <@dirbaio:matrix.org> if you unify peripheral versions then "lots of" is just 2 usart versions or 3 spi versions yep
<re_irc> <@adamgreig:matrix.org> so to "just maintain the registers" you need some format for that, and XML ain't it imo
<re_irc> <@dirbaio:matrix.org> yeah the SVD format is horrible
<re_irc> <@adamgreig:matrix.org> at the time, the way pacs were maintained was one svd per pac repo/crate, with the xml hand edited, so this was a step in the direction of not having to edit xml by hand and combining multiple devices in one crate
<re_irc> <@adamgreig:matrix.org> I don't need convincing on the virtue of maintaining a golden set of register definitions instead, don't worry :p
<re_irc> <@adamgreig:matrix.org> I like to imagine your initial import was a lot easier from stm32-rs than it would have been from ST directly
<re_irc> <@dirbaio:matrix.org> oh yeah totally!
<re_irc> <@adamgreig:matrix.org> but yea, I wanna play with ideas for cortex-m where it's a somewhat smaller target before working out how to tackle stm32-rs, I think
<re_irc> <@ryankurte:matrix.org> i'm not yet ready to share this with the outside world but, if any of y'all are interested in wasm on embedded i've created a new room and am dropping updates there: https://matrix.to/#/#wasm-embedded:matrix.org
<re_irc> <@ryankurte:matrix.org> unless i've broken something new you can grab a runtime and run wasm apps on the rpi talking I2C and SPI now
bpye1 has joined #rust-embedded
bpye has quit [*.net *.split]
procton has quit [*.net *.split]
mightypork has quit [*.net *.split]
bpye1 is now known as bpye
mightypork has joined #rust-embedded
procton has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> Holy crap
<re_irc> <@firefrommoonlight:matrix.org> I wrote a WASM frontend rust framework back in teh day
<re_irc> <@firefrommoonlight:matrix.org> Then had an epiphany and decided native HTML/CSS/JS is the way
<re_irc> <@firefrommoonlight:matrix.org> *It was a bit React-like, but used a macro-based syntax