<i509vcb[m]>
The spresense port would be a new part, so no chat room currently exists
<sajattack[m]>
ah, missed that, wasn't familiar with it
<i509vcb[m]>
<ShuntaroOhno[m]> "I want to develop a board called..." <- Hi, I'm not sure if you are the person who mentioned the looking into a port for spresense parts on the embassy issue tracker.
<i509vcb[m]>
If you have general questions for "where do I start" I imagine people here can help
<i509vcb[m]>
The spresense parts are certainly interesting given there are 6 Cortex M4 cores on the chip
<i509vcb[m]>
s/M4/M4F/
<ShuntaroOhno[m]>
<i509vcb[m]> "Hi, I'm not sure if you are..." <- Thanks, i509vcb .
<ShuntaroOhno[m]>
I don't really understand the "the person who mentioned the looking into a port for spresense parts on the embassy issue tracker" (especially what `embassy issue tracker` is), so it's probably not me.
<i509vcb[m]>
> I don't really understand the "the person who mentioned the looking into a port for spresense parts on the embassy issue tracker" (especially what `embassy issue tracker` is), so it's probably not me.
<i509vcb[m]>
Huh okay so I guess someone independently also started looking at it
<ShuntaroOhno[m]>
And what I currently want to know is exactly where do I start. This is my first time running a completely new board, so I don't know where to start.
<ShuntaroOhno[m]>
I understand that CXD5602 is the name of the processor. Spresense seems to use an OS called NuttX, but will this be ignored when developing with Rust?
<i509vcb[m]>
<ShuntaroOhno[m]> "I understand that CXD5602 is the..." <- Yes, you would be directly programming the hardware. Although this means that you'd need drivers for the chips on things like the lte dev module for the parts
<adamgreig[m]>
currently James Munns is our representative on the council and his term (slightly shortened as he started part-way through the normal 1 year) is up soon
<adamgreig[m]>
if anyone is interested in being the team representative, please speak up! otherwise, I understand james is also happy to continue for another term
<JamesMunns[m]>
Yep! I'm happy to continue, but if anyone feels strongly that I shouldn't, or strongly feels like they are (potentially) interested, I'm happy to chat here or privately!
<adamgreig[m]>
thanks! second announcement is about the Embedded Recipes conference in Nice in May, they emailed asking if anyone would be interested in talking about Rust: https://embedded-recipes.org/2025/
<adamgreig[m]>
and third announcement/reminder is that Rust Week is still coming up in Utrecht and we'll have having an embedded unconf at the end, please let me know if you'd like to be on the guest list! we still have space for people and you don't have to be a wg member
<adamgreig[m]>
and I think finally romancardenas do you want to announce the riscv releases?
<adamgreig[m]>
ok, on to the other agenda items, first off i509vcb has opened a PR for the async digital traits for embedded-hal-async that we discussed last week: https://github.com/rust-embedded/embedded-hal/pull/649
<adamgreig[m]>
not sure if there's anything to discuss about it yet, i509vcb?
<i509vcb[m]>
Nothing in particular that isn't mentioned in the pull request already.
<i509vcb[m]>
Pretty much a copy of the blocking traits, but async
<i509vcb[m]>
The main semantic difference is that when Ready is returned, the operation is guaranteed to have happened
<adamgreig[m]>
cool, thanks!
<i509vcb[m]>
If someone does have an issue with those semantics then I can discuss a bit
<adamgreig[m]>
so especially if you've used armv8 support that might be worth a quick look
<JamesMunns[m]>
ooooh, that's a very cool addition
<JamesMunns[m]>
I should look at using that on the 2350 👀
<adamgreig[m]>
yea! nice that you can quite easily do it at startup from the linker script
<adamgreig[m]>
if you're up for checking it over that would be great, I don't think I have any armv8 hardware to hand so i'd stuck at just checking the rm...
<adamgreig[m]>
enable feature, smash stack, see if you get a fault :P
<JamesMunns[m]>
I haven't actually used a 2350 yet, but hope to soon :D
<JamesMunns[m]>
@cbjamo might be able to tho
<adamgreig[m]>
James Munns, wanna talk about your rust society thing?
<JamesMunns[m]>
Yep!
<JamesMunns[m]>
The wheels keep turning on "figure out what to do with the Launching Pad, Working Groups, etc."
<JamesMunns[m]>
In the last council meeting, we discussed potentially turning the launching pad into a more long-term home for "cross cutting teams" that don't fit into an existing top level team
<JamesMunns[m]>
however, that somewhat doesn't really cover Domain working groups. @thejpster shared a blog post he wrote a while back about formalizing community oriented groups into a "Rust Society" of sorts, with chapters for different groups.
<JamesMunns[m]>
To date, there haven't been any firm answers to "what should the existing working groups do, what are they, and how do we handle it if a lot more groups want to make one too".
<JamesMunns[m]>
So this proposal is for setting up a third group, next to the Foundation and Project, to cover groups of users of the language.
<JamesMunns[m]>
This is still very early, basically one meeting and this report is all the momentum behind it so far :)
<JamesMunns[m]>
but since it affect the embedded wg, and this is the group I'm most familiar with, I thought I would float the idea here, for any questions or feedback.
<JamesMunns[m]>
So: if folks have thoughts for or against, please do lemme know, now, on the comments of the gist, or on Zulip!
<bartmassey[m]>
Do we get tie pins and a secret handshake? I really want tie pins and a secret handshake.
<bartmassey[m]>
More seriously, I'd note that the ACM SIG structure is kind of like this.
<JamesMunns[m]>
I imagine each group is free to set up their own swag and procedures, given they fall within the code of conduct :)
<JamesMunns[m]>
and yeah, not anything hugely novel here, but the hope is to formalize this, because there really hasn't been much in the past.
Socke has quit [Ping timeout: 252 seconds]
kevlan[m] has joined #rust-embedded
<kevlan[m]>
This setup feels similar to an idea that was tried at a former employer where they had what we called "guilds" for regular meetups of folks across the company that were interested in the same topics such as the "devops guild" or the "cloud guild" where members could share ideas and advocate for company wide standardization and support for things pertaining to their guild topic.
<JamesMunns[m]>
yep, the idea is to serve as the home for both "domain groups" like wg-embedded would be, but also potentially local/regional meetup groups, and really any group of folks that would like a structured way of saying "hey, we're here doing this stuff"
<bartmassey[m]>
I feel like the sticking point will be what this third group gets in terms of status and support. For example, are representatives from these groups invited to future All-Hands? Does the Foundation commit to providing some level of financial support somehow? etc.
<JamesMunns[m]>
I do mention those in my report, and I do think it's an important thing to establish!
<JamesMunns[m]>
so the first gut check is "does this seem palatable as an evolution of wg-embedded, and are there any details I should stick to when proposing this to the council and foundation", really.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Gotta run. 👋
<adamgreig[m]>
as choices go I think it has a lot going for it, but there's a wide range of possible outcomes
<bartmassey[m]>
I love this document and the work you've put into it and the proposal. Thank you! I think it makes sense to try something along these lines.
<adamgreig[m]>
I feel like it needs to exist because someone wants it to exist, not because a few working groups need a home
<adamgreig[m]>
* exist, not _just_ because a
<adamgreig[m]>
but if it did exist, it would be a fantastic home
<bartmassey[m]>
I also have to leave sadly…
<JamesMunns[m]>
yep, there will absolutely be a need for hands to help set it up, and there's definitely some minimum "activation energy" required for it to actually get on it's feet and become self sustaining
<adamgreig[m]>
right
<adamgreig[m]>
but if that can be found then i think the outline in your/jpster's proposal is nice
<adamgreig[m]>
I don't know that we're in a position to be imposing specific requirements around how it looks :P
<JamesMunns[m]>
Happy to use whatever position I have to at least ask :D
<JamesMunns[m]>
I think there is a lot of interest in supporting groups like the WG in SOME way, it's just never been clear HOW
<JamesMunns[m]>
so it's led to a lot of dragged feet
<JamesMunns[m]>
im hoping that if there's a coherent destination, there will be good will and an interest in seeing it succeed
<JamesMunns[m]>
But yeah, there's been a general spreading consensus that the project should be "for people shipping parts of the language and toolchain", which is pretty clearly a distinct set from what the working groups do
Socke has joined #rust-embedded
<JamesMunns[m]>
but like I said, there's also be an ongoing interest in getting user group feedback, feeding into project goals, having knowledgable people to ask before making design decisions that would affect them, etc.
<JamesMunns[m]>
So: asks from me right now are just any feedback for or against, probably just "big picture" stuff for now, haven't gotten as far as impl details.
<JamesMunns[m]>
and honestly any "yep im down that sounds great" responses are always useful, so I know I'm not proposing something folks wouldn't actually be happy about, and spending lots of time pushing for things :D
<JamesMunns[m]>
I'll keep folks up to date on how the discussion goes, it's still very early, for sure.
<JamesMunns[m]>
(that's all I have unless anyone has any questions!)
<jannic[m]>
<adamgreig[m]> "enable feature, smash stack, see..." <- Works as expected on rp2350.
<jannic[m]>
<adamgreig[m]> "so if you trigger a stack..." <- Took a bit longer as I can't access 0xe000ed28 from gdb ("Cannot access memory at address 0xe000ed28"). But after I added some inline assembly to read it into a register, I could verify that bit 20 is actually set. (And no other bit.) And the UsageFault handler is getting called.
<thejpster[m]>
Is there a better way to do this? I hope there's a better way to do this - this was no fun at all.
<thejpster[m]>
> Files changed: 278
<thejpster[m]>
😢
<thejpster[m]>
Also, fun fact, it takes Foxit PDF three minutes to do a full search of the 14,500 page Arm Architecture Reference Manual Version 8.
<thejpster[m]>
I couldn't use the HTML version because I couldn't find the search button - only one that searched the whole Arm website
<thejpster[m]>
the 1996 Arm ARM was 322 pages :/
<adamgreig[m]>
<jannic[m]> "Took a bit longer as I can't..." <- "set mem inaccessible-by-default off" to let you access it from gdb
<adamgreig[m]>
But, sweet! Thanks for checking!
<jannic[m]>
Works as well. Good to know. I thought it was some hardware limitation, that this memory region wasn't accessible from the debug interface.
<adamgreig[m]>
Just gdb thinking it knows better :p
pcs38 has quit [Quit: leaving]
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]>
Hello. I have started a project of writing a bare metal Rust App for the Zynq7000 based board. I saw https://git.m-labs.hk/M-Labs/zynq-rs and I am now wondering whether there are any Cortex-A(9) crates. I only saw support for Aarch64.
<RobinMueller[m]>
* any Cortex-A(9) support crates. I
<RobinMueller[m]>
* any Cortex-A(9) support crates, * crates out there. I
<RobinMueller[m]>
* Hello. I have started a project of writing a bare metal Rust App for a Xilinx Zynq7000 based board. I saw https://git.m-labs.hk/M-Labs/zynq-rs and I am now wondering whether there are any Cortex-A(9) support crates out there. I only saw support for Aarch64.