<sourcebox[m]>
I would expect the H747 to draw about 200-300mA depending on the used peripherals inside. That's about 0.6-1W of power that has to be dissipated. So expect some noticable rise in internal temperature.
IlPalazzo-ojiisa has joined #rust-embedded
korken89[m] has joined #rust-embedded
<korken89[m]>
Has anyone use a library for generating RPCs for use on top of smoltcp? I'm thinking creating Command/Response interfaces is surely a solved problem? 😅 The closest I found is https://docs.rs/urpc/latest/urpc/
<korken89[m]>
* Has anyone used a library for generating RPCs for use on top of smoltcp? I'm thinking creating Command/Response interfaces is surely a solved problem? 😅 The closest I found is https://docs.rs/urpc/latest/urpc/
<korken89[m]>
Unfortunately not maintained anymore though
<chrysn[m]>
Won't a crate that uses fugit (or heapless) and its defmt 0.2 suffer from the version being upgraded to 0.3, and the 0.2 trait not being provided any more? Can they pin that dependency (other than running --locked all the time)? Or does the trouble only occur when someone else pulls in 0.3 (which can be avoided as long as people do fine-grained feature gating, and not have a defmt feature that pulls in all implemented versions at
<chrysn[m]>
the cost of some compile time)?
<JamesMunns[m]>
fwiw: I plan to do your initial suggestion for postcard in the near future.
<JamesMunns[m]>
(this is generally the main motivator for postcard 2.0 - to version heapless and other public deps)
<Lakier15[m]>
Are you foreseeing any wire format changes for 2.0?
<JamesMunns[m]>
nope, specifically NOT making wire changes in 2.0
<JamesMunns[m]>
I'll probably add clear docs to say which library versions are compatible with which wire versions - though I'd probably need a PRETTY GOOD reason to ever break the wire format. There's really one "known deficiency" atm (char encoding), but it's not a bug and it's a pretty rare/weird thing (sending `char` instead of `str`)
<JamesMunns[m]>
* I'll probably add clear docs to say which library versions are compatible with which wire versions - though I'd probably need a PRETTY GOOD reason to ever break the wire format. There's really one "known deficiency" atm (char encoding), but it's not a bug and it's a pretty rare/weird thing (sending `char` instead of `str`)
<PhilMarkgraf[m]>
I am looking at using embedded_bus::spi to share multiple devices on a SPI bus. Is there a version that offers the SpiBus trait to your driver, instead of SpiDevice? The device drivers I am working with control their own chip-selects and assume the former traits.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
you can't share SPI safely if the driver manages CS on its own
<dirbaio[m]>
because then the "thing that shares SPI" can't know whether one driver has CS asserted, in which case it should prevent other drivers from using the bus
<PhilMarkgraf[m]>
<dirbaio[m]> "because then the "thing that..." <- Thank you. That makes sense. (My implementation provides separation between the two usages, so it would be okay. But I understand that is not always the case.)
<adamgreig[m]>
hi @room, it's meeting time again! agenda is just on its way...
<adamgreig[m]>
whew, sorry, had to deal with a quick first aid issue, agenda is https://hackmd.io/r5y0wKqKRoymV0mHE1Hynw, please add anything you'd like to announce or discuss!
<adamgreig[m]>
ok, let's begin! I only have a super quick announcement to remind everyone about the RustNL embedded unconf happening may 9-10th for working on embedded wg projects, please message me if you're interested in coming and haven't already
<adamgreig[m]>
any other announcements?
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol>
adamgreig[m]: oh hey I want to attend :)
<adamgreig[m]>
fairly light agenda for this week then! we have a couple of open e-h issues but I think they've now both been more or less discussed in meetings
<DanielakaCyReVol>
DanielakaCyReVol: just bought a ticket, thanks for the reminder 😅
<adamgreig[m]>
well, how unusual! anything else anyone wants to discuss in the meeting?
<therealprof[m]>
Not sure how well people are prepared to talk about microbit and nrf-hal...
<therealprof[m]>
Tangentially WG relevant due to the discovery book...
<adamgreig[m]>
it sounds like there's now at least three people looking to help maintain if they can be given permission for it
<therealprof[m]>
Permissions for microbit have been given already, but there's no final word on nrf-hal yet.
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I really am eager to start work on nrf-hal: I'm working on a fork now that I'm using for my classes
lulf[m] has joined #rust-embedded
<lulf[m]>
I started porting the microbit crate to embassy, but after thinking about it for a while, I'm wondering if it's better to port discovery book directly to embassy-nrf.
<bartmassey[m]>
I'm still uncertain on whether the Disco Book should require async/await. Not totally against, just unsure.
<lulf[m]>
You don't need async/await with embassy-nrf
<dirbaio[m]>
Ulf and I have explained this quite a few times in the various github threads 🤣
<dirbaio[m]>
embassy-nrf supports both blocking and async
eldruin[m] has joined #rust-embedded
<eldruin[m]>
yeah that name keeps confusing people
<bartmassey[m]>
Yeah, just confused for a moment sorry
<adamgreig[m]>
the nrf-hal repo is not part of the wg, but I think therealprof and James Munns can both grant access maybe?
<dirbaio[m]>
you can use it blocking (with no "runtime"/executor), async with no runtime (with something like block_on), or async with runtime (with embassy-executor, rtic or another executor)
<dirbaio[m]>
so
jannic[m] has joined #rust-embedded
<jannic[m]>
How stable is embassy? (Stable in the sense of rare breaking changes, not related to quality.)
<jannic[m]>
If it's still rapidly evolving, keeping the discovery book up to date might be difficult.
<dirbaio[m]>
what embassy-nrf can do is a superset of what nrf-hal can do
<dirbaio[m]>
you have the option to use async if you want to
<dirbaio[m]>
my plan was to port the discovery book as-is (keeping all the examples/exercises without async), and then later perhaps add a chapter introducing async
<dirbaio[m]>
the thing is
<bartmassey[m]>
That makes huge sense.
<dirbaio[m]>
if you build a HAL
<dirbaio[m]>
80% of the code is shared between blocking and async
<therealprof[m]>
dirbaio[m]: So rewrite the book a 3rd time?
<dirbaio[m]>
all the modeling of the peripherals, all the register access etc is the same. the only difference is "how you wait for stuff"
<thejpster[m]>
dirbaio[m]: Except the missing radio driver?
<thejpster[m]>
(I’m not here … I’m on a break during a training. Byeeeeeee)
<dirbaio[m]>
thejpster[m]: porting it is a 10 minute job. that driver is not "production-ready" though, it's a toy
<bartmassey[m]>
The biggest advantage of the MB2 for this is its easy availability at a low price, and its popularity with educators outside Rust
<dirbaio[m]>
therealprof[m]: yes? at least it's not rewriting for an entirely new MCU. just porting it to another HAL
<therealprof[m]>
dirbaio[m]: Okay, would that be a third "branch" or a rewrite of the 2nd?
<dirbaio[m]>
if nrf-hal stays unmaintained it should replace the current microbit book IMO
<dirbaio[m]>
if nrf-hal resurrects then we can have both in parallel, dunno
<therealprof[m]>
dirbaio[m]: That's not helping... 😅
<bartmassey[m]>
There's plenty of developers including myself willing to maintain nrf-hal for the existing chips.
<dirbaio[m]>
not helping what?
<lulf[m]>
eldruin[m]: That is true... I wonder if most of these things doesn't need to be in the BSP, but can live on crates.io as separate crates. So what remains is the somewhat convenient pin name mapping which I think is the most time saving. Not sure what to do about that though.
<therealprof[m]>
dirbaio[m]: Decision making.
<lulf[m]>
Maybe we just need more books :)
M9names[m] has joined #rust-embedded
<therealprof[m]>
"It could go one way... *or* the other"
<M9names[m]>
I don't believe the existence of two previous versions is a good argument for not putting our best foot forward
<adamgreig[m]>
I think two books is confusing enough
<dirbaio[m]>
well it's not up to me to make the decision! i'm part of the WG but not of the team that maintains the docs/website
<dirbaio[m]>
i'm just giving my opinion
<adamgreig[m]>
given the age of the f3disco I'd be more inclined to retire the f3 version and keep the microbit one only?
<therealprof[m]>
dirbaio[m]: I was trying to get your opinion and received two, though. 🤣
<dirbaio[m]>
my opinion is if nrf-hal stays unmaintained then the current book should be replaced because we don't want a book relying on an unmaintained HAL
<adamgreig[m]>
if nrf-hal has a bunch of people interested in keeping it maintained and that's what the current book is written against, that seems like the best immediate route, if all that's needed is for those people to get maintainer access to the hal
<therealprof[m]>
dirbaio[m]: Right, but as it seems people are willing to maintain nrf-hal.
<dirbaio[m]>
that's why I said if
<dirbaio[m]>
if nrf-hal gets active maintainership then we should have two books
<dirbaio[m]>
s/should/can/, s/books/versions of the book/
<adamgreig[m]>
as in, two microbit books, one using embassy and one using nrf-hal? why?
<eldruin[m]>
lulf[m]: yeah but my point would be that with a BSP you just import one crate and you have everything at your disposal. I would argue figuring out "which pieces come together how" is not trivial in the beginning
<eldruin[m]>
* the beginning. A good template can help a lot of course
<therealprof[m]>
adamgreig[m]: I agree.
<bartmassey[m]>
I think there should be one book. The STM32 book should be retired once its remaining content has been ported. I don't really have strong opinions on nrf-hal vs embassy-nrf: one is easier since the content is already there, the other is newer and provides a better path into Embassy
<bartmassey[m]>
I would prefer the book start on top of a BSP crate, but again I don't feel super-strongly about it.
<adamgreig[m]>
yea, I'm happy to see the stm32 version retired, and so long as nrf-hal has someone maintaining it (which it looks like it will once they're given access) then keeping the current version of the book is much less work
<therealprof[m]>
I'm leaning towards using a BSP, too.
<lulf[m]>
adamgreig[m]: I think embassy could benefit from something discovery-book like too (and introducing async), so I guess that's why. But whether that's part of the 'official' discovery book or some other book I don't know...
SergioGasquez[m] has joined #rust-embedded
<SergioGasquez[m]>
Hi! Related to the discovery book, for ESPs we have a few books that cover, more or less, the same topics as the discovery book. I opened a PR (https://github.com/rust-embedded/discovery/pull/559) to add links them, but wanted to hear your thoughs on it, maybe you want to keep the discovery book without too many links and only related to the "official" content (I'll happily close the pr in this case)
<eldruin[m]>
adamgreig[m]: AFAIK the f3disco book "just works". I would not replace it if we have mantainability issues with the microbit one
<adamgreig[m]>
is anyone volunteering to write an embassy-nrf version of the discovery book?
<lulf[m]>
> <@adamgreig:matrix.org> as in, two microbit books, one using embassy and one using nrf-hal? why?
<lulf[m]>
* I think embassy could benefit from having a discovery-book too (and introducing async), so I guess that's why. But whether that's part of the 'official' discovery book or some other book I don't know...
<dirbaio[m]>
yes!
<therealprof[m]>
adamgreig[m]: @dirbaio:matrix.org was, until he wasn't.
<dirbaio[m]>
????
<adamgreig[m]>
eldruin: maybe we can make the front page more clearly recommend the microbit one to new users? I think having both options from the start might just confuse someone and these days probably not many people already have an f3disco
<dirbaio[m]>
I'm planning to port the book to embassy-nrf
<bartmassey[m]>
The STM version of the Disco book depends on the F3 Disco board: this is a great board, but it is harder for most people to get and supplies are sometimes limited. Also, a lot of people start MB2 with Python and then want to move lower level.
<adamgreig[m]>
dirbaio: ah right, so you'd be interested in writing such a thing as an introduction to embassy anyway?
<dirbaio[m]>
because I want a version of the book with embassy-nrf to exist
<therealprof[m]>
dirbaio[m]: You put a condition on it.
<adamgreig[m]>
got it
<dirbaio[m]>
sorry for the confusion 🤣
<dirbaio[m]>
let me clarify
<eldruin[m]>
adamgreig[m]: yeah we should do that. now it looks like they are too equivalent
<bartmassey[m]>
The MB2 version of the Disco book is currently quite incomplete. Some content from the STM version is missing, and there are some topics I would like to add once we've stabilized on a platform.
<adamgreig[m]>
what's the benefit of keeping the f3 one up, do you think? just in case people who happen to have an f3 stumble across it, or because it has any content that's not present in the microbit one?
<adamgreig[m]>
got it, thanks bartmassey
<bartmassey[m]>
I will port the F3 content to MB2 book once we have settled on what that book is going to look like.
<adamgreig[m]>
my preference then would be to retire the stm32 one once the mb one is more up to date and make it clear the mb one is the one to look at, but we could keep hosting the stm32 a while longer as a small link for those who want it I guess
<dirbaio[m]>
- I'm planning to port the book to embassy-nrf, because I want a version of the book with embassy-nrf to exist. I think lulf wants to help too. I've been planning to do this for a while, i've ordered a microbit. I'm going to do it no matter what.
<dirbaio[m]>
- I would *really like it* if it was posted on the WG website. I think it *should* replace the existing book *if nrf-hal stays unmaintained*, if that's not the case then I would *prefer* both books to be on the WG website so that people new to embedded Rust learn about the two options at their disposal (nrf-hal, or embassy).
<dirbaio[m]>
* - I'm planning to port the book to embassy-nrf, because I want a version of the book with embassy-nrf to exist. I think lulf wants to help too. I've been planning to do this for a while, i've ordered a microbit. I'm going to do it no matter what, over the following months
<dirbaio[m]>
- I would _really like it_ if it was posted on the WG website. I think it _should_ replace the existing book _if nrf-hal stays unmaintained_, if that's not the case then I would _prefer_ both books to be on the WG website so that people new to embedded Rust learn about the two options at their disposal (nrf-hal, or embassy).
<adamgreig[m]>
I'm not a fan of having alternate versions of the book where the only difference is which HAL is used, but I do want the version we host to be the most complete/useful one
<eldruin[m]>
adamgreig[m]: we can also add a banner in the f3 book saying that there is a newer version of the book for another board, for the people that find the link via search engine, which sometimes rather links to old stuff
<dirbaio[m]>
If the WG decides to not accept the Embassy version of the book, i'll probably host it on the embassy website together with the other embassy docs.
<adamgreig[m]>
if the people volunteering to maintain nrf-hal ( bartmassey ) want to work together with dirbaiolulf on an updated embassy-nrf version (i.e. no particular desire for it to be based on nrf-hal going forward), perhaps that's the best outcome?
<therealprof[m]>
I think embassy is important enough that we might entertain the idea of a new book.
<bartmassey[m]>
I don't want to maintain the F3 book once we've got the MB2 book ready, personally. If someone else does that's great.
<adamgreig[m]>
but maybe in the upcoming few weeks it makes sense to nevertheless get the open nrf-hal PRs merged and such
<bartmassey[m]>
I think 90% of the hal MB2 book and the Disco book would be the same.
<adamgreig[m]>
eldruin[m]: yea, good idea, and maybe "this version is unmaintained and we can't support it, but it's here to look at for historical reference"
<bartmassey[m]>
I have already merged some of the nrf-hal PRs in a fork. If I can get commit privs on that repo I can do it there also.
<adamgreig[m]>
bartmassey: am I right in thinking that you and the other people volunteering to maintain nrf-hal are primarily doing so because of its use in the disco book?
<eldruin[m]>
adamgreig[m]: hmm, more like "this works just fine but we have newer cooler stuff over here" the f3 hal is working fine AFAIK
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
> Seems like embassy currently doesn't support it I have currently no clue on how to make it work otherwise
<firefrommoonligh>
HMU if you have questions; I do it all the time. There are different techniques available in the STM32 ADC and timer hardware depending on the specific use case
<adamgreig[m]>
eldruin[m]: it's working fine, but do we want to support people who get stuck on it, fix any bugs, that sort of thing?
<firefrommoonligh>
One of the simpler ones is to set up a sequence in the ADC of channels you want, then periodically DMA them together
<adamgreig[m]>
therealprof: do you have admin access to the nrf-rs org? do you know who does?
<firefrommoonligh>
You can also use Basic timers to do them continuously or w/e
<eldruin[m]>
adamgreig[m]: I would say depends on the bug, if somebody submits some small openocd fix, that would be fine for me to merge
<firefrommoonligh>
(Basic timers are p much designed for this, and the analogous case with DACs)
<therealprof[m]>
adamgreig[m]: I don't think so but I can check. @jamesmunns:beeper.com certainly does.
<bartmassey[m]>
Maybe? Certainly because of the current utility of nrf-hal for the MB2.
<bartmassey[m]>
To be honest, I was thinking that this discussion might happen next week, so I'm not as up-to-speed on embassy-nrf and microbit-bsp as I should be (obviously)
<JamesMunns[m]>
<adamgreig[m]> "the nrf-hal repo is not part..." <- Afk but can later!
<bartmassey[m]>
I'm teaching a 10-week Rust Embedded course on the MB2 with microbit and nrf-hal right now: we are at week 7. It's going OK, but I'm having the students use my forks a lot because of the current situation, and not really using the Disco book because we are well past what it covers.
<therealprof[m]>
Ooof, seems *a lot* of people have access to that org. 😬
<adamgreig[m]>
bartmassey: if you and henk weren't stepping up to volunteer to maintain nrf-hal, I think we'd basically be saying "yea, nrf-hal is unmaintained, the embassy folks are already planning to port the book to embassy, makes sense to host their version ones it's done"
<adamgreig[m]>
s/ones/once/
<therealprof[m]>
<therealprof[m]> "I think embassy is important..." <- 👆️ No comments on that?
<adamgreig[m]>
but if you're mainly offering to keep nrf-hal up-to-date because of its use in disco/your course, and you'd just as happily swap those to embassy-nrf and benefit from collaborating with them, then it's a somewhat circular justification
<bartmassey[m]>
I'm fine with moving stuff to embassy-nrf, but I'd prefer to have a BSP crate that doesn't require async/await for basic stuff. But I can live with that if that is what folks want to go with.
<adamgreig[m]>
it sounds like that's achievable just using embassy-nrf
<dirbaio[m]>
for the 1000th time, embassy-nrf doesn't require async-await 🤣🤣🤣🤣
<adamgreig[m]>
therealprof: a new book to replace discovery, or a new book alongside it?
<eldruin[m]>
therealprof[m]: dirbaio had a draft plan of porting the book and then adding chapters about async
<dirbaio[m]>
🫠
<bartmassey[m]>
I am aware of this!
<adamgreig[m]>
dirbaio: yea, we know it doesn't _require_ it, but it's about whether it would get used in the bsp
<adamgreig[m]>
(and thus in the disco book)
<bartmassey[m]>
But it's really nice to start teaching with a BSP crate, and embassy-nrf does require async/await currently.
<dirbaio[m]>
BSP can have non-async and async modules, iirc that's what ulf was proposing
<adamgreig[m]>
I assume you will be using async in your embassy-discovery book since it's all about discovery
<therealprof[m]>
adamgreig[m]: A new book alongside of it. I think we had for some time plans to cover higher level concepts but didn't have any grip on that. Now we do, thanks to embassy.
<dirbaio[m]>
or the BSP can be fully non-async if its main use case is the book and we don't want async in the book (or the start of it)
<adamgreig[m]>
dirbaio: yea, I think agreement on "bsp is mostly non-async so the whole start of the book can ignore async, maybe it comes in at a later chapter" would then be ok?
<dirbaio[m]>
yeah
<bartmassey[m]>
That would be fine.
<adamgreig[m]>
therealprof: who's the target audience? discovery is explicitly "new to embedded _and_ new to rust", are you suggesting something one level up?
<dirbaio[m]>
also re bsp vs no bsp: I do think BSPs help at the beginning with "get a blinky running" because they hide complexity from the user
<adamgreig[m]>
the book could even drop the bsp towards the advanced chapters I suppose, but yes, agreed that they're really helpful to start with
<dirbaio[m]>
but they translate very badly to the user moving to use another board, which 99% likely won't have a BSP
<SergioGasquez[m]>
Maybe there also a bennefit of not using a bsp in the disco book? Most of the devkits do not have a bsp in the embeded Rust eccosystem
<adamgreig[m]>
Sergio Gasquez: but the disco book is entirely about using a microbit2, which does
<adamgreig[m]>
it's not designed to be used with some other devkit really
<dirbaio[m]>
i've seen people asking on this chat "I want to use $BOARD but it doesn't support embedded rust! only C!"
<dirbaio[m]>
while what they mean is $BOARD doesn't have a BSP, and they don't realize they don't need a BSP
<adamgreig[m]>
so maybe a late chapter can introduce people following the book to the concept of not using the BSP and using the HAL directly, but it's not the direction
<adamgreig[m]>
s/direction/starting point/
<bartmassey[m]>
I really want a gentle introduction to Rust Embedded, and a BSP crate provides that. Most of the people I'm teaching have no embedded experience and very little Rust experience. 😀
<therealprof[m]>
adamgreig[m]: The target audience would be people who want a bit more framework than just learning about rather lowlevel embedded concepts.
<dirbaio[m]>
or "how do I make a BSP for $BOARD" and then get bogged down writing it (which is not easy, it uses fairly advanced rust concepts like type aliases and reexports and shit)
<SergioGasquez[m]>
adamgreig[m]: But concepts are still portable, if some of those concepts are abstracted by the bsp the user migth be lost when starting a project on a different board
<eldruin[m]>
dirbaio[m]: maybe that is a chapter for the embedonomicon, rather
<bartmassey[m]>
The current microbit crate provides a pretty thin layer over the nrf-hal stuff. It shows through well enough that my students can see what's going on. I consider this a feature.
<dirbaio[m]>
eldruin[m]: yeah... but then you're cementing the idea of "you SHOULD have a BSP if you want to do things 'right'"
<dirbaio[m]>
which is somewhat debatable
<dirbaio[m]>
I write all my projects without BSP
<adamgreig[m]>
so maybe I can suggest that right now, we get bart and henk access to nrf-rs to get the hal PRs merged and it generally up to shape, which is useful for the immediate microbit book and their course and current and future nrf-hal users
<adamgreig[m]>
in the short term future, the microbit bsp is ported to embassy-nrf, the discovery book is updated to reflect that, and the new additions to the book use it
<adamgreig[m]>
we keep async out of the bulk of the discovery book, and it's still primarily focussed on teaching general embedded+rust
<eldruin[m]>
dirbaio[m]: hmm I would not think it that way. I would present the chapter as in "that is something you could do, if your audience is like x and your board has x features"
<eldruin[m]>
s/x/y/
<dirbaio[m]>
yeah
<dirbaio[m]>
but currently the book teaches people "you MUST HAVE a BSP"
<bartmassey[m]>
I might also suggest adding @qwandor as an nrf-hal maintainer if folks are willing. They've contributed the hal-1.0 patches and have said that they are willing.
<adamgreig[m]>
I don't know how much dirbaio wants it to also introduce embassy and embassy concepts, but perhaps that and async can come into a later chapter?
<lulf[m]>
adamgreig[m]: Sounds like a good plan to me, it's always good to have maintainers who actually use the stuff.
<dirbaio[m]>
this way we bypass the "should the BSP use async" bikeshed
<dirbaio[m]>
it's just not async
<adamgreig[m]>
more explicitly: I wouldn't want the discovery book to transition from "teach general embedded and rust, happens to use nrf-hal" to "teach embedded and embassy, happens to be in rust"
<adamgreig[m]>
but that latter would make sense for an embassy-hosted/embassy-written book
<eldruin[m]>
dirbaio[m]: I'm just saying that is how you interpret it, that is not written anywhere in the book
emilgardis[m] has joined #rust-embedded
<emilgardis[m]>
I have a quick thing which I realise won't fit in the meeting time + i'm late, we're planning on switching the casing defaults on svd2rust, https://github.com/rust-embedded/svd2rust/pull/805 I'm all for it but want to have atleast one more +1 for it
<dirbaio[m]>
adamgreig[m]: agreed. it'd start with "embassy-nrf + cortex-m + cortex-m-rt", where the experience is nearly identical to "nrf-hal + cortex-m + cortex-m-rt"
<adamgreig[m]>
emilgardis[m]: will look, from what I was seeing it seemed fine though
<adamgreig[m]>
(not sure if i'll change what stm32-rs does however :P)
<bartmassey[m]>
dirbaio[m]: But I'd really like to still start with a BSP. I'm fine with microbit-bsp if we can provide non-async versions of the functionality.
<adamgreig[m]>
yea, I think that's what dirbaio meant
<dirbaio[m]>
yep
<therealprof[m]>
People have been invited.
<adamgreig[m]>
did you get all three?
<therealprof[m]>
Yes.
<adamgreig[m]>
thanks!
<therealprof[m]>
Took a bit of research to get all the GH handles but I got it.
<bartmassey[m]>
Thank you!
<adamgreig[m]>
ok, thanks everyone!
<bartmassey[m]>
I'm really excited to see progress here. Thanks everybody!
<adamgreig[m]>
so our outcome is we'll first get nrf-hal up-to-scratch and it has some new maintainers, but we'll later expect microbit-bsp to move to embassy-nrf and the discovery book along with it
<adamgreig[m]>
and then new later chapters in discovery can cover a bit of non-bsp and async stuff
<adamgreig[m]>
(and embassy)
<dirbaio[m]>
there's the `microbit` crate, then there's the `microbit-bsp` crate from lulf which is already using embassy-nrf
<dirbaio[m]>
(though async I believe)
<adamgreig[m]>
ah, sorry, I guess I mean just microbit
<dirbaio[m]>
whether to port microbit to nrf-hal or not is another question
<adamgreig[m]>
therealprof: let's bump "a new book" discussion to later, maybe the rustnl workshop? I'm interested but I think it's a different topic
<bartmassey[m]>
microbit to embassy-nrf, but yeah. @lulf seems willing if we can figure out a plan
<dirbaio[m]>
(including the "needs a runtime" misconception again :melt
<dirbaio[m]>
s/:melt/🫠)/
<dirbaio[m]>
who are the current maintainers of microbit?
<dirbaio[m]>
IOW how can we get the decision-making process "unstuck"?
<bartmassey[m]>
At some time I'd like to discuss the state and status of RTIC, but definitely not today
<dirbaio[m]>
bartmassey[m]: sounds scary? :D
<therealprof[m]>
adamgreig[m]: Oh absolutely. That certainly was more a pitch to @dirbaio:matrix.org regarding his proposal.
<therealprof[m]>
dirbaio[m]: Me and some others.
<lulf[m]>
I think I have the maintainer rights, but being fairly new I don't want to turn things upside down if users want things to stay as they are
<lulf[m]>
(And that's totally fine, I'm not in a hurry)
<adamgreig[m]>
emilgardis: lgtm
<therealprof[m]>
dirbaio[m]: Oh, you as well, due to being member of the @nrf52 team.
kenny has joined #rust-embedded
<dirbaio[m]>
yeah, but same, I don't want to turn things upside-down 🤣
<dirbaio[m]>
especially me because i'm not "neutral", i'm the embassy author lol
<therealprof[m]>
Much appreciated. 😜
<dirbaio[m]>
the way I see it is
<dirbaio[m]>
option A: port `microbit` to `embassy-nrf`
<dirbaio[m]>
option B: make a new crate (`microbit-bsp` maybe) on top of `embassy-nrf`.
<dirbaio[m]>
option C: maintain in parallel `microbit v0.13` with `nrf-hal`, and `microbit v0.14` with `embassy-nrf`.
<dirbaio[m]>
option C will be VERY confusing for users, I'd discard it right out of the gate
<bartmassey[m]>
There is already an Embassy microbit-bsp crate, which I think is part of the confusion here? It uses async/await.
<dirbaio[m]>
yeah
<dirbaio[m]>
so
<dirbaio[m]>
given there's people still using microbit + nrf-hal for teaching etc maybe B is better
<dirbaio[m]>
if we do A, users of microbit + nrf-hal have "nowhere to go" which is bad, while it's not that much better for users of embassy-nrf
<lulf[m]>
Makes sense to add some blocking APIs to microbit-bsp I think.
<lulf[m]>
It's a nice arena to experiment/rethink without disrupting too many
<lulf[m]>
* too many users
<dirbaio[m]>
yeah
<dirbaio[m]>
in an alternate reality where no one stepped up to maintain nrf-hal I'd have argued for option A
<bartmassey[m]>
I'm new to Embassy so I'm not quite sure the best way to add blocking APIs to microbit-bsp. Hopefully someone can help with that.
<dirbaio[m]>
so my proposal is
<dirbaio[m]>
- decide on this question (port `microbit`, or use `microbit-bsp`)
<dirbaio[m]>
* - decide on this question (port `microbit`, or use `microbit-bsp`)
<dirbaio[m]>
- work on the BSP API until we get something we agree is suitable for the discovery book (for example, no (or optional) async as discussed above)
<dirbaio[m]>
- start porting the book
<dirbaio[m]>
for this question my proposal is option B: leave microbit as-is and work on microbit-bsp
<dirbaio[m]>
if anything because it's less likely to face opposition from people currently relying on microbit+nrf-hal
<bartmassey[m]>
I will help maintain microbit for now, since it doesn't need much and is working fine with the current MB2 Disco Book. Mostly things need to be updated for embedded-hal 1.0, and now that we can merge @qwandor's patches that should be a lot easier.
<bartmassey[m]>
(patches to nrf-hal)
<jannic[m]>
BTW does anyone know if the microbit / microbit-bsp crates are also usable for calliope mini? https://calliope.cc/en
<jannic[m]>
AFAIK it is very similar to the microbit, main difference being the shape of the PCB. But I don't know how similar it really is. Having some pins assigned differently might be very annoying.
<eldruin[m]>
IIRC the motion sensor was different. BMI160 or so but there have been several versions
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
hey I'm just jumping on here late, if anyone wants to know what some of the initial pains are and things they wish they'd known when the first start out with embedded going through a Discovery Book, I'm happy to provide my experience.
<eldruin[m]>
the website also cites having a light sensor, yet I spent several minutes navigating in the website and I cannot find a simple list of actual devices on it
<dirbaio[m]>
AdamHott[m]: please share! 👀
<jannic[m]>
eldruin[m]: https://calliope-mini.github.io/ seems to be more informative. But it looks like it's only available in German.
<AdamHott[m]>
I'll ping you!
<jannic[m]>
jannic[m]: I don't see anything about a light sensor, though.
<AdamHott[m]>
ok let me throw it here!
<AdamHott[m]>
I think for me going through the Discovery Book, I ran into a lot of common errors and had problems troubleshooting.
<AdamHott[m]>
I found the group here and that's why I've been successful so far, everyone helped me out. But if I didn't have that help, I might have stumbled.
<dirbaio[m]>
what things did you struggle with?
<AdamHott[m]>
taking Peripherals and getting access to GPIOs, knowing what those are, what those things mean.
<AdamHott[m]>
*GPIO Pins
<AdamHott[m]>
Difference between HAL and PAC
<AdamHott[m]>
What up and down state means on a Pin
<AdamHott[m]>
Voltage associated with common boards
<AdamHott[m]>
How to find the right information to setup memory.x
<AdamHott[m]>
What a linker is, what a runner is
<AdamHott[m]>
what is .cargo -> config.toml
<AdamHott[m]>
.cargo/config.toml
<AdamHott[m]>
common crates for embedded
<AdamHott[m]>
importance of understanding limits of what a microcontroller can do
<AdamHott[m]>
I still don't really understand that one
<M9names[m]>
I think the problem of HAL vs BSP is exacerbated by the microbit BSP, because it's really two BSPs smashed together into one crate with two facades.
<M9names[m]>
Maybe it's not so bad in a teaching environment where they can ask someone with more knowledge, but as a solo newbie the microbit repo would be impenetrable.
<dirbaio[m]>
for v1+v2? yeah.... agreed
<firefrommoonligh>
I agree with everything Adam Hott said. I remember going through this a few years ago. We've discussed this before, but I'll echo the point that a particular, avoidable pitfall I hit was due to use of BSPs, and related abstraction layers: This made moving from tutorial land to practical land difficult
<firefrommoonligh>
Questions like "What is the difference between F3, F3xx-hal, FDiscovery or etc libs. And it turns out one of them wrapped the other, and didn't add much other than abstractions for the LEDs wired to specific pins
catch22[m] has joined #rust-embedded
<catch22[m]>
Anyone tried rust rover with the discover book and had any luck with code completion . It wasnt working at all for me
<firefrommoonligh>
So, then I'm already in "Shit, I guess I need my own template repo" territory. Specifically, figuring out what dependencies you need, and what each does, is a pain point
mabez[m] has joined #rust-embedded
<mabez[m]>
cunts
<firefrommoonligh>
Another angle on this: I think providing useful application templates is important. Ones that can immediately be used on practical projects. They should include Cargo.toml, config.toml, and a main.rs with the basics.
<AdamHott[m]>
getting a first working flash on a new board for me takes a bit of time, templates are nice
<thejpster[m]>
quick question about RustNL if anyone here knows the answer - if I want to come to the unconf do I need a ticket to the main conference? or can I get a ticket to the unconf? Would like to do both - unclear currently if I can do this on work time or I'm buying my own ticket.
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
I bounced off the embedded discovery books completely when I was getting started because they were so specific to hardware I didn’t have and wasn’t interested in using 🤷 I just found example projects for the hardware I had and went from there. I’m probably not the target audience, I can see them being really valuable for e.g. educators. IMO it therefore makes sense to optimise the books for the target audiences they’re
<barnabyw[m]>
really useful for
<firefrommoonligh>
Another tangential point: We've discussed typestates here extensively over the years. I highlight here not pros/cons of them in general, but how full examples are important. There used to be (maybe still are in some areas) libraries that include examples as a single `main` function. It shows you how to configure and use a peripheral.
<firefrommoonligh>
Real programs will always force you to declare your types. This will be in a struct field, a function parameter, or some global store (Mutex, RTIC Shared etc). So, you immediately end up in a situation where you are inserting `i8` into the type fields and following the compiler error to find the actual type. The examples could have fixed this by demonstrating how to use the various types in a function, struct etc.
<JomerDev[m]>
<firefrommoonligh> "> <@jomer_dev:matrix.org> Has..." <- Great! Do you by chance have a repo or something I could take a look at to get some understanding?
<AdamHott[m]>
barnabyw[m]: that's an interesting point, who is the target audience for the Discovery Book?
<barnabyw[m]>
afaik: people who are learning both embedded and rust from scratch at the same time
<firefrommoonligh>
JomerDev[m]: No public repo, but I can C+P some code. Are you looking for continuous samples, or discrete readings?
<AdamHott[m]>
thejpster[m]: nice one!
<thejpster[m]>
Adam Hott: all our training course materials are open source. Always have been.
<JomerDev[m]>
firefrommoonligh: Continuous would be great. If I recall correctly I need to get 50 samples a second
<AdamHott[m]>
thejpster[m]: awesome!
<AdamHott[m]>
<barnabyw[m]> "afaik: people who are learning..." <- how deep would the intro to Rust need to be?
<dirbaio[m]>
something we DEFINITELY need to do is switch the book from openocd+gdb to probe-rs
<dirbaio[m]>
ah no it already uses cargo embed
<dirbaio[m]>
(should switch to the newer probe-rs run but that's less bad)
<dirbaio[m]>
it still tells you to install gdb tho
<AdamHott[m]>
I've been trying to get my head around probe-rs for some time now.
<AdamHott[m]>
my gear to test another round of equipment with a new probe arrives tomorrow
<AdamHott[m]>
I hope that will solve it
<AdamHott[m]>
<dirbaio[m]> "something we DEFINITELY need..." <- I've gotta run, but I'd be open to help with the Discovery Book if you want a newbie's perspective!
<barnabyw[m]>
even including that one, stm32 still probably has the lowest hal:chip ratio of any manufacturer with good rust support 😁
<dirbaio[m]>
lol.
<dirbaio[m]>
but the highest absolute amount of hals 🤣
<JomerDev[m]>
Hmm, from my understanding this also isn't quite doing the same as the C code I linked earlier, where the only interrupt that happened was a dma interrupt. Or is that just not in the code you shared but still the place you call read_dma?
<firefrommoonligh>
Def not
<firefrommoonligh>
Like I said, there are many ways to use ADCs
<firefrommoonligh>
*I think the way I posted there doesn't even use an interrupt; you just parse the buffer whenever
<firefrommoonligh>
In a diff setup, I have 14 channels across 2 ADCs, using discrete reads. It uses interrupts to start and stop each sequence, for example
<firefrommoonligh>
In what I posted, the CPU is only used in the initial setup code I posted, then the ADC and DMA peiphs handle the rest, continuing keeping ADC readings in that buffer
<firefrommoonligh>
* the ADC,, * timer, and DMA
<JomerDev[m]>
Alright. I think I'll have to do a lot of reading to see how to use this fully and in the way I think I want to
<JomerDev[m]>
Thank you for the example!
<firefrommoonligh>
It is fire and forget. I think you can increase the buffer size, then separate the channels by alternating. (The example uses 2 channels). So, you could set it to len=20, then the even numbers would be the first channel, odds the second, then you could feed it into DSP using a larger block size
<firefrommoonligh>
s/numbers/indices/
<JomerDev[m]>
In my case I want to read the values from a load of analogue hall sensors and fire off a can message whenever any one of them gets over a set value. So I'll need to check the buffer as frequently as the values refresh
<firefrommoonligh>
Sounds like DMA TC interrupt
<JomerDev[m]>
It does. I think I'll play with it a bit tomorrow and see if I can get it to work
<adamgreig[m]>
Jomer Dev: many stm32 adcs have a built-in analogue watchdog, so if all you're doing is comparing the reads to some value, you could have it run continuously in the background and just interrupt you when one of them exceeds the limit