ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
richardeoin has quit [Ping timeout: 268 seconds]
richardeoin has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
slabity[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> <dirbaio[m]> "if it's just at startup the..." <- just at start up. I suggest basically that.
AtleoS has quit [Ping timeout: 255 seconds]
AtleoS has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> I am a bit confused by the new RCC api in embassy-stm32. I used to do "config.rcc.mux = ClockSrc::HSE" but I don't know what this should be now
<dirbaio[m]> config.rcc.mux is renamed to config.rcc.sys
<Ecco> oh ok cool thanks
<dirbaio[m]> since it's what chooses the sysclk
<Ecco> yes, makes sense
<AdamHott[m]> Is there an RTIC room on matrix?
haobogu[m] has joined #rust-embedded
<AdamHott[m]> thanks!
crabbedhaloablut has quit []
AtleoS has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
atesterlol[m] has joined #rust-embedded
<atesterlol[m]> yo
<atesterlol[m]> anyway to force read to read minimum amount of bytes/
<atesterlol[m]> s//`/, s//`/, s///?/
<atesterlol[m]> s//`Read::/, s//`/, s///?/
<atesterlol[m]> i thought maybe to use take, but im not sure how performant efficient it is
<atesterlol[m]> JamesMunns[m]: > <> ```rust... (full message at <>)
<JamesMunns[m]> I guess that's "read_exact", but maybe that helps :D
<JamesMunns[m]> ah, shoot!
<atesterlol[m]> im not executing read
<atesterlol[m]> im using io::copy which executes the read method of a struct which implements Read
<atesterlol[m]> in this implementation im calling read of a specific member of the struct. the problem is it stops suddenly even tho there is more space at the buffer
<JamesMunns[m]> yep, `Read::read` returns when ANY contents are immediately ready:, but `io::copy` should retry until either the buffer is filled or "EOF" is returned:
<JamesMunns[m]> if your input is returning EOF, e.g. Ok(0), then that sounds like a bug in your source.
<JamesMunns[m]> There's no way to "force" it to read at least N bytes.
<JamesMunns[m]> (other than wrapping your source and buffering manually, I guess)
<atesterlol[m]> JamesMunns[m]: yep it doesnt do it for some reason
<atesterlol[m]> actually, it might be that it is
<JamesMunns[m]> "it doesn't do it", can you share what your source is?
<atesterlol[m]> no im mistaken
<dirbaio[m]> read() is allowed to return less bytes, even if more are immediately ready
<JamesMunns[m]> dirbaio[m]: yeah but io::copy retries if read returns not enough
<dirbaio[m]> there's no guarantee it returns ALL the ready bytes in a single calll
<dirbaio[m]> s/calll/call/
<dirbaio[m]> that's how it works
<atesterlol[m]> i meant, in my implementation read, i do more operations of buf, which is important that buf will be filled
<atesterlol[m]> dirbaio[m]: i know, im looking ofr a solution
<atesterlol[m]> atesterlol[m]: by the way these operations are encryption
<dirbaio[m]> so
<atesterlol[m]> s//`/, s/,/`,/, s/of/on/
<atesterlol[m]> so if its not completely filled, i cant decrypt
<atesterlol[m]> because it depends on nonce and other enc stuff
<dirbaio[m]> you want to implement a Read adapter that reads encrypted bytes from an underlying Read, and returns decrypted data?
<atesterlol[m]> ya
<atesterlol[m]> i already implemented
<atesterlol[m]> but the problem is it doesnt fill the buffer
<dirbaio[m]> you usually do that by storing a buffer in self
<atesterlol[m]> atesterlol[m]: > <> i mean,... (full message at <>)
<dirbaio[m]> big enough for one "block"
<atesterlol[m]> * when i get to line 5, it doesnt fill \`buf`
<dirbaio[m]> so
<dirbaio[m]> the key is you can "leave" data in self.buf
<dirbaio[m]> either "half-read" encrypted packet
<dirbaio[m]> * either a "half-read" encrypted block
<dirbaio[m]> or a "half-returned" decrypted block
<dirbaio[m]> so you can keep that data across read() calls
<atesterlol[m]> i dont need to keep the data
<atesterlol[m]> the data is already being transferred to another place
<atesterlol[m]> by using copy
<dirbaio[m]> you do if you want to implement read()
<dirbaio[m]> because the caller might read only 1 byte from you
<dirbaio[m]> if your block size is 64 bytes, you need to keep the other 63 bytes somewhere
<dirbaio[m]> to return in future read() calls
<atesterlol[m]> dirbaio[m]: this shouldn't for how i implemented read and write.
<atesterlol[m]> * this shouldn't happen for how
<atesterlol[m]> the write always writes 32kb, and read should read exactly 32kb, but it doesn't happen, it reads less
<atesterlol[m]> maybe i could use take, and then use read_to_end, tho im skeptical of the performance.
<dirbaio[m]> mhmhm
<atesterlol[m]> <JamesMunns[m]> "let mut buf = [0u8; 16]; // we..." <- > <> ```rust... (full message at <>)
<atesterlol[m]> * any idea on the performance of `take`? i guess its like this
<dirbaio[m]> if you want to implenent std::io::Read and be fully compliant with it you MUST support read() calls with any buffer size
<dirbaio[m]> even 1 byte
<atesterlol[m]> dirbaio[m]: yes it does
<dirbaio[m]> of course if you know you only use it with io::copy then you can take shortcuts
<dirbaio[m]> but then you're relying on the implementation details of io::copy
<dirbaio[m]> which is quite fragile
<atesterlol[m]> dirbaio[m]: its more efficient tho
<atesterlol[m]> which is why im trying to adapt to it
<atesterlol[m]> much more efficient, like twice as efficient
<dirbaio[m]> io::copy is just a loop of read() on the source, write() on the destination
<dirbaio[m]> there's no magic
<dirbaio[m]> it's the same as if you wrote such a loop yourself
<JamesMunns[m]> dirbaio[m]: (there is sometimes magic)
<JamesMunns[m]> JamesMunns[m]: but it doesn't have to be:
<dirbaio[m]> (there are some specializations if both src and dst are files or sockets or something, but they definitely won't apply to your "decrypting Read" wrapper)
<atesterlol[m]> dirbaio[m]: there is actually some magic
<atesterlol[m]> it reduces half of the syscalls i need
<dirbaio[m]> this magic doesn't apply with custom Read impls
<atesterlol[m]> it does since my Read method uses sockets
<dirbaio[m]> it only applies if src and dst are both plain old fd's
<atesterlol[m]> * since my `Read, * Read` method
<atesterlol[m]> s/Read/`read`/
<dirbaio[m]> if you wrap the reader with your own Read implementation written in plain old rust, it's not a plain old fd anymroe
<dirbaio[m]> s//`/, s//`/, s/anymroe/anymore/
<dirbaio[m]> and the magic no longer kicks in
<atesterlol[m]> it relies on the implementation of my socket
<dirbaio[m]> ¯\_(ツ)_/¯
<dirbaio[m]> just benchmark it when you're done implementing, you'll see what I mean
<atesterlol[m]> i also did benchmark it
<JamesMunns[m]> I think though the long answer to your question is that "there is no way to force read to always return in some increments".
<atesterlol[m]> got twice as fast
<JamesMunns[m]> the way to do it is to wrap it, and use a buffered reader or something
<dirbaio[m]> what did you benchmark
<atesterlol[m]> JamesMunns[m]: tho i did see `take`
<atesterlol[m]> but im not sure on the performance on it
<atesterlol[m]> dirbaio[m]: the program
<atesterlol[m]> used time command
<dirbaio[m]> :|
<dirbaio[m]> but you benchmarked fd-to-fd copy
<dirbaio[m]> * you benchmarked someting that does fd-to-fd copy
<dirbaio[m]> it's gotta be that
<dirbaio[m]> the moment you add a custom Read wrapper it's not a fd-to-fd copy anymore
<atesterlol[m]> dirbaio[m]: tho there is `sendfile`?
<atesterlol[m]> so what is special about copy?
<atesterlol[m]> oh i know why i got this implementation because it was fd-to-fd as you said
<atesterlol[m]> s/implementation/result/
<atesterlol[m]> but my reader is my own implemenation of Read
<atesterlol[m]> s/implemenation/implementation/, s//`/, s//`/
<dirbaio[m]> sendfile only works with FDs yep
<atesterlol[m]> and writer is plain old fd
<atesterlol[m]> so yes, but it still doesn't solve my original question tho
<dirbaio[m]> rust's stdlib is using specialization (a magic unstable Rust feature that can't be used from outside the stdlib yet) to mark some Read/Write types as "this corresponds to a plain FD from the kernel"
<dirbaio[m]> typically files and sockets
<dirbaio[m]> so io::copy uses a fast path if BOTH the source and destination are FDs
<dirbaio[m]> if not, it uses a plain old "read, write, repeat" loop
<atesterlol[m]> dirbaio[m]: i dont see where it cares about it
<atesterlol[m]> in src
<atesterlol[m]> generic_copy does what you mentioned
<JamesMunns[m]> dirbaio[m]: now THATs a doc comment
<atesterlol[m]> dirbaio[m]: well what does properties will return?
<atesterlol[m]> it extracts hints/metadata, which i guess part of the hints is that there is a socket inside...
<JamesMunns[m]> this is probably not the road you want to go down, btw, dirbaio was just telling you why it was working like that
<atesterlol[m]> anyway im not pretty sure how thats relevant since there is a performance improvment
<atesterlol[m]> JamesMunns[m]: the comment above isn't intended to you
<atesterlol[m]> JamesMunns[m]: btw he didn't explain why there is a performance improvement, i think he more was trying to say there isn't a performance improvement
<dirbaio[m]> i've said it like 3 times
<dirbaio[m]> there is a perf improvement ONLY if src and dst are BOTH files or sockets
<dirbaio[m]> which is not your case, src will be custom decrypting adapter.
<dirbaio[m]> so there won't be a perf improvement in your case
<dirbaio[m]> even if there was in your benchmark
<dirbaio[m]> because you benchmarked the wrong thing
<atesterlol[m]> how so
<atesterlol[m]> ok
<atesterlol[m]> here is the benchmark
<atesterlol[m]> without copy: `1.61s user 0.04s system 80% cpu 2.067 total`
<atesterlol[m]> with copy: `0.39s user 0.05s system 58% cpu 0.752 total`
<JamesMunns[m]> for what its worth, this room is usually for bare-metal or RTOS devices, and not linux
<JamesMunns[m]> you might have better luck in the official discord or zulip, if this is something you are doing on Linux.
<atesterlol[m]> JamesMunns[m]: oh. what happened to the previous one?
<JamesMunns[m]> atesterlol[m]: previous what?
<atesterlol[m]> JamesMunns[m]: the previous channel
<atesterlol[m]> it has a crab logo
<atesterlol[m]> * it had a crab logo
wyager[m] has joined #rust-embedded
<wyager[m]> atesterlol[m]: Did you post the actual code for your benchmark anywhere?
<atesterlol[m]> wyager[m]: i used `time`
<JamesMunns[m]> atesterlol[m]: Do you mean ?
<JamesMunns[m]> JamesMunns[m]: this is the `rust-embedded` room, for embedded systems.
<atesterlol[m]> JamesMunns[m]: oh yes
<atesterlol[m]> i searched it in the channel list but couldn't find it, thought they changed the name for rust embedded
<JamesMunns[m]> might be a direct link in your client
<atesterlol[m]> yep, thanks
<atesterlol[m]> wyager[m]: anyway no
NickStevens[m] has joined #rust-embedded
<NickStevens[m]> <JamesMunns[m]> "for what its worth, this room is..." <- There are definitely people here from the embedded Linux side of things too (like me), but agree most of the questions are coming from the bare-metal or RTOS side. I just don't want to scare off questions about things like meta-rust-bin, spidev, i2cdev, etc that are Linux hardware based.
<dirbaio[m]> see? the perf advantage of std::io::copy goes away once you have a custom Read wrapper
<NickStevens[m]> And atesterlol's question seems unrelated to hardware to me
bguruprasath5[m] has joined #rust-embedded
<bguruprasath5[m]> Hello all, I’m using embassy on nrf52840 with embassy boot and softdevice for one of my projects. So far everything works perfectly. but some time randomly getting restart while performing operations when connected to Ble. is there any way to find out where and what is causing the restart. Or is there any logger we can use to find out the issue.
<atesterlol[m]> <dirbaio[m]> "see? the perf advantage of std..." <- yep. you're right, but i still don't understand why it happens on my end like that
<atesterlol[m]> let me show how i did it
<atesterlol[m]> wait its the wrong code lol
<atesterlol[m]> read_ext is just read_exact, with encryption
<atesterlol[m]> <NickStevens[m]> "And atesterlol's question..." <- yep, i thought its the all-rust topic for some reason
<atesterlol[m]> * all-rust topic channel for some
dngrs[m] has joined #rust-embedded
<dngrs[m]> <atesterlol[m]> "the previous channel" <- there were some Matrix issues when upgrading the room, it couldn't be salvaged
Shell is now known as TheEarlGrey
TheEarlGrey is now known as Shell
Foxyloxy_ has quit [Quit: Textual IRC Client:]
Foxyloxy_ has joined #rust-embedded
AtleoS has joined #rust-embedded
AtleoS has quit [Changing host]
AtleoS has joined #rust-embedded
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
almindor[m] has quit [Quit: Idle timeout reached: 172800s]
StephenD[m] has joined #rust-embedded
<StephenD[m]> ayo, probably a silly question. But is there a way to do 8 bit and 16 bit transfers with an SPI bus, or easily convert between the two?
<StephenD[m]> On the rp2040 there seems to be less overhead in 16 bit mode, but some commands require 8 bit mode