<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
<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 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
pcs38 has quit [Quit: leaving]
astapleton[m] has joined #rust-embedded
<astapleton[m]>
I just ran into a problem I haven't experienced before and am looking for some advice. I discovered that due to optimization, the rust compiler will happily emit out of order instructions that result in toggling GPIOs on my system that then power down subsystems that should not be powered down yet. I fixed it by putting a compiler fence in my wrapper for GPIO access (around linux-embedded-hal). Is this a my program problem (ie.
<astapleton[m]>
something that could really confuse people and waste hours of time and having it accounted for in GPIO access functions might be worthwhile?
<astapleton[m]>
I should be putting the compiler fences in places that could modify hardware state that effect currently ongoing operations), or should linux-embedded-hal or gpio-cdev (which linux-embedded-hal) be emitting those operations? It's pretty unexpected to me that a GPIO state could be modified out of order like that, but I guess that could technically happen on an MCU too, and I would need those fences. However, this seems like
<astapleton[m]>
* I just ran into a problem I haven't experienced before and am looking for some advice. I discovered that due to optimization, the rust compiler will happily emit out of order instructions that result in toggling GPIOs on my system that then power down subsystems that should not be powered down yet. I fixed it by putting a compiler fence in my wrapper for GPIO access (around linux-embedded-hal uses). Is this a my program
<astapleton[m]>
problem (ie. I should be putting the compiler fences in places that could modify hardware state that effect currently ongoing operations), or should linux-embedded-hal or gpio-cdev (which linux-embedded-hal) be contain those fences? It's pretty unexpected to me that a GPIO state could be modified out of order like that, but I guess that could technically happen on an MCU too, and I would need those fences. However, this seems
<astapleton[m]>
like something that could really confuse people and waste hours of time and having it accounted for in GPIO access functions might be worthwhile?
<astapleton[m]>
* I just ran into a problem I haven't experienced before and am looking for some advice. I discovered that due to optimization, the rust compiler will happily emit out of order instructions that result in toggling GPIOs on my system that then power down subsystems that should not be powered down yet. I fixed it by putting a compiler fence in my wrapper for GPIO access (around linux-embedded-hal). Is this a my program problem
<astapleton[m]>
(ie. I should be putting the compiler fences in places that could modify hardware state that effect currently ongoing operations), or should linux-embedded-hal or gpio-cdev (which linux-embedded-hal uses) be contain those fences? It's pretty unexpected to me that a GPIO state could be modified out of order like that, but I guess that could technically happen on an MCU too, and I would need those fences. However, this seems like
<astapleton[m]>
something that could really confuse people and waste hours of time and having it accounted for in GPIO access functions might be worthwhile?
<astapleton[m]>
* I just ran into a problem I haven't experienced before and am looking for some advice. I discovered that due to optimization, the rust compiler will happily emit out of order instructions that result in toggling GPIOs on my system that then power down subsystems that should not be powered down yet. I fixed it by putting a compiler fence in my wrapper for GPIO access (around linux-embedded-hal). Is this a my program problem
<astapleton[m]>
(ie. I should be putting the compiler fences in places that could modify hardware state that effect currently ongoing operations), or should linux-embedded-hal or gpio-cdev (which linux-embedded-hal uses) contain those fences? It's pretty unexpected to me that a GPIO state could be modified out of order like that, but I guess that could technically happen on an MCU too, and I would need those fences. However, this seems like
<astapleton[m]>
something that could really confuse people and waste hours of time and having it accounted for in GPIO access functions might be worthwhile?
<mkj[m]>
That seems strange, I would have expected the IO in gpio-cdev to act as an implicit (or maybe explicit hidden somewhere in stdlib?) compiler fence
<mkj[m]>
On a mcu the register access will be volatile so won't get reordered
<astapleton[m]>
mkj[m]: Me too
limpkin has quit [Read error: Connection reset by peer]