<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
<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]>
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)
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
<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]>
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>
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?