NUL character in an ASCII-Based protocol over UART

I am developing a UART protocol based on ASCII encoding. Communication is between a PC and an STM32 board. Packet format is like this: Packet: {STX,DATA,ETX} Where STX and ETX are 0x02 and Ox03 in ASCII.
Example:

STXHELLOETX in Hex would be: 0x02 0x48 0x45 0x4c 0x4c 0x4f 0x03

My question is where exactly is the position of \0 character in my packet? is it after ETX like this: STXHELLOETX\0 or after HELLO like this: STXHELLO\0ETX ?

• It's your protocol, you get to choose. Do you even need the \0 if you end always with ETX? – Colin Mar 26 '18 at 14:24
• Nulls are rarely used in line protocols, in effect ETX is filling the role in your protocol that a null serves when a program internally stores a null-terminated string. Packet buffers usually track length, rather than using a terminating null, but even if they use a terminating null it is removed on sending and added on receiving. – Chris Stratton Mar 26 '18 at 17:07

You specify your packet format as {STX,DATA,ETX}.

The entire DATA content of the packet is contained within the DATA field, between the STX and ETX.

If you decide to send NUL-terminated strings in your packets then the NUL is part of the string - part of your DATA field.

So you would send: STXHELLO\0ETX

• I would say that the NUL terminator of a C string is a feature of the C language and should not be considered as part of the string. The actual string to be sent would just be the characters up to, but not including, the NUL. – Peter Bennett Mar 26 '18 at 16:51
• Indeed, this response is very incorrect, and appears to have confused the asker into mistakenly accepting it. The format originally described simply does not send a null, and indeed most line protocols do not use nulls. If at some point a packet with or without the framing STX/ETX is stored inside a computer in a null terminated C string rather than in a length-designated buffer, then a null would be added. But it's not necessarily the case that this will happen at all. Typically you would only see null-terminated strings when constructing or deconstructing packet fields. – Chris Stratton Mar 26 '18 at 17:02
• @PeterBennett, OPs question states "I am developing a UART protocol". It's OPs choice how strings are sent, as others note. – TonyM Mar 26 '18 at 17:44

it depends on the DATA (the 'HELLO' word in your example):

--if it's a null-terminated string (a C-string), in wich a string is represented by an array of chars ended by a null character '\0',

or:

--if it's a 'normal' array of characters.

so the packet can be:

--STXHELLO\0ETX for the null-terminated char array: [0x02 0x48 0x45 0x4c 0x4c 0x4f 0x00 0x03]

or:

--STXHELLOETX for the normal char array: [0x02 0x48 0x45 0x4c 0x4c 0x4f 0x03]

or:

--the null char can be anywhere in the packet!...it's your protocol, as colin-s commented;

• While this includes the overwhelmingly usual possibility, you've buried it in the middle, and failed to really explain why that is the usual. – Chris Stratton Mar 26 '18 at 17:09
• @chris-stratton: i haven't any intention to 'explain why that is the usual' possibility... i only mentionned 'some' possibilities since the question is a bit general... – moyoumos Mar 26 '18 at 17:26