ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
mohdrais[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has quit [Ping timeout: 260 seconds]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 260 seconds]
kenny has joined #rust-embedded
gauteh[m] has joined #rust-embedded
<gauteh[m]> <MiloMoisson[m]> "Can targets coexist in a..." <- I'm not sure if this is exactly what you want, but I have this setup: where the target specific code lives in a sub-dir, and the generic code lives in the sfy-buoy dir. It can be compiled and tested on host, while the target specific stuff needs to be compiled separately. CI does several tests, and the makefile helps out.
<JamesMunns[m]> Reminder room: Today is the first "Impl Meeting", more details and issues you can nominate are here:
diondokter[m] has joined #rust-embedded
<diondokter[m]> Too bad I'm now always occupied when the meetings happen... :/
starblue has quit [Ping timeout: 256 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
fooker has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
Mark[m] has joined #rust-embedded
<Mark[m]> Just wondering, how come some MCU families, like STM or RP, are widely supported by the open source community, and others, like Texas Instruments, are not?
<diondokter[m]> Mark[m]: Pretty much the popularity of the chips
<diondokter[m]> And also the chip architecture. Does Rust even run on PIC chips?
fooker has joined #rust-embedded
<Mark[m]> Ah, I see. Yeah I also thought it could have something to do with the architecture not being supported, but TI also has ARM-based chips.
<Mark[m]> Can you see manufacturers adopting Rust officially likes Espressif?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> I believe ARM-based chips have faced much wider adoption because of the SVDs that are generated as part of the ARM IP licensing process. Open source can then grab the SVDs to auto-generate the chip register descriptions instead of doing it manually
<ryan-summers[m]> Whereas for i.e. something like an MSP430 you're relying on the chip vendor and compiler supplier to give you that, and if it's not in Rust, you're out of luck
<diondokter[m]> Infineon is working on it. But at Embedded World I think I spoke with a hardcore C dev and he said they were just toying with it :P
<diondokter[m]> Most vendors I spoke with really concluded that they think Rust is interesting, but it would only make sense to support it if there are enough customers asking for it
<diondokter[m]> Which is fair tbh
<Mark[m]> I'll ramp up my "when will you support Rust officially?" activity on Twitter, haha
<diondokter[m]> If you're buying 10k chips a month, definitely do!
<JamesMunns[m]> Do it anyway even if you aren't, 10 customers buying 1000 chips a year helps just as much!
juliand[m] has joined #rust-embedded
<juliand[m]> <diondokter[m]> "Infineon is working on it. But..." <- Interesting. The one I talked to said they were going to release a lot more around summer and want to even bring their own crate registry and get a lot of stuff certified (using also ferrocene as I understand). He sounded at least somewhat excited :D
<juliand[m]> these guys are apparently building compilers for Infineon (or an llvm backend, not sure) and had this company on their stand, as well:
<juliand[m]> One of their guys told me they will be releasing more stuff this month even.
<juliand[m]> No specific dates for anything though
<diondokter[m]> <juliand[m]> "Interesting. The one I talked to..." <- Probably not Ferroscene, yeah hightec is the partner they're working with
<diondokter[m]> They've made their own svd tool too:
<diondokter[m]> Supposedly it works more like chiptool
<juliand[m]> Yeah he was kinda telling me that they use ferrocene as a Rust compiler and then their own stuff in the Backend. But i have very little knowledge of how that stuff works and what would need to be certified so I just took that
<juliand[m]> diondokter[m]: Yeah that one he told me about, as well.
<diondokter[m]> Did you talk with Tiago? Because they told us he wasn't at the conference
<juliand[m]> No, his name was Chris iirc. From Germany definitely
<Mark[m]> Certification is important for industries like automobile, etc?
<JamesMunns[m]> It can be, it is required in some industries in some countries for some applications (I know I'm adding a lot of caveats, but it's real "It Depends" territory)
bomb has joined #rust-embedded
<juliand[m]> Especially for new technology (or programming languages, in this case) it seems to also help convincing some people that would otherwise not be "risking" any changes to what they have. May also have something to do with liability sometimes.
tamme[m] has quit [Quit: Idle timeout reached: 172800s]
shashankx86[m] has joined #rust-embedded
<shashankx86[m]> Is there any official rust Matrix server?
cybernaut has joined #rust-embedded
cybernaut has quit [Read error: Connection reset by peer]
barnabyw[m] has joined #rust-embedded
<dirbaio[m]> I don't think that's official?
<barnabyw[m]> oh, maybe not. it’s the most official-looking one I know
bomb has quit [Quit: 💣]
<shashankx86[m]> <barnabyw[m]> "" <- Not there anymore
<barnabyw[m]> it definitely is, last messages there were an hour ago. but not official according to the room description :P
GenTooMan has joined #rust-embedded
xerpi[m] has quit [Quit: Idle timeout reached: 172800s]
xiretza[cis] has joined #rust-embedded
<xiretza[cis]> <shashankx86[m]> "Is there any official rust..." <- there is not, they don't even want to list it in the community section on the website.
badyjoke[m] has joined #rust-embedded
<badyjoke[m]> Hello ! Why some HAL define and use a trait called Sealed ?
<JamesMunns[m]> The answer is generally: So that driver writers can make certain guarantees, but without allowing users to rely on them or extend them in ways they shouldn't
<badyjoke[m]> Thank you !
IlPalazzo-ojiisa has quit [Quit: Leaving.]
AtleoS has quit [Ping timeout: 256 seconds]
AtleoS has joined #rust-embedded
AtleoS has quit [Ping timeout: 256 seconds]
<oneDragon[m]> I've been looking at UART implementations in the Raspberry Pi recently and it seems that both tx and rx data are read from dr?
<dirbaio[m]> tx data is written, not read
<dirbaio[m]> that's how the hardware tells the difference, I guess
<JamesMunns[m]> Yeah, MMIO looks like normal data access, but the hardware is allowed to do spooky things, like tell the difference between reads and writes, or have side effects (like clearing interrupts on reads)
<oneDragon[m]> Can I understand that when write to dr registers, this u8 will be send to tx, but there is a kind of loop continue collect bit from rx and set it to dr?
Ecco has quit [Read error: Connection reset by peer]
beanflame[m] has quit [Quit: Idle timeout reached: 172800s]
Ecco has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> hi @room, meeting time! agenda is but we'll be trying out the new thing this week
<adamgreig[m]> i'm gonna try and pull together a c-m-rt release first of all, who else is around?
<cr1901> I'm here in the background lol
<adamgreig[m]> the new thing is "instead of just chatting all meeting, we try out doing some outstanding impl stuff and chat about it as it comes up"
jannic[m] has joined #rust-embedded
<jannic[m]> I'm currently on my phone, but will be at the keyboard later.
<cr1901> Ahhh interesting strategy, and one I like
<adamgreig[m]> James Munns: if you're looking at the hard-to-be-sound c-m-rt multiple sections example, maybe it'l be worth including some updated doc text in this new release?
<JamesMunns[m]> I realized I have to run soon, but re:, is it reasonable to use grounded for this?
therealprof[m] has joined #rust-embedded
<therealprof[m]> I'm here.
<JamesMunns[m]> or would you like it to be "no deps"?
<adamgreig[m]> I think my preference would be for the example to be no-deps, but I'd be OK to link to grounded as a suggestion for a library to make it easier
<therealprof[m]> Agreed.
<JamesMunns[m]> Gotcha. It'll just require reciting all the boilerplate that grounded handles for you. I'll see how it goes tho (not right now, unfortunately)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> I'm here. Let me know how I can help.
<adamgreig[m]> probably make a good advert for grounded then :P
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]> cool, draft pr for c-m-rt open,
<dirbaio[m]> o/
<adamgreig[m]> there's a few outstanding issues that could be wrapped up too: about increasing linker section alignment
<adamgreig[m]> which probably just needs the example/docs updated
<adamgreig[m]> dirbaio's old about mystery linker warnings...
<JamesMunns[m]> I think is an improvement for sure!
<therealprof[m]> was updated and seems ready, too.
<adamgreig[m]> yep, though it's not in c-m-rt so I'll get to that after
<therealprof[m]> Oh right, sorry, this multi-repo is still confusing.
<dirbaio[m]> c-m git already has breaking changes, right?
<adamgreig[m]> anyone have thoughts on the linker section alignment? i can see the utility but it potentially wastes a little ram
<adamgreig[m]> c-m git does, yes, though one of the items on my list is to revert the only (small) breaking change so we can publish a new 0.7 release from master and make the breaking 0.8 a new branch
thejpster[m] has joined #rust-embedded
<thejpster[m]> I'm fine with changing the alignment.
AdamHott[m] has joined #rust-embedded
<AdamHott[m]> adamgreig[m]: is it basically a safety vs. efficiency question?
<adamgreig[m]> hmm not exactly
<bartmassey[m]> I think the linker section alignment is good. I can't see where the extra 50-100 bytes is going to be a big deal for anyone.
<adamgreig[m]> there's no direct safety implication right now
<AdamHott[m]> ok
<adamgreig[m]> but it would be convenient for people wanting to set up the MPU to mark say the stack as a different region to .data and such
<therealprof[m]> 50-100 bytes?
<adamgreig[m]> so it's maybe useful for some people in the future, and in a better world we'd also have stuff built in to cortex-m to make it very easy to set up the mpu to do that for you...
<bartmassey[m]> More or less. Three extra 32-byte alignments, right?
<adamgreig[m]> the very worst case is each alignment adds 31 bytes
<bartmassey[m]> Yeah, so 93 bytes total.
<adamgreig[m]> but I think you could reasonably expect more like 16 on average, in some cases zero
<therealprof[m]> Yeah, I think having a useful alignment makes a ton of sense.
<dirbaio[m]> it should be opt-in
<bartmassey[m]> The literal average would be 46.5, but of course it's very much not random.
<dirbaio[m]> there's people using cmrt on devices with like 1k-4k ram
<therealprof[m]> Can still be changed if space is super tight.
<dirbaio[m]> 90 bytes can be a big deal
<adamgreig[m]> 93 is a fair chunk of waste if you only have 6K of RAM or so, but it's fairly easy to bring your own linker script with different alignment if you need to get the last bit
<thejpster[m]> they're already 4 byte aligned.
<bartmassey[m]> An opt-in feature is a possibility, but I might prefer opt-out (default to on).
<therealprof[m]> True.
<adamgreig[m]> I don't think there's any good way to make it opt-in, at least without a very dramatic change to how the linker script is generated
<thejpster[m]> the opt-out is to write your own linker script
<dirbaio[m]> people using Rust on 1k ram devices is more common than people using the MPU
<dirbaio[m]> and people using the MPU are more likely to need a custom linker script for other reasons anyway
<thejpster[m]> and the linker script is already processed in so s/ALIGNMENT/32/ is entirely feasible
<dirbaio[m]> and are likely to be more sophisticated users, having to write a custom linker script is not that big of a deal for them
<adamgreig[m]> ideally people using the MPU can get by with changes in memory.x alone, but you can't change the ram/flash section alignment there, it has to come from link.x
<dirbaio[m]> but it is for a newbie that accidentally bought the smallest stm32 and is struggling with making things fit in RM
<dirbaio[m]> s/RM/RAM/
<adamgreig[m]> but it is true that we copy into the build directory in, so you could have a feature that changes it?
<cr1901> Or ppl who just like smol devices :)
<therealprof[m]> Sorry, but 1k RAM is going to be the LAST of all problems such a newbie will face...
<adamgreig[m]> dirbaio[m]: I think very few people are using rust on 1k ram devices overall, even if it is more than are using the mpu, and I think that's because it's too hard to set up the mpu right now
<bartmassey[m]> I think 8KB is the smallest STM part being currently sold? They may have sold 4KB parts in the past…
<adamgreig[m]> but ideally we'd have a feature in c-m that automatically enables the mpu with some sensible defaults, and then a lot of people could use it
<dirbaio[m]> also it is NOT true that MPU regions have to be 32byte aligned
<therealprof[m]> Before RAM is going to be a problem, you have to worry about fitting the software that actually makes use of that much RAM into your 6kB of Flash.
<dirbaio[m]> it's some weird power of 2 thing, where if you make them bigger you need even higher alignment
<dirbaio[m]> 32byte is just the smaller you can go
<therealprof[m]> Fair.
<cr1901> FWIW, the smallest ARM I'm aware of was lpc810, which is 1k RAM and discontinued. I'd not be surprised if no ARM device on the markest is that small.
<adamgreig[m]> oh, yea, duh
<adamgreig[m]> that's more pertinent
<dirbaio[m]> so adding 32byte align doesn't even solve the problem
<thejpster[m]> STM32F030 is 4K RAM.
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]> and "mark .data as nonexecutable" is only one way of using the MPU
<adamgreig[m]> yea, specifically memory regions in the mpu must be a power of 2 and naturally aligned
<bartmassey[m]> But with 32-byte alignment you could get something working out of the box, at least, I guess.
<thejpster[m]> you could have one linker script for Cortex-M0+ and another for everything else
<thejpster[m]> because the tiny RAM devices will all be M0+
<dirbaio[m]> you might want to use it for sandboxing a kernel from userspace processes, and not care about separating executable and nonexecutable memory within the kernel.
<bartmassey[m]> It looks like there's a new PIC floating around with 256B RAM. Heh. But not relevant here.
<dirbaio[m]> for that use case you don't want 32bit align between text and data
<therealprof[m]> Honestly I'd rather have reasonable defaults and an explanation on how to go extreme, rather than being super tight up front.
<adamgreig[m]> needing the size of the region worth of alignment means forcing them to 32-byte alignment is not really helpful to anyone
<therealprof[m]> dirbaio[m]: I didn't quite get that. Why's that?
<dirbaio[m]> you might want to put kernel's text+data+rodata+bss+whatever in a single mpu region
<dirbaio[m]> and only use the mpu for userspace
<thejpster[m]> > The base address is aligned to the size of the region. For example, a 64KB region must be aligned on a multiple of 64KB
<thejpster[m]> Wait, what?
<adamgreig[m]> sure, or just use the mpu to mark a dma memory as non-cached or wahtever, lots of options
<therealprof[m]> And how's not doing a 32byte alignment going to help with that?
<adamgreig[m]> thejpster: yea, that's what dirbaio hinted at and I mentioned earlier
<thejpster[m]> Given that, I would leave the script alone and add documentation on how to copy/paste it into your project.
<adamgreig[m]> sections are powers-of-two and naturally aligned
<therealprof[m]> Fine.
<adamgreig[m]> if we don't already, we could do with documentation on "how to customise the linker script" anyway
<therealprof[m]> I remember seeing such documentation.
<therealprof[m]> That's it, thanks for the link.
<AdamHott[m]> np
<adamgreig[m]> hm, we should have a discussion/example in the c-m-rt docs though
<adamgreig[m]> OK, that's two docs updates and the mystery linker warnings
<adamgreig[m]> I'll update the docs now, anyone have any ideas about the warnings?
<thejpster[m]> We said  .got (NOLOAD) :. which I guess is SHT_NOBITS
<dirbaio[m]> > I got some help which seems to have solved my problem. Try adding the following feature in Cargo.toml
<dirbaio[m]> > `critical-section-single-core`
<dirbaio[m]> that makes no sense lol
<thejpster[m]> So we could just remove the .got section. I'm not sure how anyone would generate a global offset table without knowing about it.
<therealprof[m]> thejpster[m]: Yes.
<thejpster[m]> I'd actually prefer to fix LLVM so that the global offset table actually worked.
<thejpster[m]> Would be super useful for things like TockOS which want to be able to relocate binaries at will
<dirbaio[m]> that's not happening any time soon lol
<thejpster[m]> what would happen if we removed the .got section?
<thejpster[m]> you wouldn't get a warning on every build, but you wouldn't get a link error if you somehow turned on the global offset table.
<thejpster[m]> I'd go for not having a warning on every build. It's a very confusing warning.
<thejpster[m]> which is
* thejpster[m] checks notes
<thejpster[m]> - -C relocation-model=pic
<dirbaio[m]> maybe it's possible to, instead of removing it, assert it's empty?
<AdamHott[m]> hey all thanks so much, I have to run, I learned a ton!
<thejpster[m]> the trade off is helping people who accidentally turned on PIC and didn't want to, vs hurting people who did actually want to turn on PIC
<thejpster[m]> and I don't really see how you can turn it on by accident. maybe if you linked against some C code that was compiled with -fpic?
<dirbaio[m]> yeah I think that was the original motivation
<dirbaio[m]> (C code)
<dirbaio[m]> how do you reproduce these warnings?
<dirbaio[m]> most common way to see the warning was to cause an (unrelated) linker error, but I can't reproduce it
<adamgreig[m]> has the warning gone away by itself 🥲
<dirbaio[m]> dunnoooo
<therealprof[m]> Maybe the linker became smarter?
<dirbaio[m]> ahaha yep it shows up with 1.68 (from when I reported that issue) but not with latest stable
<adamgreig[m]> cool cool
<jannic[m]> I think can be closed. bare-metal has no longer been used for a while.
<jannic[m]> (Just clicking through random issues.)
<adamgreig[m]> hmm, the msrv is annoying
<adamgreig[m]> we bumped it to 1.60 because cortex-m was bumped to 1.60 to work with embedded-hal 1.0
<adamgreig[m]> but cortex-m-rt uses cortex-m in its tests, so we can't run its tests with a rust less than 1.60 anyway
<adamgreig[m]> in practice I can't imagine anyone's using c-m-rt without c-m...
<adamgreig[m]> so I think probably let's just bump to 1.60
<adamgreig[m]> should be ready then I think, once it's approved I'll get it released
<adamgreig[m]> cool, well thanks everyone! this was pretty productive if we got to close out a handful of c-m-rt issues and get a new release!
<therealprof[m]> Care to apply my suggestion?
<dirbaio[m]> 1.72 shows the warning, 1.73 doesn't
<dirbaio[m]> 1.73 upgrades to llvm 17
<dirbaio[m]> that's probably it
<dirbaio[m]> close issue? y/n
<jannic[m]> But it looks like the change was already reverted in the rust beta branch. So the CI should be fine again in a few days.
<jannic[m]> It would be possible to work around that by changing `#![cfg_attr(not(feature = "std"), no_std)]` to... (full message at <>)
<dirbaio[m]> fix is to stop using beta
<dirbaio[m]> the "msrv-1-75" job uses beta because back then 1.75 was beta
<dirbaio[m]> and was never changed to 1.75 lol
<jannic[m]> Well having CI jobs on beta is nice so one gets an early warning about such changes, before they hit stable :-)
<jannic[m]> But I get your point, in the msrv-1-75 we should use the released 1.75 version and not some random beta.
<dirbaio[m]> well yeah, but the msrv-1-75's job is to check whether embedded-hal async stuff builds on 1.75 (the MSRV). not on beta
<jannic[m]> msrv-1-75 is not the only job failing though.
<dirbaio[m]> the others should use latest stable
<dirbaio[m]> and if we add jobs to test on beta/nightly they shouldn't block merging
<jannic[m]> test.yml contains uses: dtolnay/rust-toolchain@beta, so it uses beta.
<dirbaio[m]> it shouldn't use beta
<dirbaio[m]> we made it use beta at the time because 1.75 wasn't stable yet
<dirbaio[m]> but that's not true anymore
<dirbaio[m]> it was supposed to be temporary, and then I just forgot about it
<dirbaio[m]> <3
<adamgreig[m]> rustc 1.38 complaining that edition=2021 is unknown 🥲
<therealprof[m]> adamgreig[m]: LOL?
IlPalazzo-ojiisa has quit [Quit: Leaving.]