<kentborg[m]>
I have an I2C bus with multiple devices on it, doing different, unrelated things. I need to occasionally physically turn off the bus to save energy, turn it back on, off again, etc. These different devices need their own initialization after power up, and need to do come cleanup and saving before power down.
<kentborg[m]>
What is the best way to do this? Is there something like shared-bus that also manages power coming and going, or should I wrap my own stuff around shared-bus (or around my own mutex)?
<kentborg[m]>
s/come/some/
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer_ has joined #rust-embedded
sroemer has quit [Ping timeout: 276 seconds]
pcs38 has joined #rust-embedded
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
For the rework of `rust-embedded/rust-raspberrypi-OS-tutorial` that Philipp Oppermann and I are working on, we've gotten to the chapter where OpenOCD. Has anyone gotten JTAG to work on the Raspberry Pi Zero 2 W? I spent a bunch of hours on it and failed. Today I took it over to my friend Keith Packard's house, and we spent some more hours on it and failed again.
<bartmassey[m]>
Any advice, leads, etc are greatly appreciated.
M9names[m] has joined #rust-embedded
<M9names[m]>
i hear the raspberry pi folks are pretty good with raspberry pi hardware, and are generally quite helpful with community projects.
<M9names[m]>
have you asked them?
BentoMon has quit [Ping timeout: 272 seconds]
<bartmassey[m]>
Not yet, but I will. Thanks!
<bartmassey[m]>
I guess just the Forums? Or is there somewhere else to look?
<M9names[m]>
forums would be a good place to start
<RobinMueller[m]>
@halfbit:matrix.org: Okay, I can confirm that my no-op app is working :) A first step. Serial printout, LED blinking and VS Code setup next..
<thejpster[m]>
I need someone with admin rights on rust-embedded/cortex-r. I tried pushing to main, and it worked! But the main branch is still called master. And I can't push to master because you have branch protection enabled.
<thejpster[m]>
Please can adamgreig or James Munns give me permissions to fix this? I volunteer to join your empty Cortex-R team if that's what I need to do. Jorge will join too.
<thejpster[m]>
‘
<adamgreig[m]>
want me to change the main branch to main?
<thejpster[m]>
if you do, I will not longer be able to push to it due to branch protections
<thejpster[m]>
but yes, main branches should be called main in 2025
<adamgreig[m]>
I don't think changing the main branch name actually renames branch protection rules
<adamgreig[m]>
but in any event I've changed it to main, removed push protection for now (it's still only applying to master though), and added you to cortex-r which lets you change those settings too
<thejpster[m]>
I think it depends on whether the rule is for a named branch or the 'main' branch? github is weird.
<thejpster[m]>
thank you
<adamgreig[m]>
no problem! i had intended for you to do the force push from the start which is why you had access to the repo but I didn't notice the branch protection was still enabled and would stop it, sorry
<thejpster[m]>
my remaining issue is the squatting on the cortex-r crate which crates.io haven't resolved yet
<JamesMunns[m]>
We aren't but it's possible some repos haven't been updated to github merge queues yet
<dirbaio[m]>
bors has been dead for a while yep
<JamesMunns[m]>
Unrelated, do any of the [Yalantis](https://yalantis.com/) folks hang out here? I saw they have a booth advertising Rust services at Embedded World.
<JamesMunns[m]>
(or does anyone know who they are?)
BentoMon has joined #rust-embedded
<thejpster[m]>
No idea
<JamesMunns[m]>
If there's anyone else with a booth there who works in Rust (and your booth page doesn't already mention Rust), let me know! I'm putting together an "Embedded World 2025 Rustacean Guide" blog post today, happy to add anyone I missed :)
<thejpster[m]>
> KDAB has grown a close partnership with the Rust experts Ferrous Systems. Together, the two companies provide market-leading knowledge and support ain all aspects of software development using Rust.
<thejpster[m]>
It's no accident our stands are co-located.
berkus[m] has joined #rust-embedded
<berkus[m]>
Are they riiring kde? :)
<thejpster[m]>
no, but Slint are RIIR'ing Qt.
<thejpster[m]>
who are also in the same corner of the same hall.
<thejpster[m]>
Everyone doing Android is also doing Rust too.
<berkus[m]>
<thejpster[m]> "no, but Slint are RIIR'ing Qt." <- They even got the same shitty license!
<thejpster[m]>
What's 'shitty' about it?
<berkus[m]>
the GPL
<berkus[m]>
i understand they want money
<berkus[m]>
but meh
<dirbaio[m]>
people are free to release their stuff under whatever license, you're free to use it or not depending on whether the license suits your use case
<dirbaio[m]>
you're not entitled to other people's work for free
<dirbaio[m]>
s/stuff/work/
<dirbaio[m]>
calling it "shitty" is a bit rude
<berkus[m]>
Yes, so why are you so triggered by me not liking the license?
<berkus[m]>
It's fine for you, enjoy, not fine for me, I use something else.
<dirbaio[m]>
not liking it therefore not using it -> fine
<dirbaio[m]>
calling it shitty -> not fine
<berkus[m]>
Shitty for me - happy?
<dirbaio[m]>
¯\_(ツ)_/¯ still rude
<berkus[m]>
Fine
<berkus[m]>
I like how we're entering the level of civilization where expressing your opinion is explicitly forbidden. That'll drive us to the heights of development, EVERYBODY AGREE.
<thejpster[m]>
are you sure your stack pointers are OK?
<RobinMueller[m]>
I'm investigating that
<thejpster[m]>
I wonder if in a basic function you're SUB SP, 16 but never writing anything to the stack so you don't notice that the pointer is bad. But the debugger notices.
<thejpster[m]>
you should be able to expand the `> Registers` panel in Cortex-Debug. Note that every CPU mode has its own stack pointer (I think there's eight CPU modes or something?), but the stack pointer for the current mode should just be in the SP register.
<JamesMunns[m]>
<berkus[m]> "I like how we're entering the..." <- Nobody is getting banned, you can say you think a license sucks, other people can say they think that's rude. That's just people sharing opinions?
<RobinMueller[m]>
thejpster: Hmm.. for the stack routine specifically, I've used your implementation. I have tried to use the one provided by Xilinx, I had to adapt it becausee of linker script differences.. Same odd behaviour
<RobinMueller[m]>
I have checked CPSR. It seems to be in SYS mode
<thejpster[m]>
what's SP? And where is that in relation to your RAM?
<thejpster[m]>
any thoughts on cortex-r-a as a name, vs cortex-ar? For a library that is to Armv7-A, Armv7-R, Armv8-R AArch32 and Armv8-A AArch32, as cortex-m is to Armv7-M, Armv7E-M and Armv8-M
<thejpster[m]>
* question for the group - any thoughts on cortex-r-a as a name, vs cortex-ar? For a library that is to Armv7-A, Armv7-R, Armv8-R AArch32 and Armv8-A AArch32, as cortex-m is to Armv7-M, Armv7E-M and Armv8-M
<RobinMueller[m]>
I have set 256MB of RAM right now, origin at 0x10_0000. SP is 0x100fd3d0 at the start of boot_core and 0x100fd3c8 at the start of main called by boot_core
<thejpster[m]>
Do you need to program the MMU to get a flat mapping from virtual to physical memory? I assume it boots with some amount of memory mapped (otherwise how would it run the boot code) but I don't know how much.
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
<RobinMueller[m]>
yes, a flat map via a static translation table.. But if the MMU config was problematic, I would expect exceptions or other issues where no code is able to run at all?
<JamesMunns[m]>
I know that sometimes single stepping ing GDB can mess with exceptions from firing, where single stepping works but if you run to a breakpoint one or two lines later, it'll actually fire the exception
<JamesMunns[m]>
As for function calls, are you running thumb or arm instructions?
<RobinMueller[m]>
James Munns: I did not specify special compiler flags, so it should be ARM
<RobinMueller[m]>
if that is the default
<RobinMueller[m]>
hm
<JamesMunns[m]>
Depending on which, you might need to jump with the correct mode switch, and then if it is thumb, you need to make sure the lowest function bit is set
<JamesMunns[m]>
Not sure what the defaults are for A/R bare metal targets
<JamesMunns[m]>
(but the fact that it's only messing up on a function call does make suspicious of required stack alignment, and ISA mode things)
<RobinMueller[m]>
The instruction set can be read from the CPSR well actually. It is 0, so ARM state is used
<JamesMunns[m]>
does the assembly seem to make sense for that then?
<RobinMueller[m]>
James Munns: phew, I guess i have to dump the elf as assembly for that. never done that before, but I can check it
<thejpster[m]>
cargo install cargo-binutils will give you rust-objdump and cargo objdump.
<RobinMueller[m]>
James Munns: `llvm-objdump-19 -dS target/armv7a-none-eabihf/debug/zedboard-blinky-rs > assembly.txt` did the job. reading assembly is hard :D
<JamesMunns[m]>
I guess mostly look at the function call, to see if anything is funky, and verify that it is in fact arm code and not thumb code being generated
<thejpster[m]>
the clue will be the instructions taking 8 hex digits :)
<berkus[m]>
<thejpster[m]> "any thoughts on cortex-r-a..." <- Cortex-ROAR?
<berkus[m]>
Cortex-REARM
<JamesMunns[m]>
if you pass -C btw it'll un-mangle the names
<berkus[m]>
>100110: e24dd030 subsp, sp, #48
<berkus[m]>
is sp correct upon entering boot_core?
<berkus[m]>
it is not yet set usually at this point
<JamesMunns[m]>
oh
<berkus[m]>
<RobinMueller[m]> "ohnooo.png" <- this looks like why gdb is stalling - it tries to loop potentially endless number of stack frames, and that takes a while
<JamesMunns[m]>
is your main() getting compiled out because there's no side effects?
<JamesMunns[m]>
good, any linker shenanigans were always spooky unsafe :D
<adamgreig[m]>
nice to finally see a lot of these horribly unsafe constructs get more attention
<adamgreig[m]>
will be a fun pain for cortex-m-rt and such though. thank goodness the edition system works really well
<JamesMunns[m]>
#![unsafe] when? (/s)
<adamgreig[m]>
...sudden moment of doubt that code generated by a 2021 edition proc macro will get the host crate's 2025 edition checks but i think not
<adamgreig[m]>
s/2025/2024/
<RobinMueller[m]>
hmm.. so the main function itself needs to be no_mangle too.. I guess if I want users to be able to simply write a main method, I need to provide an attribute macro similar to cortex-m?
<RobinMueller[m]>
(simply write a main method without unsafe attributes)
<diondokter[m]>
adamgreig[m]: Yeah macros are just copy paste from the output of the macro
<adamgreig[m]>
so they do get checked with the new edition?
<diondokter[m]>
I would think so yeah
<berkus[m]>
adamgreig[m]: they have a _2021 versions
<berkus[m]>
if something's changed
<diondokter[m]>
That's input for macro_rules! expressions
<JamesMunns[m]>
RobinMueller[m]: main isn't usually necessarily a special thing. the actual thing is usually the "entrypoint", which for you is boot_core.
<JamesMunns[m]>
I think marking the function as publicly visible with export name is just affecting optimization.
<JamesMunns[m]>
main is just convention for "we've set up all the expectations of the platform, like copying initializers, zeroing bss, etc."
<JamesMunns[m]>
s/./., normal programming starts here/
<adamgreig[m]>
it looked like the assembly had some other main that just returned
<adamgreig[m]>
i dunno what the context or environment here is
<JamesMunns[m]>
adamgreig[m]: I think I was wrong, it was calling some other function that wasn't shown in the shared disassembly
<adamgreig[m]>
aah, ok
<JamesMunns[m]>
(I messed up LR -> PC and PC -> LR)
<adamgreig[m]>
having it no_mangle should mostly just make it clearer where your main has actually ended up, but annoying if it fixes a miscompilation
<adamgreig[m]>
diondokter[m]: I thought rust handled this and it seems it does
<diondokter[m]>
Really? Then it's a lot smarter than I thought
<adamgreig[m]>
I can't have #[no_mangle] in my source, but I can use cortex-m-rt's entry/interrupt macro, which expands to an export_name
<diondokter[m]>
Interesting... That's very good!
<thejpster[m]>
yeah we haven't added that macro to cortex-r-rt or cortex-a-rt --- yet
<thejpster[m]>
I guess we could.
<adamgreig[m]>
yea, it knows which code is being generated by earlier edition macros and checks them against the respective edition, otherwise it would break upgrading if your macros generated broken code, and there'd be no way to fix it retrospectively either
<adamgreig[m]>
we could make c-m-rt emit unsafe(export_name), but then it wouldn't build on earlier editions
<adamgreig[m]>
so, phew
<realroot[m]1>
having device.clock.sìget() that returns a PrimitiveDateTime how can i check if i can remove 1 hour or minute without getting before the epoch?
<adamgreig[m]>
the options like nomem, nostack, preserves_flags allow the compiler to do a little more optimisation
<adamgreig[m]>
without nomem it has to assume the asm block might have read/write any memory, so must reload all registers holding memory and such
<adamgreig[m]>
without nostack the asm might have pushed/popped the stack so again it has to account for that, and without preserves_flags the asm might have done some status-setting operation so the compiler needs to not rely on those flags around the asm
<adamgreig[m]>
it's always safe but conservative to leave them off (unlike most c compiler asms where you add clobbers and if you forget then the compiler assumes no clobbering...)
<adamgreig[m]>
but adding them lets the optimiser do a bit more
<thejpster[m]>
I should add them.
<thejpster[m]>
Robin Mueller: does your platform support semihosting for debug output? Or arm-dcc?
<RobinMueller[m]>
okay. There are also barriers around dsb and isb, maybe those could be added as well?
<thejpster[m]>
I found them invaluable when debugging the cortex-r stuff.
<thejpster[m]>
yes I should add the compiler fences to the processor fence function functions. No point having the compiler re-ordering across a point where you're telling the processor not to re-order execution.
<RobinMueller[m]>
thejpster: that would've been the next thing I would have looked at. I have never used arm-dcc, I have to check the zynq datasheet. I think using the UART for printouts Is quite common for the zynq7000, the zedboard has a dedicated USB output for serial printouts. But i also see no reason why Segger RTT shouldn't work. A colleague of mine used coresight, which I also have never used.
<thejpster[m]>
yeah but for UART you have to bring up the clocks to the UART peripheral and do pin configuration. If you can do RTT with your debug interface, then that's a good choice.
<thejpster[m]>
arm-dcc using CP15 registers to transfer data into the debug probe. Your debugger needs to support the protocol. But it's wicked fast (compared to semihosting) and doesn't require the host to poll memory (as it does with RTT).
<thejpster[m]>
s/using/uses/
<JamesMunns[m]>
Is it on an external interface like ITM? Or still over JTAG?
<RobinMueller[m]>
thejpster: does gdb-multiarch support it?
<thejpster[m]>
it would be your GDBserver that implements it. Is that OpenOCD for you?
<RobinMueller[m]>
thejpster: oh, that would be the xilinx hw_server app
<RobinMueller[m]>
thejpster: I have no idea what it used internally
<thejpster[m]>
Goes over JTAG apparently
<thejpster[m]>
I was all set to write a crate, but Jorge beat me to it ... by several years.
<thejpster[m]>
Story of my life.
<RobinMueller[m]>
thejpster: getting any xilinx documentation again proves to be very hard. There is one forum post which mentions that HW server provides a GDB server implementation for each architecture. Other than that, I have not found anything 😅
<RobinMueller[m]>
for the zeboard specically, I think UART is also popular because it is also the common way when working with the Linux ecosystem
<RobinMueller[m]>
* common way to debug/get information when working
<RobinMueller[m]>
People have used OpenOCD for the zedboard though, so that might be an option to use arm-dcc?
<RobinMueller[m]>
* People have used OpenOCD for the Zynq7000 though and there is a configuration file in the sources, so that might be an option to use arm-dcc?
<thejpster[m]>
You can just try target_request debugmsgs charmsg though and see what happens
pcs38 has quit [Quit: leaving]
<RobinMueller[m]>
thejpster: Is that an option for starting OpenOCD? I heard that OpenOCD can now handle RTT, so that might be interesting as well.
<RobinMueller[m]>
thejpster: by the way, I have a question about stack initialization: The Xilinx boot code does not mask the interrupts from what I can see. You have done masking for all modes except ABT und UND mode. I now wonder what the best option is.
<RobinMueller[m]>
* thejpster: by the way, I have a question about processor mode configuration:The Xilinx boot code does not mask the interrupts for the various processor modes from what I can see. You have done masking for all modes except ABT und UND mode. I now wonder what the best option is.
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
congrats!
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
hpux735[m] has quit [Quit: Idle timeout reached: 172800s]
rafael[m] has joined #rust-embedded
<rafael[m]>
I am looking at maybe using this driver here: https://github.com/copterust/mpu9250. Alas, this is based on embedded-hal 0.2.3. I found the compat thing but that is for 0.2.4 onwards and also sounds a little like it may not be smooth. Is it a very complex undertaking to update from e-h-2.3 to 1.0?
<diondokter[m]>
<rafael[m]> "I am looking at maybe using this..." <- eh0.2.3 is compatible with eh0.2.7, so you should be able to use the compat layer just fine
<diondokter[m]>
But from the looks of it, updating to eh1.0 should be relatively straightforward
<rafael[m]>
i will give it a shot, gonna have a few days off soon and need a toy project
jr-oss_ has quit [Ping timeout: 252 seconds]
jr-oss has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]>
thejpster, Urhengulas: The need for [CBOR output in defmt](https://github.com/knurling-rs/defmt/pull/916) is coming closer to Ariel's showcase examples recently -- is this something that we could work together to find a timeline for? It's fine if not, I'll find workarounds, but it'd be helpful to know if we should "settle in" with them or whether it's just a matter of deciding when to click which button.
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #rust-embedded
Foxyloxy has joined #rust-embedded
pcs38 has quit [Quit: leaving]
<thejpster[m]>
Someone wants to change the Format trait in a way that might make sense but that can only happen at the 1.0 release. So we have to tie that to before 1.0 comes out. I think you change requires a Wire Format change so I wanted to do it after. However it’s not impossible to do them the other way around.
<thejpster[m]>
Is your need commercial? If so please email us.
<bartmassey[m]>
9names: Thanks very very much for the excellent hints on JTAG with Pi! I'm working on it again today, and will let you know when I figure anything out.