<vrakaslabs[m]>
- This is my first time around the block, is there anything I'm doing that is in poor taste, or better accomplished another way?
<vrakaslabs[m]>
- In the current implementation, the user instantiates the TX and RX descriptor tables, and then passes `&mut`'s of them to the device object. This is similar to the stm32-eth driver.
lightningwright has quit [Ping timeout: 255 seconds]
lightningwright has joined #rust-embedded
lightningwright_ has quit [Ping timeout: 264 seconds]
<askrodney[m]>
<JamesMunns[m]> "then yeah, maaaaybe the loop..." <- Thanks for the help James and dirbaio. I tried the loop idea and also, the LTO thing, but still seeing the same issue.
<askrodney[m]>
Will try to set up something on Linux to see if I get the same issue, and also try the Discovery book STM32F3 version. Please let know if you have any other ideas though, would be nice to update the book, for anyone else who runs into this.
<askrodney[m]>
* Please let me know if
GenTooMan has quit [Ping timeout: 260 seconds]
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
GenTooMan has joined #rust-embedded
Darius has joined #rust-embedded
Darius has quit [Ping timeout: 246 seconds]
Darius has joined #rust-embedded
sauce has joined #rust-embedded
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
<FreeKill[m]> "image.png" <- Okay this is now open and usable!
<FreeKill[m]>
It is limited at the moment (Windows only, until I work out console key input on Unix) but I'd love it it can help some folk!
<FreeKill[m]>
I would also be very interested how it actually looks on a rust binary... I expect the name mangling doesn't look great, but I can't test that myself at the mo
lightningwright has quit [Ping timeout: 264 seconds]
<JamesMunns[m]>
so like `b main`, do the assembly layout split, then look at what the instructions are inside of "main", and whether it looks reasonable or not.
mciantyre[m] has joined #rust-embedded
<mciantyre[m]>
<vrakaslabs[m]> "After many long distractions..." <- Well done. Do you plan to share your work under a FOSS license? I'd like to play around with your driver, but I don't see a license selection in the repo.
<mciantyre[m]>
mciantyre[m]: > How should I eventually try to package this code to make it useful within the ecosystem? How do we package config code that is both board and peripheral specific (pinmux in particular)
<mciantyre[m]>
I'm the teensy4-bsp maintainer. If you'd like to integrate pin muxing directly into the BSP, I accept PRs. I think these pins are unused, so there should be no harm in fixing their function.
<FreeKill[m]>
it's a little frustrating that the clang linker map doesnt contain memory region descriptions, so I have to link with gcc to get them... Wish there was a better approach
<JamesMunns[m]>
FreeKill[m]: Is there a reason you are using the linker map, rather than inspecting the elf itself, like `nm` does?
<FreeKill[m]>
The elf does not contain your memory regions
<FreeKill[m]>
IE your FLASH, SRAM1, DTCMRAM etc
<JamesMunns[m]>
It wont have the named sections, tho it will have text/bss/data segment names
<FreeKill[m]>
Yes, which is what's shown under the region headers in the tool :)
<FreeKill[m]>
But what I actually want to know day to day is "How much are my regions being used, and by what"
<FreeKill[m]>
Yeah but those are sections - there may be many in a given region
<JamesMunns[m]>
yup, totally fair!
<FreeKill[m]>
I wish it was in the elf, I hate that it's not
<FreeKill[m]>
I would like some way to specify them without a map file I think. You should also be able to provide your linker script(s), or maybe just a JSON file. Because being tied to the GCC map format is rubbish
<dirbaio[m]>
just write your own linker from scratch in Rust 🤪
<FreeKill[m]>
dirbaio[m]: That can't save me from IAR at work ;P
<askrodney[m]>
Thanks James, working on this still. Here is the split view:
<JamesMunns[m]>
If you call `si` for "step instruction", where does it land when the SIGINT happens?
<askrodney[m]>
0x162
<JamesMunns[m]>
It crashes on 162? or that's just the next step? if it doesn't crash, could you keep running si until it does?
<askrodney[m]>
crashes on 162: output Program received signal SIGINT, Interrupt.... src/main.rs:10
<JamesMunns[m]>
that seems extremely weird to me!
<JamesMunns[m]>
Only thing I can think of is that the linker script is wrong? can you print the stack pointer? I can't remember the exact command, maybe p $sp or info reg?
<JamesMunns[m]>
yeah I really don't understand, unless gdb is now catching infinite loops
<JamesMunns[m]>
that's a totally reasonable program, and there's no reason I can see for it faulting
<dirbaio[m]>
what tool are you using for gdb Rodney ?
<dirbaio[m]>
cargo-embed?
<JamesMunns[m]>
dirbaio[m]: yes
<askrodney[m]>
yep cargo-embed
<dirbaio[m]>
some tools put a breakpoint at start of main to setup RTT/defmt
<dirbaio[m]>
maybe it's interacting poorly with the gdb server
<JamesMunns[m]>
what's the gdb command to list breakpoints?
<JamesMunns[m]>
info break apparently
<JamesMunns[m]>
Rodney what happens if you hit `c` to continue after you get the SIGINT?
<askrodney[m]>
conintues to line 12, then new SIGINT on line 16 (loop)
<JamesMunns[m]>
is line 16 where you set your breakpoint?
<JamesMunns[m]>
(like as part of the exercise?)
<askrodney[m]>
Seems happy once it's inside the loop
<askrodney[m]>
no don't have that set right now, just breaks on main and 12
<JamesMunns[m]>
It's possible you are getting an "extra" breakpoint inserted by cargo-embed itself, CC Noah if you can think of why Rodney would get a SIGINT here (flash with cargo-embed, attach gdb, start stepping through main)
<dirbaio[m]>
i've looked through the probe-rs / cargo-embed code and it doesn't seem to add the breakpoint at main
<JamesMunns[m]>
but! It seems the answer is "if you get an extra sigint for now, try just ignoring it and continuing", the code and hardware looks totally fine.
<dirbaio[m]>
it's probe-run only
<dirbaio[m]>
try info break to see where is gdb placing the breakpoints
<dirbaio[m]>
perhaps the "file:line -> address" conversion is going wrong
<dirbaio[m]>
(gdb has a history of bugs with rust debuginfo)
<JamesMunns[m]>
you can see the breakpoints in the split view picture above
<dirbaio[m]>
(I don't think the discovery book should tell people to use gdb at all lol)
<JamesMunns[m]>
they look like they are at the top of main and right before the loop, to me.
<dirbaio[m]>
so there's indeed a breakpoint at main
<askrodney[m]>
dirbaio[m]: lol, what do you use day-to-day?
<dirbaio[m]>
just defmt 😅
<dirbaio[m]>
no interactive debugging
<JamesMunns[m]>
Yeah, pretty much defmt + (probe-rs cli/probe-run) for 99.9% of things for me, I only use GDB to debug when something is really wrong with the hardware or software
<dirbaio[m]>
there's the probe-rs vscode extension, which is less buggy because it doesn't use gdb and is made specifically for rust https://probe.rs/docs/tools/vscode/
<dirbaio[m]>
but in general interactive debuggers in embedded are hit or miss
<dirbaio[m]>
* embedded are very hit or
<askrodney[m]>
thanks for heads-up
<JamesMunns[m]>
(also much much harder to use if you are doing anything timing critical, like USB or BLE)
<JamesMunns[m]>
* (also GDB is much much
<askrodney[m]>
Found ferrous systems post on using defmt with probe-rs: https://ferrous-systems.com/blog/defmt/ will concentrate on getting through discovery for now, but that's next on my list 😄
TomB[m] has joined #rust-embedded
<TomB[m]>
<JamesMunns[m]> "(also much much harder to use if..." <- "my ble stuff has a bug, time to fire up gdb" - now you have 2 bugs
<TomB[m]>
honestly the smartest thing people have done is entirely offload the radio crap to a little m0 core
<TomB[m]>
trying to do shenanigans with timers and interrupts was always bound to have something go wrong
<dirbaio[m]>
yep, now you have IPC bugs 🥳
<TomB[m]>
I haven't had an IPC bug
<TomB[m]>
but I have had timer/isr related timing bugs with ble that were horrendous
crabbedhaloablut has quit []
<dirbaio[m]>
huh
<dirbaio[m]>
I only have experience with nordic's, but the pre-made radio lib they give takes care of everything, haven't had any bugs
<dirbaio[m]>
main way to fuck it up is to run your own code at too high prio breaking its timing, but in that case it throws an "assertion failed" at you instead of silently not working
<dirbaio[m]>
vs in the nrf53, they split it into application and radio cores. but they don't give you a pre-made firmware for the radio core, just the same lib as nrf52. you have to do your radio firmware and ipc yourself
<dirbaio[m]>
so, ipc bugs with fences and atomics :D
<dirbaio[m]>
* so, shared-mem IPC bugs with fences and atomics :D
<TomB[m]>
I had conflicting interrupts, a fast sensor firing drdy gpio's and then the ble timer bullshit would overlap at time, and screw up all the carefully crafted sensing algorithms, unaware of this whole ble timer prio bs, I found myself in a crap situation
<TomB[m]>
s/time/times/
<dirbaio[m]>
ahh right if you have to do realtime stuff of your own other than the radio, I can see it being mega painful 😰
<TomB[m]>
yeah, I mean whats the point of having the arm core there to do things at a particular time if... you can't
<TomB[m]>
because the ble train is coming in
<firefrommoonligh>
Hi! Do y'all know offhand what things you need to install to get FFI to work on a clean Windows install? I'm getting errors compiling CMSIS-DSP via bindgen. I used the Visual Studio installer to install the C++ pack, and installed LLVM, then pointed the LIBCLANG_PATH to C:\Program files\LLVM\\bin. Any ideas... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EiECdEfureUyVSjPWlhJilsq>)
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Last time on my laptop I installed LLVM with winget and that seemed to work
<diondokter[m]>
Btw, you sure you need llvm? And not the arm-none-eabi-gcc tools?
<dirbaio[m]>
use WSL 🙃
<diondokter[m]>
WSL and usb-connected debuggers is still not a nice combo :P
<diondokter[m]>
Though I think I heard there's gonna be some improvement there
<dirbaio[m]>
you can build inside WSL and run probe-rs outside
<dirbaio[m]>
I think you can run a .exe directly from inside WSL and it'll automatically run outside? not sure
<dirbaio[m]>
perhaps it was in WSL1 only
<diondokter[m]>
No, you can do that in WSL 2 too
<diondokter[m]>
There's gonna be a WSL2 2.0 version soon :P
<dirbaio[m]>
then maybe if you set probe-rs.exe as a cargo runner it just works
<dirbaio[m]>
no idea
<dirbaio[m]>
WSL2 2.0? 🤣
<diondokter[m]>
Yep
<dirbaio[m]>
brought to you by USB 3 Gen2x2 🤪
<dirbaio[m]>
WSL Full Speed
<dirbaio[m]>
* USB 3.2 Gen2x2
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]