1
\$\begingroup\$

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 ?

\$\endgroup\$
  • 8
    \$\begingroup\$ It's your protocol, you get to choose. Do you even need the \0 if you end always with ETX? \$\endgroup\$ – Colin Mar 26 '18 at 14:24
  • \$\begingroup\$ 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. \$\endgroup\$ – Chris Stratton Mar 26 '18 at 17:07
7
\$\begingroup\$

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

| improve this answer | |
\$\endgroup\$
  • 4
    \$\begingroup\$ 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. \$\endgroup\$ – Peter Bennett Mar 26 '18 at 16:51
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Chris Stratton Mar 26 '18 at 17:02
  • \$\begingroup\$ @PeterBennett, OPs question states "I am developing a UART protocol". It's OPs choice how strings are sent, as others note. \$\endgroup\$ – TonyM Mar 26 '18 at 17:44
1
\$\begingroup\$

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;

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ While this includes the overwhelmingly usual possibility, you've buried it in the middle, and failed to really explain why that is the usual. \$\endgroup\$ – Chris Stratton Mar 26 '18 at 17:09
  • 1
    \$\begingroup\$ @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... \$\endgroup\$ – moyoumos Mar 26 '18 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.