ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
HumanGeek has quit [Ping timeout: 246 seconds]
HumanGeek has joined #rust-embedded
starblue has quit [Ping timeout: 258 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
notgull has quit [Ping timeout: 258 seconds]
notgull has joined #rust-embedded
Guest7221 has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
starblue has quit [Ping timeout: 258 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
ni has quit [Remote host closed the connection]
ni has joined #rust-embedded
Abhishek__ has joined #rust-embedded
jr-oss_ has joined #rust-embedded
Abhishek_ has quit [*.net *.split]
jr-oss has quit [*.net *.split]
Abhishek__ is now known as Abhishek_
harishkumaran[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
ni has quit [Remote host closed the connection]
ni has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
t2[m] has joined #rust-embedded
<t2[m]> how i can learn rust embedded igime book recommondation
xnor has quit [Ping timeout: 244 seconds]
xnor has joined #rust-embedded
Guest7221 has joined #rust-embedded
<thejpster[m]> Published my SPARC target blog post.
crabbedhaloablut has quit []
likewise[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> Hi! Does anyone have experience using serialport-rs on a PC program that interfaces with embedded devices over USB? I am having trouble with messages reading not at the start, and after debugging have narrowed it down to the PC program.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RZxbGuucInEcVZuAjaoNBUhq>)
rjmp[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> > The fabric of reality oscillates
<dirbaio[m]> 🤣
<firefrommoonligh> * Hi! Does anyone have experience using serialport-rs on a PC program that interfaces with embedded devices over USB? I am having trouble with messages reading not at the start, and after debugging have narrowed it down to the PC program.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PTzeYRWZgWzlbUCEUErIcDHb>)
<firefrommoonligh> * Hi! Does anyone have experience using serialport-rs on a PC program that interfaces with embedded devices over USB? I am having trouble with messages reading not at the start, and after debugging have narrowed it down to the PC program.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SfmYcUOEyckDMKamBtZncgkn>)
<dirbaio[m]> the mcu that writes the packets to the usb serial does receive them fine?
<firefrommoonligh> So, that I can't directly verify since it's a third party device, but I think it's good based on the Putty printout
<dirbaio[m]> oh, oof
<dirbaio[m]> there's a bunch of serial port settings that make the kernel mangle the data in funny ways
<adamgreig[m]> in general are you just hoping to get packets aligned without any signalling in-band?
<dirbaio[m]> like converting CR to LF or shit
<adamgreig[m]> like if you just read a lot of bytes and print them, does it look like you're at least getting all the right bytes?
<dirbaio[m]> you might want to look at how to disable those
<firefrommoonligh> It does, from putty. Ie I have a printout that looks like this from a Putty log:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rAFrIzDUAjcaAqBNxooVORAb>)
<firefrommoonligh> (Where SS, V, and G are shorthand for the 3 message types)
<firefrommoonligh> Maybe read a single byte at a time, and don't continue the read unless it's the message start byte? I'm pretty confused by the control flow on this in general without being able to "match" a start byte or CAN ID like I do on the hardware
<firefrommoonligh> Or like, what happens if the GUI code is running while bytes are inbound etc etc
<firefrommoonligh> * Or like, what happens if the GUI code is running while bytes are inbound etc
<firefrommoonligh> If I read a lot of bytes in Rust/serial-port, the read fails
<firefrommoonligh> Like, it never fills the buffer and fails
<dirbaio[m]> what's the SS, G, V thing?
<firefrommoonligh> The 3 message types; I wrote those in to help separate the messages (0xfd is the start byte for all)
<dirbaio[m]> ahh
<JamesMunns[m]> Yeah sorry, do you have any framing to reliably tell where one message ends and the next starts?
<dirbaio[m]> and youv'e put putty in a mode that prints binary data as hex? so the usb device isn't sending you the binary data as actual hex text?
<JamesMunns[m]> like if you lose a byte or it is corrupted?
<firefrommoonligh> JamesMunns[m]: Yea - there's a start byte at the start, followed by one of 3 message-lengths. The message length can be used to determine the end
<firefrommoonligh> (And also a message type byte)
<JamesMunns[m]> but if the length byte gets corrupted ever? or you start reading half way through the message?
<dirbaio[m]> try printing the raw bytes from Rust to see if they look exactly the same.
<JamesMunns[m]> (or if 0xfd appears in the data payload)
<firefrommoonligh> dirbaio[m]: I think so. I set it to log to a "hex" file, and when I view it in a text editor, it's hex characters that are correct
<firefrommoonligh> JamesMunns[m]: There's a CRC, although I haven't implemented checking
<firefrommoonligh> dirbaio[m]: If I, say do this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fgoAeqbjWkzfwdCGccpoFlIo>)
<JamesMunns[m]> yeah but I mean if your message is like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OSbOnYtNihluRVtjPhhEezNf>)
<firefrommoonligh> Yea def; that happens
<JamesMunns[m]> so, if you control the format, this is one things COBS is used for
<dirbaio[m]> no error from read_exact? you might get an error if you've set it to nonblocking mdoe
<dirbaio[m]> s/read_exact/read\_exact/, s/mdoe/mode/
<JamesMunns[m]> it replaces all 0x00 bytes with another value, so when you see a 0x00 on the wire, you know it is the end of one frame and the start of another
<firefrommoonligh> dirbaio[m]: I thought I had errors, but maybe not
<JamesMunns[m]> it means you need to do a little bit of decoding, but not a lot.
<firefrommoonligh> JamesMunns[m]: That sounds like a great idea
<dirbaio[m]> are you on Windows?
<firefrommoonligh> Yep, re Windows
<firefrommoonligh> JamesMunns[m]: Thank y ou; will check that out; likely add
<dirbaio[m]> make sure putty is closed while you run the rust program
<JamesMunns[m]> https://docs.rs/postcard/latest/postcard/accumulator/struct.CobsAccumulator.html will do all of framing and deserialization for you.
<dirbaio[m]> otherwise data corrupts if there's 2 processes reading from the serial port
<firefrommoonligh> dirbaio[m]: Good call on that too
<dirbaio[m]> it's probably not this but windows doesn't set DTR automatically when you open the port while Linux does
<dirbaio[m]> the firmware on the usb device might care
<dirbaio[m]> I ran into this with the nordic ppk2
<firefrommoonligh> Could be!
<firefrommoonligh> Another thought - I'm always sending 64 bytes on the CAN side partly out of laziness. Maybe that ends up propagating through the chain, and the empty bytes are causing trouble
<firefrommoonligh> (with 0 pads on the right)
<firefrommoonligh> (Fixed that part on firmware now to eliminate it)
<firefrommoonligh> That gets rid of the trialing 0s in putty:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/mkUeqjgvCuTLIhyofelEqjuK>)
<firefrommoonligh> But still not sure how to align in PC software
<firefrommoonligh> Ie, the log is filled with things like this, which are fragments; they should all start with `253` (0xfd as in the hex repr from Putty)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dTwOxYgZIbDDGwbGWiStmsgk>)
<firefrommoonligh> (In the second row, you can see the 253 start byte out of place, in the others it's beyond what's shown)
<firefrommoonligh> Anyhow, I appreciate the help all; will post when I figure out more or solve it
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> On the CAN device, prior to being sent to UART. This is 100% correct:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pMibaAsuDAzHQVqBybuNurWT>)
<firefrommoonligh> * On the CAN device, prior to being sent to UART. This is the last part I can confidently say is correct:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uLeMMWmJjeEBsAvnuAnJzSmb>)
<firefrommoonligh> * On the device reading the CAN packets, prior to being sent to the UART radio. This is the last part I can confidently say is correct:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LfnBuSpcpvFYgyXPlPNmkKZS>)
ilpalazzo-ojiis4 has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> CAN messages are natively framed, allowing for natural message synchronization. UART isn't typically framed, meaning you need to typically do it in-band. Otherwise if you always "recv exactly 64 bytes" it is fairly likely you will come out of sync sooner or later.
<JamesMunns[m]> If you fall out of sync, you typically need to discard any bytes until the next start of frame (which requires some level of variable accumulation), then start receiving again.
<firefrommoonligh> Interesting! I'm handling the sync on the start of the message chain, using loop ratios and offsets. No safety checks downstream of that
<firefrommoonligh> I thought there was plenty of timing padding, but could still be problems
<JamesMunns[m]> recv_exact will listen across gaps
<JamesMunns[m]> like if you recv 63 bytes, but then drop one, then theres a big gap, you might "steal" the first byte of the next message.
<JamesMunns[m]> or if your timeout occurs halfway through receiving 64 bytes, whoops you just ate 32 bytes and you're now sitting halfway through a message
<firefrommoonligh> That fits the symptoms
<firefrommoonligh> Also, I just tried manually aligning the messages on the PC side; turns out the message gets cut off on the right side, so that won't fix it
<JamesMunns[m]> yup.
<JamesMunns[m]> so what CobsAccumulator does is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XgHOMtsspEqlwyghkIhMuPuU>)
<dirbaio[m]> framing is the answer to life, the universe and everything
<JamesMunns[m]> I mean there's only two kinds of data: frames and streams
<JamesMunns[m]> and framing is indeed how you turn streams of bytes into streams of frames :)
<dirbaio[m]> no framing, no communicating
<JamesMunns[m]> you can tell I do this a LOT because like half of postcard's helper functions and types are all around turning streams of bytes into structs or turning structs into a streams of bytes :)
<dirbaio[m]> the cobsmaster
<JamesMunns[m]> It's not the only way to do framing! But it turns out it's a pretty good way
<firefrommoonligh> I'll try read instead of read_exact and iterate on that
<JamesMunns[m]> do you control the data format over uart?
<JamesMunns[m]> like is that your pc app to your usb firmware?
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<firefrommoonligh> I control everything except for the RF MCUs, which should act as passthrough
<firefrommoonligh> So, I lose control once I send the signal over UART, and get it back on reading USB
<JamesMunns[m]> you *really* could steal "the postcard stack"
<firefrommoonligh> Yea; have been considering it
<JamesMunns[m]> like, postcard + cobs is literally designed for this
<firefrommoonligh> But isn't that not directly related to the problem? I'd been looking at it more to get red of all teh manual serializing
<JamesMunns[m]> you could send `heapless::Vec<u8>` if you still want to do your own deserialization manually
<dirbaio[m]> what's the rf mcus?
<firefrommoonligh> ESP32 + SX1280s
<firefrommoonligh> Running [ExpressLRS](https://www.expresslrs.org/)
<JamesMunns[m]> Since you're not doing async, here's a straightforward example
<JamesMunns[m]> you could also just use cobs, and steal CobsAccumulator and skip the serde step.
<dirbaio[m]> interesting, so a ready-made firmware that does uart over reality fabric oscllations instead of electron pipes
<dirbaio[m]> cool
<dirbaio[m]> also known as spacetime wiggling
<JamesMunns[m]> haven't tried to do quantum serial ports yet :D
<JamesMunns[m]> dirbaio[m]: ohhh you're talking about the serial-over-radio thing
<dirbaio[m]> ah yes sorry
<JamesMunns[m]> reminds me of all the old nrf24s
<JamesMunns[m]> (which: surprise, use (E)SB, and do stream -> frame -> stream round tripping, yaaaay!)
<dirbaio[m]> hah
<dirbaio[m]> and the frames are also framed over a stream that's the spacetime wiggling
<dirbaio[m]> itframes all the way down
<dirbaio[m]> * it's frames all the way down
<JamesMunns[m]> I mean bytes are just streams of bits, framed into an octet
<firefrommoonligh> JamesMunns[m]: > <@jamesmunns:beeper.com> Since you're not doing async, here's a straightforward example... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WKuDdhWuJANCuSDTyrHExnWr>)
<dirbaio[m]> anyone knowledgeable with stm32: is there any cursed ritual I need to perform to get PA2/PA3 working on stm32l073rz?
<dirbaio[m]> ie arduino D0/D1 on the nucleo. can't get the tests to pass. SPI is on other pins and it does pass
<firefrommoonligh> dirbaio[m]: Exactly. It's more intended for high-data rate prescribed packets for a handful of control channels, but there's an alternate functionality that lets you send arbitrary data, 2-way
<JamesMunns[m]> but yeah my "everything is frames or streams" is more like a perspective thing. If you are considering one atomic unit, it's a frame. if you are considering over time, it's a stream.
<JamesMunns[m]> But frames are a chunk of a stream, and a stream is made of frames
<firefrommoonligh> (I think the data going in the other direction is fine, but haven't fully QCed that)
<firefrommoonligh> dirbaio[m]: Yea; these bytes (bits?) have undergone quite the Odyssey, but I guess that's the power of digital
<firefrommoonligh> This is the PC software in question btw -
<firefrommoonligh> (using EGUI)
<adamgreig[m]> egui is so nice for this huh
<firefrommoonligh> I love it. Whenever I read that Rust isn't ready for GUI applications, I disagree
<adamgreig[m]> though your slightly misaligned lat/lng boxes on the bottom right there are bugging me :P
<firefrommoonligh> (Assuming you don't care about native look; I don't)
<firefrommoonligh> Hah valid
<firefrommoonligh> Basically, there are 4 types of packets: Commands from PC (Seem to be OK), data from the boat(buoy?), confirmation of the commands received, and system status. The latter 3 are glitching out more often than not, but still sometimes getting through intact
rjmp[m] has joined #rust-embedded
<rjmp[m]> <dirbaio[m]> "ie arduino D0/D1 on the nucleo..." <- Arent those jumpered to the ST link chip on nucleos by default?
<firefrommoonligh> rjmp[m]: Seems to be it
<firefrommoonligh> firefrommoonligh: file:///C:/Users/david/Downloads/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf
<firefrommoonligh> firefrommoonligh: > The USART2 interface available on PA2 and PA3 of the STM32 microcontroller can be... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rYchJAgvEDkSRbUrhJxyACzz>)
<dirbaio[m]> <firefrommoonligh> "image.png" <- yep that was it, thanks 🥲
<dirbaio[m]> dirbaio[m]: it's not on all nucleos though!
<dirbaio[m]> dirbaio[m]: it's not on most nucleos even
<dirbaio[m]> dirbaio[m]: thanks ST for being so inconsistent