Saurabh,
There is nothing to prevent you from sending data in pure
binary/hex form.
You can also send the data in some other representational
form.
For example, binary '10101011' is hex 'AB'. You could
ascii-ize that to
two ascii-coded bytes "A" and "B". Note that this
representation can be
easily "seen" in a program like hyperterminal, because it will
be
interpreted as the characters "A" and "B".
Certain binary/hex data values would be interpreted by a
program like
hyperterminal as things like <carriage return> and
<line feed>, and
<ring that bell thing>. binary '00000111' hex '07'
is control-g which
is interpreted as <ring that bell thing>. Send that and
hyperterminal
beeps (more like a grunt on my machine!). Send it as "0" and
"7" and
it just shows up as "07" on the screen.
What is the best form to send in? Depends on whether you are
primarily
interested in speed, ability to view on hyperterminal, or some
other criteria.
The really really important thing is that both the sending
program AND the
receiving program know the protocol being used.
For example, years ago I wrote a program that allowed two
computers in
different buildings to communicate packets of data back and
forth. The
communication lines could get very noisy, so we needed some
way of
verifying the data packets. So we came up with a
protocol:
Every packet begins with a carriage return and a line feed
followed
immediately by "*" which we called the synch character. Then
there was
a value from 0 to 255 expressed in ascii-ized hex such as
"AF" which told
how many bytes of data there were in the
packet. This was followed by the
data in ascii-ized hex form. This was followed by "**" and a
checksum
of only the data values. Upon successful reception of a data
packet
the receiver would sent a "we got it" acknowledge signal
back
to the sender. The sender was waiting. If it got the
acknowledge
signal it began sending the next packet. If it did NOT
receive
an acknowledgement, OR if it received a "retry" code, it
would
re-send the previous packet.
Now, because we coded everything in ascii-ized form it took us
twice as long
to send everything, BUT we could hang a dumb terminal on the
line
and actually WATCH the data packets coming over. It was
visually
easy to determine what kinds of problems we might be having.
In fact,
later we changed the protocol to send a <space>
character between
all data elements. That made the packets even easier to
read
on a dumb terminal. We traded off speed for the ability to
easily
troubleshoot problems.
But you don't HAVE to do these kinds of things. There is
nothing
wrong with sending as much of the data in raw format as you
can.
I often use a simple synchronizing protocol that sends all
the
real data in pure binary form, but which synchronizes
packets
and keeps track of packet length and does checksums. To
keep
speed up these packets are often several kilobytes in
size.
When we get too many failed packets, we switch down to using
a
smaller packet size. When things look fine, we switch
back
to using larger packets. Such an adaptive program gives
you
the best of both worlds.
You do what works best for your particular
application.
The PC and the PIC will "understand" whatever you have
PROGRAMMED them to understand. Everything else will be
gibberish.
Fr. Tom McGahee
Hi,
I needed to establish communication between a PIC and
a PC. I am sending bits serially at 9600 baud to Port-A. Someone told me
that this is not going to work, and I should send ASCII characters to the PC
as the PC stands ASCII characters. I don't understand this...could someone
please explain or refer me to an URL...
Thanks in advance for your reply.
Regards,
Saurabh