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: https://github.com/gauteh/sfy/tree/main/sfy-buoy 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.
<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
<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]>
oh, maybe not. it’s the most official-looking one I know
bomb has quit [Quit: 💣]
<shashankx86[m]>
<barnabyw[m]> "https://matrix.to/#/#rust:matrix..." <- 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]
<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]>
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]>
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 build.rs 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 link.x.in into the build directory in build.rs, 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]>
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