Hardware Reference
In-Depth Information
Text or Binary?
One of the most confusing aspects of data communications is understanding the differ-
ence between a binary protocol and a text-encoded protocol. As you learned in Chapter
2, there is a common scheme for translating the data you send into alphanumeric char-
acters. ASCII—and its more modern cousin, Unicode—allow you to convert any stream
of text into binary information that a computer can read, and vice versa. Understanding
the difference between a protocol that is text-based and one that's not, and why you'd
make that choice, is essential to understanding how electronic things communicate.
Isn't All Data Binary?
Well, yes. After all, computers only operate on binary logic.
So, even text-based protocols are, at their core, binary.
However, it's often easier to write your messages in text
and insist that the computers translate that text into bits
themselves. For example, take the phrase "1-2-3, go". You
can see it laid out in characters below, with the ASCII code
for each character, and the bits that make up that code. It
may seem like a lot of ones and zeroes for the computer to
process, but when it's reading them at millions or billions
of bits a second, it's no big deal. But what about when it's
sending it to another computer? There are 80 bits there.
Imagine you're sending it using TTL serial at 9600bps.
If you add a stop bit and a start bit between each one—
as TTL and RS-232 serial protocols do—that's 96 bits,
meaning you could send this message in 1/100th of a
second. That's still pretty fast.
1
-
2
-
3
,
g
o
!
Character
49
45
50
45
51
44
32
103
111
33
ASCII code
binary
00110001 00101101 00110010 00101101
00110011
00101100 01000000
01100111 01101111 01000001
What about when the messages you have to send are not
text-based? Imagine you're sending a string of RGB pixel
values, each ranging from 0 to 255 like this:
text (for example, email or hypertext), encoding it as
ASCII/Unicode makes sense. When the number of bytes
you'd send is minimal, as with most of the sensor strings
you've sent in this topic, encoding it as ASCII/Unicode
can help with debugging, because most serial or network
terminal programs interpret all bytes that they receive as
text, as you've seen. So:
102,198,255,127,127,212,255,155,127,
You know that each reading is eight bits, so in their most
basic form, they take up three bytes per pixel. But if you're
sending them in text form it's one byte per character, so
the string above would be 36 bytes to send nine values. If
you hadn't encoded it in text form, but just sent each value
as a byte, you'd have only sent nine bytes. When you start
to send millions of pixels, that's a big difference! In cases
like this, where all the data you want to send is purely
numeric (you don't need any text to describe the pixels
because you know the first byte is always red, the second
green, the third blue, and so on), sending data without
encoding it as text makes sense. When you need to send
• If there's a lot of data and it's all numeric, send as raw
binary.
• If there's text, send as Unicode/ASCII.
• If it's a short data string, send as whichever makes you
happy.
