sajattack[m] has quit [Quit: Idle timeout reached: 172800s]
ShuntaroOhno[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
What's a good way to silect an unused warning when it doesn't apply for a target?
<AlexandrosLiarok>
eg I use `use num_traits::float::FloatCore as _`
<AlexandrosLiarok>
`
starblue has joined #rust-embedded
<thejpster[m]>
Where can I get an arm-none-eabi-gdb.exe for Windows that supports TUI (i.e. the layout split) command? The one provided by Arm in the GNU Embedded Toolchain for Arm does not :/
<adamgreig[m]>
Maybe you can get a gdb-multiarch?
M9names[m] has joined #rust-embedded
<M9names[m]>
yeah, i usually just use a mingw64 gdb-multiarch installed via msys2
<M9names[m]>
i guess all the other binary distribution options would work though? maybe it's on scoop
<M9names[m]>
or chocolatey
<thejpster[m]>
choco didn't have one and scoop's wasn't very useful (just gave me XML errors).
<thejpster[m]>
msys2's gdb-mutiarch seems to have TUI support, although it throws a lot of errors about missing symbols in the symtab
<thejpster[m]>
thanks for the suggestion! better than what i had before :)
ni has quit [Ping timeout: 248 seconds]
ni has joined #rust-embedded
<RobinMueller[m]>
<RobinMueller[m]> "thejpster: Thanks for the..." <- I think it is difficult/impossible to write a generic run-time cortex-a, at least one re-usable by the zynq, because that chip does chip specific things at boot time like restarting cpu1 and/or cache/mmu operations.. However, it might be possible to allow re-using assembler fragments for something like bss/data init or stack pointer initialization. maybe it is also an option
<RobinMueller[m]>
to have something like the _pre_init function used by cortex-m-rt?
<thejpster[m]>
cortex-r-rt has that kind of assembly shim, which I use on my actual Cortex-R52 based SoC to initalise the ECC engine
<RobinMueller[m]>
thejpster: something similar like _pre_init? or did you replace the whole _start method?
<thejpster[m]>
you provide a _start but you can call _default_start as part of it if you like
<thejpster[m]>
AFAIK, MPU initialise can be performed in Rust after main. The default MPU config must be enough to run the start-up code so it should enough to run the MPU init code.
<thejpster[m]>
Not sure about MMU config though. Never tried it.
<RobinMueller[m]>
thejpster: I think the order of operations might be problematic for re-using it.. the current order of operations in the xilinx boot code is: 1. for cpu0, go to nomal boot routine, restart cpu1 (zynq specific) 2. set VBAR vector table offset 3. Various cache and memory operations, disable MMU and SCU 4. stack setup 5. re-enable MMU, SCU, caches and all other kinds of stuff, including VFP, 6. branch to start
<RobinMueller[m]>
i don´t know if the order is strictly required, but zynq-rs did it similarly, so I would assume it is important
<RobinMueller[m]>
What about increasing re-usability of operations like stack init or bss zeroing / data init, at least for cortex-a ?.. that would make providing/writing an own chip specific boot routine easier at the very least
<thejpster[m]>
I don't feel like they really need to be re-usable components. They're only a few lines of assembly. If the standard runtime doesn't work I think you're better off just forking the start-up code.
zeenix[m] has joined #rust-embedded
<zeenix[m]>
Hi folks, I've rather general (and therefore likely silly) question: I'm writing a library that I want to be attractive for baremetal embedded targets. It's going to be no_std for sure but no_alloc is quite challenging. I'm wondering if it's even worth the trouble. Many modern microcontrollers have alloc available for them, right? I guess the question is how many potential users I'd be alienating if I don't support no_alloc.
<thejpster[m]>
zeenix: it's not hard to set up a heap, it's just most people don't need one, and not having some saves a bunch of worries about fragmentation and heap exhaustion. If your library really needs one, it's easy enough for people to add one.
<thejpster[m]>
But can it really not be done with static allocation? What does the library do?
<RobinMueller[m]>
thejpster: Okay.. I think I will just override the _start method completely in a separate zynq-rt crate, it's probalby the easiest way to re-use as much of the vendor supplied asm code as possible. I can still use the vector table part
<RobinMueller[m]>
thejpster: I also split up off the cortex-a-rt crate into a separate crate so changes/adjustments for one family in the future can not affect the other.. there is some duplication, but I think that's okay, right?
jasperw- has quit [Ping timeout: 252 seconds]
<zeenix[m]>
<thejpster[m]> "zeenix: it's not hard to set..." <- Thanks. It's a varlink implementation library so IPC/RPC. There are certain places where strings would be nice to have but with stack-based string (through heapless) you have to always specify the size and with alloc::string::String you don't, so it gets a bit complicated to abstract over the two. I guess I could just choose specific sizes and have some local abtractions over alloc
<zeenix[m]>
and heapless but I feel that "one show fits all" kind of approach will likely not work here
<zeenix[m]>
thejpster: sorry for the late response but I had back to back meetings and I didn't expect such a prompt response. :)
<JamesMunns[m]>
<thejpster[m]> "zeenix: it's not hard to set..." <- fwiw, I ended up doing the type punning we talked about @zeenix in postcard-rpc, so it's possible to safely swap between String, &str, and heapless::String, and I've found it works pretty well, though postcard-rpc's processing model is "immediate FIFO", so it's a bit easier to just fall back to &str when you only need ephemeral messages on the embedded side.
<JamesMunns[m]>
<thejpster[m]> "zeenix: it's not hard to set..." <- I agree with JP, any chip COULD do alloc, so it's more a question about how palatable that will be to users.
<JamesMunns[m]>
Interested to see what you're cooking up, would be neat to compare with postcard-rpc!
pcs38 has quit [Quit: leaving]
<zeenix[m]>
James Munns: Lennart is really pushing for moving from D-Bus to Varlink in the systemd space so there is a need for a good async Varlink API and that's my main goal here. I realized that there is nothing stopping me from also making it work for comms between a a host and an MC. So a part of it will be very similar to postcard-rpc in the sense that I aim to provide a USB-based transport and varlink is about providing an API. The main
<zeenix[m]>
diff is that the encoding is plain JSON. That of course means, that it won't be as efficient as p-rpc (although not as inefficient as one would think since modern processors are designed for handling parsing of data, and most messages are pretty small anyway since it's control data) but this also means that the RPC messages can themselves be the log as well, making debugging super easy/simple.
<JamesMunns[m]>
Interesting! I think JSON is definitely palatable on larger chips (rp2xxx, esp32), which are also likely chips to have enough RAM to spend on an allocator. I'll have to look into Varlink! I already do JSON-to-postcard bridging in poststation.rs, maybe I should look into making a varlink bridge for it as well.
<JamesMunns[m]>
How does varlink declare/discover schemas for JSON messages? or is it just "lol whatever"?
<JamesMunns[m]>
ah need, it has it's own IDL
<JamesMunns[m]>
s/need/neat/
<zeenix[m]>
James Munns: There is an IDL but it does not need to necessarily translate into anything on the Rust side and I'd like to keep it that way
<zeenix[m]>
frankly, the schema part is not something I learnt to appreach in p-rpc, although I understand your reasoning for it
<JamesMunns[m]>
yeah, I mean tho since poststation can already do translation, I could automatically match postcard schemas to varlink idl schemas, and do the translation automatically. Or present a varlink IDL based on the device's postcard schema.
<zeenix[m]>
in zbus, I had to have the similar Type trait but there there was no way out of that because of a few fundamental incompatibilities between serde and D-Bus
<JamesMunns[m]>
Yeah, I imagine I could automatically populate all the of the device's capabilities through the service interface: https://varlink.org/Service
<JamesMunns[m]>
so, you plug in a device, poststation figures out the schema, then presents a varlink service that matches that device, and varlink clients can query it and automatically send messages
<JamesMunns[m]>
I meant to look into this for dbus support as well, but if the world is moving to varlink, then maybe that's the move :D
<zeenix[m]>
yeah, sounds good actually
<zeenix[m]>
the only diff is that I already created a popular and stable crate for D-Bus but varlink doesn't have one yet :)
<zeenix[m]>
I wouldn't suggest using the current varlink crate. I don't even think you can use it for your purpose since that one is geared towards code generation from IDL at build-time (putting aside the non-maintained status and blocking-only API)
<JamesMunns[m]>
Good to know!
<zeenix[m]>
s/appreach/appreciate/
<dirbaio[m]>
Rust 1.85 and Edition 2024 is now out! 🥳
<danielb[m]>
I think I'm most excited for the rustfmt changes in 2024 :D
<diondokter[m]>
Very nice. Still kinda sad the Range changes didn't make it in. Could've removed a lot of clutter from sequential-storage
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
float::abs in const! Seems like such a small thing but boy that'll be nice.
pcs38 has joined #rust-embedded
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
kevlan[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
<thejpster[m]>
I wrote two MPU drivers today, because I was off sick and bored. I am quite liking the bitbybit crate with it's support for enums of arbitrary width (either exhaustive or non-exhaustive).
<thejpster[m]>
if you call Cpsr::new_from_raw_value(foo) and the mode field isn't valid, my_cpsr.mode() returns None
<thejpster[m]>
if I remove Option the macro shouts at me because ProcessorMode is not exhaustive.
<diondokter[m]>
That's sometimes what you want. But when you have something with like 12 reserved variants, you might want a catch-all to catch all of those
<thejpster[m]>
And the function `fn Cpsr::set_mode(&mut self, mode: ProcessorMode)` doesn't let you pass None in when setting it
<thejpster[m]>
So you want one enum variant Reserved which is selected for any N input values, but generates only one output value when picked?
<thejpster[m]>
that would make the round-trip lossy, right?
<diondokter[m]>
<thejpster[m]> "that would make the round-trip..." <- That would be with a 'default'. With a 'catch-all' it wouldn't be lossy because generally the catch-all is a variant which also carries the raw data
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
amusil[m] has joined #rust-embedded
<amusil[m]>
Hello, can someone please enlighten what am I doing wrong? I have ADC + DMA circular pointing to buffer singleton!(SAMPLE_BUFFER: [u16; 4] = [0; 4]), but the order of samples in the buffer is reversed. However the direction of ADC is from lower to higher, if I try to reverse the direction in ADC I'll get complete nonsense in the array, there is simply no logical order. Any idea what might be wrong?
<amusil[m]>
* Hello, can someone please enlighten me what am I doing wrong? I have ADC + DMA circular pointing to buffer singleton!(SAMPLE_BUFFER: [u16; 4] = [0; 4]), but the order of samples in the buffer is reversed. However the direction of ADC is from lower to higher, if I try to reverse the direction in ADC I'll get complete nonsense in the array, there is simply no logical order. Any idea what might be wrong?