Peter wrote:
> True, but it is always easier to use a popular protocol. In HTTP your
> request would be encoded as a single line, like:
>
> GET /%FC\r\n

Certainly not always easier.  It might or might not be easier in this case.
If I remember right, there is some handshaking when a HTTP connection is
first started.  There is nogitiation of the HTTP version or something back
and forth.  It's not all that easy, especially if you haven't done it
before.

Bare TCP on the other hand can't be any worse than HTTP since HTTP is
layered on TCP.  You connect to the server in the PIC and then you send
binary bytes, which is easier than text.  With HTTP you have the same TCP
connection setup, then you have to do the initial HTTP handshaking that you
didn't show, then you get to issue the command you showed, then you still
have to parse the response.  With a simple binary protocol, you get the
response directly without any interpretation required.

So, no, it's not obvious to me at all the HTTP would be easier.

> And that's it (a discussion might start about how a HTTP/x.y protocol
> request would be handled). It can be issued by any browser or by a
> telnet client for testing. The browser address window would contain
> http://1.2.3.4/%FC for this.

But then the data has to come back in text form that the browser can
display, which is not the most convenient form for the program, and
certainly not the most convenient for the PIC to produce.

For testing binary TCP connections, I use my TEST_TCP program.  In fact, if
you implement a simple binary opcode protocol, you could use it directly to
control a LED or something.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist