<cr1901>
JamesMunns[m]: Sorry for the Voyager 1 latency... CoAP looks cool. I wonder if there's a curl tool for it? I have a notifier app using JSON-RPC, that takes a bit too many resources for my liking (because I compile it on the same 32-bit ARM SBC that runs it). Maybe postcard+CoAP plus an ad-hoc mini async server plus "curl app to send codes to server" would serve me better.
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
vancz has quit [Server closed connection]
vancz has joined #rust-embedded
bitob[m] has joined #rust-embedded
<bitob[m]>
<JamesMunns[m]> "I'm thinking about poking around..." <- As Jan-Henrik said, there is coap-zero (no-std, no alloc) from the Fraunhofer-IML Rust Embedded Group under die OLFL-1.3 license. There was not too much further development the last month, but we have the crate in use for our lwm2m experiments, so it works for us. If the crate is interesting for you, feel free to get in touch.
starblue has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
starblue has joined #rust-embedded
<JamesMunns[m]>
<cr1901> "James Munns: Sorry for the..." <- Not sure! Back in the day (a few years ago) I remember using a browser plugin to do something like that.
<JamesMunns[m]>
<bitob[m]> "As Jan-Henrik said, there is..." <- Thanks! It's definitely very interesting. I've used coap in the past, and was looking around for inspiration on maybe using a more standard/off the shelf protocol with more defined semantics.
<JamesMunns[m]>
Though I am also somewhat interested in concurrent request handling (in coap: NSTART > 1), as well as easier dispatching based on URIs
<JamesMunns[m]>
I uh, actually invented something yesterday that handles a good bit of that, I'm not sure if I plan to keep going down that route or taking some of the techniques and applying it to coap. My thing is really only handling routing and schema validation, so it still might benefit from combining it with coap for better defined protocol semantics
<JamesMunns[m]>
Still very messy/boilerplate-y, but it gives you a hashmap-like dispatcher, and with some embassy features, you can have per-URI concurrency limits
<JamesMunns[m]>
I also actually do a think where I used blake2s to hash(URI + schema) to get 8-byte unique identifiers, rather than sending the full URI, so you can use the same message type on different "paths"
<Noah[m]>
AdamHott[m]: > <@greengenie:matrix.org> Hi all, I had success flashing a micro:bit V2 with the led-roulette example from the Discovery book, the application is flashed and the micro:bit V2 is performing as expected, but had an error with RTT during the flashing process:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/sfTPAXNiEPwREtxEUKnQlGKQ>)
Guest7221 has quit [Server closed connection]
<AdamHott[m]>
i didn't enabe RTT in the firmware, not sure how to do that
<AdamHott[m]>
And I don't know how to locate the SVD file... :/
<AdamHott[m]>
Oh wait I found the SVD I think
<AdamHott[m]>
I was able to edit the SVD file and the debug session is working without errors, I'll continue to look into this RTT firmware enablement
Jan-Henrik[m] has quit [Quit: Idle timeout reached: 172800s]
mabez[m] has joined #rust-embedded
<mabez[m]>
FYI to the RISC-V team, I submitted a PR upstream to add imafc bare metal targets: https://github.com/rust-lang/rust/pull/117874, if you wouldn't mind giving it a once over
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Small announcement for usb-users, I've finally kicked out usb-device 0.3: https://crates.io/crates/usb-device - there's probably downstream ripple into many HALs/various drivers as well
chrysn[m] has joined #rust-embedded
<chrysn[m]>
<jan-henrik> "There is also this library on..." <- Nice, this will be a good test case for whether coap-handler (and the upcoming coap-request) will also manage to abstract over one more CoAP Rust implementation.
<chrysn[m]>
(And the fact that I only now learned of this indicates that both I need to search better outside crates.io, and conversely that crates are much better discoverable if they are uploaded there)
<chrysn[m]>
<JamesMunns[m]> "Thanks! It's definitely very..." <- > <@jamesmunns:beeper.com> Thanks! It's definitely very interesting. I've used coap in the past, and was looking around for inspiration on maybe using a more standard/off the shelf protocol with more defined semantics.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BwwihjfGCKxJJWRHrpZgsBmv>)
<chrysn[m]>
For CoAP there is FASOR being worked on -- and while this doesn't change the NSTART, it changes the RTT estimate, which is often the thing that is really bugging users who want to change NSTART.
<JamesMunns[m]>
Interesting! I realized that how I'm building things I sort of want to act a bit like a reverse proxy, actually, in that different "services" downstream may have different concurrency capabilities, in that you might be able to have 3x in-flight requests for one message, but only 1x in-flight for another kind of message.
<JamesMunns[m]>
My actual use case is for clients/servers over a direct link, such as USB and/or serial, so again I have a bit more of a specialized knowledge about the use case
<chrysn[m]>
I didn't get the Voyager context; James Munns, what are you building? (If it's stdout-over-CoAP, there's a sketch for that, and a partial implementation)
<chrysn[m]>
* partial implementation) [edit: ah, no, it's about postcard w/ schema; could be in discovery metadata]
<chrysn[m]>
* partial implementation) \[edit: ah, no, it's about postcard w/ schema; could be in discovery metadata\] [edit2: race condition...]
<chrysn[m]>
In that case yes, NSTART=1 is not really essential, but then there's the question of the transport in general:
<JamesMunns[m]>
coap was one potential way of defining that protocol, because it has a lot of semantics defined. But I admittedly don't need all the semantics
<chrysn[m]>
* If you're going over UDP (via USB-CDC-ECM or similar), you can't know it's just a USB link
<chrysn[m]>
* If you're going over serial, there is slipmux that inherits NSTART limitations, but they can be argued away way more easily
<chrysn[m]>
* I'd actually send CoAP over USB directly (mentioned briefly at the last IETF on the topic of CoAP alternative transports), which would possibly not have any NSTART concept to begin with
<chrysn[m]>
Indeed the host-side part would then do proxying, and depending on the transport, that'd also be unbounded w/rt open requests (esp. if it's a web browser that does WebUSB on one side and WebSockets on the other, just to be reverse-proxied again in the cloud ... yes, quite feasible :-) )
<JamesMunns[m]>
right now I'm using CDC-ACM as a sort of slip (but not even the IP part, it's assumed src and dest are implicit), though I'll switch to "raw" USB instead
<JamesMunns[m]>
yeah, I've written various flavors of that exact concept over the years :D
<JamesMunns[m]>
I'll have to look at slipmux and see how they chose to do it. I tend to just use COBS for framing and call it a day :p
<chrysn[m]>
COBS is way nicer than what SLIP does, yes :-)
<JamesMunns[m]>
oh no, does it use DLE/ETX byte stuffing or something?
<chrysn[m]>
It uses whatever SLIP uses
<chrysn[m]>
At any rate, I agree it's a good interface to easily have pluggable extensibility (just one more resource / handler), especially b/c the host can transparently forward it (unless the application says it can't by including proxy-unsafe options that the proxy then needs to know)
<JamesMunns[m]>
Yeah, I hadn't actually considered proxying-on the interface, when I was talking about a reverse proxy I meant entirely on the device.
<JamesMunns[m]>
but, that's a good point for coap and using a standard: there's tooling and semantics for that if I wanted to offer that kind of access
<JamesMunns[m]>
and ideally writing a device-specific driver crate to allow that should be no harder than say, wrapping a REST API, and allow you the same options for concurrency if you want multiple in-flight requests
<chrysn[m]>
What precisely do you mean by in-flight requests? Because:
<chrysn[m]>
* NSTART is how much may be in flight between the CON request and the ACK response. That may or may not correspond to
<chrysn[m]>
* (there is no parameter for) requests that have been received and not sent a response (or, in case of observations, their last response) yet. Of those you can have as many as you want (but the server may at some point say 5.03 I'm Busy or or 4.29 Slow It Down Buddy)
<chrysn[m]>
Is "Response" here the "I'm done with it here's the data" or just a "OK yeah I'm working on it"?
<chrysn[m]>
(which a CoAP server would send in the same message if the task is done quickly)
<JamesMunns[m]>
unspecified so far, I'm familiar with coap's "ok im working on it hold on")
<dirbaio[m]>
usb can't lose packets, so "ACKing" the request is not very useful
<JamesMunns[m]>
I think there's room for "you sent me a valid request but I immediately say no"
<JamesMunns[m]>
vs "I say yes now, but it'll take me some time to get you the answer"
<dirbaio[m]>
first is just an error response
<dirbaio[m]>
second is a success response that takes a while to arrive
<JamesMunns[m]>
(usb totally can lose messages tho, it uses a crc16 and bit errors affect us all)
waveguide[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I admit it is rare tho :p
<dirbaio[m]>
lol
<dirbaio[m]>
well all standard usb classes are designed based on the assumption that usb doesn't lose data
<dirbaio[m]>
same as you'd design a protocol over TCP
<chrysn[m]>
<dirbaio[m]> "usb can't lose packets, so "..." <- Yeah, a CoAP-over-USB might easily not even have an NSTART, and whatever you send it is regarded as enqueued (and I think there's some flow control by which the device can NACK things to avoid unbounded memory)
<dirbaio[m]>
yea, usb has builtin backpressure: the device can slow down reading requests to get the host to slow down
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
m5zs7k has quit [Ping timeout: 255 seconds]
m5zs7k has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
Farooq has quit [Quit: Idle timeout reached: 172800s]
<chrysn[m]>
If I'm implementing a protocol (yes CoAP :-) ) on embedded-nal-async and I need timing, I take the embedded-hal-async delay as a time source. What do I take when I need a source of low-grade randomness? embedded-hal's rng is both unproven and sounds more like a hardware number generator.
<JamesMunns[m]>
that's an impl and not a trait, though
<JamesMunns[m]>
and you will still need an entropy source/seed.
<dirbaio[m]>
rand_core::RngCore
<chrysn[m]>
The rand_core looks like I can take a rand_chacha as an instance, so I'll take the more generic one and trust the compiler to monomorphize as efficiently as if I'd only ever have taken one :-)
<JamesMunns[m]>
yeah, that's definitely what I'd recommend for a library
<chrysn[m]>
Oh, rand_core is sitting *below* chacha
<chrysn[m]>
(looks confused)
<chrysn[m]>
... but their shared docs look grokable enough.
<JamesMunns[m]>
the rust-crypto ecosystem uses traits and implementations... extremely creatively
<JamesMunns[m]>
I'd uh, suggest leaning heavily on rust analyzer and dot completion
<dirbaio[m]>
typenum, generic-array ð
<dirbaio[m]>
rand_core alone is not that bad fortunately
<JamesMunns[m]>
entire algorithm implementations are just macros, from other crates, etc. etc.
<JamesMunns[m]>
I literally just had to figure out how the blake2 crate works lol
<JamesMunns[m]>
But yeah, if your library takes an R: RngCore, then your users can pass in a ChaCha8Rng and it will work.
<chrysn[m]>
Hm, makes me wish once more for docs.rs cross-crates "implemented by"
<JamesMunns[m]>
idk if this is a reason to not do it, but you could totally grief with that. Publish a crate with a type AAAAAAAA to be at the top of the list and just say "James was here"
<JamesMunns[m]>
and it would be impossible to render the page for serde::Serialize lol
<JamesMunns[m]>
(opt in lists would be very cool indeed tho)
<chrysn[m]>
Rank by download counts and ... oh no, even worse griefing. (Then OTOH, those probably violate crates.io ToS, or at least docs.rs's ToS, so shrug).
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
<JamesMunns[m]> "idk if this is a reason to not..." <- I am in favor of doing this as incentive to crates team to address the problem
<firefrommoonligh>
* In reply to @jamesmunns:beeper.com
<firefrommoonligh>
idk if this is a reason to not do it, but you could totally grief with that. Publish a crate with a type AAAAAAAA to be at the top of the list and just say "James was here"
<firefrommoonligh>
I am in favor of doing this as encouragement to the crates team to address the problem
<JamesMunns[m]>
> the problem
<JamesMunns[m]>
What problem?
<dirbaio[m]>
the squatting problem I guess
<dirbaio[m]>
there's good news re that, the new policy RFC got approved and they're probably going to nuke the heaviest squatters :D
<JamesMunns[m]>
oh no it's "talk about name squatting" day, gotta go lol
JonathanDickinso has joined #rust-embedded
<JonathanDickinso>
AFAIR crates.io will hand over parked crate names if you ask and they have the time
<dirbaio[m]>
they didn't because there was no policy outlining when is that allowed
<dirbaio[m]>
the new policy fixes that, so they can now
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
<ryan-summers[m]> "adamgreig: Any chance i can..." <- sure, done
StephenD[m] has joined #rust-embedded
<StephenD[m]>
Anyone use the flash on the stm32f411 for storing data before? Wondering how I should best go about that - specifically the reading and writing binary data to one chunk of flash (I can handle the serialization/deserialization)
<chrysn[m]>
Is that one of those where you have to write big areas of the flash (say 512 bytes) in one go b/c it's internally checksumming?
<StephenD[m]>
I'm not sure if that's the reason why but I do believe you need to at least erase big chunks at once
<dirbaio[m]>
it doesn't have ECC
<dirbaio[m]>
it does have annoyingly huge erase sectors, 128kb!
<adamgreig[m]>
the first four sectors are 16kB, then a 64kB, then the remaining 3 are 128kB
<adamgreig[m]>
so if you can put a small bootloader in sector 0, you can put config in sector 1, and your firmware starting from sector 2
<dirbaio[m]>
want to do a-b updates? pay more for a dual bank bigger chip ðĪŠ
<diondokter[m]>
StephenD[m]: Ah, then just see of your HAL already implements it
<adamgreig[m]>
I mean, if your firmware fits into a bit less than half the flash, you can still have a bootloader in sector 0, use 1-5 as A, and 6-7 is 256kB of B
<adamgreig[m]>
it's just less convenient than the actual dual bank ones
<spinfast[m]>
I guess its a minlp problem, I've read now the simplex LP algorithm works before, and that's pretty neat, but wow, minlp seems like a whole other thing
<spinfast[m]>
1.6s to find optimal clock settings seems reasonable, now I need to expand it for the whole clock tree âïļ
<spinfast[m]>
and stuff it in a build.rs ;-) ;-) ;-)
<adamgreig[m]>
what difficulty of problem are you solving? can you constrain it to integer MHz?
<spinfast[m]>
* and stuff it in a build.rs
<spinfast[m]>
pll with a series of dividers providing audio clocks to multiple audio peripherals
<StephenD[m]>
So should I just use this and call it with `nth(...)` to get the specific sector I care about?
<adamgreig[m]>
for stm32 clock trees it's usually really really quick because you want the pll input to be 1-2MHz, so with integer MHz input clock you divide by the clock (odd) or half the clock (even), then a couple of small problems to get the right output freqs for audio/usb/can/etc
<adamgreig[m]>
I guess if it's audio then you usually don't have round MHz frequencies
<adamgreig[m]>
less convenient :P
<chrysn[m]>
adamgreig[m]: ... or something like that, yes -- but if you want to do journaling of your config (I insist that "do not remove power supply now" is for 90s era console game saving) and recovery including config, you're down to 128k firmware quite quickly
<adamgreig[m]>
chrysn: sure, and then you buy a chip with more flash, they sell plenty of them :P
<spinfast[m]>
its not, because for audio you have varying sample rates and TDM settings (e.g. N channels multiplexed into a serial stream at B bitrate)
<adamgreig[m]>
lots of use cases just don't ever need to bootload new firmware, though
<adamgreig[m]>
and flash is probably one of the most expensive bits of the chip, so it makes sense to sell models with less of it, I think
<spinfast[m]>
* its not a round MHz settings, for audio and for imxrt in particular I may have varying sample rates and TDM settings (e.g. N channels multiplexed into a serial stream at B bitrate) to M peripherals with variations
<StephenD[m]>
diondokter[m]: Ah cool, ty
<spinfast[m]>
* its not a round MHz settings, for audio and for imxrt in particular I may have varying sample rates and TDM settings (e.g. N channels multiplexed into a serial stream at B bitrate) to M peripherals with variations.
<spinfast[m]>
On rt685 this gets even more complex as there's even more flexcomm (serial audio) interfaces for arrays of dmics I guess?
<spinfast[m]>
I mean I guess there's probably some simple math I could've done to get there... but the solver seems cool, and maybe lets me write constraints and and get a clock tree like cubemx or mcux config might try and do
<spinfast[m]>
* and do, but programatically
<spinfast[m]>
I didn't see mcux config trying to generate a sane clock tree though, it just graphically showed it and let me tweak the numbers (maybe I missed it), I swore cubemx did try and generate the settings for one given desired peripheral clocks?
<spinfast[m]>
been forever since I used it
<dirbaio[m]>
cubemx does try to generate one yep
<dirbaio[m]>
the UI is a bit confusing, you put numbers in and it recalculates the others, so it's not obvious what's a constraint and what's an ouptut
<spinfast[m]>
sadly it seems the apopt optimizer is proprietary, I guess gekko must be doing something to use it... wonder if there's a FOSS equivalent
<diondokter[m]>
Haha yeah, just wanted to suggest that too
<dirbaio[m]>
don't use ekv if your store is small though, the "setup cost" is way higher, you need 10+ sectors if you want good perf
<diondokter[m]>
Very similar, but they are each better for different data. Well, as long as you don't need checksums haha
<chrysn[m]>
Raw NOR flash sounds like it's relying on per-bit writes; my impression is that that's getting increasingly rarer.
<diondokter[m]>
Usually it's per word. And it differs per chip how big a word is
<dirbaio[m]>
ekv writes only once to each "word" after erase, and the word size is configurable. so it works on chips with ECC flash
<diondokter[m]>
It's the erasing that's the real problem
<diondokter[m]>
Sequential storage map writes once too. The queue writes twice
<diondokter[m]>
But that's why we have multiple traits for it
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
Socke has quit [Ping timeout: 252 seconds]
Socke has joined #rust-embedded
<spinfast[m]>
dirbaio: I don't see how z3 might solve a constraint minlp problem off hand, though I could be wrong
<spinfast[m]>
s/constraint//
<dirbaio[m]>
I dunno, I haven't messed with it. from their readme it seems it can do some optimization
<dirbaio[m]>
if anything you can make the "cost" to optimize into a variable and add "where cost < N" and keep running it over and over tightening it
<dirbaio[m]>
* if anything you can make the "cost" to optimize into a variable and add a "where cost \< N" clause and keep running it over and over tightening it
<dirbaio[m]>
I have no idea if that's the way you do it or there's "builtin" optimization support
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]