<re_irc>
< (@iamnesia:matrix.org)> For a toy project on ESP32, I'm want to do some simple UI stuff that involves animation, and I'm trying to decide how to approach a render loop. Would it make sense to run the render loop on the 2nd core or would I just end up spending any time saved sharing data between threads instead?
<re_irc>
Either i only handle interrupts on the high priority thread, and then send processed events to a queue on the UI thread, then drain that before each update/render.
<re_irc>
Alternatively, the UI thread only handles the rendering part and I would need some way to share the application state (I don't know, maybe just wrap the framebuffer and send that or smth)
<re_irc>
I just can't really find any examples of anyone doing something similar, so I I feel like I'm on the wrong track.
<re_irc>
I realize that you ideally don't want a busy loop, but, at least while there are active animations, I can't rely on just reacting to input
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
brazuca has joined #rust-embedded
<re_irc>
< (@chemicstry:matrix.org)> : I'm not familiar with particular ESP32 architecture, but sharing data between threads is usually not a problem. Both cores use the same RAM space so as long as you don't copy/clone framebuffer it should be fine. There is no inherent overhead to multiple cores except for atomic synchronisation (Mutex), which is negligible if done right
<re_irc>
< (@chemicstry:matrix.org)> also in my experience biggest bottleneck is sending framebuffer to LCD, so make sure to use a fast LCD interface that is DMA capable
<re_irc>
< (@chrysn:matrix.org)> We're discussing ways to implement the "get_period()" method of the (unproven) embedded-hal PWM trait. Given frequencies are dealt with in Hz by the backing implementation, could anyone suggest good types for the associated Time type which get_period returns?
<re_irc>
< (@adamgreig:matrix.org)> "fugit"'s types are a popular choice
<re_irc>
< (@adamgreig:matrix.org)> in general the "how to deal with time" business in embedded-hal 0.2 proved quite messy and is deleted for 1.0 pending working out something better
<re_irc>
< (@chrysn:matrix.org)> Yes, but they don't have rational types (where, like, a value of 20 represents 1/20th of a second)
<re_irc>
< (@adamgreig:matrix.org)> they have "Rate" which is in Hz
<re_irc>
< (@adamgreig:matrix.org)> hmmm
<re_irc>
< (@adamgreig:matrix.org)> yes, I see, that's also not "value of 20 is 1/20th of a second" though is it
<re_irc>
< (@chrysn:matrix.org)> Yes, that kinda does represent a time too -- I'd prefer something I can semantically add to some other time (even if it's just a newtype around Hz that has different arithmetic sematnics)
<re_irc>
< (@adamgreig:matrix.org)> I guess if you had Rate<1, 1> then 20 ticks is 20Hz is 1/20th of a second as a period
<re_irc>
< (@chrysn:matrix.org)> (Frankly, I'd have just put "Hz" in as a duration time, but I'm the reviewer, and the original author of the HAL impl wasn't too happy with it, and on further consideration I see how there is a difference in usage)
<re_irc>
< (@adamgreig:matrix.org)> you can use your own time types too, unfortunately this sort of mess is why they've been removed from 1.0 for now
<re_irc>
< (@chrysn:matrix.org)> Yeah, that's something I'll have to deal with in addition :-/
<re_irc>
< (@adamgreig:matrix.org)> integer duration means you can't represent sub-1Hz frequencies which is a pain too
<re_irc>
< (@adamgreig:matrix.org)> anyway, I think for interoperability the fugit types are nice because they're somewhat widely used (but by no means universal)
<re_irc>
< (@chrysn:matrix.org)> I lost track of too many changes toward 1.0; busy year. I figure I'll be using 0.2.max types for some time still, possibly re-exporting the traits for them to be easily available to users.
<re_irc>
< (@adamgreig:matrix.org)> but you could also punt on it for now, provide equivalent methods on your hal structs directly without impling a trait using whatever units/scaling seems nice, and wait for e-h 1.0?
<re_irc>
< (@chrysn:matrix.org)> : Yeah, then fraction types would be the thing.
<re_irc>
< (@adamgreig:matrix.org)> that's fair, but whether Pwm ever graduates from "unproven"...
<re_irc>
< (@adamgreig:matrix.org)> what's the issue with using fugit's Rate again? you can add/subtract even if it's sort of meaningless, but you can also convert to a duration in whatever scale/units you want and then do maths there
<re_irc>
< (@chrysn:matrix.org)> Its semantics are not quite those of a duration, but those of a frequency. They're equivalently interconvertible, but their operations have different semantics -- adding durations is different from adding frequencies.
<re_irc>
< (@chrysn:matrix.org)> Granted, this would be more relevant if anything was _demanded_ from the type in terms of implementing some addition, but if something gives me two durations and there is an implementation to add them, I'd expect them to be added as a sum of durations and not as the reciprocal of the sum of their reciprocal durations.
<re_irc>
< (@chrysn:matrix.org)> But yeah, maybe that is not too bad, and having a frequency as a duration is fine enough as long as we're dealing with the trait-as-it-is-now.
<re_irc>
< (@adamgreig:matrix.org)> sure, but I mean, you can ask the user for a Rate and then immediately convert it to a Duration if you want to use that internally/operate on it
<re_irc>
< (@chrysn:matrix.org)> OK, thanks for your input, I'll summarize and reference it on the issue, see where things go from there.
* re_irc
(@chrysn:matrix.org) bangs his head on the table after finding that a long series of refactoring ultimately fails to deliver because "static"s (even inside a function) need their types writable.
<re_irc>
< (@chrysn:matrix.org)> I don't suppose there is a magic trick around static-cell that allows me to handwave over the type of the static without using TAIT?
<re_irc>
< (@jamesmunns:beeper.com)> I don't think statics can use generic parameters at all, unfortunately
<re_irc>
< (@jamesmunns:beeper.com)> Maybe tait helps with that, but you can't use generics to monomorphize multiple statics
<re_irc>
< (@chrysn:matrix.org)> I don't need (open) generics, I just can't name the type because it contains type names the used crates don't make public, and also the it's a mess (it'd be, like, 4-5 layers of horrible name variations down; even if I convinced all upstreams to make their name pub, the name would easily span 4 lines)
<re_irc>
< (@chrysn:matrix.org)> I don't need to, there's one defining use for TAIT, and just a single static of single well-known (just not well-namable) type.
<re_irc>
< (@chrysn:matrix.org)> The crucial type I can't easily name is the "HT" -- it's an (unnamable due to the choices of the ".with_wkc()" implementation) unnamable type, and inside there is one layer of "LeftOrRight<..., LeftOrRight<..., NeverFound>>" with some wrapper type at the "..." position, and I shudder to write out what'd happen if I used that builder pattern a few steps longer.
<re_irc>
< (@chrysn:matrix.org)> The whole instance is probably still just 3-4 pointers large, but its name isb̵͎͎̘̘̞͍̦̩̰͖̎̿̀͑̒̑̆͑̚å̴̼͙̠̩̰͉͙̃͊̍̈́͠d
<re_irc>
< (@chrysn:matrix.org)> * is b̵͎͎̘̘̞͍̦̩̰͖̎̿̀͑̒̑̆͑̚å̴̼͙̠̩̰͉͙̃͊̍̈́͠d
<re_irc>
< (@chrysn:matrix.org)> I've looked at lazy_static, but it also takes a type, as does once_cell.
* re_irc
(@chrysn:matrix.org) bites down on his pride and uses an allocator.
<re_irc>
< (@chrysn:matrix.org)> They do happen to be available on these systems, and allocations at startup don't hurt this badly. When push comes to shove, I can estimate the size, and have a static bump allocator that's just big enough for these two things.
<re_irc>
< (@chrysn:matrix.org)> By the way, to wrap up: After resorting to boxed I piped the type through type_name_of_val: it's "&mut riot_wrappers::coap_handler::GcoapHandler<coap_handler_implementations::wkc_implementation::WellKnownCore<coap_handler_implementations::forking::ForkingHandler<coap_handler_implementations::wkc::ConstantSingleRecordReport<riot_module_stdio_coap::stdin::StdinHandler<128>>,...
<re_irc>
< (@chrysn:matrix.org)> and yeah, there's not only a type there that I can't name because it's from a private module, there's also something in there that's the output of RPIT ("fn new_dispatcher() -> impl Handler + Reporting")
<cr1901>
Does this have to do with the trait sig for Flavor?
<re_irc>
< (@jamesmunns:beeper.com)> Maybe, that's a lot of lifetime shenanigans, and I don't have my thinking cap on
<re_irc>
< (@jamesmunns:beeper.com)> What are you trying to achieve?
<re_irc>
< (@jamesmunns:beeper.com)> Like, big picture what are you using flavors for?
<cr1901>
Read sequentially from AVR EEPROM, since it's not in the same address space as flash
<re_irc>
< (@jamesmunns:beeper.com)> Flavors want to borrow data for things like strs, like your info str
<re_irc>
< (@jamesmunns:beeper.com)> If you can't keep a reference to that, you need to buffer it somewhere
<cr1901>
So I want to read into a buffer I passed into the Seq data structure, specifically for this
<cr1901>
like a bump allocator
<cr1901>
Anything that's not an array/string doesn't need to occupy redundant RAM space for a copy of the EEPROM
<re_irc>
< (@jamesmunns:beeper.com)> You probably need to indicate the lifetime of the internal buffer separate from 'de
<re_irc>
< (@jamesmunns:beeper.com)> Probably make a Vec, the use that to create a flavor instance, with the deser'd type being the same lifetime as the borrow of your vec thing
<re_irc>
< (@jamesmunns:beeper.com)> Whatever you are sticking thing borrowed strs and things into
<cr1901>
Ahhh
<re_irc>
< (@jamesmunns:beeper.com)> This is relevant, i think the pr to add support for Io read/write is hitting the same issue roughly.
<re_irc>
< (@jamesmunns:beeper.com)> So I might make a little demo for that, not sure when tho
<cr1901>
anyways, I don't understand why it's returning with lifetime '1 at all... I guess self.buf (where buf has type &'de [u8]) actually gives a &'a [u8] inside a function taking &self?
<re_irc>
< (@jamesmunns:beeper.com)> Haven't looked too deep, not sure.
<cr1901>
if it doesn't work, I'm stuck w/ the crate not being very useful on AVR potentially... shame
<re_irc>
< (@jamesmunns:beeper.com)> 'de generally means "the lifetime where the input buffer remains valid"
<re_irc>
< (@jamesmunns:beeper.com)> So you definitely need a separate 'buf lifetime for "the time that the side buffer is valid".
<cr1901>
Yea, the version that compiles was also the wrong path (because once you call bump once you can't call it again)
<re_irc>
< (@jamesmunns:beeper.com)> You probably need some trickery like split at mut
<re_irc>
< (@jamesmunns:beeper.com)> But I'm also not 100% certain that would work
<cr1901>
Linked code uses split_at_mut... I'm just mulling over/minddump. Please don't feel obligated to respond, you gave me some ideas :)
<re_irc>
< (@jamesmunns:beeper.com)> I'm not _certain_ postcard's current public interfaces can express a deserialized type bound by a lifetime other than that of the input buffer.
<cr1901>
Must be great to see me using postcard in ways you didn't intend, yes? :)
<re_irc>
< (@jamesmunns:beeper.com)> (where "'a" is the input buffer)
<cr1901>
There _isn't_ really an input buffer before deserialization starts. It's created on-the-fly. This would be great for a Vec if I had alloc, but I don't
<re_irc>
< (@jamesmunns:beeper.com)> Yeah
<cr1901>
I'm about to cave and make it a const generic array
<cr1901>
that's owned by Seq
<re_irc>
< (@jamesmunns:beeper.com)> I don't know if that would actually help
<re_irc>
< (@jamesmunns:beeper.com)> I do think this is the same problem the io traits pr has tho
<re_irc>
< (@jamesmunns:beeper.com)> serde.rs does talk about deserialize lifetimes, there's generally three options: 1. owned, 2. ephemeral borrows, 3. "'de" borrows
<re_irc>
< (@jamesmunns:beeper.com)> but you are trying to describe something that is none of those three
<re_irc>
< (@jamesmunns:beeper.com)> e.g. you pop "ephemeral borrows" out of your eeprom reader, but you want it to end up working sort of like "'de" borrows (but not "'de")
<re_irc>
< (@jamesmunns:beeper.com)> alloc "cheats" here by taking "transient" borrows and turning them into "owned" data, e.g. reading a str, and turning it into a String
<re_irc>
< (@jamesmunns:beeper.com)> okay, i'm sufficiently intrigued, lemme see what I can hack up before I need to take my dog for a walk.
<cr1901>
Apologies :P
<cr1901>
In any case, >For example when deserializing from an IO stream no data can be borrowed.
<cr1901>
I can't seem to express "copy to a buffer that lasts longer than 'de"
<re_irc>
< (@jamesmunns:beeper.com)> I'm cheating a little bit, but that should get you in the ballpart, assuming your eeprom interface allows you to pop bytes at a time?
<cr1901>
yes
<cr1901>
the eeprom interface is a linear scan
<cr1901>
of the bytes in a separate address space
<re_irc>
< (@jamesmunns:beeper.com)> the trick was to tie the "'de" lifetime to the lifetime of the interning buffer, not any input or anything
<cr1901>
type Remainder = (); <-- I forgot "()" was a type for the past hour lmao
<re_irc>
< (@jamesmunns:beeper.com)> lol
<cr1901>
Anyways, I will take a look and adapt to my needs, tyvm
<re_irc>
< (@jamesmunns:beeper.com)> you actually probably should define the source and remainder types, if you don't you won't be able to "compose" the flavor, e.g. with a cobs or crc flavor
<re_irc>
< (@jamesmunns:beeper.com)> but I was lazy, and this was a demo.
<cr1901>
Yea, Idk what the types should be
<cr1901>
Source I guess is "u8", and Remainder is "the part of the interned buffer that was unused"
<cr1901>
Another advantage to this- you can store postcard data on an I2C eeprom
<re_irc>
< (@jamesmunns:beeper.com)> Yeah actually in this case
<re_irc>
< (@jamesmunns:beeper.com)> you might not actually be able to really compose this sort of flavor, or rather this is the "storage" flavor. I dunno off the top of my head
<cr1901>
Go walk your dog and mull it over if you want :)
<re_irc>
< (@jamesmunns:beeper.com)> I wonder if I should be more strict about using "pop" vs "try_take_n", since the latter should (?) only be used for taking borrowed slices like "&[u8]" and "&str".
<re_irc>
< (@jamesmunns:beeper.com)> if you used it for something else, it'd get inadvertently interned here.
<re_irc>
< (@jamesmunns:beeper.com)> yeah, pretty much. We just use it for filling into a temporary buffer before creating the actual f32/f64/char
<re_irc>
< (@jamesmunns:beeper.com)> I just used "try_take_n" for perf reasons instead of "pop" to avoid error checking N times
<cr1901>
I guess try_take_n_owned would have limited utility (or by default could call try_take_n and then clone)
<cr1901>
Idk, I don't use floats in embedded Rust, and chars probably aren't a great idea to store either
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, it's mostly that theres no distinction between "take N because we want to borrow it" and "take N just because I know how many bytes I need right now"
<cr1901>
(should there be a distinction?)
<re_irc>
< (@jamesmunns:beeper.com)> there hasn't needed to be one until now
<cr1901>
Sorry :P
<re_irc>
< (@jamesmunns:beeper.com)> hey, you can only build for use cases you can imagine :)
<re_irc>
< (@jamesmunns:beeper.com)> but this and the io traits have similar needs
<cr1901>
BufferedWindow from the io traits is probably similar to what I actually need, but I haven't looked closesly
<re_irc>
< (@jamesmunns:beeper.com)> yeah, that would be if you wanted to read a block from the eeprom at a time into ram
<re_irc>
< (@jamesmunns:beeper.com)> (instead of one at a time). It's basically like reading into a buffer with the Read trait.
<re_irc>
< (@jamesmunns:beeper.com)> but adding a new default method to the trait shouldn't be a big deal, and I can switch the internal usages into that.
<cr1901>
yea, that's also reasonable/doable. I am doing "one byte at a time" to minimize memory usage
<cr1901>
using a bufferedwindow won't stop the need for interning
<re_irc>
< (@jamesmunns:beeper.com)> yup
brazuca has joined #rust-embedded
<re_irc>
<Orange_Murker> Sorry for noob question. Where can I see which clocks are used by default for my particular board in stm32f4xx-hal if I don't set them with rcc.cfgr?
<re_irc>
<Orange_Murker> * a noob question. Where can I see which clocks are used by default for my particular board in stm32f4xx-hal if I don't manually
<re_irc>
< (@ithinuel:matrix.org)> Does anybody know about rust-iot and/or has tried to do some 6lowpan stuff in rust?
<re_irc>
< (@dirbaio:matrix.org)> smoltcp can do 6lowpan
<re_irc>
I'm exploring what would it take to build something that could carry tiny payloads over ~8km (~5miles) (not line of sight though) 😄
<re_irc>
I'm over optimistic but there's learning opportunities 🙂
<re_irc>
< (@dirbaio:matrix.org)> I don't think ieee802154 can do 8km? with super-directional antennas and/or ignoring the max legal tx power limits maybe lol
<re_irc>
< (@ithinuel:matrix.org)> my knowledge there is near 0 so that's highly likely not what I need 😄
<re_irc>
> The concept of IEEE 802.15.4 is to provide communications over distances up to about 10 metres and with maximum transfer data rates of 250 kbps
<re_irc>
< (@ithinuel:matrix.org)> I'll need to look for something else 😆
<re_irc>
< (@dirbaio:matrix.org)> you _just_ need it to go 1000 times more distance, no big deal
brazuca has quit [Quit: Client closed]
<re_irc>
< (@jamesmunns:beeper.com)> I think the zolertia folks got some pretty ridiculous long range radio stuff working on 802.15.4, but yeah, super directional antennas for a single point to point link.
<re_irc>
< (@jamesmunns:beeper.com)> : fwiw, lora/lorawan is typical for these kinds of ranges.
<re_irc>
< (@ithinuel:matrix.org)> That's what I had in mind initially but it turns out the shield I salvaged from a clear out were some ATZB-RF (AT86RF212 based modules).
<re_irc>
< (@dirbaio:matrix.org)> oh huh so ieee802154 also has subghz phys. I thought it was just 2.4ghz
<re_irc>
< (@dirbaio:matrix.org)> so yea perhaps you can get better range with those