20:32 <AlexandervanSaas> I have what's probably a very easy to solve problem but I can't figure it out by myself so here it goes. I'm trying to log data over serial and I'm using the postcard crate for serialization and deserialization and cobs encoding to be able to separate the frames. On the receiving end I recorded some data with a serial monitor but there aren't any zero bytes in the bytes I recorded. I verified the zero byte is appended to the

20:32 <AlexandervanSaas> messages on the sending side and with a hex editor I can see my messages in the recorded bytes, sans the zero byte. Why could that be?

20:32 <AlexandervanSaas> * that be? I'm using embassy and `blocking_write`.

21:19 <JamesMunns[m]> Do the other bytes look reasonable? If not it might be a baudrate issue. Can you share the code somewhere so I can take a peek?

21:21 <AlexandervanSaas> Yes the other bytes are correct. I forgot that I had a logic analyzer but I've now confirmed the zero byte is transmitted at the end of each message.

21:21 <JamesMunns[m]> I can't think of anything that would "swallow" the values

21:22 <AlexandervanSaas> I'm using a second raspberry pi pico as a serial bridge. It wouldn't make sense to me but could that swallow the zero byte?

21:22 <JamesMunns[m]> AlexandervanSaas: Ah! So the sender is definitely working, and definitely sending the zeroes, but the receiver isn't seeing them? What are you using to buffer/accumulate the bytes on the receiver side?

21:22 <AlexandervanSaas> JamesMunns[m]: Just a serial monitor like Serial Studio or picocom

21:23 <JamesMunns[m]> Hmm, maybe they could be seeing it as a NUL byte and walling it, if you are using it in some kind of a text mode

21:23 <JamesMunns[m]> s/walling/swallowing/

21:24 <JamesMunns[m]> Might be worth looking around the code or settings to see if they have anything about that?

21:27 <AlexandervanSaas> Nothing jumps out to me but I'm not very familiar with C https://github.com/Noltari/pico-uart-bridge/blob/master/uart-bridge.c

21:30 <JamesMunns[m]> That uses tinyusb, and I see at least one strlen

21:30 <JamesMunns[m]> which in c-strings, only counts the len to the first null byte

21:31 <JamesMunns[m]> not sure, but that's my first guess

21:32 <JamesMunns[m]> https://github.com/hathach/tinyusb/blob/da3e511b92bf3963cdbba41cc90c6b1e32704aa4/src/class/cdc/cdc_device.h#L163-L166

21:32 <JamesMunns[m]> but hmm, that's write_str, which isn't called... hmmmmmm

21:33 <JamesMunns[m]> So it goes something like:

21:33 <JamesMunns[m]> (other device) -> SERIAL: bytes1 -> (pico) -> USB: bytes2 -> PC

21:33 <JamesMunns[m]> where you DO see the zeroes at SERIAL: bytes1, but don't see them at your PC?

21:33 <AlexandervanSaas> Correct

21:34 <JamesMunns[m]> So we know either the pico bridge or your PC are eating zeroes, we just have to figure out which one :)

21:34 <AlexandervanSaas> I also suspect the uart bridge

21:35 <AlexandervanSaas> * suspect the pico uart bridge

21:37 <JamesMunns[m]> Do you have a SWD debugger for one of your picos?

21:39 <JamesMunns[m]> if so: you could try smashing together the embassy https://github.com/embassy-rs/embassy/blob/main/examples/rp/src/bin/usb_serial.rs example with the UART one, and make your own UART bridge, or use defmt to print the raw bytes received

21:39 <JamesMunns[m]> * UART bridge, and/or use

21:40 <AlexandervanSaas> Appologies, the second pico (the uart bridge) is running this https://github.com/raspberrypi/picoprobe

21:40 <AlexandervanSaas> * running this,, * not the other project I linked https://github.com/raspberrypi/picoprobe

21:43 <AlexandervanSaas> So the second pico is a SWB debugger for the first one. I don't have a second SWD debugger/third pico unfortunately.

21:48 <JamesMunns[m]> I'm not sure how better to debug, sadly. I'm not familiar enough with the pico-sdk, tinyusb, or the rest of the stack to know whats up :/

21:55 <AlexandervanSaas> lol I found a ST link

21:57 <AlexandervanSaas> To me it seems very unlikely that my computer is somehow eating the zero bytes.

22:18 <JamesMunns[m]> <AlexandervanSaas> "To me it seems very unlikely..." <- you could take the embassy usb-serial example and just send `1, 2, 3, 4, 0` on the wire every second or somethingh

22:18 <JamesMunns[m]> then you could prove it

22:43 <AlexandervanSaas> It is my computer that's swallowing the zero bytes.

22:43 <AlexandervanSaas> s/is/_is_/, s/./!/

22:43 <AlexandervanSaas> s/is/_is_/, s/./! WTF!?/

22:43 <adamgreig[m]> probably it's the serial monitor and it's just only designed for text or something

22:43 <adamgreig[m]> maybe whip up a rust program using postcard to receive the serial data and decode it?

22:45 <AlexandervanSaas> Is it common for software to skip zero bytes? I tried three different serial monitors so far

22:47 <adamgreig[m]> ... admittedly no, it doesn't seem common

22:47 <adamgreig[m]> like you'd possibly expect it from software designed to just monitor text

22:48 <adamgreig[m]> if you have python installed, install pyserial, try just like import serial; s = serial.Serial("/dev/ttyACM0", 9600); data = s.read(16); print(repr(data)) (replace 9600 with your baud rate) and see if the 0s appear there?

22:48 <adamgreig[m]> pyserial definitely doesn't strip 0s so if they're missing from that it's something really screwy on your computer itself

22:48 <adamgreig[m]> (replace /dev/ttyACM0 with like COM15 or so if you're on windows)

22:50 <AlexandervanSaas> ah, when passing -H/--displayhex to minicom it does display the zero byte

22:50 <adamgreig[m]> aah, cool

22:50 <adamgreig[m]> then yea, I guess it's coming through fine and your software's just stripping it because it's only showing you text

22:50 <adamgreig[m]> maybe it strips other control codes too?

23:03 <AlexandervanSaas> Actually that option displays the bytes as hex string but it doesn't write the raw bytes to a file. So I know my computer is receiving the null byte but I don't have the file that I need yet.

23:07 <AlexandervanSaas> I'll write my own tool to read from serial and write to a file. Thanks everyone!