<re_irc>
<@matt:ucc.asn.au> anyone know of an example of a "&dyn I2c" from alpha embedded-hal where the "Error" types vary across instances? trying to figure what syntax I need
kenrendell[m] has joined #rust-embedded
<re_irc>
<@matt:ucc.asn.au> actually I guess that couldn't work since the error types when calling it would vary
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> You can create your own "DynI2c" trait that mirrors the existing trait but returns "Result<(), Box<dyn i2c::Error>>", then make a blanket "impl<T> DynI2c for T where T: I2c". Of course this requires alloc unfortunately
<re_irc>
<@matt:ucc.asn.au> aha right, thanks. I'm on Linux so alloc will be OK in this case
Dr_Who has quit [Ping timeout: 252 seconds]
cr1901 has quit [Ping timeout: 246 seconds]
<re_irc>
<@guenther_rostig:matrix.org> Today a Nuclleo Board arrived, I'd like to test the ethernt communication with it, before switching to my MSP432. But at first I'm going to test the bliny example, the good old hello world program for MCUs. I followed the instructions at Starting your own project (https://github.com/stm32-rs/stm32h7xx-hal/tree/master/examples), but "cargo build" gives me the message that cortex_m_rt...
<re_irc>
one time dashes, one time underscores, doesn't that matter?
<re_irc>
<@marmrt:matrix.org> cargo.toml uses dashes, source code uses underscores. Such is the way it is, the official rust book probably has the explanation
<re_irc>
<@guenther_rostig:matrix.org> Building of the whole repo works. But not of a single example. Till yet....
<re_irc>
<@seanmlyons22:matrix.org> : Thanks!
<re_irc>
Coming back to this, there was indeed a lot of good advice above.
<re_irc>
Especially the point about avoiding a workspace. I had wanted a single point of specifying the dependencies, but perhaps that can be automated.
<re_irc>
I’ll be better about searching previous chats next time!
<re_irc>
<@ryan-summers:matrix.org> Does heapless have anything like a "growable ring buffer"? I basically want to provide some external (contiguous) memory and treat it as a single ring buffer
<re_irc>
<@ryan-summers:matrix.org> Very similar to the heapless::pool::Pool, but with a binary buffer
Foxyloxy has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> : You mean for &[u8]?
<re_irc>
<@ryan-summers:matrix.org> Yeah
<re_irc>
<@diondokter:matrix.org> I don't think heapless has that
<re_irc>
<@ryan-summers:matrix.org> I can't imagine a run-time growable ring buffer is some insanely new thing that no ones already implemented
<re_irc>
<@diondokter:matrix.org> Not sure what you mean with 'growable'
<re_irc>
<@dirbaio:matrix.org> heapless Deque?
<re_irc>
<@ryan-summers:matrix.org> Meh, I'm trying to avoid const generics. I want this to be in some hidden part of a lib, where the user provides the buffer so they can declare memory
<re_irc>
<@ryan-summers:matrix.org> Very similar to how smoltcp lets you spec the socket buffers without const generics
<re_irc>
<@dirbaio:matrix.org> ahh so heapless structs but instead of owning the storage inline, they let you pass in a "&mut [T]"?
<re_irc>
<@dirbaio:matrix.org> * [T]" for the backing storage?
<re_irc>
<@ryan-summers:matrix.org> Yeah, but in my case it's always just some u8 memory. I'm just using it to cache serialized MQTT packets in
<re_irc>
<@ryan-summers:matrix.org> +until they get ack'd
<re_irc>
<@ryan-summers:matrix.org> Don't mind if I do
<re_irc>
<@ryan-summers:matrix.org> Thanks MIT
<re_irc>
<@ryan-summers:matrix.org> s/MIT/0BSD - this is for minimq so it's opensource anyways
<re_irc>
<@dirbaio:matrix.org> the smoltcp ones are a bit too complex maybe because they're tailored for TCP use cases (the whole allocated/unallocated thing is so it can handle holes in tcp out-of-order rx)
<re_irc>
<@dirbaio:matrix.org> * one is
<re_irc>
<@dirbaio:matrix.org> * maybe, because it's
<re_irc>
<@ryan-summers:matrix.org> I _think_ MQTT guarantees ordering of things, need to review
<re_irc>
<@dirbaio:matrix.org> but you can probably just ignore it
id_tam has quit [Ping timeout: 245 seconds]
emerent has quit [Ping timeout: 264 seconds]
emerent_ has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> FWIW , I've beat my head on similar problems. IMO, if you have GUARANTEED FIFO semantics, something sort of bbqueue shaped is generally the best approach IMO (though, maybe not exactly bbqueue, depending on your access profiles). As soon as you get a scent of out of order pops though, it all falls over, and really you're better off with just a general purpose allocator.
<re_irc>
<@jamesmunns:beeper.com> like, bbqueue in framed mode is _more or less_ a FIFO allocator, though it can't grow to span multiple regions
<re_irc>
<@jamesmunns:beeper.com> If you _generally_ free things in the order they are allocated, I'd probably suggest starting with linked-list-allocator, and add an optimization to start your search right after your last allocation, instead of starting at the beginning of the linked list like it currently does.
<re_irc>
<@jamesmunns:beeper.com> You could probably make bbqueue a little more flexible with "have access to multiple things" instead of strict "one at a time in/out" like it is now if you're willing to give the producer/consumer being "Send", not sure if you care about directly DMA'ing into or out of the buffer.
<re_irc>
<@ryan-summers:matrix.org> MQTT has a hard requirement that the order is maintained on republication, so this is a strict history buffer FIFO, so ringbuffers should be idea here
<re_irc>
<@ryan-summers:matrix.org> * ideal
<re_irc>
<@jamesmunns:beeper.com> : But can they be ack'd and dropped out of order?
<re_irc>
<@jamesmunns:beeper.com> this is where I fell apart trying to use bbqueue for my "sort of like mqtt" protocol in anachro
<re_irc>
<@adamgreig:matrix.org> : this was prescient!
<re_irc>
<@ryan-summers:matrix.org> No, they cannot
<re_irc>
<@ryan-summers:matrix.org> Both the sender and receiver must maintain ordering of ACKs and retransmissions
<re_irc>
<@ryan-summers:matrix.org> I think minimq is _nearing_ MQTTv5 feature-completeness, so that's pretty neat :) I'm refactoring it to remove all the const-generic mess and use user-supplied buffers like smoltcp now. Experience has shown me that is definitely the better way
<re_irc>
<@ryan-summers:matrix.org> Should make it a lot more applicable for resource-constrained systems, although that's generally not the case for IoT devices
<re_irc>
<@ryan-summers:matrix.org> I really need to make a blogpost or video about it, MQTT makes run-time configuration, telemetry, and device dash boarding like zero work for an app
<re_irc>
<@jamesmunns:beeper.com> open offer, if you wanna do a podcast chat on it, I have a pretty jaded view of mqtt for constrained devices, and would actually really appreciate someone with a rosy view to help pop some of my preconceptions :D
<re_irc>
<@ryan-summers:matrix.org> I hate that its hard for me to find time to do fun rust projects nowadays. It's all risk analysis all the way down
<re_irc>
<@ryan-summers:matrix.org> +for my other job
<re_irc>
<@ryan-summers:matrix.org> : Might take you up on that, I've been kicking the can on demoing this stuff for a long time, but I think it's wildly cool and easy to use. QUARTIQ just used it in some neutral atom traps
<re_irc>
<@jamesmunns:beeper.com> Yeah, feel free to not prepare at all, or feel like you have to demo, but it might be useful for figuring out what would be nice to demo as a video or blog post :D
<re_irc>
<@ryan-summers:matrix.org> Tbh had never used mqtt before this project, we selected it based on the specific needs of this project and built a rust driver for it
<re_irc>
<@ryan-summers:matrix.org> I've got a ton of easy-to-do demos in my office right now, just need to turn them on :)
<re_irc>
<@jamesmunns:beeper.com> I'll send you a DM to coordinate :)
<re_irc>
<@ryan-summers:matrix.org> Sounds good, I'll be out visiting Noah at the start of next week but let me know and we can coordinate. I'm heading home now because it's way too late to still be in the office
<re_irc>
<@thejpster:matrix.org> MQTT runs over TCP right? And in my experience TCP sucks over NB-IoT. Spent hours desk surfing in the British Library trying to find the only NB-IoT signal that existed back in about 2019 debugging that damned thing.
<re_irc>
<@thejpster:matrix.org> Worst case I think NB-IoT can ramp up to about 1000 retries per packet, so the latency can be huge.
<re_irc>
<@jamesmunns:beeper.com> : Generally, yes, which is part of my complaint about using mqtt for constrained devices :D
<re_irc>
<@ryan-summers:matrix.org> Yeah, it works great when you have ethernet though
<re_irc>
<@jamesmunns:beeper.com> (there's MQTT-SN, which is much more reasonable for embedded IMO, but I've never actually seen it used over plain MQTT)
<re_irc>
<@jamesmunns:beeper.com> A lot of the (now older) mobile stuff was based on CoAP or LwM2M instead of mqtt, which I think also plays better with less reliable pipes
<re_irc>
<@jamesmunns:beeper.com> coap/lwm2m is more "http-lite" than pubsub, though does have some basic "subscribe" features. Can't say I'm too much of an expert tho
<re_irc>
<@thejpster:matrix.org> LwM2M uses CoAP as a transport right?
<re_irc>
<@jamesmunns:beeper.com> it's based on coap, no idea if they did that by layering on top or just modifying the protocol itself
dc740 has quit [Remote host closed the connection]
<re_irc>
<@9names:perthchat.org> iirc DTS only has memory addresses + sizes, peripheral addresses and whether they're enabled, and interrupt controller config.
<re_irc>
It's not really enough to build an svd from, you'd need to scrape peripheral register names and offsets from C header files as well.
<re_irc>
<@9names:perthchat.org> I don't think I've ever seen an svd from the vendor for an applications processor, either
<re_irc>
<@avery71:matrix.org> stm32-rs has svdtools which is typically used to patch preexisting SVDs, you might be able to use it to create one from scratch