Methods for start of frame marker on STM32 USB CDC - Page 1
Forum section: electronics / projects

author: Psi
author_rank: Super Contributor
timestamp: April 21, 2025, 03:23:45 am
content: I'm starting on a new project and just wondering which way I should go for a start of frame marker in the serial datastream.This is using STM32F0 virtual com port over USB (CDC).Are there any easy techniques/time savers that I should be aware of?So far I can think of a few options1) Special char + escape character2) Open the com port in 9 bit mode and use the 9th bit for special commands like start of frame. (anyone tried 9bit CDC?)3) Use some of the flow control signals CTS RTS DTR etc..4) Use break command5) Use a very fast baudrate, eg 2mbit, and simply have a 128bit UUID for start of frame and just hope it never happens in the middle of a datastream.6) implement an extra layer in the USB CDC protocol to get some extra commands outside of the serial data stream.7) Don't use serial at all, use HID instead.Is there anything else I've missed and does anyone have any suggestions about which is the best optionI don't need a crazy fast baud rate. 115200 is fine.I value reduced complexity and would prefer to not being writing/fixing low level USB code.I think currently I'm leaning towards options 2 or 4 (9 bit serial or break command)Has anyone used 9bit serial with STM32 CDC before? I know 9bit serial has a tendency to be a bit broken when it comes to UARTS but i would think USB CDC should just work?

author: ataradov
author_rank: Super Contributor
timestamp: April 21, 2025, 04:49:57 am
content: COBS encoding is the hands down best packet serialization scheme. It has really low overhead and implementations for both encoding and decoding are less than 10 lines of code.

author: moffy
author_rank: Super Contributor
timestamp: April 21, 2025, 04:51:26 am
content: Baud rate over USB, unless it is going to a USB to serial converter IC like FTDI or via a UART, doesn't mean anything in a straight USB to USB connection. I found that when testing the max data rate from an imxRT1020 NXP processor, CDC, didn't matter what the baud rate was set to I got better than 20Mbytes/s.

author: Psi
author_rank: Super Contributor
timestamp: April 21, 2025, 05:18:15 am
content: Quote from: ataradov on April 21, 2025, 04:49:57 amYeah, the main reason to not go with COBS in this case is that I have a lot of data packed structures that I want to stream out to the PC (Sometimes adding/removing structures dynamically). It's easy if I can simply pass a data structure pointer and length to the USB CDC and let its buffer handle everything. If I go with COBS I need to insert some pre-prepossessing into that, or use up lots of ram to double buffer the structures in COBS format.I currently have the PC sending a serial break condition to trigger re-sending all the structures.The STM32 CDC seems to detect that fine and it's kind of nice that the PC has control of how often the data is resent.Quote from: moffy on April 21, 2025, 04:51:26 amYeah I had a play and that does seems to be the case. It just runs as fast as it can over USB regardless of baud rate you open the port at.

author: moffy
author_rank: Super Contributor
timestamp: April 21, 2025, 05:26:24 am
content: If you used a sync pattern followed by the size in bytes for the next transmission, you would know when to start looking for the next sync pattern, without having a false triggering by the data.

author: Psi
author_rank: Super Contributor
timestamp: April 21, 2025, 05:27:39 am
content: Quote from: moffy on April 21, 2025, 05:26:24 amTrue.

author: ataradov
author_rank: Super Contributor
timestamp: April 21, 2025, 06:21:23 am
content: Any scheme that does not change the data would be vulnerable to synchronization issues. Obviously you can have a very long synchronization sequence, but that just reduces the probability of collision. This may be acceptable in your case, especially if you can check the length of the expected data based on the ID or something like that.

author: voltsandjolts
author_rank: Unknown
timestamp: April 21, 2025, 08:28:34 am
content: If data rates are not an issue, you can do something simple but wasteful, like all data in ascii hex and header markers in binary. But if this is tx only, look again at COBS, encoding is easy, like in the single buffer you already have, if it's > 256 bytes.https://www.eevblog.com/forum/microcontrollers/implementing-uart-data-packets-with-consistent-overhead-byte-stuffing-(cobs)/Edit:Actually, for the ascii hex solution, I'd probably keep the headers ascii too, not using ascii hex chars of course. This kinda thing;#HXYZ_a1b8d74cc538e3