<JamesMunns[m]>
Question for y'all, but especially consultant-y folks (who have to answer this a lot, like myself) like diondokter and thejpster and ryan-summers, do we have a good "executive summary" on the state of embedded Rust today? Like I can point to a lot of tutorials and technical talks, but do we have a good short-ish... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kHlmyvhnWPRCsQpKObXnoXsr>)
<diondokter[m]>
JamesMunns[m]: Yeah was just looking for that one haha.
<diondokter[m]>
It's also just a short list and far from conclusive
<JamesMunns[m]>
I was talking to someone who looked at embedded Rust in like 2019-2020, the company ended up using Rust for backend/linux but not embedded, and now is at a new company where they are looking to re-evaluate make the case for Rust. They asked for "recommendations for where to read up on the current embedded Rust ecosystem", and I didn't have a great answer that wasn't "how to learn embedded Rust"
<JamesMunns[m]>
I wonder if that's a gap in our comms/marketing effort.
<JamesMunns[m]>
* to re-evaluate + make the
<diondokter[m]>
Honestly, I've not yet really had someone ask this general question. People usually ask very specific questions like 'can I do X on hardware Y?'.
<diondokter[m]>
That's usually relatively easy to look up
<JamesMunns[m]>
We're probably at the point where folks are coming around for a second look after maybe evaluating once 3-5 years ago, and it might be good to have a less detailed "how you do it" and more "what it's like today" statement
<JamesMunns[m]>
I'm about to go on vacation for a week, but if anyone writes a good overview, I'll just link to that, otherwise I'm up to collab on something, it might be good to have an overview "signed off" by multiple independent folks.
<diondokter[m]>
Yeah true. The funny thing is that everything is still kinda the same when looked at from a distance. But RTIC has really matured, embassy exists now and there are so many more drivers, libraries and tools available.
<diondokter[m]>
Not to mention official support from Espressif
<JamesMunns[m]>
> everything is still kinda the same when looked at from a distance
<JamesMunns[m]>
Or maybe that's just our perception from looking up close :D
<diondokter[m]>
Maybe?
<JamesMunns[m]>
But yeah, we probably should be thinking about folks "on the sidelines", didn't jump in yet, but are still open to the idea, and just trying to gauge when the right time to "jump in" is
<diondokter[m]>
JamesMunns[m]: Yeah, we talked about this before.
<diondokter[m]>
It'd ideally be some webpage I think. But which format? Idk
<diondokter[m]>
* some webpage/site I
<JamesMunns[m]>
Just an idle thought. Definitely open to feedback :)
lehmrob has joined #rust-embedded
<ryan-summers[m]>
Honestly, I'm working on a fresh project that is starting this month and when I pitched Rust the answer was just "Nah, not interested" which was somewhat annoying. I think I've talked so much about it that they're just tuning me out
<ryan-summers[m]>
I think its just fighting against a conservative mindset oftentimes
<ryan-summers[m]>
But yeah, would be nice to have a "Hey look, this is actually a thing" page, since honestly the support is great. The key is that you are restricted to the more well-supported platforms, like ST, Nordic, ARM-targets, etc. If you stray from that, it's more of "Heh, good luck!" And that's a bit risky from a project management perspective
<ryan-summers[m]>
Since in the early planning phase all of the part numbers are up in the air and you're looking for a best-match and specs are constantly changing. If suddenly the language becomes far less supported, that's a problem
<ryan-summers[m]>
So honestly the fact that you can't really do i.e. rust on msp430 or AVR or PIC32 targets or whatever is actually somewhat of a red flag some times
<ryan-summers[m]>
Downside is its a lot of work to add support with somewhat little value-add, which is why not many people have done it from what I can tell
<ryan-summers[m]>
(I know you can, but the experience is very different from i.e. stm32 from what I've heard)
<diondokter[m]>
Heh, sometimes I get asked whether using an STM32 would be fine or not with a weird almost guilty sounding voice.
<diondokter[m]>
Like... yeah maybe 14 years ago using an STM32 is kinda novel but it's so normal now :P
<diondokter[m]>
ryan-summers[m]: Also, the cheap arm cores are cheap enough now that I personally don't see a reason to use any of these other than running legacy software
<ryan-summers[m]>
I don't either, but often times in big orgs the actual part selection may not be done by the embedded teams and/or may be limited for other reasons
<ryan-summers[m]>
Or you're supporting legacy devices with rewrites etc.
<ryan-summers[m]>
Idk I'm somewhat griping out of frustration tbh. But the key is that the Rust support is not as wide reaching as C. Basically, using C, you never have to worry
<ryan-summers[m]>
* to worry. With Rust, you do have to be a bit more careful
<JamesMunns[m]>
40 years of momentum will do that :p
<diondokter[m]>
Heh, the cheapest attiny on octopart is $0.30 for 10K and has 6 pins.
<diondokter[m]>
The cheapest STM32C0 is $0.36 for 10K and has 8 pins and 32x the flash memory size.
<JamesMunns[m]>
yeah, there are some occasional reasons why, IIRC MSP430 still has the lowest power, and DSP and control folks (SMPS, motor control) still have favorite TI parts, etc.
<JamesMunns[m]>
but for like "general purpose embedded", strongly agree cortex-m is usually the right default choice
M9names[m] has joined #rust-embedded
<M9names[m]>
msp430 is definitely not the lowest power
<ryan-summers[m]>
TI parts are used a lot in medical because they have a very solid track record that's understood by companies
<diondokter[m]>
But yeah, it could be better supported. However, I'm not gonna work on compiler support for chips I'm not using
<ryan-summers[m]>
The architecture and silicon has not changed in decades, and that's viewed as a positive because of "known risk"
<JamesMunns[m]>
M9names[m]: oh? I thought the fram parts were pretty silly when it comes to very low power designs, could be out of date tho
<diondokter[m]>
M9names[m]: Hard to beat the STM32U0 :P
<ryan-summers[m]>
I did a low power design on an MSP430F series (not FRAM) and it was pretty low power, but a Nordic will blow it out of the water
<ryan-summers[m]>
FRAM parts are fun to work with. Did some of the spacex systems on those, and they're weird
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<ryan-summers[m]>
All memory is RAM, but also persistent through reboots. Fun!
<diondokter[m]>
ryan-summers[m]: Yeah it's neat! But also relatively expensive
<ryan-summers[m]>
It's really good for rad-resistance though
<diondokter[m]>
The satellite I worked on had it as well
<ryan-summers[m]>
Apparently FPGAs lock up like no other once you get into space
<ryan-summers[m]>
But yeah, I think the primary reason companies still use MSP430s etc. are due to known risk, legacy hardware, and understanding of the silicon. I don't think they make a ton of sense for modern designs though given the benefits the newer processors have
<ryan-summers[m]>
More speed, more flash, more RAM, less power, less cost
<ryan-summers[m]>
Well tbh don't know about the msp430 cost
<diondokter[m]>
ryan-summers[m]: Doesn't really sound like they really need to run legacy code, but also just conservatism
<ryan-summers[m]>
Yes, that's what I'm referring to. It has to do with risk tolerance
<diondokter[m]>
ryan-summers[m]: The cheapest one seems to be $0.276
<ryan-summers[m]>
Well, that's at least the excuse they hide behind. I call absolute BS on that personally
<diondokter[m]>
* be $0.276 at bulk
<diondokter[m]>
But again, only 0.5kb flash and 0.5kb ram
<ryan-summers[m]>
I have discovered a number of unknown silicon errata in the msp430 that no one found even though they're ~3 decades old... And yeah, that's what I mean
<JamesMunns[m]>
<diondokter[m]> "But again, only 0.5kb flash and..." <- I feel like MSP430 and AVR are platforms that are really designed for writing ASM, using C (or even Rust) is kinda a "backport"
<ryan-summers[m]>
To be fair, more common MSP430s have up to 192KB of flash and you could easily write Rust
<JamesMunns[m]>
tbh, those two platforms DO have a fairly pleasant instruction set, and if you are comfortable with assembly, they are actually kinda nice to do so with
<diondokter[m]>
Yeah half a kb of assembly is very manageable
<JamesMunns[m]>
but you can also see that something like cortex-m's ISA was designed for a much more modern language/compiler friendly design
<ryan-summers[m]>
But like a 192KB flash + 8KB SRAM MSP430 is 8.85$ | 1k
<diondokter[m]>
JamesMunns[m]: Yeah, just the fact that returning from an interrupt is the same as a normal return from a function is very nice!
<diondokter[m]>
ryan-summers[m]: Ouch, you can buy an STM32H7 for that
<ryan-summers[m]>
Yeah that's my point, they aren't cheap by any measure
<ryan-summers[m]>
Also the peripheral suite is a bit pitiful IME
<ryan-summers[m]>
Random comment, but recently my rustc has been hanging when compiling PACs, and I've never seen this before, but its now happened like ~4 times now. Anyone else ever seen this?
<JamesMunns[m]>
have you done a cargo clean since updating versions?
<ryan-summers[m]>
Just did and retrying, that has solved it in the past, but doesn't appear to currently
<JamesMunns[m]>
I've found cargo doesn't always work great when upgrading toolchains, I get some weird errors sometimes if I don't clean
<JamesMunns[m]>
if it's (somewhat) repeatable I'd definitely say open an issue, I haven't seen it yet, but I haven't been doing a ton of pac builds
<ryan-summers[m]>
Yeah I think so. The powershell and MSVCC version works fine
<diondokter[m]>
dirbaio[m]: Linuxified windows :P
<ryan-summers[m]>
Lots of client projects use windows-only software unfortunately. Used to be a die-hard i3wm guy
<ryan-summers[m]>
So now I'm just a sad engineer :(
<diondokter[m]>
I'm just using windows most most dev (non mingw). Only occasionally drop down to WSL if really needed
<diondokter[m]>
s/most/for/
<diondokter[m]>
But I'm pretty much the only one at Tweede golf :P
<ryan-summers[m]>
What's the real issue when you start getting errors like Can't find Ok? Something about core not existing for the target?
<JomerDev[m]>
I had a similar issue and it turned out to be some dependency enabling std
<ryan-summers[m]>
Yeah that's what I'm thinking it is again.
<ryan-summers[m]>
Hmm but wait, std is enabled and should be because I'm running cargo test
<diondokter[m]>
If you scroll all the way up to the first errors, it'll tell you if you if there's no std available
<diondokter[m]>
I wish it would just quit after those errors and not try to compile anyways
<ryan-summers[m]>
Ah, was trying to run cargo test while I had a hidden cargo.toml setting the target to the embedded device
<ryan-summers[m]>
Woopsies
lehmrob has quit [Quit: Konversation terminated!]
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
<thejpster[m]>
I’ve started not setting default targets for cross-compiled bare metal stuff. It’s easier to say “build for arm” than “test for whatever machine this host is”
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
we scheduled this week for doing issue triage, but there are a few points people have added that are worth discussing briefly at the start before we move on to that
<diondokter[m]>
Right on time :D
<JamesMunns[m]>
Announcement: I'm starting a new podcast with Amos (fasterthanlime) called the "Self-Directed Research Podcast", the website is here: https://sdr-podcast.com/, with links to RSS/Spotify/Apple Podcasts.
<JamesMunns[m]>
First episode is coming out tomorrow :)
<JamesMunns[m]>
follow/subscribes greatly appreciated, I promise lots of fun deep dives on embedded stuff :D
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Does Saturday August 24 look good for an Discovery MB2 Book Sprint? We have 4-5 chapters to write, and I'd like to try one or two using that approach… We'd probably start 8AM US Pacific, which should accommodate most folks
jannic[m] has joined #rust-embedded
<jannic[m]>
"Listen on .... Whatever you damn well please" ← love it :-)
<adamgreig[m]>
bartmassey[m]: sounds ok! probably best to just pick a time as I'm sure we won't manage a time everyone can do
<adamgreig[m]>
in principle i'm busy in the afternoon and early evening but i'm sure I can be around for a good chunk
<JamesMunns[m]>
+1 to "this is the time"
<bartmassey[m]>
Yah, just want to get it on folks' calendars and see if there's some obvious giant conflict I missed
<bartmassey[m]>
We can discuss the details next week
<adamgreig[m]>
let's go with that then :) cool
<adamgreig[m]>
diondokter, since you have to leave early, do you want to talk about your point on embedded-storage?
<diondokter[m]>
Yes please!
<diondokter[m]>
So I've been thinking about the embedded storage traits and think they're lacking.
<diondokter[m]>
I have this feeling that there exists a potential trait that can accomodate most storage device types.
<diondokter[m]>
I'd love to know what people think. About this trait (or the one I posted in the opening of that issue), but also about the idea and the feasibility
<cr1901>
My personal opinion, as someone who used s-s recently (last few months) is: "My gut doesn't like how complex this trait is"
<cr1901>
Maybe I could grow around to liking it, but there are a lot of associated consts, and am not sure I like One True Trait
<bartmassey[m]>
"const generics aren't stable yet" What needs to be stabilized to use them here?
<chrysn[m]>
I agree that the traits are lacking; there have been several other discussions in that direction already on the issue tracker.
<diondokter[m]>
What brought this on is that the current NorFlash traits only encode write once and write twice, while in practice we have NOR flash that behaves differently.
<diondokter[m]>
And there's no current way to abstract to more storage types
<chrysn[m]>
* issue tracker. (searching for completeness' sake...)
<diondokter[m]>
cr1901: Yeah, that's a concern of mine as well
<cr1901>
Is back-compat the reason to not put extra behavior into the NOR flash trait?
<diondokter[m]>
But currently with sequential-storage I don't have the ability to support more hardware than just simple nor flash
<diondokter[m]>
cr1901: Not sure what you mean?
<diondokter[m]>
I have not thought about back-compat. Also I think it's fine to make a breaking change
<cr1901>
>the current NorFlash traits only encode write once and write twice, while in practice we have NOR flash that behaves differently. <-- so why not modify the NorFlash trait instead of making a supertrait?
<cr1901>
"Super" as in "One True Trait"
<diondokter[m]>
Because I see a larger problem/opportunity
geky[m] has joined #rust-embedded
<geky[m]>
diondokter[m]: That second-write-zero ability is fascinating
<diondokter[m]>
geky[m]: That's STM for ya :P
<cr1901>
Well, maybe I'd grow around to the new Storage trait. Just my gut is "phew, that got complicated fast" :P.
<diondokter[m]>
I think it'd be super cool to be able to write a storage crate that works on RAM, Flash and SD without many compromises
<diondokter[m]>
cr1901: I'd love suggestions on how to improve it!
<diondokter[m]>
But all these devices are almost the same
<bartmassey[m]>
Is it "second write zeros" or "subsequent writes erase ones"?
<diondokter[m]>
* the same. Just a little bit of info is required to make it all come together
<chrysn[m]>
Ideally allowing its users to do compile time stuff like "if this does allow multiple writes in that place … take that different path where we can do with fewer erase cycles".
<cr1901>
My suggestion is to not put too much stock in my gut reaction :P. Probably as proposed, the trait would let be implement s-s for 24xx series without issues
<chrysn[m]>
I agree that the traits are lacking; there have been several other discussions in that direction already on the issue tracker. (searching for completeness' sake...)
<chrysn[m]>
* > super cool to be able to write a storage crate that works on RAM,
<chrysn[m]>
* issue tracker. (searching for completeness' sake...)
<geky[m]>
diondokter[m]: It may be too much of a change, but if you're breaking compat I want to advocate for renaming write -> prog or program. That way you can also have a write trait that implicitly erases. May make supporting RAM/SD/NVRAM easier
<chrysn[m]>
* > super cool to be able to write a storage crate that works on RAM,
<chrysn[m]>
Ideally allowing its users to do compile time stuff like "if this does allow multiple writes in that place … take that different path where we can do with fewer erase cycles".
<geky[m]>
geky[m]: Maybe this is also too off topic
<dirbaio[m]>
IMO we should do the most straightforward thing and not overabstract
<dirbaio[m]>
the semantics of eeprom vs nor flash vs block devices are quire different
<geky[m]>
But they smell the same :)
<dirbaio[m]>
which means the filesystems/databases you run on top will also be quite different
<JamesMunns[m]>
geky[m]: false friends are tricky :p
<cr1901>
(Wow, stop the presses... I agree w/ dirbaio[m] on something technical :P)
<diondokter[m]>
Yeah, I kinda agree with that. But also, I see that I could make s-s work in RAM and in SD card blocks too if I had the right trait to build on
<dirbaio[m]>
something like sequential-storage or ekv is written for NOR flash, it won't perform well when running on a sdmmc-like block device
<dirbaio[m]>
without adapting it
<chrysn[m]>
dirbaio[m]: It can adapt itself by querying const properties.
Jonathan[m]1 has joined #rust-embedded
<Jonathan[m]1>
* which means that if you abstract, the abstraction will work for a specific implementation but not for all... making it somewhat useless
<Jonathan[m]1>
dirbaio[m]: which means that if you abstract, the abstraction will work for a specific implementation but never for all...
<Jonathan[m]1>
> <@dirbaio:matrix.org> something like sequential-storage or ekv is written for NOR flash, it won't perform well when running on a sdmmc-like block device
<chrysn[m]>
Plus, not all users will write code that needs to perform the best at all possible times.
<dirbaio[m]>
so I think the use case for "write some filesystem that can work on top of either eeprom or blockdev or nor" is will be quite rare
<dirbaio[m]>
and
<dirbaio[m]>
if you do need that, you can still do it at a higher layer in the FS/DB crate
<JamesMunns[m]>
So, maybe as a countervoice:
<JamesMunns[m]>
I think that diondokter (et al) SHOULD go try it. I don't think "discuss traits without impls in meetings" has ever been very productive.
<JamesMunns[m]>
I'm supportive of experimentation, but maybe it'd be better to discuss a demo instead of an idea?
<chrysn[m]>
dirbaio[m]: For file systems, yes. For other more fallback-style things ("just write to the media, or let the user plug in a more sophisticated config backends"), I think that's common.
<dirbaio[m]>
ekv::Database::new(ekv::NorInterface::new(my_nor_flash)) vs ekv::Database::new(ekv::BlockDeviceInterface::new(my_block_device))
<diondokter[m]>
dirbaio[m]: Tbh, that's the best argument against the idea
<dirbaio[m]>
and NorInterface BlockDeviceInterface do things specifically optimized for NOR or blockdevs
<dirbaio[m]>
if you don't care about perf you can write "bad" adapters that convert from e.g. NOR to a blockdev by doing "read+modify+write"
<diondokter[m]>
JamesMunns[m]: Yeah, I just wanted to gauge reactions. And I think I have everything I need :)
<cr1901>
Precedent for the bad adapter... the stuff I'm doing to get 24xx EEPROMs to work with s-s
<adamgreig[m]>
it sounds like right now the traits we have for eeprom/nor/block are not perfect either though, so perhaps the alternative is to make a small set of nice and similar/easily-interoperable traits for modelling those types of flash
<cr1901>
That project stalled, but I should prob open-source the code anyway
<adamgreig[m]>
s/flash/memory/
<diondokter[m]>
adamgreig[m]: Yes, the current traits are fine except for some details IMO
<adamgreig[m]>
anyway yep, thanks for the thoughts everyone! let's wrap this topic up in a minute or two
<diondokter[m]>
* are fine (for modelling NOR flash) except for
<dirbaio[m]>
so I feel like the complexity of the "uni-trait" outweighs the advantages.
<adamgreig[m]>
maybe just getting one trait for all norflash is hard enough, heh
<dirbaio[m]>
plus with a uni-trait it's hard to enforce "please only pass me NOR flashes"
<chrysn[m]>
ia0[m]: My gut feeling is that a trait (family) covering all possible NOR variations will already also cover the rest.
<diondokter[m]>
adamgreig[m]: But having many defeats the purpose of the abstraction :P
<chrysn[m]>
dirbaio[m]: As long as it quacks like a NOR flash…
<dirbaio[m]>
a blockdev won't quack like a NOR flash without trashing performance
<dirbaio[m]>
and atomicity guarantees
<diondokter[m]>
The problem is that you need to optimize for 'good' flashes while still allowing 'bad' flashes
<diondokter[m]>
Can't do that with the current design
<diondokter[m]>
But ok, I think there are other subjects :P
<dirbaio[m]>
diondokter[m]: you can if you do the NorInterface, BlockDeviceInterface thing
<geky[m]>
dirbaio[m]: I'm not sure I buy this, even if erase is a noop?
<geky[m]>
Is is just the prog granularity that's a problem?
<dirbaio[m]>
geky[m]: with NOR you can write 1 byte. with a blockdev you need to read the block, modify it, write it.
<bartmassey[m]>
gtg, thing came up 👋
<adamgreig[m]>
let's move on to the other points now, we can revisit the traits afterwards if people would like
<dirbaio[m]>
dirbaio[m]: you could do that too with e.g. different kinds of nor flashes too. Write a "page interface" that handles the low-level writing of records to pages, then make one impl for "no multiwrite", another for "multiwrite only zero", another for "multiwrite only twice" etc. they can share code internally as needed.
<adamgreig[m]>
Folkert de Vries: do you want to talk about the compiler tests?
FolkertdeVries[m has joined #rust-embedded
<FolkertdeVries[m>
yes
<adamgreig[m]>
I think testing cortex-m 0.5.0 is kind of old, but if the point of the test is "can rust build a cortex-m binary" then it probably doesn't matter too much
<adamgreig[m]>
wrt the qemu -cpu flag, it's not a huge problem, the only issue I can think of is that if rust started emitting armv7 instructions on a thumbv6 target we wouldn't necessarily catch it.. but that's already true depending on exactly what goes wrong
<FolkertdeVries[m>
so yeah the point of that test does seem to be: can it build. cortex-m is very foundational, kind of std-adjacent, so we've argued that it makes sense to include in the rustc compile test suite
<adamgreig[m]>
the tests do still check that a valid binary is generated and can run, which i think is the main thing
<adamgreig[m]>
I can see them both being slightly annoying tests though for sure, we probably could replace them with a barebones test that includes just the bare minimum bits of cortex-m-rt to do bringup and semihosting to qemu or such
<adamgreig[m]>
we don't need (or want) to test the cortex-m or cortex-m-rt crates, we just want to test the compiler can generate working binaries for those targets and run them, so replacing cortex-m/cortex-m-rt crates would be ok i think
<adamgreig[m]>
whether it's more or less effort/reward to do that vs vendor them or continue to download them, I'm not sure
<FolkertdeVries[m>
yes kind of up to them at this point
<adamgreig[m]>
does that answer your immediate questions at least?
<FolkertdeVries[m>
I do think we can use cortex-m0 for one of the tests, but cortex-m23 does not seem to be supported. I'll just fix that in the PR and we'll see what happens on CI
<FolkertdeVries[m>
yes, thanks
<adamgreig[m]>
cool yea, if you can use cortex-m0 now then definitely may as well
<adamgreig[m]>
ryan-summers / Folkert de Vries, want to talk about the cmse-nonsecure-entry pr?
<diondokter[m]>
Gtg, see ya round!
<diondokter[m]>
* Gtg, see ya around!
<FolkertdeVries[m>
right, related in some ways: there is not that much review capacity anyway, but especially for embedded, there just seems to be nobody that is able to quickly review changes. That is frustrating when we do want to make changes
<FolkertdeVries[m>
so for that PR in particular, the reviewer just gets re-rolled a bunch of times. So we chatted with the triage team, and what would be helpful is if we sort of bring our own expertise
<adamgreig[m]>
yea, makes sense, we've talked about this sort of thing with the rust-lang people a bit recently too
<FolkertdeVries[m>
this is very consistent with some conversations at RustNL also yes
<adamgreig[m]>
I think generally having some embedded people help with reviewing technical details is good, but for trustzone specifically I think the problem is how much trustzone expertise we have here too
<FolkertdeVries[m>
the PR in its current state actually also doesn't need specific trustzone knowledge I think, besides the motiviation for why this is a useful feature at all
tamme[m] has joined #rust-embedded
<tamme[m]>
In this case a "vibe-check" by somebody who knows about Trustzone-M would be useful. For example by having a look at the generated assembly (which is checked in a test).
<FolkertdeVries[m>
i.e. we want to be sure that we're actually stabilizing the right design
ejpcmac[m] has joined #rust-embedded
<ejpcmac[m]>
tamme: We could compare with what is produced by the C Arm toolchain maybe?
<ejpcmac[m]>
And ensure there is no surprising thing when you start doing Rust instead of C
<adamgreig[m]>
any thoughts on what we could do immediately to start helping that?
<tamme[m]>
ejpcmac[m]: Yes, that is what we went for for the stabilization report. We linked a C project compiled in godbolt both with Clang and GCC.
<FolkertdeVries[m>
re helping: look at the design, and post that it looks good in the tracking issue I think? t-lang just has no way to evaluate the design otherwise
<tamme[m]>
or post that it is not good if you think it needs more work ;)
<FolkertdeVries[m>
yes, perhaps also a look at the test suite to see if anything is missing there
<adamgreig[m]>
I'll try and find time to look at it this week, and if anyone else here wants to have a look please do, we could also chat about it here
<FolkertdeVries[m>
and we might still look into making one of those rmake tests to actually run this in practice on CI
<adamgreig[m]>
let's move on to the other issues; I think we'll have to postpone issue triage to next week since we had a lot of things to discuss this week!
<adamgreig[m]>
( James Munns, thanks for preparing the spreadsheet, could you make it read-only again for now and we can unlock it again next week?)
<JamesMunns[m]>
It's still read only :)
<adamgreig[m]>
hah, even easier
<JamesMunns[m]>
I'll be out next week, I'll ping you for your google acct so you can have write permissions (or you can dupe it and share next week)
<adamgreig[m]>
apologies if anyone was counting on doing triage this week, it's a nice way to fill in a quieter meeting but when there's a bunch of new things being brought up I thought it make sense to work through them
<adamgreig[m]>
sure, thanks
<adamgreig[m]>
ok, the final points for this week then are a handful of svd2rust PRs
<adamgreig[m]>
the first one is around the no_mangle DEVICE_PERIPHERALS static we define to ensure the singleton-ness
<adamgreig[m]>
ultimately I think the solution is probably "don't provide singletons in the PAC" but in the meantime moving to the links= key in Cargo.toml is probably a better way to avoid multiple versions linking together...... except for it not being backwards compatible, i.e. you could link one version using DEVICE_PERIPHERALS and another using links
<jannic[m]>
Changing the name has the same disadvantage.
<adamgreig[m]>
ah yea, was about to say that too
<adamgreig[m]>
changing it to a device-specific name helps "link multiple PACs together if you want that for some reason"
<adamgreig[m]>
but then same hazard arises
<jannic[m]>
And it looks like no_mangle doesn't really guarantee uniqueness, the linker may not even notice the multiple definitions.
<adamgreig[m]>
ideally that would be a bug in rust but it sounds like it might not be considered a bug
<JamesMunns[m]>
jannic[m]: wait what? I didn't think that was possible without weak linkage (which Rust doesn't have)
<adamgreig[m]>
thanks everyone! see you next week for probably some issue triage :P
<chrysn[m]>
Wrap-up sounds like a good time for this:
<chrysn[m]>
In case you haven't heard but are nearby: The RIOT project will have a [community event, the RIOT summit](https://summit.riot-os.org/2024/), in a month in Vienna. While the OS is largely written in C, I expect a few embedded Rust topics to come up, including an intro workshop that's bilingual in Rust and C.
<chrysn[m]>
The call for speakers is officially over, but the form is still up in case you want to present something embedded related that'd fit the event (it's not just about the OS, we'd like to keep a wide view of things).
burrbull[m] has joined #rust-embedded
<burrbull[m]>
> but still using memory mapped structs
<burrbull[m]>
Have you looked PR after rewrite?
<burrbull[m]>
s/structs/structsHave/, s/Have//
<burrbull[m]>
Have you looked PR after rewrite?
<burrbull[m]>
* > but still using memory mapped structs
<burrbull[m]>
Have you looked PR after rewrite?
<burrbull[m]>
* > but still using memory mapped structs
<adamgreig[m]>
no, sorry! I'll check it
<geky[m]>
<bartmassey[m]> "Is it "second write zeros" or "..." <- Second-write zeros at byte-level. -- It's common for NOR/internal flash to include internal ECC bits to make the underlying flash last longer, but since these bits are stored on the same flash medium, they get in the way of bit-masking-to-zero tricks. _But_, if you make the ECC such that the zero byte has an ECC of all zero bits, you can at least make the jump to a zero-byte
<geky[m]>
work. Quite useful for marking old pages as deleted.
<geky[m]>
I think it's quite neat
<bartmassey[m]>
Thanks!
danielb[m] has quit [Quit: Idle timeout reached: 172800s]