<sajattack[m]>
I'm trying to figure out how to do 8-bit writes to the pins (using PAC ports was my strategy) but then I also need a uart which takes pins from the pins struct with owns all the ports :/
<sajattack[m]>
s/with/which/
<sajattack[m]>
alternatively, did anyone ever end up writing a crate for arbitrary ports made up of embedded-hal pins?
<sajattack[m]>
I could probably hack something up using embedded-hal pins and bitops if I had to. Just feels like I'm missing something
<sajattack[m]>
* missing something obvious
<sajattack[m]>
is this what the steal is for?
VaradShinde[m] has joined #rust-embedded
<VaradShinde[m]>
Hi , i stimbled accross this room lookiing for a flash solution for my IMXRt1064 board, i am trying to run a debug code in which i am using the rtt_target to print hello world program, i have so far managed to flash the code using cargo embed with this message
<VaradShinde[m]>
is there a possibility that my flash program is failing because probe-rs cannot fetch it
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
SiHo[m]1 has quit [Quit: Idle timeout reached: 172800s]
xorio42[m] has quit [Quit: Idle timeout reached: 172800s]
AdinAck[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
andodeki2[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has joined #rust-embedded
<Noah[m]>
Feels like when we reset the chip the probe also vanishes for whatever reason 🤔
<Noah[m]>
This error happens when we cannot find a debug probe for flashing. So that means that your USB device is not reachable after flashing anymore for unknown reasons.
<VaradShinde[m]>
I can confirm that when i use MCUXpresso IDE to flash my equivalent C program it does that with no issues and the program works fine so i am pretty sure the USB device should be fien for this as well
<M9names[m]>
<sajattack[m]> "what's the room for avr-hal?" <- avr-rust/Lobby
BenoitLIETAER[m] has joined #rust-embedded
<BenoitLIETAER[m]>
Is there an Embassy (embedded) Rust roadmap for Microchip atsamx7x support ? 🤔
<BenoitLIETAER[m]>
(Not really into ESP and ST32....)
<JamesMunns[m]>
<BenoitLIETAER[m]> "Is there an Embassy (embedded..." <- > <@blietaer:matrix.org> Is there an Embassy (embedded) Rust roadmap for Microchip atsamx7x support ? 🤔
<JamesMunns[m]>
> (Not really into ESP and ST32....)
<JamesMunns[m]>
I think I've heard of some folks interested in ATSAM support in embassy, but I don't know of anyone actively working on it right now. You might be interested in #embassy-rs:matrix.org
<JamesMunns[m]>
But in general, most HAL support isn't something that is planned out or roadmapped, it comes down to whether someone is interested enough to add support :)
mkj[m] has joined #rust-embedded
<mkj[m]>
someone had some work-in-progress recently https://matrix.to/#/!YoLPkieCYHGzdjUhOK:matrix.org/$o_5b1c6AaLwequl_c4vgVRKiYtGv1xrievxXFfwjkBE?via=matrix.org&via=tchncs.de&via=mozilla.org
<BenoitLIETAER[m]>
JamesMunns[m]: Wow James himself ! 😅
<BenoitLIETAER[m]>
OK, understood and agreed.
<mkj[m]>
oh, not 7x
<BenoitLIETAER[m]>
Ah yes thanks, but I see an atsamd-rs room, might monitor it anyway
<omniscient_[m]>
We use EFM32 at work which also lacks support, so I'm vaguely interested in working on that. I've seen there are PACs but the HAL crates on GitHub are pretty barebones and not updated
siho[m] has joined #rust-embedded
<siho[m]>
omniscient_[m]: Are you talking about making HALs that are functional or embassy support?
<siho[m]>
omniscient_[m]: Forgot to make it a thread , but I would be interested in collaberating on adding support for EFM32/EFR32.
<omniscient_[m]>
both probably
<siho[m]>
SiHo[m]: Like HALs, but I'm not too interested in adding embassy support :D but I guess that's mostly timer and HAL integration right?
<siho[m]>
SiHo[m]: Currently working on making a HAL for the EFR32MG
<omniscient_[m]>
Well massive disclaimer, I am new to both embedded and embassy, but as far as I'm aware embassy-nrf wraps the underlying sync nrf HAL crate, so it would be possible to do the same I guess
<omniscient_[m]>
Plz correct me if I am wrong.
<dirbaio[m]>
> embassy-nrf wraps the underlying sync nrf HAL crate
<dirbaio[m]>
no it does not
<omniscient_[m]>
:zipp
<omniscient_[m]>
* 🤐 Thanks for correcting me. I thought I saw that when I was browsing the source last night, sorry/
<BenoitLIETAER[m]>
I'll probably have to move from 'vaguely' interested to 'committed' to contribute to SAM RH707/RH71 support, in this order: probe-rs, pac, atsamx7x-rshal and thus/then RTIC`.
<siho[m]>
SiHo[m]: I hope to be able to group it like the `nrf-rs` organization with some `nrf-common` style.
<BenoitLIETAER[m]>
(already tried and pushed couple of related PRs)
<JamesMunns[m]>
(we were at 675 responses on Saturday morning, I'll get an updated count before the meeting tomorrow! Thank you to everyone who has already taken the time to respond!)
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
dav1d has quit [Ping timeout: 252 seconds]
<JamesMunns[m]>
<JamesMunns[m]> "(we were at 675 responses on..." <- Update: 828 responses right now, would be very cool to hit 1k before the meeting :)
<adamhott[m]>
<JamesMunns[m]> "Update: 828 responses right now,..." <- Awesome!
<VaradShinde[m]>
<JamesMunns[m]> "Varad Shinde you might want to..." <- Sorry missed this thanks for the head sup
cinemaSundays has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
What's the best way to get the start and size of a custom link-section at runtime ?
<JamesMunns[m]>
I prefer using #[link_section] on a static, rather than any linker hacks
<AlexandrosLiarok>
yea same. I need to setup the MPU cache regions
<AlexandrosLiarok>
and I don't want to hard code the region sizes.
<JamesMunns[m]>
so:
<JamesMunns[m]>
* make a static, with something like a `GroundedArrayCell` from the `grounded` crate
<JamesMunns[m]>
* put it in it's own linker section
<JamesMunns[m]>
unfortunately, it does require you to manually size the static and the linker section, but this rarely changes
<JamesMunns[m]>
I think there's an example of this in the embassy faq, lemme check
<AlexandrosLiarok>
I could do it with the static address and sizes directly but due to region number restrictions I will probably need to do it once for the whole region.
<AlexandrosLiarok>
I /think/ I can do this by defining linker script vars and access them through extern, just wondering if I can do this in a better way.
<JamesMunns[m]>
I prefer doing it this way because otherwise the provenance gets... weird
<JamesMunns[m]>
the old way of using extern symbols and defining a single byte static as the start address is questionably sound - taking a pointer to a single byte only gives you provenance of that
<JamesMunns[m]>
while making a correctly sized + placed static makes it clear the provenance of the entire region
<AlexandrosLiarok>
I don't think the example is very relevant. I do use the statics with the link section as in the example. I now need to retrieve the total section size for using when configuring the MPU cache regions.
<JamesMunns[m]>
I think it is - you can get the address and len from the GroundedArrayCell, and use that when configuring the MPU region
<AlexandrosLiarok>
I have multiple such statics in different source files though
<AlexandrosLiarok>
I guess I /could/ put them in a common static.
<JamesMunns[m]>
or put them all in the same region and keep them as separate statics. But yeah, you could also make one big static region, and "tear off" parts to hand out to various drivers.
<AlexandrosLiarok>
Ideally I would configure the MPU cache regions for each static but it has size constraints (power of 2) and can configure limited number of regions. I use ~13 DMA statics currently and can only configure up to 8 regions.
<AlexandrosLiarok>
so Ideally I just want to configure my whole .dma_accessible region.
<AlexandrosLiarok>
but don't want to hard-code the address in the source code.
<JamesMunns[m]>
so, at least for configuring the MPU, it's probably more "fine" to get the addr and len through externs, but actually accessing the data is better done through statics
<AlexandrosLiarok>
* so Ideally I just want to configure my whole .dma_accessible ~~region~~ section.
<JamesMunns[m]>
so you COULD have 13 statics all in the same section, make the whole section non cached or whatever through the MPU, and do the access through the individual statics
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
for example, that's making sure the stack is 8 bytes aligned
cinemaSundays has quit [Quit: Connection closed for inactivity]
<AlexandrosLiarok>
is there a better way to configure the MPU ? cortex-m only provides u32 register access.
<JamesMunns[m]>
there's a cortex-mpu crate, but I think it's likely out of date and currently abandoned
<JamesMunns[m]>
might be a good starting place. If you are interested in maintaining it I think I still have contact with the owners
LucasChiesa[m] has joined #rust-embedded
<LucasChiesa[m]>
Hi! I have a question that was probably answered many times, but I am looking for a global allocator to use for an stm32l0. I found embedded-alloc and talc. Anyone here would like to share some tips regarding any of those packages? I am mostly worried about ROM size.
cr1901 has joined #rust-embedded
<LucasChiesa[m]>
<LucasChiesa[m]> "Hi! I have a question that was..." <- Those or any other global allocator to recommend :)
<JamesMunns[m]>
tbh those are the two I am aware of: embedded-alloc/linked-list-allocator is the typical choice, it is known "meh" for performance, but widely used and very simple. `talc` is much newer and is much smarter, but likely more complicated
<JamesMunns[m]>
I'd guess (with no data!) code size wise, e-a will do better, and if you are only allocating rarely, then it's likely to work well. If you are making a lot of small allocations very often, it might be worth it perf-wise to use talc (or another allocator)
AtleoS has joined #rust-embedded
konkers[m] has joined #rust-embedded
<konkers[m]>
Can anyone point me to an example of integrating <https://github.com/rust-embedded-community/tinyrlibc> into a project? I'm experimenting with wrapping MicroPython and would love an easier solution for libc than having the user bring their own. The naive approach of taking a cargo dependency on it did work for me.
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has joined #rust-embedded
<diondokter[m]>
<konkers[m]> "Can anyone point me to an..." <- The problem is that C has a global namespace. Bring two libc's and they will clash.
<diondokter[m]>
So when you have two crates as a dependency that each bring their own libc, you will not have a great time
<JamesMunns[m]>
is it complaining that the symbols aren't found?
<JamesMunns[m]>
you might need a use tinyrlibc as _; in your main to ensure that it is not culled as dead code
<dirbaio[m]>
they're saying it did work
<dirbaio[m]>
so i'm not sure what's the quesiton?
<dirbaio[m]>
s/quesiton?/question :D/
<JamesMunns[m]>
I'm guessing it was a typo for "didn't work" :p
<diondokter[m]>
dirbaio[m]: I think the question is, how to include libc in your code so that a user of the crate doesn't have to
<konkers[m]>
s/<//, s/>//, s/did/didn't/
<konkers[m]>
<JamesMunns[m]> "I'm guessing it was a typo for..." <- indeed :(
<konkers[m]>
<diondokter[m]> "I think the question is, how..." <- More generally link it in at all. There's no conflict w/ the platform libc (newlib/picolib) as those don't get included unless I specifically add those to the link path.
<konkers[m]>
I'll try the use tinyrlibc as _; when I get a chance (hobby project)
jduck[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
PedroFerreira[m] has quit [Quit: Idle timeout reached: 172800s]
<konkers[m]>
Thanks, I'll take a look. Any thoughts on adding header files to it?
<konkers[m]>
I'm not totally sure how the mechanics of that would work. Possibly a second lib crate that you could call from a build.rs to get a path to the libraries to pass to cc or bindgen.
<konkers[m]>
I suppose, since cc requires you to have a cross compiler (i.e. arm-none-eabi-gcc) installed, that'll probably come with a sysroot with headers.
<JamesMunns[m]>
stuff that's not supposed to have side effects got reordered?
<danielb[m]>
I hope it's just midnight programming and some banal thing I can't think of right now
<danielb[m]>
compiler antics, I really would like to not have
<danielb[m]>
like, the future clears an AtomicBool, interrupt handler sets it to true, poll is supposed to return Pending while the bool is false, but the debug print after the await prints false
<JamesMunns[m]>
does your future require being polled once before it installs a waiter
<JamesMunns[m]>
because if so that is a very common "oops"
<danielb[m]>
damn it
<JamesMunns[m]>
if the thing happens before you poll the first step at the await then your waker won't be installed