<mkj[m]>
<thejpster[m]> "Has anyone else seen hot garbage..." <- don't think I've seen that, but `llvm-dwarfdump` might give a hint if the compiler is doing something odd?
chrysn[m] has joined #rust-embedded
* chrysn[m]
is happy to see nrfdfu 0.2.0 released. thanks, thejpster!
<Noah[m]>
Max[m]: a git bisect would help to find where this started to go wrong
<Max[m]>
Noah[m]: so its broken since a specific probe-rs commit?
<Noah[m]>
Max[m]: Would it possible for you to bisect through versions? :)
<Noah[m]>
Max[m]: yes, it worked before
<Max[m]>
Noah[m]: sure
<Max[m]>
Max[m]: just installed through the installer so far
<Noah[m]>
Max[m]: you can checkout the repo, run git bisect and then to check each commit in the guided search with `cargo run -p probe-rs-tools -- info` or `cargo run -p probe-rs-cli -- info` for earlier versions I believe
<Max[m]>
Noah[m]: ok
<Max[m]>
Max[m]: running..
<Max[m]>
Max[m]: wjhats the expected output?
<RobertJrdens[m]>
<jason-kairos[m]> "(it let it figure out what the..." <- IIRC you have to be explicit. Though that meshes well when working based on datasheets and reference manuals.
<jason-kairos[m]>
not great for using it as if it was protocolbuffers
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<RobertJrdens[m]>
<jason-kairos[m]> "(I don't think you can declare..." <- Sure you can. You have to. The syntax rejects overlaps and gaps.
<dcz[m]>
I started building an async executor for fun because I have a couple parallel loops. Then I thought, maybe do it properly and looked at embassy... and embassy is forking the entire embedded ecosystem. I'm back to my own executor
pcs38 has joined #rust-embedded
<dirbaio[m]>
????
<dirbaio[m]>
It works with the embedded ecosystem. Embedded-hal, cortex-m, etc.
<dirbaio[m]>
* It works with the embedded ecosystem. Embedded-hal, cortex-m, defmt, etc.
<dcz[m]>
maybe to some extent but I'm seeing: embassy-usb-synopsys-otg, embassy-usb, embassy-stm32, and I doubt my device is supported
<dirbaio[m]>
You can use embassy-executor with non-embassy hals just fine. For example esp-hal, rp2040-hal
<dirbaio[m]>
It's just an executor.
<dcz[m]>
I guess I can still write my own Future impls and use the embassy executor...
<dirbaio[m]>
(and you can use embassy hals with non-embassy executors just fine. For example there's people using them with RTIC)
<dcz[m]>
oh, there are other executors as well? I thought embassy just sweeped the area
<dirbaio[m]>
RTIC v2 has an async executor built-in
<dirbaio[m]>
There's also people using async-task in embedded esp32, that requires alloc tho
<dcz[m]>
thanks, good to know, even if I want something a lot more bare bones
jannic[m] has joined #rust-embedded
<jannic[m]>
For me, matrix loads extraordinarily slow right now. If that doesn't improve, I won't be able to attend the meeting today. (Which wouldn't be too bad to be honest, after being at RustWeek, my family demands some attention :-) )
<dirbaio[m]>
Yeah matrix is barely working for me as well 💩
<i509vcb[m]>
Is it element or matrix which is imploding?
<adamgreig[m]>
hi @room, let's try and have a meeting if Matrix cooperates! agenda is https://github.com/rust-embedded/wg/discussions/839, please add anything you'd like to announce or discuss and we'll start in a few minutes
Coat0168 has joined #rust-embedded
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
ok, let's begin!
<adamgreig[m]>
(sorry, matrix is being pretty laggy here)
<adamgreig[m]>
so the main thing is that rustweek happened last week, thanks to everyone who could attend! we had an embedded unconf the last two days with a handful of wg members and a number of people from other organisations too; the notes are: https://hackmd.io/4h6nxmDLRgGn6CDhIobPeQ
<therealprof[m]>
Hah, I haven't even had time to check and add to the notes.
<adamgreig[m]>
me neither, getting back has been a whirlwind
<adamgreig[m]>
and I'm also 50% trying to remotely help a plumber try to understand a toilet fitting at my house, heh
<adamgreig[m]>
so, let me try to summarise the main outcomes from the unconf
<adamgreig[m]>
1) there is good interest in working with various silicon vendors to help continue to advance some level of standardisation, including things like the hal traits, and maybe a more concrete idea of what "support" could look like (eg ensuring they have a good svd / a contact point for rust support in the org / a good pac+hal / BSPs and examples / ...), but it's not obvious to many people how to really get involved and we perhaps have
<adamgreig[m]>
something of a discoverability issue (the blank website and very long github readme probably don't help here)
<adamgreig[m]>
2) we want to continue working on updating our documentation; not only things like the discovery book and perhaps continue the revamp onto the embedded book / nomicon but also things like the website
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol>
For reference, here is what oreboot demands from silicon vendors:
<adamgreig[m]>
3) the Rust Society plan continues to develop and while no decisions have been made it continues to seem likely the wg will eventually be placed outside of the rust project and perhaps inside of a new organisation where several such working groups and other groups could belong; there was talk of having the rust project officially bless/accredit some groups as being in some sense "official", i.e. say "this is the official embedded
<adamgreig[m]>
wg and we stand by what they say should be done for embedded [e.g. use the e-h traits]", and thus also point to us from websites and so forth so that we maintain a similar level of "officialness" while outside the project, which might also continue to allow funding from the foundation etc
<adamgreig[m]>
3b) we also talked about restructuring the wg a bit. I feel like right now there's a lot of people who are interested in joining but the jump currently is from "outside" to "team member with release access on crates.io", and we don't manage the transition very well, so there was some discussion of rewriting our processes/charter to allow a general membership and then later people having access to maintain crates, perhaps based on
<adamgreig[m]>
some templates that are available for setting up this sort of group
<adamgreig[m]>
hmm, and a few smaller points too
<adamgreig[m]>
4) we clarified that DMA is fine to treat as shared memory with some other thread and normal fences and suitable mmio access should be fine for synchronisation
<adamgreig[m]>
5) it sounds like read_volatile and write_volatile will change their guarantees to ones that are useful to us wrt always emitting a certain instruction on supported sizes and being guaranteed to synchronise with atomics too
<adamgreig[m]>
which will probably make them suitable for use with mmio without new read_mmio or write_mmio methods
<adamgreig[m]>
I think that's the general recap! I plan to start thinking about this restructuring thing in a bit more detail soon and will write up an rfc for it
<adamgreig[m]>
though it's in some sense separate to the rust-soc stuff and could happen before
<adamgreig[m]>
other than that, I don't think I have any announcements. rustweek was an excellent conference and I encourage people to attend next year too :)
<therealprof[m]>
It sure was a ton of fun, including the excellent locations. Next year should be happening in the same place.
<DanielakaCyReVol>
I really struggled to understand that rust-soc is meant to mean Rust Society, not Rust System-on-Chip... 😅
<kevlan[m]>
Having a starting point to send vendors to would be great. We are usually talking to FAEs and field sales folks that don't have a huge amount of technical expertise on the programming side so being able to have something that is targeted more to the manager types would be very helpful for those conversations.
<adamgreig[m]>
yep, exactly. we don't really have anything to send anyone at the moment
<jannic[m]>
There are several other PRs in the embedonomicon repo that were already approved but not merged, probably due to the pipeline failures.
<therealprof[m]>
therealprof[m]: On that note. bartmassey proposed to create and run a script on the discovery book repo to close all issues/PRs against the old discovery book.
<adamgreig[m]>
jannic[m]: ah yea, I guess they will need rebasing as we don't have ghmq on for those. unless...
<adamgreig[m]>
let's see how that goes
<therealprof[m]>
Gotta go...
<adamgreig[m]>
yep, me too, still recovering from rustweek! i'll try and get some more material together for next week, see you all!
<JamesMunns[m]>
Oh no, traveling and got my time zones wrong, hope everyone has a good week!
<DanielakaCyReVol>
No time for me to recover, as I am on my way to IWP9. :D Rust Week was awesome. Have a good week y'all! \o/
<Max[m]>
<Noah[m]> "Oki" <- anyway i can help?
limpkin has quit [Quit: No Ping reply in 180 seconds.]
limpkin has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
So, back to STM32 for the disco book now that nrf-HAL is unmaintained?
<firefrommoonligh>
<therealprof[m]> "On that note. bartmassey..." <- What's the status on the book? I was tracking that it was originally on stm32 F3 (How I learned). Moved to Microbit/nrf. Now that lib's unmaintained and no obvious path to that changing.
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
jsolano has quit [Quit: leaving]
jsolano has joined #rust-embedded
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
firefrommoonlight: Not sure I understand the question. The new book is micro:bit v2 only. The `microbit` crate is being maintained again for now. We might move to the Embassy crate at some point, but I'm in no real hurry right now.
<Noah[m]>
<Max[m]> "anyway i can help?" <- Somehow it decodes the ROMtable wrong. I am not sure yet why, but we have to dig in the PR that is the first bad one.
<Noah[m]>
Noah[m]: I don't have a board with me to test, but I will see if I can spot it.
<Mathias[m]>
<kevlan[m]> "Having a starting point to..." <- The interest in Rust is probably currently filtered out because requests end up being handled by different people. We want to encourage vendors to have a point of contact that can be looped in by sales/FAEs and would increase the visibility on the demand.
<firefrommoonligh>
I'm seeing it based on an unmainted lib
<firefrommoonligh>
I'm all for stable libs that don't need updates, but I do not think that's what's going on here.
<bartmassey[m]>
firefrommoonlight: As far as I know, both nrf52833-hal and microbit-v2 are currently in decent shape, and myself and others are trying to keep them there. Are there specific maintenance issues you are concerned about? Or am I still missing something?
<firefrommoonligh>
<bartmassey[m]> "firefrommoonlight: As far as I..." <- No; I'm all about stable software that works as is
<firefrommoonligh>
But I wasn't sure if that was the case here. Was about to start a proj with it, but remembered that the BLE might not be straightfoward without nRF Connect
<firefrommoonligh>
If it's stable and fine, I'm fine with that
<bartmassey[m]>
Honestly, for BLE I'd look at Embassy's TrouBLE, which is a well-supported and nice solution.
<firefrommoonligh>
I remember the HAL being in good shape around the time of the latest release in 2022; I used it then and it worked well. There were some API oddities like the timer module not really being built. (THin PAC wrapper), but that's patchable in firmware by adding a high level timer module
<firefrommoonligh>
(The BLE and ceullar thing is on Nordic; may not be fixable here)
<firefrommoonligh>
*I think I also patched the GPIO to be easier to use without typestates, but that's a matter of taste
<dirbaio[m]>
cellular can be done without blobs in the application core
<dirbaio[m]>
for BLE you can either use
<dirbaio[m]>
- the old "softdevice" blob + the nrf-softdevice crate. works well, fully certified, in "maintenance mode" by nordic
<dirbaio[m]>
- the new "softdevice controller" + nrf-sdc crate + the trouble-host BLE stack. In theory it needs trouble to get certified if you want to ship it in a commercial product.
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]>
we have trouble built into the BSP here with examples https://github.com/lulf/microbit-bsp I'm actively working on adding bits this week.