ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
stgl has quit [Quit: ZNC 1.8.2 - https://znc.in]
stgl has joined #rust-embedded
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 252 seconds]
ivche_ is now known as ivche
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
BentoMon has quit [Ping timeout: 276 seconds]
BentoMon has joined #rust-embedded
BentoMon has quit [Ping timeout: 276 seconds]
kline has quit [Remote host closed the connection]
kline has joined #rust-embedded
pcs38 has joined #rust-embedded
BentoMon has joined #rust-embedded
<jason-kairos[m]> I'm pretty sure what I would actually want is to generate debug symbols for constants, which is impossible as far as I can tell.
<JamesMunns[m]> Constants do have to exist in FLASH, not RAM, if you ever use them to initialize a value that exists in RAM (on the stack, etc).
<JamesMunns[m]> I have no idea how to get GDB to show you that value, and it is usually "inlined" at wherever the usage site is.
<jason-kairos[m]> You are right. Maybe what I really want is for my immutable statics to live in flash. (linker script madness)
<JamesMunns[m]> I don't know if that's a great idea, I can imagine that breaking in fun and challenging to debug kinds of ways
<JamesMunns[m]> It's possible the compiler might already do that for statics that are truly read-only, and don't have inner mutability?
<JamesMunns[m]> you could see what linker section they end up in already
dngrs[m] has joined #rust-embedded
<dngrs[m]> are you trying to optimize for size? standard talking points would then be cargo bloat and "did you do a release build?"
<jason-kairos[m]> Yes. Actually, it turns out that the `size` command miscomputed the size of data due to some linker trickery that Hubris OS does.... (full message at <https://catircservices.org/_irc/v1/media/download/AdsICg-5Z5I3f6ghegQFwWMwolFVt9BWk0xEVH0CGM23Kux_lo8-Uj_1-iD87tAPV_5Dq1eKGaEjh99ZX9MrQN6_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9leHdPWHJCcm5ta2pUdWtkdnlnRE9zSHE>)
<dngrs[m]> I think you might also be interested in using https://github.com/rust-embedded/cargo-binutils to create a .bin if you want to see the actual size that gets flashed
<dngrs[m]> apart from that you might succeed in nerd sniping cbiffle on mastodon :D
<dngrs[m]> dngrs[m]: actually that might not apply since I don't know what linker tricks hubris is up to
<jason-kairos[m]> I don't want to bother cbiffle unless I absolutely have too
<jason-kairos[m]> I think I can solve this with all of the information you all have provided.
wassasin[m] has joined #rust-embedded
<wassasin[m]> Implementing a routing table; any suggestions for a fixed-size btreemap crate?
jsolano has joined #rust-embedded
<jsolano> What is the easiest way of getting tags to be used with vim? I tried rusty-tags, but I have many subprojects and I end up with loads of project tag files, I would like instead to get a top level tag file (like done with ctags --recursive)?
<dngrs[m]> <wassasin[m]> "Implementing a routing table..." <- Can you use alloc and go with the std one? I imagine a balancing tree to be pretty annoying to write/use without alloc
<wassasin[m]> dngrs: any ordered map with log(n) lookup will do
<wassasin[m]> Trying https://crates.io/crates/scapegoat now
<dngrs[m]> That looks pretty rad
<dngrs[m]> If I understand it right it has a special purpose allocator
<wassasin[m]> I would actually prefer something simpler, but getting it done is more important right now. I can always write something simpler when I have time or if I run out of volatile memory
<dngrs[m]> results-first approach is good in my book
<wassasin[m]> Was briefly considering heapless::LinearMap, but that is not really acceptable
richardeoin has quit [Ping timeout: 244 seconds]
richardeoin has joined #rust-embedded
mkj[m] has joined #rust-embedded
<mkj[m]> does it need to be sortable, or would heapless::FnvIndexMap do?
<wassasin[m]> Deriving a hash from an address would make no sense in this case, I have 12bits addresses
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> Why is linear unacceptable? How many addrs are you going to have?
pcs38 has quit [Ping timeout: 276 seconds]
<RobinMueller[m]> did anyone ever write a custom TCP server on port 19021 to expose defmt frames? I did this in Python using the select API, but the TCP client never seems to be writable, and when I send something back, I don't see any printouts..
<RobinMueller[m]> * defmt frames to be read by defmt-print? I
<RobinMueller[m]> i can see the defmt-print connection though
<RobinMueller[m]> ok nevermind, firmware problem, I am sending empty frames back to defmt-print 😅
pcs38 has joined #rust-embedded
<RobinMueller[m]> James Munns: the defmt logger variant which puts defmt frames into a spsc queue and then consumes the queue it in the main loop works great, thanks for the advise :)
<wassasin[m]> <dirbaio[m]> "Why is linear unacceptable..." <- 2000
<wassasin[m]> Might actually be better to just have an array now that I think about it
<wassasin[m]> Address space is 12 bits
<wassasin[m]> Device with most ports will be 6 ports, so I am using an u8 as a routing table bitmask for each address
<wassasin[m]> Yes, an array makes more sense :'), 4k RAM is an OK sacrifice
pcs38 has quit [Quit: leaving]
richardeoin has quit [Ping timeout: 252 seconds]
richardeoin has joined #rust-embedded
richardeoin has quit [Client Quit]
sroemer has quit [Quit: WeeChat 4.5.2]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
richardeoin has joined #rust-embedded
pcs38 has joined #rust-embedded
<jason-kairos[m]> Silly question: if a rust function takes a function pointer / closure / etc. type thing - is a call to the function pointer capable of being see with static static analysis tools?
<jason-kairos[m]> I think probably not.
<jason-kairos[m]> s/see/seen/followed/
<jason-kairos[m]> I have not tried picking apart disassembly of that type of function under the assumption that using them on embedded is probably a bad idea
<JamesMunns[m]> The answer is "sometimes", at least as far as I am aware: https://github.com/Dirbaio/cargo-call-stack?tab=readme-ov-file#features
<JamesMunns[m]> > The tool has imperfect support for calls through function pointers (fn()) and dynamic dispatch (dyn Trait). You will get a call graph from programs that do indirect calls but it will likely be missing edges or contain incorrect edges. It's best to use this tool on programs that only do direct function calls.
<JamesMunns[m]> IF the tool can eliminate the options down (based on the signature I think?), and the number of options is useful, you can sometimes figure it out
<JamesMunns[m]> for things like fmt where everything breaks down to similar calls, it gets sorta unbounded really quickly
<JamesMunns[m]> in a lot of simpler cases like iterator map, I'd guess the closures get inlined in most optimized cases
loki_val is now known as crabbedhaloablut
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded