<dirbaio[m]>
dirbaio[m]: I think you need the `&*` to convert from `&mut` to `&`
<dirbaio[m]>
dirbaio[m]: since the `&mut` can't be copied but the `&` can
<paumanok[m]>
dirbaio[m]: Okay that's compiling, now I'm just going to test this out with the driver I ported.
<paumanok[m]>
What does the &* express?
<dirbaio[m]>
paumanok[m]: * is the derefernece operator, converts from `&mut T` to `T`
<dirbaio[m]>
& takes a reference to that, converts from `T` to `&T`
<dirbaio[m]>
* `*` is the derefernece operator, converts from `&mut T` to `T`
<dirbaio[m]>
`&` takes a reference to that, converts from `T` to `&T`
<paumanok[m]>
dirbaio[m]: ah, I so rarely see the manual dereference, this seems to be working nicely
<dirbaio[m]>
paumanok[m]: yeah rust is usually smart enough to figure out what you mean automatically
<dirbaio[m]>
dirbaio[m]: but not in this case :P
<paumanok[m]>
dirbaio[m]: I really appreciate the help today, I'm going to make a writeup for this in the hope it helps one or two poor souls out there
Foxyloxy has joined #rust-embedded
rom4ik3 has joined #rust-embedded
jiande20201 has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
Foxyloxy_ has quit [Ping timeout: 252 seconds]
rom4ik has quit [Read error: Connection reset by peer]
rom4ik3 is now known as rom4ik
jiande2020 has quit [Ping timeout: 252 seconds]
jiande20201 is now known as jiande2020
starblue has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]>
Beningo appears to have done very little research, and concluded no one is using Embedded Rust and it might get to 10% in 10 years.
<thejpster[m]>
If you pop to the Ferrous stand you can see a full truck dashboard, written in Rust using Bevy.
<thejpster[m]>
* Oh, if you are at Embedded Workd, if you pop to the Ferrous stand you can see a full truck dashboard, written in Rust using Bevy. And some CAN stuff I did.
relia1[m] has joined #rust-embedded
<relia1[m]>
Isn't making those sort of conclusions tiobe pretty dubious as well?
<relia1[m]>
* of conclusions from tiobe pretty
<relia1[m]>
* of conclusions using tiobe pretty
<thejpster[m]>
I know a bunch of people making everyday stuff using Rust and they have no interest in telling you about it because it’s a trade secret add a competitive advantage.
<thejpster[m]>
Does anyone run an anonymous Embedded focused developer survey?
AdamHord- is now known as AdamHorden
<ryan-summers[m]>
Honestly, that article makes a lot of really solid, valid points. But the conclusion is botched
<ryan-summers[m]>
Like yes, most of the established teams and companies I work with will likely never switch to Rust because they do have millions invested in C- and C-like infrastructure/libs. That doesn't mean they never will though
<ryan-summers[m]>
Also, those companies are dionsaurs and ripe for being ripped out of their niche because they're stagnating
<ryan-summers[m]>
What that article should really focus on is why companies are sticking to those outdated methodologies and how we can fix it. Because sticking with C and existing infra feels like a horrible approach to me
<oneDragon[m]>
Currently, I'm looking at something about Raspberry Pi network interface cards.
<oneDragon[m]>
I found that GPIO provides a kind of alternative function named RGMII_MDIO, but seems it's implement(raspi linux) haven't used this kind of method, but Instead, it uses a direct address manipulation via MMIO to use MDIO (At least from my perspective it directly write int into MMIO mem.）
<oneDragon[m]>
Are there any special considerations in the implementation of this section?
<ryan-summers[m]>
Does that make sense? I'm not entirely certain what you were asking
<ryan-summers[m]>
RGMII is another hardware interface, just like SPI or I2C
<oneDragon[m]>
Does it seem to have something to do with hardware manufacturers? I'm interviewing an integration vendor right now, and they don't actually put a lot of effort into the bottom layer, directly using drivers provided by hardware vendors, so they don't provide rust drivers plus market push, and they won't easily transform rust.
<ryan-summers[m]>
Not sure what you're asking there. Are you asking about how to use the RGMII interface?
<ryan-summers[m]>
Also, Raspberry Pi microcontrollers are not open source and it can be hard to get the spec sheets for them. Running bare metal on RPI can be quite difficult at times
<oneDragon[m]>
Yes, I know RGMII is another kind of hardware interface, basically use in the OSI layer PHYSICAL and DATA_LINK, and there is two pins( i not sure if should call this ) name MDIO and MDC
<ryan-summers[m]>
I suspect the difficulty here may be that the RPI datasheets don't fully disclose how to use the networking peripherals?
<ryan-summers[m]>
Which doesn't surprise me. I think the full datasheets are typically behind NDAs
<oneDragon[m]>
ryan-summers[m]: it make sence
<oneDragon[m]>
Quick hard to understand what is the reasons of contains RGMII_MDIO and RGMII_MDC in GPIO (
<ryan-summers[m]>
I think it's primarily just because they publish only a snippet of the full datasheet
<ryan-summers[m]>
So that part is relevant only to a part that is not provided externally
<ryan-summers[m]>
Which chip are you looking at by the way?
<ryan-summers[m]>
(There's lots of different RPI micros based on which variant you're playing with)
<oneDragon[m]>
right now i was looking at soc:bcm2711 and phy:bcm54213PE
<oneDragon[m]>
I hear some kind of news about rpi4 is the first rpi that we could use genet without impl pcie ..
<oneDragon[m]>
* pcie .. (or something like that)
<ryan-summers[m]>
Yeah the official datasheet indeed doesn't provide any information about the RGMII interface unfortunately, so I suspect that isn't published
<M9names[m]>
i'm sure broadcom would be happy to share info about their hardware with you, if you sign an NDA and order a million parts
<M9names[m]>
if you want to run bare-metal rust on a microprocessor target there are other SOCs with much more available documentation.
<ryan-summers[m]>
I was able to do bare metal on RPI v2 I think a number of years ago, but I think that was because the networking was provided by some binary blob that sat next to firmware
<M9names[m]>
i'm sure you can do it, i'm asking why you would choose to do it
<ryan-summers[m]>
And by a number of years ago, I mean like 8 and now I feel old
<oneDragon[m]>
to be honest, i found a kind of datasheet provided by broadcom BCM54213PE in the internet, but it basically just a kind of regs control manual
<ryan-summers[m]>
That's generally all datasheets usually are. But yeah, what 9names said, if you want to do networking on a bare metal device, there are other much better suited target devices, such as the STM32H7
<ryan-summers[m]>
Large parts of the RPI bare metal are undocumented, such as even getting the thing to boot your own firmware
<oneDragon[m]>
understand
<ryan-summers[m]>
Contrary to the RPI being a beginner friendly tool, RPI bare metal is not for beginner embedded devs
<oneDragon[m]>
* understand, I had received some recommendations for f103, but I only had the Raspberry Pi.
<M9names[m]>
if you want to run Rust on a Raspberry Pi, you can do that. Raspberry Pi OS has a 64bit version, and aarch64-unknown-linux-gnu is a tier 1 Rust target.
<M9names[m]>
you can still access a lot of hardware directly if you really need to. but it is simpler if you let Linux do that for you instead
<oneDragon[m]>
I see. Thank you. 🥳
<oneDragon[m]>
I'll see what's convenient.
<M9names[m]>
if you are new to embedded, my recommendation would be to start with something simpler than the H7, but still having a lot of memory.
<M9names[m]>
esp32c3's are a good choice here, as is the raspberry pi Pico or Pico W
<ryan-summers[m]>
Yeah definitely agreed. I only mentioned the H7 because you were referencing networking support. But networking is an advanced embedded topic
<sourcebox[m]>
No 1 issue that comes up when I talk with other devs is that they don't realize that Rust is suited for embedded. Even much better than C++.
<sourcebox[m]>
And they often only see the security aspect, not the tooling.
<sourcebox[m]>
There is this common misbelief that abstractions always lead to bloated unperformant code.
<sourcebox[m]>
Don't know if someone here is interested in this, but I can at least tell that there are some music products on the way that use Rust internally. One is the Redshift 6 synthesizer: https://supercriticalsynthesizers.com/
<sourcebox[m]>
One dev of it can be found at the Rust Audio Discord server.
<sourcebox[m]>
Another one (according to some mention on YT) is the Tasty Chips GR-Mega:
<sourcebox[m]>
https://www.elektron.se/en/ is also using Rust for a new product, not sure if bare metal, probably Linux. They had some Job offer for a Rust developer a while ago and there also some talk on the Rust Audio Discord about it.
<sourcebox[m]>
Me personally, I'm working on 2 products that will be release at some point (hopefully this year). But I can't speak about details in public yet.
<sourcebox[m]>
s/release/released/
Mark[m] has joined #rust-embedded
<Mark[m]>
We are using embedded Rust to make interactive Star Wars-themed prop items. Not ready yet, but we hope to ship the first before summer (hardware and product design takes time)
<sourcebox[m]>
For us doing music-related stuff it will be interesting how things develop in the long-term because we typically have longer product cycles than usual and firmware updates are a common thing even after years.
<sourcebox[m]>
So stability guarantees of Rust are a pro, but the remaining question is if one should freeze the used crate versions once things are running unless they really offer fixes to prominent bugs.
<sourcebox[m]>
E.g. with C and ST HAL, I don't update it at all unless a critical fix was applied.
<ryan-summers[m]>
<sourcebox[m]> "So stability guarantees of..." <- This generally is an "it depends" kind of question that depends on your development cycle. For Stabilizer + Booster (QUARTIQ), we have HITL tests that run whenever PRs merge, so we always update dependencies as soon as updates are available because its easy to search for regressions. But if you're just doing bug fixes for some product and no longer actively developing, there's
<ryan-summers[m]>
something to be said about locking down dependencies
<ryan-summers[m]>
It really has to do with whether or not you're going to develop on the platform in the future
<sourcebox[m]>
Of course with Rust package managment it's tempting to run cargo update all the time.
<sourcebox[m]>
In complete contrast to what was done traditionally with C, at least in my case.
<ryan-summers[m]>
We have dependabot setup and just handle dep updates every monday
<sourcebox[m]>
Also, e.g. with ST HAL, you get a monolitic block that offers nearly all you need while with Rust you rely on third party crates with sometime subtle implications.
<sourcebox[m]>
Other question: what do people using Ferrocene which is based on Rust 1.68, newer crates will probably not compile on that rather quickly?
<JamesMunns[m]>
sourcebox[m]: I imagine if you're in safety critical you're managing/vendoring/reviewing your deps more in depth than average
<JamesMunns[m]>
JamesMunns[m]: and if you require old rustc support as a safety critical company, it's probably reasonable for YOU to do it, or to pay the maintainer to do it.
<ryan-summers[m]>
Yeah safety critical generally requires an analysis of any dependency for suitability for the application in question
<sourcebox[m]>
JamesMunns[m]: For sure.
<ryan-summers[m]>
* Yeah safety critical generally requires a formal risk assessment / analysis of any dependency for suitability for the application in question
<sourcebox[m]>
But I honestly don't know what I should answer a hardcore C developer showing a simple Rust hello-world pulling 100+ dependencies. And yes, these people are scared about that.
<sourcebox[m]>
The answer could be "that's how it is today", but that's a bit simple.
<vollbrecht[m]>
sourcebox[m]: i think the first think is do educate for example the difference between [build-deps] / [dev-deps] / [deps]. In many embedded rust projects the [deps] are quite small.
<sourcebox[m]>
vollbrecht[m]: They are not so small if you regard the whole tree.
<vollbrecht[m]>
> <@sourcebox:matrix.org> But I honestly don't know what I should answer a hardcore C developer showing a simple Rust hello-world pulling 100+ dependencies. And yes, these people are scared about that.
<vollbrecht[m]>
* i think the first think to do is to educate for example the difference between \[build-deps\] / \[dev-deps\] / \[deps\]. In many embedded rust projects the \[deps\] are quite small.
<JamesMunns[m]>
sourcebox[m]: IMO then we need better educational tools. If you don't want that, you can write it all from scratch if you'd like! But that's the trade off
<JamesMunns[m]>
using ANY deps isn't even mandatory!
<JamesMunns[m]>
nothing about cortex-m or cortex-m-rt or embassy are magical - you can do without them entirely
<JamesMunns[m]>
it's a silly idea! And if they are using ST or NRF's toolchains with tons of vendored libs, then it's a little hypocritical of them! Unless they just want someone to do the curation work for them, but that's not "no dependencies".
<JamesMunns[m]>
But that's the tradeoff! Are you inventing the world from scratch, or not? If not, it's up to you as the integrator to choose which deps you use
<JamesMunns[m]>
and most deps are mit+apache2! If you want to vendor them and hack out bits or recursive deps, you can!
<sourcebox[m]>
JamesMunns[m]: Yes, but a full package from ST is generally more trusted.
<JamesMunns[m]>
you just can't ask someone to do it for you for free because YOU prefer it!
<JamesMunns[m]>
(this is the metaphorical "you", not picking on you specifically sourcebox)
<JamesMunns[m]>
sourcebox[m]: Sure, but you're paying ST! Even if only indirectly
<sourcebox[m]>
Yeah, to me personally these things are quite clear, but I'm sometimes just too tired to explain these details to someone who is not really willing to like it.
<JamesMunns[m]>
sourcebox[m]: my advice is: don't!
<JamesMunns[m]>
if you feel inspired, write these things up
<JamesMunns[m]>
if you don't, help the people that want to learn!
<JamesMunns[m]>
it's WAY more rewarding than trying to convince stubborn people!
<sourcebox[m]>
I'm talking about those people that I know personally for many years.
<JamesMunns[m]>
Then that's up to you to decide if it's worth it! If they don't see the value, that doesn't make your enjoyment or productivity with it less shiny.
<JamesMunns[m]>
I do think we should always improve our communication, but the best we can do is bringing the horse to water.
<JamesMunns[m]>
Anyway, not saying we don't need to help address concerns, just don't let people "what about" you to death. The "what about" never actually end for many folks, because at the end of the day they just aren't interested (yet), and that's okay.
<sourcebox[m]>
People can always ask me questions, but sometimes my impression is they just pretend some interest or try to find the slightest issue to dislike it.
<JamesMunns[m]>
sourcebox[m]: I think that's a reasonably accurate impression in some cases, I've met people like that too.
<JamesMunns[m]>
like I said, after many years of talking to many people about Rust, I've found it much more productive to spend my time assisting people who want to try/use rust, than to spend time convincing people that don't.
<JamesMunns[m]>
Or even spending time correcting people who are willfully wrong about Rust.
<sourcebox[m]>
I'm working in a relatively small business where a lot of devs know each other. New and younger devs are not that easy to find because the payment is quite low compared to what you get in other domains.
<sourcebox[m]>
These companies are small and often only 1 or 2 people.
<JamesMunns[m]>
I'm not quite sure what you mean! It's unfortunate that industry has hiring issues. Embedded as an industry IMO is very fractured, and some teams and companies are living in relatively poor conditions.
<JamesMunns[m]>
But also the industry can often be hugely insular and those folks reject ANY new ideas
<JamesMunns[m]>
but yeah, you can't help people that don't want help
<JamesMunns[m]>
if they can't hire anyone, or can't ship because too many defects, that's unfortunate! But if they can and they can, then maybe they are okay with the tools they have!
<Lumpio->
Looking for a support group for people who are forced to use STM32 HAL at work
<JamesMunns[m]>
Like, I think Rust is a better tool, but that's not to say you can't do good stuff with (IMO) less good tools.
<Lumpio->
Maybe one day I could be one of those "folks using rust" for work
<JamesMunns[m]>
Lumpio-: I believe in you!
<Lumpio->
Unless I get utterly bored of embedded before that, I'm not that super enthusiastic about using it for *everything* like web apps and whatnot just yet
<dirbaio[m]>
unpopular opinion: rust is not great for web :P
<vollbrecht[m]>
Lumpio-: should call it Anonyme STM32 H4lcoholics
<Lumpio->
oooh
AtleoS has quit [Ping timeout: 256 seconds]
<Lumpio->
dirbaio[m]: I can see it being useful for something where you actually _need_ the performance, idk some kind of CDN stuff or edge processing for requests
<sourcebox[m]>
My hope is that younger devs are more open to Rust and even if they are not hired for that specifically, they can introduce it over time. But with the payment usually offered in my domain, they will not take the jobs at all.
<Lumpio->
But for your average CRUD app? ehhh
AtleoS has joined #rust-embedded
<dirbaio[m]>
Lumpio-: yeah, my thoughts exactly
<barnabyw[m]>
sourcebox[m]: what domain is that?
<sourcebox[m]>
Music instruments and other audio stuff.
<sourcebox[m]>
The market is just too small.
<sourcebox[m]>
And the competition is large.
<sourcebox[m]>
Also, the distributors and shops take a good share, so there's often not much left for the manufacturer.
<barnabyw[m]>
ah yeah, tends to be people who are willing to work on stuff they love for less than they could get working on boring stuff elsewhere. I know that very well 🤪
SimonJohansson[m has joined #rust-embedded
<SimonJohansson[m>
How would one read the stack pointer value in inline assembly? I haven't managed to find that many resources online in how to retrieve a registers value, or I am just very bad at googling
<JamesMunns[m]>
SimonJohansson[m: which CPU/architecture
<SimonJohansson[m>
Right, seems more useful to use the library function. Thanks!
juliand[m] has joined #rust-embedded
<juliand[m]>
<dirbaio[m]> "unpopular opinion: rust is not..." <- Haters gonna hate ;D
<JamesMunns[m]>
juliand[m]: "other people don't have to like the things you like" :)
<juliand[m]>
Haha :P I'm more inclined to say "the web is so broken, not even Rust can fix it"
<juliand[m]>
And regarding the discussion above: my impression from talking to a couple of people at embedded world today is that many companies are actually very interested in Rust and are at least planning on supporting it in the near future with their product or service. There has been not a single person saying it's stupid or C is better or whatever you might imagine hearing (not sure whether I could convince the ST rep though😂).
<juliand[m]>
And in terms of chip manufacturers: at least Infineon is also working on it (in addition to Espressif, of course) and want to release more stuff this year.
<juliand[m]>
So it feels like people wanna use it but want to wait a bit more to see how it works out for others.
spinfast[m] has joined #rust-embedded
<spinfast[m]>
I think it'd take a lot to convince st
<spinfast[m]>
maybe less to convince nxp though
<spinfast[m]>
* maybe a little less to
<spinfast[m]>
one major automotive customer demanding it... and you'd think it'd happen
<spinfast[m]>
like look at the s32z line and tell me that wouldn't benefit from Not-C given the magnitude of the part complexity involved
<JamesMunns[m]>
+1 to "if your company is even INTERESTED in Rust, ask your sales rep about it monthly"
<spinfast[m]>
s32z2... "8x Arm Cortex-R52 +
<spinfast[m]>
Lockstep Arm Cortex-M33"
<spinfast[m]>
* s32z2... "8x Arm Cortex-R52 + Lockstep Arm Cortex-M33"
<spinfast[m]>
to be fair I think the idea is to replace discrete controllers with that beast... but good luck programming and testing it
beanflame[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
<spinfast[m]> "to be fair I think the idea is..." <- It’ll run an RTOS. Or probably several instances of one.
<thejpster[m]>
We put R52 support in Ferrocene and I do need something to actually try it on…
<JamesMunns[m]>
Has anyone made a heterogeneous hypervisor yet?
<JamesMunns[m]>
something that can babysit different A/R/M cores?
<thejpster[m]>
But why? They can’t run the same code.
<JamesMunns[m]>
more "what babysits all the other cores"
<JamesMunns[m]>
hypervisor might not be the right word, but more what does management of programs + threads on diverse cores
<dirbaio[m]>
easy, just compile an 8051 emulator for all cores and now you only have to manage N identical 8051 cores :D
<thejpster[m]>
Wouldn’t that imply that Core A could inspect and alter the run-time state of Core B, where they don’t have the same architecture and so don’t have the same memory bus. Sounds cheaper to put a slice of it on each core.
<JamesMunns[m]>
thejpster[m]: you're certainly more familiar with those cores than I am! I haven't messed around with heterogenous cores since the imx7
<JamesMunns[m]>
(A+M)
<thejpster[m]>
Imagine if you had a CPU with two cores with different architectures on literally the same bus. That would be weird.
<JamesMunns[m]>
thejpster[m]: aren't there cores like that? IIRC imx7 (A + M) have shared peripherals and memory spaces
<JamesMunns[m]>
not ALL peripherals and memory, but a subset
<thejpster[m]>
The AM57 I used I think had 12 MMUs.
<thejpster[m]>
So, yes, but only for weak values of “shared”
<JamesMunns[m]>
thejpster[m]: lol
<thejpster[m]>
These things are also full of Tightly Coupled Memory.
<JamesMunns[m]>
thejpster[m]: Good Luck, I'm behind 12 MMUs
<thejpster[m]>
Can’t have the motor controller stall a cycle because the GPU wanted another piece of texture.
<thejpster[m]>
Related, I think the bus contention counters in the 2040 are very cool and widely underused.
<JamesMunns[m]>
pretty much true for all perf counters
<adamgreig[m]>
hi @room, meeting time again! agenda is https://hackmd.io/cguuCz6QRRetGvv4DcYulQ, please add anything you have to announce or discuss and we'll start in a few mins
<adamgreig[m]>
i swear 80% of the element "new version is available update now?" popups happen at a few minutes before 7pm on tuesdays. always tempting fate
<adamgreig[m]>
ok, let's go! one quick announcement from me first, svdtools 0.3.14 was released
<vollbrecht[m]>
adamgreig[m]: just use element-nightly and get the joy everyday ;D
<adamgreig[m]>
I wanted to gauge feelings for tweaking the weekly meetings, I feel like in the last few weeks (perhaps since e-h 1.0 even) we've had slightly less useful discussions in the week and I wonder if it might be productive to try out a more active hour, maybe every other week or once a month or something
<adamgreig[m]>
from my point of view it's been easy enough to make time to run the meetings because it's always there, but then I log off and have dinner and it's much harder to make time to close up some bugs or file some PRs or whatever
<adamgreig[m]>
I'm not sure what it looks like exactly, but maybe a sort of quick roundup of open things that can probably be tackled fairly quickly (not necessarily in an hour, though), like updating some documentation, dealing with a PR, whatever, and perhaps whoever's around and interested would take on one thing and we would work through it in the meeting
<adamgreig[m]>
dunno, just a vague thought from last week, so interested in hearing people's thoughts
<adamgreig[m]>
purely discussion-oriented meetings seemed an OK fit for hashing out trait design for e-h for instance, but when we have fewer specific things to work out like that there's not as much to say
<adamgreig[m]>
of course, that's fine too, we can also just have some shorter/quieter meetings!
<JamesMunns[m]>
I appreciate you running these! It's honestly great to have a dedicated time in the week
<JamesMunns[m]>
I do sorta agree that these can end up with "a lot of people talking and sharing opinions and fewer people with time to do the things"
<adamgreig[m]>
yea, I love the dedicated time in the week and want to keep that
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
adamgreig[m]: I'd be interested to follow along with a discussion about handling PRs, that would help me out a lot.
<dirbaio[m]>
yea... lately we've had lots of "conclusion: yes, we have to do X"
<JamesMunns[m]>
I'm open to trying new formats! I could give some thoughts, but if you're willing to lead them I'm down to try whatever :)
<dirbaio[m]>
but it still doesn't get done
<adamgreig[m]>
just wondering if we could make it so some of those time slots are nominally for doing things at the same time
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
<dirbaio[m]> "unpopular opinion: rust is not..." <- As the guy running the fullstack Rust class right now, have to respectfully disagree 😀
<adamgreig[m]>
dirbaio[m]: right! I feel bad about a lot of these because many are things I could do but then don't, but I can't do all of them and that makes it hard to do any of them...
<JamesMunns[m]>
I dunno how we can flip the script: so that people are empowered to make the changes they need, and keep more people informed and aware, but less bikeshedding if only one or three people are making the changes
<JamesMunns[m]>
like, less "central design committee" and more "collective reviewer brain", if that makes sense?
<adamgreig[m]>
I like to think that at least the actual team members are empowered to make changes but perhaps aren't for other reasons
<adamgreig[m]>
like, updating some trait documentation to clarify a point might not be best done by someone outside the team
<JamesMunns[m]>
tbh I think ad hoc impl sessions might be fun, yeah
<JamesMunns[m]>
have people around to discuss, make PRs, review them, get them closed quickly?
<JamesMunns[m]>
so, I'm totally for your suggestion adamgreig :D
<JamesMunns[m]>
"everyone shows up on Tuesday night and we make things better" is a pretty cool meeting vibe :D
<adamgreig[m]>
that's my vague ambition, though it might turn out to be hard to actually do :P
<relia1[m]>
I think it would be great for newer folk (like me) to the embedded/rust community to get a feel on things too.
AtleoS has quit [Ping timeout: 256 seconds]
<adamgreig[m]>
it's a long time ago but I remember when we were writing the embedded book we had a similar sort of vibe to that
<bartmassey[m]>
Best way to find out how it works is to try, I think.
<jannic[m]>
Quite often when the weekly meeting is quiet or about topics where I can't contribute much, I use the time to sort through gitlab tickets / pull requests during that time. So for me it's useful to have that regular meeting even if not much happens in the meeting room.
<JamesMunns[m]>
I think the Fun part is choosing what to direct the attention towards, e.g. what do we work about? but IMO yeah - let's try it
<JamesMunns[m]>
jannic[m]: +1 for "keeping the space going" wrt the weekly meeting times
<adamgreig[m]>
yea, I definitely intend to keep the weekly meeting going
<adamgreig[m]>
the one day a week I usually get home by 7 💀
<adamgreig[m]>
does anyone have suggestions for things we might look at working on next week? I have a list or two somewhere I'll try and dig up, we could put them on the minutes
<bartmassey[m]>
I have a first thing to nominate.
<vollbrecht[m]>
Currently the Agenda for "current Meeting" is always directly created before it right?
<vollbrecht[m]>
Maybe have a running issue for each new meeting where everybody can put stuff in, in advanced.
<vollbrecht[m]>
Open it one week before next meeting would be helpful. We do something similar in our beweekly meetings in esp-rs
<bartmassey[m]>
I'd like to get everybody to look at @qwandor's recent awesome changes to nrf-hal
<bartmassey[m]>
They've got some review, but I feel like I haven't done enough there.
<adamgreig[m]>
the rtic meetings have just one document I think, but I'd worry a little about tracking changes and noticing any vandalism and such
<JamesMunns[m]>
+1 to "long standing doc", or at least have a place to always find it (like `agenda.rust-embedded.org` or something)
<bartmassey[m]>
Could use Github Discussions or wiki, maybe?
<vollbrecht[m]>
in esp-rs we use it more so everybody just can writeup his things he want to talk about or accomplished in that week, with no barrier to it.
<vollbrecht[m]>
than you don't need to do the work of curating beforehand, just moderating what actual the meeting should talk about
<dirbaio[m]>
maybe we can do one issue per topic, then add a "nominated" label
<dirbaio[m]>
nominated for discussion in the meeting
<JamesMunns[m]>
(gotta run, have a great week y'all!)
<adamgreig[m]>
dirbaio[m]: oh, yep, we used to do this, in fact every agenda since forever has a link to "nominated issues" at the top 🙈
<adamgreig[m]>
for a lot of smaller things someone wants to announce or discuss there's not necessarily an issue, though
<adamgreig[m]>
still, for a lot of things there is
<bartmassey[m]>
Can always file a new issue for things.
<adamgreig[m]>
what if we run out of issue numbers 😱
<adamgreig[m]>
it wouldn't be hard to keep an open issue in the wg repo for "upcoming meeting" where people can leave a comment, and close it with the minutes PR after each meeting
<adamgreig[m]>
but when we did that before they would often go unused
<adamgreig[m]>
oh, nice!
<adamgreig[m]>
thanks for the link
<adamgreig[m]>
that does seem neat
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
I like the idea of doing some work during the meeting, I'm in!
<juliand[m]>
<vollbrecht[m]> "in esp-rs we use it more so..." <- I feel like having open issues there in advance (or PRs to review etc) might also help getting more people to try working on them. Like, if I can get more familiar with the topic before the meeting, I'd be more comfortable volunteering to work on it (I guess?)
<adamgreig[m]>
we could even paste the minutes into the discussion issue and skip having to make a PR, heh
<adamgreig[m]>
perhaps it's nice to preserve them in the repo itself, not just in the github data, though
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Ooh, the one serious discussion and I show up late...
<therealprof[m]>
We tried doing the nominating tags a while ago but I'm not really sure we have so many new issues to talk about that nominating would make a bit difference.
<adamgreig[m]>
I think we get enough new issues in a week, just usually I try and dig them out of my inbox and put them on the agenda at the start, depending on what's possibly useful to talk about
<adamgreig[m]>
but there's usually at least a few such things
<juliand[m]>
For the ones that are not nominated, they could be discussed in the GitHub discussion. Which might be a cool thing for people who can't usually make it to the Tuesday meetings
<adamgreig[m]>
yea
<adamgreig[m]>
cool, ok, thanks for all the useful thoughts!
<adamgreig[m]>
I'll try out a github discussions for each meeting, we can resume nominating some issues and see how that goes, and next week let's have a go at "doing things rather than just talking about them" and see if it works out too
<therealprof[m]>
I hadn't realised there were so many. I've given up tracking GH notifications, for some reason it's impossible to mute the irrelevant ones so I'm getting tons of spam for e.g. Rust project repos.
<therealprof[m]>
Sounds good. An hour of focused work usually gets more done than planning for an hour and hope that people follow up with the actual work.
<ayakasakura[m]>
I've been turning the real-time chaos captured on my phone and computer into songs to spread the word. I'm keeping this up, turning each real moment into music. This is the face of national censorship in Japan, but I'm not backing down. Let's make this go viral!
ayakasakura[m] has left #rust-embedded [#rust-embedded]
<M9names[m]>
So... regardless of what we do with the weekly meeting I think it might be nice to have some regular "what are you working on / planning to work on" session.
<M9names[m]>
I know some in the community are pretty good at talking about their projects, but it's definitely not something I do often without prompting.
<M9names[m]>
The existing setup works well for project announcements but I think something a bit more conversational would be nice.
<adamgreig[m]>
Sounds nice! Like a few minutes at the start or end where we ask people to just chat about anything they're working on?
<M9names[m]>
It doesn't have to be at the same time or interval as the weekly meetings, and it's probably better for timezone/schedule diversity if it's not a one hour window of opportunity to talk shop
AtleoS has quit [Remote host closed the connection]
AtleoS has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<vollbrecht[m]>
<adamgreig[m]> "cool, i made the first discussio..." <- small suggestion: you could maybe change the last sentence from "discussion" to something like the "live discussion"(as its already a github discussion 😄 )
<vollbrecht[m]>
Also maybe emphasize on the point that people are encouraged to start adding there input immediately. E.g to comment on the topics you mention + link/showoff there stuff they worked on down below
<vollbrecht[m]>
s/discussion/meeting/
<vollbrecht[m]>
* small suggestion: you could maybe change the last sentence from "meeting" to something like the "meeting with live discussion"(as its already a github discussion 😄 )
<vollbrecht[m]>
Also maybe emphasize on the point that people are encouraged to start adding there input immediately. E.g to comment on the topics you mention + link/showoff there stuff they worked on down below
<vollbrecht[m]>
s/discussion/meeting/, s/discussion/part of the meeting/, s///