1
The ascii character "NUL"'s value is 0. Is it possible to send this character over a serial line without getting it interpreted as no data being sent?
1
The ascii character "NUL"'s value is 0. Is it possible to send this character over a serial line without getting it interpreted as no data being sent?
4
Yes, of course. The framing of characters is separate from their contents. There is no reason that eight bits of zero would be inherently interpreted as "no data is sent" -- any more than a disk sector full of zeroes would be.
To elaborate: In typical async serial you have a start bit, then eight data bits, then a stop bit. You would still have the eight data bits - they'd just happen to be all zeroes. The start and stop bit tell the receiver "here's a character". What the bits in the character happen to be are irrelevant.
If a receiving program happens to interpret the NUL as "no data," that is its business, but that's an application layer issue.
For example, if the receiving program is a terminal emulator it will likely do nothing when it receives a NUL (because that's what most real terminals did). The serial port API will still have registered the receipt of the NUL character and handed it to the program. It's the terminal emulator that decided "oh, I'll just ignore that."
There are a whole lot of applications for sending "binary" data over async serial lines that would have failed had NULs not been sent or received at all.
For more info, see https://en.wikipedia.org/wiki/Asynchronous_serial_communication
0
The serial protocol has start and stop bits, and data is fenced within those - N81 (no parity, 8 bits, 1 stop bit will allow you to send any ASCII character, and is 1 common encoding), thus by sending a start bit or not sending a start bit it is possible to differentiate between nothing and null.
"thus by sending a stop bit or not sending a stop bit it is possible to differentiate between nothing and null" -- Not true. A stop bit by itself is invisible compared to the idle (mark) state. It's actually the start bit that indicates there is something (i.e. a frame) on the wire, and the stop bit(s) confirms the end of that frame. A missing/invalid stop bit(s) generates a framing error. Otherwise there's a received character with a pending/optional parity check. – sawdust – 2017-03-17T06:01:33.443
So what would 0 across a serial line look like? – user233009 – 2017-03-17T05:40:40.597
2One bit time of "spacing" condition, which would be the start bit. Eight more bit times of "spacing" - the data bits, in this case all zeroes. And then at least one bit time of "marking" - the stop bit. After that it's the transition to "spacing" condition that signals the next character frame has started. This can occur at any time after one stop bit (or whatever the requirement is; a few old devices required two or even 1.5 stop bits) has been completed; an idle line is held at "marking" condition for as long as necessary, until the next character frame begins. – Jamie Hanrahan – 2017-03-17T05:50:43.247