<JamesMunns[m]>
ryan-summers[m]: there's a crate for it, or something like what I typed above
<ryan-summers[m]>
Oof nice, refactor of MQTT buffer management took the client stack size from 4376 bytes to 760 bytes :)
<thejpster[m]>
(but seriously, the DWARF records in the ELF can tell you how big stuff is - some debuggers can parse DWARF for you, or you might be able to ask GDB?, or you can parse the DWARF yourself).
<ryan-summers[m]>
Yeah I know its sitting in the elf, but I really CBA to just figure out a simple measurement. Maybe if I was doing a ton of optimization here
<thejpster[m]>
fair!
<thejpster[m]>
Apropos nothing: https://github.com/8051Enthusiast/biodiff looks cool. Binary diffing using bioinfomatics algorithms tuned on DNA sequences to find matching subsequences.
<ryan-summers[m]>
That indeed looks like a very useful snippet for the future
<ryan-summers[m]>
Total aside, but having DNS in an embedded project feels so wrong. The lines between embedded and a full on PC are blurring hard with all the awesome features embedded Rust is enabling
<ryan-summers[m]>
It's starting to look like even having an entire TLS client on hardware wouldn't even be that hard either with embedded-tls
<JamesMunns[m]>
mnemos is a lot of that vibe: there's so much useful embedded stuff out there now, you really can have the bulk of an OS by just cobbling together parts
<ryan-summers[m]>
But also, the rust lifetimes let you do some absolutely crazy things safely without allocating memory
<JamesMunns[m]>
heck, even the kernel scheduler is JUST using async, which means we don't even have to write a gnarly pre-emptive scheduler yet (though we'll need one for userspace)
<JamesMunns[m]>
but also "oh we can just drop in smoltcp and bam network stack" is pretty amazing, I definitely want to try out embedded-tls too :D
<ryan-summers[m]>
Smoltcp isn't even a very big flash overhead, which is insane
<ryan-summers[m]>
Also seems to outperform various hardware-based network stack chips
<JamesMunns[m]>
Yeah, it was like 10-20KiB depending on features IIRC?
<JamesMunns[m]>
Honestly thought about using dirbaio's "networking over usb" as an alternative to cdc-acm, once you end up wanting multiple "ports"
<JamesMunns[m]>
the only challenge is you need to set up DHCP on the host (or pass through networking), or configure static IPs, so it's not quite as plug and play
<JamesMunns[m]>
oh wait, it was even weirder, you need to have a DHCP server on the device (which smoltcp doesn't support), since it's acting as a network interface (think usb-to-ethernet), to assign an address for the PC
<ryan-summers[m]>
Yeah just ran cargo-bloat on Stabilizer in release, and smoltcp with UDP, TCP, DHCP, and DNS takes 53.7KB
<ryan-summers[m]>
Man, the MQTTv5 client is also only 13.6KB
<thejpster[m]>
IPv6 link local addressing with bonjour?
<diondokter[m]>
Man... Then why does the modem blob on the nrf9160 take ~150 KB? 🫠
<thejpster[m]>
To be fair, LTE-M and NB-IoT have a lot of layers.
<JamesMunns[m]>
thejpster[m]: could do! smoltcp supports ipv6 and mdns
<diondokter[m]>
thejpster[m]: Surely they do that on the other core
<thejpster[m]>
There's a full FDMA/TDMA resource allocation system running here - not just fling the packet at the ether and cross your fingers.
<thejpster[m]>
I thought the blob was the firmware for the other core?
<diondokter[m]>
No, I mean the nrfxlib library you run on your application core
<thejpster[m]>
Oh, huh. No idea what they're doing with that then.
<dirbaio[m]>
the nrf91 modem blob is just a thin layer that sends your function calls to the modem over shared ram ipc, it doesn't implement any protocols at all
<dirbaio[m]>
it's 190kb?!
<thejpster[m]>
is that the ELF size, with debug symbols?
<therealprof[m]>
A binary blob with debug symbols? Pretty sure they're not keen on providing reverse engineering support...
<dirbaio[m]>
it's a .a with debug symbols yes
<dirbaio[m]>
or at leat was last year
<dirbaio[m]>
question is whether the 190k is the .a size or the actual on-flash size
<diondokter[m]>
In my experience with very little own code you can balloon your flash size to >100kb calling just a couple of modem api's
<diondokter[m]>
That's why I mentioned the 150KB
<diondokter[m]>
Well... I guess those IPCs don't handle themselves :P
<dirbaio[m]>
O-o
<dirbaio[m]>
* O_o
<dirbaio[m]>
the IPC protocol is not that complex, I'd expected it to be implementable in 20-30kb :|
nex8192 has left #rust-embedded [Error from remote client]
<dngrsspookyvisio>
<thejpster[m]> "IPv6 link local addressing..." <- I was also gonna suggest link local. IPv4 might even suffice
dngrsspookyvisio has joined #rust-embedded
tiwalun[m] has joined #rust-embedded
<tiwalun[m]>
<diondokter[m]> "Man... Then why does the modem..." <- Do you mean the libmodem.a thing from the nrf_modem lib? Seems to be about 20 kB according to arm-none-eabi-size, the rest is probably debug symbols.
<dirbaio[m]>
ahh that makes more sense
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
emilgardis[m] has quit [Quit: Idle timeout reached: 172800s]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
micro[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
crabbedhaloablut has quit []
rmja[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
nic-starke[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Learned that in the latest GitHub blog
nex8192 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
duderonomy has joined #rust-embedded
fuse117[m] has joined #rust-embedded
<fuse117[m]>
are methods like transmute_copy generally okay in embedded rust. i am trying to serialize (convert to byte arrays) POD structs for transmission over a wire. the C coder in me wants to pack the struct and just use a pointer to it with its size.
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
in smoltcp I never transmuted; I felt that the convenience isn't worth the potential UB (a lot of the cost of which is the cost of reviews) and the performance isn't affected
<whitequark[cis]>
I think the performance cost in embedded Rust is actually lower than in server/desktop Rust because in the latter case you might be missing out on some cool SIMD-ized memcpy if the compiler fails to see it, but in embedded you're just doing it 4 bytes at a time anyway
<whitequark[cis]>
of course this changes if you compare a safe POD serializer implementation to a memcpy operation more unusual than a bytewise copy on the CPU; say if you can use DMA scatter-gather to send your network packets, you would probably be missing out on some benefits