Dr_Who has quit [Read error: Connection reset by peer]
rainingmessages1 has quit [Read error: Connection reset by peer]
rainingmessages1 has joined #rust-embedded
Socke has quit [Ping timeout: 244 seconds]
Socke has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
frdem has joined #rust-embedded
LoriLorusso[m] has joined #rust-embedded
<LoriLorusso[m]>
thejpster[m]: Hi! I've never posted here but I totally agree. I would love to set up a call to chat about how we can work together
<LoriLorusso[m]>
Sorry, I'm lori, I work for the Rust Foundation and am working on the RCN.
<thejpster[m]>
Hi Lori!
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<LoriLorusso[m]>
Would love to talk things out with y'all. What do you think is the best way to make this happen. I'm all in on whatever works best.
frdem has left #rust-embedded [#rust-embedded]
<diondokter[m]>
Hi there! Who is the 'you' here? Do you mean the working group or commercial users or anybody in this chat room?
<thejpster[m]>
There are 3,800 odd people in here :)
rainbyte has quit [Read error: Connection reset by peer]
rainbyte has joined #rust-embedded
gkoebel has quit [Ping timeout: 265 seconds]
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
gkoebel has joined #rust-embedded
<LoriLorusso[m]>
I meant the group or what makes the most sense for the general you. I can do 1:1s but I think it might be more beneficial to have a group call. I know you have meetings and if you would be willing to give me a few minutes that would also be great.
<thejpster[m]>
The meetings are held over text chat, in this room, Tuesdays at 8pm Berlin time. We can certainly give you a few minutes at today's meeting if you like.
<thejpster[m]>
I think I would propose at the meeting that we pick a couple of people from the WG to form a sub-group to chat with you in more detail, probably in a Zoom call.
<thejpster[m]>
Then come back with recommendations.
<LoriLorusso[m]>
absolutely. I am free today and really appreciate this opportunity
sskartheekadivi has quit [Read error: Connection reset by peer]
sskartheekadivi has joined #rust-embedded
glitchy has quit [Ping timeout: 241 seconds]
glitchy has joined #rust-embedded
sskartheekadivi has quit [Read error: Connection reset by peer]
sskartheekadivi has joined #rust-embedded
sskartheekadivi has quit [Read error: Connection reset by peer]
sskartheekadivi has joined #rust-embedded
raymondr has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
sknebel has quit [Remote host closed the connection]
sknebel has joined #rust-embedded
AstraKernel[m] has quit [Quit: Idle timeout reached: 172800s]
raymondr has quit [Remote host closed the connection]
<thejpster[m]>
I'm cycling home now, so I might be a few minutes late to the meeting
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room , meeting time! agenda is https://github.com/rust-embedded/wg/discussions/932 (thanks thejpster for putting it together), please add anything you'd like to announce or discuss and we'll start in about five minutes
<thejpster[m]>
I made it
<thejpster[m]>
<thejpster[m]> I minimised my qemu-system-arm issue with the mps3-an524 machine....
<LoriLorusso[m]>
Now for the backstory - one of the things the Rust Foundation heard from our members is that they wanted a place where they could network with the broader technical community about how they are using Rust and how to help advance adoption
<LoriLorusso[m]>
They also wanted a place to create a sort of lobbying function where they could work closer with the Rust project and advocate on certain things they would like to see in the language - giving real world examples of what certain changes could mean down the line
<LoriLorusso[m]>
They also wanted a place to work outside of the Project and focus on the ecosystem - crates and other projects that they use and come up with ways to create reference architectures and other case studies to help other companies adopt Rust into their stack
<LoriLorusso[m]>
And from the Project side they also wanted feedback from users - companies and individuals that can help them work through decisions they make and see what impacts they are having
<LoriLorusso[m]>
long story short and quite a few attempts at coming up with a name we landed on the Rust Commerical Network
<LoriLorusso[m]>
We see this as another entry point to working with Rust, the Rust Project, and the Rust Ecosystem
nikomatsakis[m] has joined #rust-embedded
<nikomatsakis[m]>
...so many attempts at naming...
<LoriLorusso[m]>
where in the spirit of open source companies can get together to tackle their problems out in the open and work with the project
<LoriLorusso[m]>
If you scroll down to the membership piece you can see we got a lot of interest from a variety of companies and individuals that use Rust and want to contribute back
<LoriLorusso[m]>
we have a monthly meeting where we start with general housekeeping and move on to presentations (these can be from some of the initives started in Zulip or individuals that have something they want to share or discuss)
<thejpster[m]>
Lori (and Niko): do you have a good feel currently for what the Rust Embedded Devices Working Group is doing, or would a little bit of history here be helpful?
<LoriLorusso[m]>
Would love to learn more. my fingers are getting tired and I guess that's like saying I have a dry throat from talking! :)
<adamgreig[m]>
thanks for the introduction!
<adamgreig[m]>
I guess the idea is that perhaps the wg would be an rcn-affiliated wg and thus some wg members would be rcn initiative members, or something like that?
<adamgreig[m]>
well, I'll let thejpster fill you in on the wg background first
Mathias[m] has joined #rust-embedded
<Mathias[m]>
This a follow-up to a discussion that came out of last year's RustWeek, in parallel to REWG to leaving the Rust Project. The unanimous opinion was for the REWG to continue operating on an individual contribution basis. There was some mention that companies prefer to operate in consortiums, and the REWG had no interest in dealing with contracts or money. When discussing this with Niko, he suggested that the Rust Foundation might be
<Mathias[m]>
a place for companies to pool their effort. Alexandru, Tiago, James and I talked to the Rust Foundation and eventually submitted a proposal. For what I heard this got picked up and morphed into the RCN thanks to the effort of Lori and co.
<Mathias[m]>
I would like to thank everyone involved in making this happen. My hope is that companies having an interest in REWG as providers or consumers will leverage the RCN and create a group there, to come up with share priorities / needs whether for the REWG or the Rust Project, and then act on them in pooling resources (money, engineers) to pursue them.
<LoriLorusso[m]>
We are definitely wanting to pool our efforts and help make things centralized. We also understand and champion that groups like yours existed well before us and have a wealth of knowledge and experience to tap into. We would love to see participation in the group and for you to present what you're working on at one of our calls
<LoriLorusso[m]>
My goal is to also have members of other foundations like the CNCF or Python join us so we can look into the interop space and again work together
<LoriLorusso[m]>
Part of when we created the RCN we worked with Pete from the Safety Critical Rust Consortium to have guidelines for if a group that previously existed wanted to join under the RCN
<LoriLorusso[m]>
again not saying that is a goal just that we took that into account so that we could be very transparent in that could look like and leaving the RCN is part of it as well
<LoriLorusso[m]>
not changing the way you operate etc.
<LoriLorusso[m]>
all of this is to say I would love to chat more and I don't want to take up too much of your meeting time
<adamgreig[m]>
I'm on board with the general aims of the RCN, but it's not clear to me whether the idea is for the rewg to exist within the RCN, or to be its own entity that's somehow affiliated/associated with the RCN, and if the latter, then what that means in practice compared to just some individual REWG members also happening to be RCN members
<adamgreig[m]>
I can see that other entities in the RCN would like to be able to work together with us and discuss things of mutual interest/importance, so I guess the idea is the RCN helps to facilitate that in settings that are more conducive than having random company reps join this matrix room
<LoriLorusso[m]>
I don't think we need to answer that today. I think having some REWG peeps join the RCN to get a feel for it and report back works.
<adamgreig[m]>
yep, sure!
<thejpster[m]>
Who here is a member of both groups?
<thejpster[m]>
I am by virtue of Ferrous Systems joining the RCN.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
That would be my question as well?
<therealprof[m]>
s/?/./
<adamgreig[m]>
right now it's not clear (or perhaps even not likely) that the rewg will remain under the project umbrella, there's talk of it moving into a rust society umbrella, and I guess perhaps the idea is that the RCN could also be a home for it
<LoriLorusso[m]>
what I think would be great is to have a call with some of you and then perhaps have a representative present at an upcoming RCN meeting. to discuss what you're doing and what interest their may be from the RCN in helping with your goals
<adamgreig[m]>
sure, sounds sensible to me
<Mathias[m]>
My thinking is that companies (ideally with employees involved with REWG) would take part of RCN. Those people/companies would then in turn engage with the REWG.
<Mathias[m]>
A big unknown to me is how companies will organize themselves in the RCN around the embedded topic. It's really diverse.
<adamgreig[m]>
ok, so maybe an initial call with me, therealprof, thejpster, Mathias, is anyone else interested in joining?
<LoriLorusso[m]>
Mathias: & adamgreig I see this as an opportunity for us to at the minimum share info across the board and perhaps you can help outline that for the RCN
<Mathias[m]>
Sounds good
<nikomatsakis[m]>
I'd like to join!
<nikomatsakis[m]>
Or at least be added as optional on the invite. If not me, then Jack Huey or David Wood most likely, one of the Rust project directors
<nikomatsakis[m]>
I've been a bit distracted during this call but for me the tl;dr is that the RCN will I think more and more be a kind of "front door" for companies who are using Rust or looking to learn more about working within their domain, and i want to ensure that for those folks doing embedded we don't wind up "two" embedded working groups, so to speak. You all have done a really great job over the years keeping this community focused,
<nikomatsakis[m]>
building out the HAL traits, etc, and I want to make sure things stay that way.
<adamgreig[m]>
makes sense!
<LoriLorusso[m]>
Thanks so much. I'm a matrix newbie - can I start a DM group to sort out the meeting info? This is really exciting and I appreciate your time and together we can sort out a path forward
<therealprof[m]>
LoriLorusso[m]: Yes, you can.
Noah[m] has joined #rust-embedded
<Noah[m]>
I would probably interested for probe-rs to at least get some info :)
<Noah[m]>
* would probably be interested for
<therealprof[m]>
therealprof[m]: Start a DM with one person, then add more.
<thejpster[m]>
We'll make sure we disperse here, and also reach out to all the associated groups (probe-rs, embassy, stm32-rs, nrf-rs, rp-rs, tock, etc)
<Noah[m]>
very much part of the REWG community but also kinda standalone
<thejpster[m]>
Embedded Working Group Cinematic Universe
<LoriLorusso[m]>
just in time for Avengers Doomsday
<adamgreig[m]>
ok, thanks for the discussion everyone! we'll have this separate meeting and report back afterwards
<thejpster[m]>
please take a look and see if you can spot anything egregious, as we haven't done a release for a while
<adamgreig[m]>
so my sole concern over a cortex-m 0.7.8 release is that I still have a gut feeling that we don't actually need a cortex-m-macros crate and if we can avoid it then so much the better for everyone's compilation times and general dependency sprawl, but I've managed to put precisely zero time into investigating if we can replace them with a macro by example
<thejpster[m]>
not the end of the world if I have to yank, but I'd like to at least try and avoid that
<adamgreig[m]>
at this point it's maybe better to just get 0.7.8 out the door and if we can remove the macros crate for 0.8 then great
<thejpster[m]>
you could remove the macros in a 0.7.9 - it's an internal detail
<thejpster[m]>
I spent 30 minutes reading the locally generated docs (cargo doc --target=thumbv8m.main-none-eabihf, for both cortex-m and cortex-m-rt) and found at least 3 bugs. So if anyone has some time, I would urge you to do the same.
<adamgreig[m]>
ok, will do that too
<adamgreig[m]>
have you run cargo-semver-checks? it was clean last time I merged a bunch of cherry-picks but there's been a few more changes since then
<adamgreig[m]>
(well, clean enough)
<thejpster[m]>
it doesn't work cross compiled, AFAIK
<thejpster[m]>
and building natively it cannot see the asm module and whines about a lot of stuff
<adamgreig[m]>
interesting, I guess that's a change from the previous version of the asm module
<thejpster[m]>
the good news is, I have TrustZone-M working with these new releases
<thejpster[m]>
and it's relatively painless. Although ST are doing their level best to make it difficult.
<thejpster[m]>
(you must program whether SRAM is secure or nonsecure on an individual 512 byte page basis, even though there's about 2 MB of SRAM available)
<adamgreig[m]>
hah, thanks st
<adamgreig[m]>
very nice though
<adamgreig[m]>
ok, so for the release let's have a few more eyes on the docs and general state of things and hopefully have it published before next meeting?
<adamgreig[m]>
leaving the macros in for now
<thejpster[m]>
that would be great. I can finish my materials using the git branch for now.
<adamgreig[m]>
final point is yours about the armv7e-m/armv8-m tests; any idea how much work that is to add on top of our existing qemu tests?
<thejpster[m]>
well there's two avenues
<thejpster[m]>
we can expand the testsuite system cortex-m already uses
<thejpster[m]>
or aarch32 has more of a set of standalone binaries that you build and run and check their output is as expected
<thejpster[m]>
which gives more more opportunity to muck up system state (like switch to the Process Stack Pointer, which has to be the last test in the test suite because nothing else will run after it)
<thejpster[m]>
either way, some coverage of things like the asm:bootload_ns function I think is required. Especially in our role as target maintainers, or "the first people to shout when the compiler breaks somethign"
<adamgreig[m]>
yea, makes sense
<adamgreig[m]>
expanding the existing testsuite I think would be very easy but probably not buy us much since I doubt it would really explore any differences in the v7e-m or v8-m VMs
<diondokter[m]>
<thejpster[m]> (you must program whether SRAM is secure or nonsecure on an individual 512 byte page basis, even though there's about 2 MB of SRAM available)
<diondokter[m]>
Yes, and *every* vendor does it differently. And often DMA does not care about the SAU settings, so each vendor has custom settings for that too
<thejpster[m]>
there are qemu machines for the Cortex-M3. Cortex-M4, Cortex-M7, Cortex-M33 and Cortex-M55 currently, plus the microbit machine covers the Cortex-M0.
<thejpster[m]>
We currently only use the microbit machine and the lm3s machine (a Cortex-M3).
<thejpster[m]>
I can see a thumbv8.1.main-none-eabihf target on the horizon, so knowing qemu can do Cortex-M55 is useful.
<thejpster[m]>
uh, thumbv8.1m.main-none-eabihf
<thejpster[m]>
really rolls of the tongue, that one
<adamgreig[m]>
ok, perhaps porting some equivalent of the aarch32 standalone test binaries would make sense for 0.8 then
<adamgreig[m]>
I think that's all for this week, thanks for your agenda items thejpster!
gkoebel has quit [Quit: gkoebel]
cr1901_ has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.7.2]
cr1901 has quit [Ping timeout: 259 seconds]
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
gkoebel has joined #rust-embedded
jjido has joined #rust-embedded
wucke13[m] has joined #rust-embedded
<wucke13[m]>
How do I figure out the correct `tim_clock_hz`, the argument to `Mono::start()`?
<wucke13[m]>
I got a question regarding RTIC v2 + Monotonic via timer on stm32.
<wucke13[m]>
From my point of view, there can't be a correct answer; unless I configure the timer by hand, there is no definitve answer to it. Yet the example just uses a _magically correct_ value without ever setting up hardware such that this value is correct, AFAICT.
az1[m] has joined #rust-embedded
<az1[m]>
which example are you looking at?
<az1[m]>
There's an rtic room that may be more helpful. From looking at the comments in stm32f3_blinky they're relying on knowing the default clock configuration. The alternative is to setup the clock tree first and pass in the frequency you've set.
<wucke13[m]>
<az1[m]> which example are you looking at?
<az1[m]>
right, like the comments say you can either hardcode a value (e.g. you know the default) or you can read it from the peripheral.
<az1[m]>
I believe the stm32 hal stores the clock config in a static variable after you configure it, and TIM2::frequency() will use that to determine the frequency of TIM2.
<az1[m]>
* I believe the stm32 hal stores the clock config in a static variable after you configure it, and TIM2::frequency() will use that to determine the frequency of TIM2. Also if you look at line 17, that's how you would query TIM2.
<az1[m]>
`timer_clock_hz` is the frequency of the clock source you're using, `timer_hz` is the frequency of the monotonic. So yes, `tim_clock_hz` must be a multiple of `timer_hz`.
<az1[m]>
If you're using the default frequency (line 20) then any change to `RCC` could throw off your timer. If you're going to use `TIM2` I'd setup your clocks and then call `TIM2::frequency()` to get the actual frequency of the timer and use that when you initialize the monotonic driver (e.g. `Mono::start()`).
<wucke13[m]>
There is no ::frequency() in pac::TIM5, nor in cx.device.TIM5
<wucke13[m]>
(the only mentionings of ::frequency in my local cargo docs are for stm32f4xx_hal::dwt::MonoTimer and stm32f4xx_hal::rtc::ClockSource
<wucke13[m]>
* There is no ::frequency() in pac::TIM5, nor in cx.device.TIM5)
<az1[m]>
Ah. I'd ask over in the RTIC room. #rtic:matrix.org
<az1[m]>
In the interim, can you use systick instead?
<wucke13[m]>
az1[m]: Yes! I was using that, but my understanding is that systicks trigger ISR, and thus setting a high systick rate will degrade performance notably, but setting a slow systick rate will reduce precision for timing severily. I try to get the best of both worlds, hence the attempt to get of systicks and onto actual timers for timing. Or is my understanding wrong?
<wucke13[m]>
Anyhow; thank you for the pointers kind stranger!
jjido29 has joined #rust-embedded
rainbyte has quit [Read error: Connection reset by peer]