<ryan-summers[m]>
ESP32 is an entire product line of microcontrollers. You'll need to figure out which exact esp32 is being used. Once you have that, you can indeed use either the esp32 PAC or the associated HAL. Check out the Espressif Github org for more info: https://github.com/esp-rs
<JamesMunns[m]>
<ryan-summers[m]> "ESP32 is an entire product..." <- To be fair, the esp32 is ALSO a specific device in the esp32 product line, and I think this board might be that esp32 chip
<ryan-summers[m]>
Hah, never knew that actually :)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
When in doubt and you have espflash installed you can always run espflash board-info. It will tell you the chip and its revision plus its unique mac address
a2800276 has quit [Quit: leaving]
danielb[m] has joined #rust-embedded
<danielb[m]>
<mobergmann[m]> "I looked veeeeery closely at the..." <- I would recommend looking at esp-hal of esp-idf-svc, the PAC crates are VERY low level
a2800276 has joined #rust-embedded
PedroFerreira[m] has joined #rust-embedded
<PedroFerreira[m]>
I have a weird problem trying to call code located in an arbitrary memory address (RP2040). I am getting the address, creating a `*const fn()`, converting it to a ref and then just calling it normally, i.e. `func(<arguments>)`, where `func` is a `&fn(...)`. Somehow, when I look at the produced assembly code, I see:... (full message at
<PedroFerreira[m]>
* I have a weird problem trying to call code located in an arbitrary memory address (RP2040). I am getting the address, creating a `*const fn()`, converting it to a ref and then just calling it normally, i.e. `func(<arguments>)`, where `func` is a `&fn(...)`. Somehow, when I look at the produced assembly... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GvSdcsTdmqTXscmRLaglNeco>)
<PedroFerreira[m]>
* I have a weird problem trying to call code located in an arbitrary memory address (RP2040). I am getting the address, creating a `*const fn()`, converting it to a ref and then just calling it normally, i.e. `func(<arguments>)`, where `func` is a `&fn(...)`. Somehow, when I look at the produced assembly... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nCWhJBvRapvnDeeBrIfDecxK>)
<PedroFerreira[m]>
* I have a weird problem trying to (unsafely) call code located in an arbitrary memory address (RP2040). I am getting the address, creating a `*const fn()`, converting it to a ref and then just calling it normally, i.e. `func(<arguments>)`, where `func` is a `&fn(...)`. Somehow, when I look at the... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hAdLlLdrXpPTXetqithnXtgj>)
<JamesMunns[m]>
`fn` is already a function pointer, `&fn` is a pointer to a function pointer
<JamesMunns[m]>
don't forget in cortex-m the lowest bit of the address needs to be set for functions you call, that marks it as a thumb function, it'll hard fault if you call a function with the lowest bit unset
exark_ has joined #rust-embedded
exark has quit [Read error: Connection reset by peer]
ni has quit [Ping timeout: 258 seconds]
ni has joined #rust-embedded
<PedroFerreira[m]>
wow, it magically works now, thanks James Munns !
<JamesMunns[m]>
The might be a less gross way than transmute to cast, but that should work afaik.
<PedroFerreira[m]>
yeah, I already hit my head against the wall trying to figure out why readelf and objdump were giving me addresses off by 1
<JamesSizeland[m]>
When I try to erase and flash the softdevice hex following the https://github.com/embassy-rs/nrf-softdevice readme, I get an ERROR: probe_rs::architecture::arm::core::armv7m: The core is in a locked up status as a result of an unrecoverable exception.
<JamesSizeland[m]>
The chip ends up in a weird state and I have to copy a demo hex across to fix it.
<JamesMunns[m]>
Might want to be reporting in the #probe-rs:matrix.org room, or in their issue tracker? Especially if it works with an old version and not the new one
<danielb[m]>
a bisect would help a lot, this isn't the first "locked up" issue I've seen
<JamesSizeland[m]>
<JamesMunns[m]> "Might want to be reporting in..." <- Aha will do, didn't know about this room
<dirbaio[m]>
embassy-stm32 v0.1 was missing async i2c for F1, L1, F2, F4.
<dirbaio[m]>
if you're using one of these, switch to embassy-stm32 from latest git and it'll work
<LucasChiesa[m]>
dirbaio: it's stem32l031
<dirbaio[m]>
hmm i'm not sure then
<dirbaio[m]>
might still be worth trying to switch to git, there's been lots of other fixes since then
<LucasChiesa[m]>
I used directly the i2c without going through the driver, and that works. I am using some embassy newer than the release, but not the latest git (because I now needed some newer rust feature)
<LucasChiesa[m]>
or at least it seemed to need Rust 1.81 which is beta now
<dirbaio[m]>
latest git works on latest rust stable, 1.80
<dirbaio[m]>
* latest embassy git works
<dirbaio[m]>
(unless you enable nightly features, then you need latest nightly)
<LucasChiesa[m]>
but you think that the problem might be going from the embassy_hals to embedded_hal?
<LucasChiesa[m]>
dirbaio[m]: ah, great, I'll try that then
<dirbaio[m]>
it should work, embassy-stm32 implements all the embedded-hal and embedded-hal-async traits
<dirbaio[m]>
maybe it's not picking up the impl because `embassy_stm32::i2c::I2c<'_, embassy_stm32::peripherals::I2C1, DMA1_CH1, DMA1_CH2>` doesn't impl the trait for some reason
<dirbaio[m]>
maybe wrong dma channels
<LucasChiesa[m]>
ahh... ok, I can try that!
<LucasChiesa[m]>
Indeed! The DMA Channels where the problem!
<dirbaio[m]>
all these generics are gone in latest git, that's another reason to update. it's now just `I2c<'_, Async>`
<LucasChiesa[m]>
nice. I'll finish this code, commit, and then update :)
<LucasChiesa[m]>
Thanks dirbaio !
<LucasChiesa[m]>
btw, are you planning a new embassy release?
<dirbaio[m]>
soon
<LucasChiesa[m]>
great! and thanks again!
<LucasChiesa[m]>
<dirbaio[m]> "all these generics are gone in..." <- updated to latest git. Much nicer with one the Mode to specify. Thanks again!
<JamesMunns[m]>
but if there are no objections, I'm happy to turn this list into the proper form, and get it submitted to the survey team as soon as this week (or later if we need more time to work)
<adamgreig[m]>
definitely all for doing the survey, it might be worth some planning beforehand on how/where to distribute the link for maximum reach too
<adamgreig[m]>
having the tockos team involved sounds great too
<adamgreig[m]>
or are you thinking there's a less direct way to get similar information?
<JamesMunns[m]>
I think part of my goals for this survey is for sharing around to get the attention of both employers, MCU vendors, etc.
<adamgreig[m]>
it would be a shame to run the survey and it not get to people doing big production stuff and so underrepresent usage, so making sure it runs for a decent length of time and we manage to get the link spread far and wide seems important
<BogdanOlar[m]>
don;t get me wrong: I would like to know the answer to that question, it's just that I'm worriedd we might lose some answers because of it
Diaeresis[m] has joined #rust-embedded
<Diaeresis[m]>
Perhaps an estimate of order of magnitude (10s, 100s, etc.) would be sufficient
<JamesMunns[m]>
I think orders of magnitude and a "I'm not sure/I can't say" answer definitely makes sense
<therealprof[m]>
Diaeresis[m]: Yeah, I think that's the information James is looking for, I was also thinking about rephrasing it.
<JamesMunns[m]>
Definitely open to phrasing suggestions, this was a very rough first draft of all questions :)
rom4ik1 has quit [Quit: bye]
rom4ik1 has joined #rust-embedded
<therealprof[m]>
If I haven't miscounted, we're currently at 11 questions.
<adamgreig[m]>
is it worth having any Qs specifically about the wg? did you know it existed, is what we do helpful / could we be more useful sort of thing
<therealprof[m]>
adamgreig[m]: Maybe we can have 2 micro surveys?
<JamesMunns[m]>
I think we could run multiple surveys, but there's also not a hard limit on questions
<therealprof[m]>
I do think it would make sense to have one to gauge general interest in embedded Rust and how it is used and one that is targeted more towards our work.
<JamesMunns[m]>
(and probably would be better to split them out)
<therealprof[m]>
JamesMunns[m]: Didn't you say 10 max?
<JamesMunns[m]>
therealprof[m]: This does make sense, the Leadership Council recently ran an "effectiveness" survey
<Diaeresis[m]>
"At what scale is your company shipping devices using Rust at?" Instead of free text provide 10s, 100s, etc. in drop-down box fashion for possible answers.
<adamgreig[m]>
we want the same people answering all the Qs (?) so I think one link to a bigger survey is probably better?
<adamhott[m]>
Having worked in sales and marketing for some time, I'd think to keep in mind that we want people to be engaged for long enough to click submit, which means less questions.
<JamesMunns[m]>
Maybe we can figure out a multiple choice or radio button way to ask the question?
<therealprof[m]>
adamgreig[m]: I think the more succinct a survey is, the more likely and the more people are willing to answer it and answer it fully.
<JamesMunns[m]>
that'll also save some effort collecting the responses
<bartmassey[m]>
Is there some easy way to deduplicate responses from people in the same organization a bit?
<JamesMunns[m]>
therealprof[m]: not strictly, there's some commentary in the discussion
<JamesMunns[m]>
bartmassey[m]: specifically no, these must be anonymous and not collect PII
<adamgreig[m]>
yea, the more multiple-choice/radio questions the better I think
<JamesMunns[m]>
JamesMunns[m]: it does mean the "average devices" becomes a bit less valuable, but right now we don't have any concrete info :p
<adamgreig[m]>
it's not going to make the number smaller, at least :P
<bartmassey[m]>
maybe at least a "number of developers in your organization" question? Might be useful to know
<therealprof[m]>
adamhott[m]: Yeah, fully agree. Also even if the people fight on, the last questions are always receiving less attention and willingness to answer, so the early questions should always be the most important ones.
<JamesMunns[m]>
yeah, we might want to phrase it as "N respondents work at a company shipping 10k devices", etc
<JamesMunns[m]>
JamesMunns[m]: (in the results outcome, not the question itself)
<adamhott[m]>
I'd believe to limit fill in the blanks as well, those require too much mental effort.
<adamgreig[m]>
the worst is mandatory fill-in-blanks. top way to get me to just discard the whole survey
<JamesMunns[m]>
I think we can make most/all questions optional!
<vollbrecht[m]>
JamesMunns[m]: NASA engineer working on a rover but only shipping 1 devices. For the person not a good questin, but we may want the persons answers :D
<vollbrecht[m]>
s/questin/questinn/
<JamesMunns[m]>
vollbrecht[m]: they always make two :p
<adamgreig[m]>
usually they only have to ship one though!
<adamgreig[m]>
ok, if you're happy to make a new issue to track working through the questions that sounds great, thanks James Munns!
<jannic[m]>
Of course there are differences between PRs and issues, but the goal to not let them get stale is the same.
<adamgreig[m]>
oh indeed, that should be updated to include issues
<adamgreig[m]>
yea
<adamgreig[m]>
certainly happy to keep it simpler than the main rust-lang system, which has to deal with a lot more reports
<adamgreig[m]>
so yea, proposal sounds good so far!
<adamgreig[m]>
anything else on triage?
<jannic[m]>
No, that's it from my side.
<adamgreig[m]>
cool, thanks
<adamgreig[m]>
next up, adamhott?
<adamhott[m]>
Yes, thanks Adam, give me a moment to type this out
<adamhott[m]>
The rough draft proposal for a submission to the Rust Foundation for a Project Grant is in the github discussion.
<adamhott[m]>
The questions to ask here is, would having a hands-on guided lab book for more advanced topics regarding Rust in Robotics be useful to the Rust Community and the Embedded Community.
<JamesMunns[m]>
I think it would be a good thing to have, but I'm unsure if making it a wg project is a great idea.
<adamhott[m]>
No worries either way, look to gather everyone's thoughts
<JamesMunns[m]>
It is a substantially larger task and scope than even the discovery book, and I'm a little worried how we would maintain it.
<adamgreig[m]>
I had a look over the draft, it looks like a cool project and I think could be a good book too, but as James Munns I'm not sure it fits into the wg
<JamesMunns[m]>
(I'm not the only vote here! just sharing my thoughts)
<adamgreig[m]>
it is similar to the discovery book except for the significantly increased scope, but that increased scope does make it quite different
<adamhott[m]>
No worries at all, I totally get it
<adamgreig[m]>
it's well and good when you're maintaining it, but if you weren't maintaining it, it would be a huge effort for the wg to keep up-to-date, and probably unfair on the book itself to languish a bit like that
<adamhott[m]>
It's definitely a larger scope
<adamgreig[m]>
in previous years the rust foundation did have grants that seemed like a good fit for this sort of project, but I'm not sure if that's what's become the recent grant categories
<therealprof[m]>
Fully agree that this is not something that the WG can handle, but I do think it's an effort we support, especially when asking for grants.
<therealprof[m]>
* effort we can support, especially
<adamhott[m]>
I plan on doing it myself either way
<adamgreig[m]>
right... would it be useful to the rust community and the embedded community? sure, yes, easily
<adamhott[m]>
Well I mean...
<adamgreig[m]>
but is it a wg project? i wouldn't have thought so
<adamhott[m]>
I'll do it on my own if the WG wouldn't take it on as a project
<adamhott[m]>
And that's no problem
<adamgreig[m]>
it's frustrating that right now the grants the foundation are offering are contingent on supporting wg/team projects, and not otherwise generally available, but I don't think it makes sense to try and squeeze this into the wg just for that purpose
<therealprof[m]>
adamgreig[m]: Have you checked that this is the case? We could talk to the foundation either way.
<jannic[m]>
BTW in the past I was successful with grant applications which didn't list a well-defined goal to achieve (like a book), but mostly describing the kind of activities I was planning to perform.
<adamgreig[m]>
I think the grants they are offering right this moment are quite narrowly-scoped, but they have in the past offered much more open grants
<adamgreig[m]>
I don't know if they plan to do those again this year or what, though
<therealprof[m]>
We could still check with them. Last time I heard they were actually asking for suggestions on which grants to offer... sounded like they had a lot of money to spend but couldn't figure out how to do it effectively to the most benefit of the Rust project and community.
<jannic[m]>
"Project Fellowships" looks quite similar to last year's grants, with the added requirement that it's only open to members of WGs and teams.
<bartmassey[m]>
I will talk with the Foundation folks this week about their current granting philosophy and plans.
<adamhott[m]>
I do have an open PR to add me to the resources group, not sure where that stands.
<adamhott[m]>
What everyone decides is totally ok
<adamhott[m]>
bartmassey[m]: thanks Bart!
<adamgreig[m]>
jannic[m]: this year they're qualified with "to support contributions that serve the goals of the Rust Project Teams and Working Groups"
<therealprof[m]>
Nice.
<jannic[m]>
Which is quite broad, isn't it? The Adam's proposal would surely serve the goals of our working group, even if we decide not to manage the result.
<jannic[m]>
s/The//
Makarov73 has joined #rust-embedded
<adamgreig[m]>
true, maybe so! I had read it as being more specifically focused on the wg goals but maybe because I was reading it alongside the new project goals stuff
<adamgreig[m]>
hopefully we can find out more info soon, thanks bartmassey
<adamgreig[m]>
would you like to talk about the disco stuff?
<bartmassey[m]>
Sorry, yes
<bartmassey[m]>
Just really briefly. I have been working quite a bit on it lately, and I think I have something that can work. I've done a lot of cleanup, but there's still a lot to do.
<bartmassey[m]>
I had to reorganize the first few chapters quite a bit, which was beyond the scope of the triage proposal. Folks should look at it and see if it's acceptable.
<adamhott[m]>
Bart I was working on the clocks and timers chapter with Henk, do you have the result of that?
<bartmassey[m]>
We should move this to rust-embedded now, I think. I'll try to do that today.
<bartmassey[m]>
We are plus about 4 chapters now, two of new material and two from reorgs, more or less.
<bartmassey[m]>
I will schedule a book sprint for later this month or early next month. Probably a Saturday morning US Pacific start, which should allow the Europe folks to participate.
<bartmassey[m]>
Right now I don't have a rendered version: top priority. You can pull the repo and build one pretty easily.
<adamhott[m]>
I went into mdbook and ran mdbook serve after I cloned it
<therealprof[m]>
Okay, just curious.
<bartmassey[m]>
basically mdbook build in the mdbook directory
<therealprof[m]>
Do we care about the CI failures?
<bartmassey[m]>
I will fix them.
<bartmassey[m]>
One of the big improvements is that cargo build at the top level now reliably builds every bit of code in the book. I split it all out from being inlined in the md
<therealprof[m]>
"The following topics will be covered (eventually, I hope):" 😅
<bartmassey[m]>
Yeah, this is just the triage phase. We definitely have more chapters in store. Hopefully you folks can help. @Henk and I have a plan.
<adamgreig[m]>
sounds good! do shout if you run into any issues moving the repo
<adamgreig[m]>
in particular I think the moment it's moved you'll lose admin access until it's added to the resources team, but that might be different now
<bartmassey[m]>
Good point. Will watch out for it.
<adamgreig[m]>
ok, that's all we have time for today, thanks everyone! remember that next week we have the second round of issue triage, so come prepared!
<adamgreig[m]>
prepared to read loads of really old issues 😅
<ryan-summers[m]>
Sorry, I'm on the tram and can't really 100% be at the meeting, but I don't know if there's an active stm32g4xx-hal maintainer with merge permissions and there have been some questions about merging some PRs. I'm happy to hit merge on them if I get permissions, but maybe more appropriate for one of the active contributors to get permissions.
<adamgreig[m]>
ryan-summers: I'm at least the maintainer of last resort there, so if the last maintainer isn't around any more I can give you permissions
<JamesMunns[m]>
adamgreig[m]: Do you need me to prep a todo list spreadsheet for that again?
<adamgreig[m]>
(that would be dotcypress, or luctius on github)
<adamgreig[m]>
JamesMunns[m]: if you could that would be great! we didn't quite finish the last one so we can start there but then maybe move on to embedded-hal or something
<JamesMunns[m]>
yeah, I had a one-liner for it and a little bit of text editor preprocessing
<adamgreig[m]>
ryan-summers: are there active contributors without permissions? in any event I'd be happy to add you if you'd like
<ryan-summers[m]>
And having a commit history on the repo :)
<adamgreig[m]>
doesn't look like they're on matrix
<ryan-summers[m]>
But no knowledge outside of that for that family, I unfortunately am using c with that family currently
<adamgreig[m]>
👍️ thanks, I've asked if they'd like access too
<adamgreig[m]>
ok, gotta run, seeya all!
<ryan-summers[m]>
Awesome, thank you :)
<adamgreig[m]>
i hope it's as nice weather wherever you are... this is the best and perhaps only day of summer we're getting here
<JamesMunns[m]>
adamgreig[m]: Hope the sky stays clear, if you're telescoping :D
<adamgreig[m]>
haha it's forecast to get cloudy just as it gets dark 😭 but it was clear the last few nights!
<adamgreig[m]>
it's still wild to me what you can see with just a normal camera and lens pointing at the sky though! temptation to get an actual telescope increasing with every clear night
<therealprof[m]>
Ooh, there's some MBs out there with a nRF52833 on board? Wild...
<JamesMunns[m]>
therealprof[m]: yeah the bbc micro v2 is 833 based
<JamesMunns[m]>
s/micro/microbit/
<therealprof[m]>
Not generally, no... Due to parts availability there are two variants of the V2.2X devices with a different interface chip; a limited run of devices were built using the nRF52833-QDAA and further devices are built using the nRF52820-QDAA.
<JamesMunns[m]>
oh! TIL
<therealprof[m]>
Oh, I misread.
<therealprof[m]>
I think the main MCU is always a nRF52833.
<therealprof[m]>
I think they're talking about the debugger.
<therealprof[m]>
bartmassey: How would you like to handle changes? Found a few typos and wrong links already.
LiamKinne[m] has quit [Quit: Idle timeout reached: 172800s]
balbi[m] has joined #rust-embedded
<balbi[m]>
Hi everyone,
<balbi[m]>
Sorry for the off-topic message, but my team is looking for Embedded Rustaceans to join our team. If you are interested, please apply on the link below. If you have experience with `embassy`, it's even better.
<JamesMunns[m]>
Oh, also an announcement I forgot to mention, I'll be at RustConf this year, if anyone wants to meet up, feel free to send me a DM :)
Jonathan[m] has joined #rust-embedded
<Jonathan[m]>
I seem to have been mentioned a bit back but I can't find the message. bartmassey: do you remember? seems likely it may have been you
ejpcmac[m] has joined #rust-embedded
<ejpcmac[m]>
<adamgreig[m]> "it would be a shame to run the..." <- And there could also be companies shipping millions of devices to production, without Rust for now, but are evaluating it. This is a potential of going from 0 to *many* in one update.
<dirbaio[m]>
rust over the air 🦀
<dirbaio[m]>
* devices getting rust over
<ejpcmac[m]>
And people doing Rust for internal tools in companies, actually used by other people, but not actually shipping this Rust code to production (since it’s for internal tools)
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<ejpcmac[m]>
dirbaio[m]: Air contains dioxygen, which oxidizes. That makes sense :)
<dirbaio[m]>
oxigen oxide
<danielb[m]>
oxigen monoxide
<danielb[m]>
sounds potent
<dirbaio[m]>
about equally lethal as dihydrogen monoxide
<dirbaio[m]>
* about equally lethal as DHMO (dihydrogen monoxide)
<danielb[m]>
Yeah, careful asking "I'll have h2o, too!"
<danielb[m]>
* Yeah, be careful asking
<ejpcmac[m]>
Yeah, I’ve heard that anyone who consumes it dies some time after.
<dirbaio[m]>
100% mortaility rate
<dirbaio[m]>
not surprising, since it's the main component in acid rain