Guest7282 has left #rust-embedded [Error from remote client]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
crabbedhaloablut has quit [Ping timeout: 245 seconds]
AdamHorden has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
starblue has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #rust-embedded
m3vict[m] has joined #rust-embedded
<m3vict[m]>
Hi! Could anyone share some tips on how to build a Rust project (bare-metal or embassy async) for a better debug? When building with opt-level=1 and lto I get binary size of around 25000, with opt-level=0 is 75000. But even with opt-level of only 1 it is basically impossible to step through functions using gdb, only some complex stuff like defmt prints don't get inlined.
<m3vict[m]>
* with opt-level=0 it is 75000.
Guest7282 has joined #rust-embedded
<M9names[m]>
turning off LTO helps a lot
<M9names[m]>
it's still not a great experience tbh. there's a reason why there's not many folks that use breakpoint or step-debugging for embedded rust
<m3vict[m]>
I am building without lto now and anything other than opt "0" is still impossible to debug.
<M9names[m]>
are you setting debuginfo-level=2?
<M9names[m]>
should be able to do that by putting in debug=2 in your flags if you're adding debug to a release build
<m3vict[m]>
I am using debug build
<m3vict[m]>
So I think it has this by default.
IlPalazzo-ojiisa has joined #rust-embedded
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
Print debugging with defmt-rtt ftw
<henrik_alser[m]>
Can’t even remember last time i brought out gdb
<m3vict[m]>
I use defmt as well, but gdb servers different purpose and It can't be replaced with defmt.
<m3vict[m]>
E.g. when debugging time-critical responses and you would want to setup bkpt in interrupt handlers, without an overhead of printing, which can introduce significant delays.
<danielb[m]>
As if stopping on a breakpoint doesn't cause a delay 🙃
<danielb[m]>
(Jk jk)
<henrik_alser[m]>
With serial printing 100% but since defmt-rtt my workflow has shifted, gdb is more or less unusable in async/interrupt driven code in my experience, whereas defmt over rtt print debugging has been working great for all of my needs, but ymmv of course!
<henrik_alser[m]>
Since it stops all other interrupts from firing it quickly turns into a confusing mess in my experience, also if you’re working with something like nrf softdevice, pausing the core makes it all explode in your face. But it has its use cases i guess, i just havent had a reason to bring it out for the past couple of years was my point :) Hope you have a better time with it!
<M9names[m]>
i'm genuinely curious how you debug something time-critical with breakpoints m3vict, because i would love to have another tool in my toolbox
<korken89[m]>
So I was playing with creating a "softdevice" last night and got it building and so, but I'm getting some detail wrong as everything is optimized away (0 size). I copied the linker script of cortex-m-rt and generated a dummy Reset method and my own vector table as a test. I made a super small test project to test this, can anyone see why this is just removing everything? https://github.com/korken89/crypto-softdevice/tree/main
<korken89[m]>
As I understand it the KEEP(*(.vector_table.entries)); is the magic that should force the vector table to not be optimized out, and from there referenced things should also not be optimized out
<korken89[m]>
* As I understand it the KEEP(*(.vector_table.entries)); is the magic that should force the vector table to not be optimized out, and from there referenced things by this table should also not be optimized out
<korken89[m]>
But I think I got something wrong in my understanding here
crespum[m] has quit [Quit: Idle timeout reached: 172800s]
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Do you have the map file from your compilation? You can test your assumption and see if the vector table is correctly located
<korken89[m]>
Hmm, do you know where to find it?
<dirbaio[m]>
you also need #[used] in the static
<korken89[m]>
I tried to add #[used] to no change :/
<FreeKill[m]>
korken89[m]: You need to configure rustc to link with the map option
<FreeKill[m]>
Then it should appear in your compilation directory
<korken89[m]>
Alright!
<dirbaio[m]>
this needs to be in the `[build]` section, I htink it doesn't get applied otherwise
<korken89[m]>
Good find! I think that might be the issue, suddenly I'm getting linker errors :D
<korken89[m]>
It's working!!!! :D
<korken89[m]>
Oh god, thank you! Even my cat started questioning my sanity
<FreeKill[m]>
I'm sure your cat has never thought you sane
<korken89[m]>
And MAP file confirms the layout
<korken89[m]>
xD
starblue has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
djdisodo[m] has joined #rust-embedded
<djdisodo[m]>
been playing with avr because i have ton of uno r3s for some reason but got me thinking
<djdisodo[m]>
to get wifi working unos often have to use some wifi expansion like espXX
<djdisodo[m]>
and even esp8266 is powerful than most of avr chips
<djdisodo[m]>
as long as you want to use wifi i see no reason to not choose esp but esp boards aren't even expensive than no-wifi boards
<diondokter[m]>
I think you've figured out why ESP is so popular!
<djdisodo[m]>
it is popular but why arduino uno r4 came with arm?
<djdisodo[m]>
and wifi version has additional esp bruh
<diondokter[m]>
I'm not super familiar with the microcontroller capabilities of ESP chip, but AFAIK it can't do everything.
<diondokter[m]>
Looking at it, ESP can't do e.g. ethernet or CAN-FD. These are things other chips can do
starblue has joined #rust-embedded
<diondokter[m]>
It is one of the few Cortex-M microcontrollers with 5V IO
<diondokter[m]>
It's been a while since I looked at, but the new uno r4 chip isn't very special, except for one thing:
<diondokter[m]>
* looked at it, but
<dirbaio[m]>
i've always found these "arduino with wifi" boards so funny. the esp32 is like 50x more powerful than the main MCU 🤣
eZioPan[m] has joined #rust-embedded
<eZioPan[m]>
then there is a arduino esp32, with only a esp32 on pcb🤣
<eZioPan[m]>
s/only//, s/on/as/, s/pcb/main MCU/
<jannic[m]>
Thanks to everybody involved that you didn't stick to the planned 1.0.0 release date, but take the time to discuss the `&mut self` question. While personally I guess that both approaches have their merits and there won't be a clear winner, it's still a good think to properly think through the consequences. Even if in the end it'll be a vote or even a coin toss.
<jannic[m]>
And even more important: Thanks for having such a polite conversation. It's a pleasure to read all those comments in the ticket. It's obvious that there are different opinions, and also that some are impatiently waiting for the release. Still, no personal attacks, no power games. That's why I like the rust embedded community!
leonardvdj[m] has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
it’s nuts how much cheaper the arduino R4 is compared to the R3, especially considering how much more powerful the new renesas chips are. good to see them finally moving away from DIP 8 bit AVRs in a flagship product
<Lumpio->
Yeah *finally*
<Lumpio->
Now hopefully people will adopt them
<Lumpio->
I've already heard people complain about how some crappy library with no notion of software design or HAL layer didn't work on it and it turned out the library was full of random inline AVR ASM
<diondokter[m]>
I always thought the name was a nordic invention. But is softdevice a general term?
<korken89[m]>
I have no idea tbh, but I like the name from nordic :)
<korken89[m]>
I hope it won't end with DMCA xD
<korken89[m]>
I wonder if one can expose async stuff over an API like that hmm
<diondokter[m]>
Ha in theory yes
<korken89[m]>
I mean if I write an async radio stack and want to share it, hypothetically
<diondokter[m]>
You need to store the data and present a poll function
<korken89[m]>
Yeah, the actuall async API can be in the user space wrapper
<diondokter[m]>
Data could be void* and poll would need to be extern C
<diondokter[m]>
This could be a neat crate actually. That would also provide a header file and a rust wrapper around it that implements Future
<korken89[m]>
Hehe
<diondokter[m]>
Maybe you don't even need void*. But you would have to make like an extern struct or whatever it's called
<korken89[m]>
Yeah as along as the layout is stable
<korken89[m]>
I guess repr(C) is enough really
<korken89[m]>
Unless you really want an type erased thing :)
<diondokter[m]>
Well, the thing is that you can't tag a compiler-generated future with repr C
<korken89[m]>
Ah no, I was thinking if all that is on the userspace side and that a poll API is only exposed over the softdevice API. Not sure if it's enough though
<diondokter[m]>
Ah ok. Probably also want waker support
<korken89[m]>
I feel an evening of experimentation needs to be added to the calendar :D
<diondokter[m]>
I guess that's included in the poll...
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
<diondokter[m]> "I'm not super familiar with..." <- it can do ethernet though :D but yes only normal can no can-fd
<vollbrecht[m]>
vollbrecht[m]: and in general you are absolutely right they are so many different peripheral that exists that it is impossible to cover everything with one chip. so you need to look for the appropriate one
<diondokter[m]>
vollbrecht[m]: Oh, I didn't see ethernet when I glanced over the peripheral list
<diondokter[m]>
diondokter[m]: The list is longer than I expected. But maybe my mind is still stuck with the old ESPs
<JamesMunns[m]>
There's at least one "stable abi" attempt that includes async, `crabi` I think? It's definitely a little cursed.
<diondokter[m]>
Oh does it really? All I saw was things like slices, strings etc.
<JamesMunns[m]>
crabi seems "official", I was definitely thinking of a third party crate
<korken89[m]>
Nice!
<vollbrecht[m]>
<diondokter[m]> "The list is longer than I..." <- the classical esp32 has support for external mac's/phy or using the internal one called "emac"
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
I need some opinions. I added a repair function to `sequential-storage`. If you got a random shutdown and later get a corruption error, you can call the repair function to recover pretty much everything. Only the thing you were writing or erasing might or might not be there.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hqOTnOzmVctUVcoLVCCwVihn>)
<diondokter[m]>
* or erasing at the time of the shutdown might or
<diondokter[m]>
* I need some opinions. I added a repair function to `sequential-storage`. If you got a random shutdown and later get a corruption error, you can call the repair function to recover pretty much everything. Only the thing you were writing or erasing at the time of the shutdown might or might not be there.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uiypUfdDKLbsSJemzjTXJLUi>)
<diondokter[m]>
Thing is that that's still a pain to implement
<JamesMunns[m]>
On one hand: some people (maybe just at development time) might want to be able to "hand repair" things, so autorepair might not be great? On the other hand, it'd be nice to handle that automatically
<AdamHott[m]>
Hi all, I'm making a lot of progress getting my raspberry pi pico w project setup, but I'm having problems figuring out how to add cyw43 and cyw43-pio crates. I'm getting the error that cyw43 and cyw43-pio require the std library. Here is my cargo.toml file: https://github.com/CodingInGreen/rp2040_tests/blob/master/Cargo.toml
<diondokter[m]>
In this system, it'd have to 'own' the flash. I don't really want that. The user might want to do other things with flash in different memory regions that don't have anything to do with my crate, like creating backups or firmware updates
<JamesMunns[m]>
Maybe I'm way off base now :), I was mostly just suggesting you could support multiple regions
<JamesMunns[m]>
diondokter[m]: It needs to own the moral equivalent of `Arc<Mutex<Flash>>`, yes
<JamesMunns[m]>
but it can be a shared static
<diondokter[m]>
Yeah, I feel like you're proposing a full-blown storage solution while mine is more aimed to be a building-block
<JamesMunns[m]>
<diondokter[m]> "Well, but the user might have..." <- I thought you were already there.
<diondokter[m]>
Yes, but I don't manage those regions
<diondokter[m]>
The user does
<JamesMunns[m]>
diondokter[m]: fair!
<JamesMunns[m]>
Maybe I'm off base, it seems like a problem I'd solve in a similar way. Happy to chat more if it's interesting :)
<diondokter[m]>
To fetch an item, you give it access to your flash, the memory region addresses where this map is located, a buffer to do the item reading in and the key of the thing you're looking for
<diondokter[m]>
And I really like that it's 'just a function'. There's quite a lot of state everywhere, but I've managed it so the only relevant state is in flash
<diondokter[m]>
Makes debugging and maintenance a lot easier
<dirbaio[m]>
does it need to "scan" the memory every time to find where the circular buffer starts/ends?
<diondokter[m]>
dirbaio[m]: Yes, but it tries to be efficient about it. It can very quickly find the right page and only scan the page. There are bad cases where we have to scan for more.
<diondokter[m]>
I want to add optional caching too, but that's not implemented yet
<dirbaio[m]>
efficient how? O(n) if there's n pages?
<diondokter[m]>
I don't know how to best describe it in big O notation...
<diondokter[m]>
Searching for the correct page is O(n), but with a shortcircuits if it finds it early.
<diondokter[m]>
Then it needs to search for the correct item on the page. But it doesn't need to read it all, only the item headers. The data isn't read at all until we find the correct item (or an empty spot to write a new item)
<diondokter[m]>
The to-be-implemented cache would save the page states and keep track of the addresses of relevant items. The cache would (once populated) reduce everything to almost O(1)
<Lumpio->
Then again searching flash is kinda fast and you could treat it kind of like a file manually just as easy
<Lumpio->
E.g. read to your own variables, save only when necessary
<diondokter[m]>
If you can get away with erasing and writing a whole page of flash every time you want to update it, then it's better to do that.
<diondokter[m]>
But on e.g. Nordic you only get 10k erases. If your device needs to last 10 years and you wake up every hour and need to update the flash, then you don't have enough cycles
<Lumpio->
No I know, but you could treat the sequential storage thing like a file
<Lumpio->
So you don't need to worry about it being "O(n)" or whatnot for lookup
<diondokter[m]>
Sure
<dirbaio[m]>
often the data you have in flash doesn't fit in ram
<diondokter[m]>
I actually have some stats for the queue implementation.
<diondokter[m]>
Pushing some data on the queue on my mock flash implementation with 4 1kb pages, it takes on average 3 writes and 18 reads
<JamesMunns[m]>
is that for every push, e.g. it's not amortised at all?
<Lumpio->
dirbaio[m]: Well this one seems to want a data buffer big enough for your key anyways so
<Lumpio->
For stuff that just plain won't fit in RAM an interface that just gives you the most up-to-date "&[u8]" might work
<diondokter[m]>
JamesMunns[m]: Nothing is cached, so yeah that's it
<diondokter[m]>
That's why I want to add cache later :P
<JamesMunns[m]>
Gotcha! Yeah, I guess I'm saying you can have one a `Mutex<(State, Flash)>` if you want to support exactly one region, or `Mutex<([State; N], Flash)>` if you want to support multiple regions
<JamesMunns[m]>
and then keep your functions, and amoritize the cost per-region so you don't have to rescan every push.
<diondokter[m]>
Yeah, not exactly sure how I want it. Might just end up with having the user just hold on to the cache having them pass it to the function
<diondokter[m]>
It's an option
IlPalazzo-ojiisa has joined #rust-embedded
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 245 seconds]