<Jubilee[m]>
<Ralph[m]> "korken89: GH's dependabot just..." <- > <@rursprung:matrix.org> korken89: GH's dependabot just offered me to upgrade `panic-halt` to v1.0.0 - congrats on the major release! 🥳
<Jubilee[m]>
> i noticed however that on your repo you neither have a v1.0.0 tag nor a GH release for it (the latter can only be created if you have the former) - maybe you forgot to push the tag? i'd also suggest to create the GH release to make it more visible
<Jubilee[m]>
Well, when adding a release, you can simply name a branch and it will tag that.
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Ping timeout: 276 seconds]
sroemer has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<korken89[m]>
<Ralph[m]> "korken89: GH's dependabot just..." <- I generally don't do GH releases, but I can make one
<haobogu[m]>
Hello rustaceans! Has anyone succeed to use qspi flash + memory mapped mode in Rust? I managed to enable memory mapped mode for stm32h7 + w25q64, the first read is good, but when I read the same address again, the data becomes 0x88888... (full message at
<thejpster[m]>
top tip: if you implement a filesystem, use fsck on your disk images and it will tell you about (some of) the mistakes you made.
<thejpster[m]>
Like apparently FAT32 also uses 0 in a parent directory entry to point at the root directory. And it's important to also write to the second FAT. And volume labels are supposed to be written down twice.
<omani[m]>
anybody know of a good electronics group in matrix? for questions, etc. like electronics.stackexchange
therealprof[m] has joined #rust-embedded
<therealprof[m]>
<adamgreig[m]> "man, that would have saved me..." <- I used that all the time back in the day when I was experimenting with filesystems. 😅
<adamgreig[m]>
i just stared at the various fat "specs" until i spotted problems one at a time 😅
<adamgreig[m]>
ok, let's begin
<adamgreig[m]>
first off, welcome berkus to the wg and cortex-a team! we've already had a new aarch64-cpu release thanks to them!
<adamgreig[m]>
and, the first new discovery book sprint happened and a bunch of new material got written for an interrupts chapter, thanks to everyone who took part! the plan is to hopefully cover dma next time and then look at revamping the examples to use probably embassy's nrf hal
<adamgreig[m]>
any announcements from anyone else?
<adamgreig[m]>
cool, then let's move on to the agenda points, korken89 do you want to talk about the linker script symbols?
<korken89[m]>
Sure! It's mostly that I stumbled on a potential issue where our provided symbols don't allow for stable use of MSPLIM in thumbv8 as we don't have a "stable" symbol for "end of statically allocated memory"
<adamgreig[m]>
I'm not sure what the argument is for keeping all our symbols private, do we have any public symbols?
<adamgreig[m]>
things like _stack_start we say can be overridden by user linker scripts (ie memory.x) but we don't provide anything for "find the start of a section" or whatever
<korken89[m]>
There is a private symbol, but this seems like something anyone that uses thumbv8 would want to use?
<adamgreig[m]>
so either cortex-m-rt could gain a function that returns the location (and then that's the public interface, not the symbol) or we add a new symbol without underscores?
<adamgreig[m]>
I think c-m-rt could possibly have a const pub fn so it should be usable in most contexts
<korken89[m]>
That's the 2 possible solutions I have thought about :)
<korken89[m]>
Not sure if there are any dragons hiding in this though, our usecase is quite simple/naive
<adamgreig[m]>
it's not like there's much of a common standard for what the linker script "public interface" is
<adamgreig[m]>
like, it's only used because the end user has put -Tlink.x, they could just as well have put their own or anything else
<adamgreig[m]>
so we could also just say "yep you can use __euninit or whatever else you find in the linker script, we'll only break them in major releases of c-m-rt" or something
<korken89[m]>
What I think is the common practice to lean on is something that makes MSPLIM work like flip-link but in HW - which is what made use it (the MCU does weird stuff so we can't use flip-link). It might not be worth finding a "global solution" to this?
<adamgreig[m]>
so just add some methods to c-m?
<adamgreig[m]>
we're likely to have a c-m-rt release v soon so now's a good time to add some more symbols and/or consts if we want
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
i've also ran into this issue, "fixed" it by editing the linker script
<dirbaio[m]>
imo we shouldn't tell the user to use _enuinit, because then we'll break them if we add more sections after uninit
<korken89[m]>
Yeah, __euninit just happens to be at the right stop today
<korken89[m]>
s//`/, s//`/, s/stop/spot/
<adamgreig[m]>
sure, we could add something more specifically "end of static ram" or whatever
<dirbaio[m]>
it should be _stack_end
<dirbaio[m]>
and document that if the user overrides _stack_start they should also override _stack_end
<korken89[m]>
Makes sense, should be simple to uphold both from docs and usage perspective. And anyone that reads about modifying _stack_start knows about _stack_end.
<korken89[m]>
If it feels like an OK way forward I can make a tentative PR where the discussion can continue async :)
<adamgreig[m]>
sgtm
jannic[m] has joined #rust-embedded
<jannic[m]>
dirbaio[m]: Documentation is the key point here: People overriding the linker script need to know what invariants need to be kept. Doing that with trial & error is tedious and can cause subtle errors.
<adamgreig[m]>
and keep it as symbols that users have to do the extern "C" static bla bla dance with, or add some constants/methods to c-m-rt too?
<adamgreig[m]>
probably just symbols is fine for now. i think the cortex-m crate probably will struggle to use these things anyway for a "set msplim" method because you might not be using cortex-m-rt
<korken89[m]>
Yeah, I think a symbol is enough - we can always add more later if a common use-case arises :)
<adamgreig[m]>
cool. if you get that pr together i'll get it merged and we can release with the other recent c-m-rt updates
<korken89[m]>
Thank you all for the discussion, I have what I need to make progress 🚀
<adamgreig[m]>
the only thought i did manage to have is that we'd imagined the -pac crate being a peripheral access crate (ie register level access) for the common cortex-m cpu peripherals like nvic, systick, mpu etc
<adamgreig[m]>
but in riscv-pac it's more "traits that are used by PACs"
<jannic[m]>
We have some points from last week that we didn't have time for.
<adamgreig[m]>
I'd had "c-m-rt needs a release" which we've touched on, and the new svd2rust methods which got merged, was there anything else?
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
adamgreig[m]: Maybe cortex-m-pac can have a `peripheral` module for that
<adamgreig[m]>
romancardenas: we'd want them to be a separate crate so that the shared traits can be stable while the peripheral access changes more frequently
<romancardenas[m]>
In riscv we have the riscv-peripheral crate. Maybe cortex-m-peripheral?
<adamgreig[m]>
we could call it cortex-m-peripherals and cortex-m-pac, or cortex-m-pac-traits and cortex-m-pac
<adamgreig[m]>
ah yea, ok
<adamgreig[m]>
and then probably cortex-m-hal
AdinAck[m] has joined #rust-embedded
<AdinAck[m]>
adamgreig[m]: dirbaio's `yoink` was a strong candidate, but we ended up going with `from_write` 🥴
<adamgreig[m]>
from_write is nice, good thought
<jannic[m]>
adamgreig[m]: Typing on my phone right now so difficult to check. May indeed be the only point. I thought there were more but I'm not sure.
<adamgreig[m]>
romancardenas: anyway i'd like to keep it consistent with riscv so if you have riscv-peripheral and riscv-pac that seems like it could work fine. is -peripheral register-level access or more like a hal?
<romancardenas[m]>
`cortex-m`: low-level access to registers
<romancardenas[m]>
`cortex-m-pac`: traits and error enum to build the rest of the crates on top of
<romancardenas[m]>
`cortex-m-peripheral`: standard peripherals
<romancardenas[m]>
adamgreig[m]: It is kind of hal, I think. You can read registers but it provides high level abstractions to ease the programming
<romancardenas[m]>
It is between a PAC and a HAL. Indeed we have embedded-hal and embedded-hal-asyn impls
<romancardenas[m]>
burrbull[m]: This PR made me think: would we want svd2rust to re-export the preferred atomic interface for a given target?
<romancardenas[m]>
pac:atomic would be core::sync::atomic when possible or portable_atomic::atomic for atomicless chips
<romancardenas[m]>
So for weird targets such as Zaamo RISC-V we could configure portable-atomic accordingly at PAC level
<romancardenas[m]>
* This PR made me think: would we want svd2rust to re-export the preferred atomic interface for a given target?
<romancardenas[m]>
pac:atomic would be core::sync::atomic when possible or portable_atomic for atomicless chips
<JamesMunns[m]>
The opinion so far was "do it in the HAL"
<dirbaio[m]>
svd2rust already does too many things :D
<dirbaio[m]>
for example about the rp2xx atomic set/clear/xor aliases: are we going to add support to svd2rust for every possible atomic / bitbanding alias out there that vendors invent? :P
<romancardenas[m]>
If we rely on a pac::atomic thing, registers can have an as_atomic method that converts to the proper type, let it be real atomic or emulation
<romancardenas[m]>
And a crate such as portable-atomic would have all the muscle for ISA quirks
<adamgreig[m]>
treating all the mmio registers as atomic types seems a bit fraught lol
<dirbaio[m]>
I think HALs can extend the register API with blanket impls on the register type (at least they can with chiptool, not sure if the way svd2rust generates code allows that?)
<dirbaio[m]>
no modifications required to chiptool
<romancardenas[m]>
That is also possible with svd2rust, yep
<dirbaio[m]>
then imo I wouldn't add support to svd2rust itself for these things
<romancardenas[m]>
Ok, we just leave it to HALs to implement atomic operations when it applies, right?
<dirbaio[m]>
(it's just my opinion tho, and i'm not a svd2rust maintainer)
<burrbull[m]>
agreed. it is not breaking, so it can be added any day in future
<adamgreig[m]>
cool, anything else anyone wants to discuss today?
<JamesMunns[m]>
mini announcement: I'm doing a lot of work on postcard-rpc now, I expect to make a couple of breaking changes, but also make a lot of things nicer. Just a fair warning if anyone is thinking of upgrading RIGHT NOW (instead of in a week or two)
<JamesMunns[m]>
The biggest changes are done, but there will be a few technically breaking changes still.
<JamesMunns[m]>
Just a PSA :)
<adamgreig[m]>
👍️ thanks everyone!
<romancardenas[m]>
Thank you!
<JamesMunns[m]>
Thank you adamgreig !
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
<JamesMunns[m]> "mini announcement: I'm doing a..." <- I've been loosely following the progress and have indeed decided to wait until the major changes are in haha, thanks!
<JamesMunns[m]>
That being said, you can do VERY COOL new things now, like having borrowed req/resp types, types that are different on no_std/std (e.g. `&str` and `String`), etc:
<JamesMunns[m]>
And I have an arch diagram here: https://docs.rs/postcard-rpc/latest/postcard_rpc/ - that shows a bit about how postcard-rpc can hopefully work over a lot more transports than just USB, including radios (like lora) or i2c, since the interfaces are modular and I now can reduce the size of the headers substantially :)
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
<dirbaio[m]> "i've also ran into this issue..." <- there is an open issue for `riscv-rt` that you linked your solution to, but the issue seems to be stalled. do you know what we can do to get the issue unstuck?
<rmsyn[m]>
maybe I should add it to next week's discussion topics?
<dirbaio[m]>
I know almost zero about riscv sorry
<dirbaio[m]>
I guess to get it unstuck someone should try to find the root cause and then send a PR
<rmsyn[m]>
dirbaio[m]: alright, it's more about the linker scripts in this case, and you linked a solution that works. that's why I asked
<rmsyn[m]>
someone else in the issue seems to have a problem with how you solved the issue, but didn't supply any more information about why "it's not the way to go"
<rmsyn[m]>
dirbaio[m]: I can create a PR with a working linker script based on your fixes, was just asking if you had more insight about why someone might object to your approach
<rmsyn[m]>
my linker-fu is not as good as yours, or others with more experience in this community
<dirbaio[m]>
I dont' remember anymore, I'm prettysure I copied the solution from that issue or someone suggested it in matrix, I didn't get to understand the cause. just wanted embassy's CI to build...
<rmsyn[m]>
dirbaio[m]: same for me, I needed a fix for a board I'm working on. I guess I can just do some more research, open a PR, and let whatever critique may come
cinemaSundays has joined #rust-embedded
<Danilo[m]>
What's a good way to debounce GPIO inputs within an async codebase? With a classical interrupt-based codebase I'd poll an input periodically and would use https://docs.rs/debouncr/ for debouncing, but for async there might be different patterns.
<Danilo[m]>
(One option might be using embassy and scheduling an async task to poll the input. But maybe there are more elegant solutions.)