On Sat, December 17, 2011 2:41 pm, Harold Hallikainen wrote:
> In the several projects I've done that work on private networks, I use
> HTTP for a human interface and TCP for a machine interface. A host can
> connect, send commands and get responses. My most recent project allows 5
> simultaneous TCP connections. I've also done SNMP, but find TCP easier to
> do.
>
> Harold
>
>
>
>> As more and more things are controlled over the internet ; What schemes
>> are best for connecting embedded devices to [ laptops and smart phones
>> and
>> tablets ] ?
>>
>> I have some presumptions =3D=3D>  Most connections do not require high s=
peed
>> data transfer. Simple messages are sufficient.  Simple while extensive
>> ID
>> schemes are best.....
>>
>> What do PIClisters suggest ?
>> Gus
>>
>>

To clarify what Harold said- for human interface, HTTP is probably the
best, but HTTP rides on top of TCP.  You can make a custom protocol, but
if you want to avoid writing an application for each platform you want to
support, an HTTP interface is probably the most flexible.

For the basic protocol, UDP is simple- kinda like throwing a ball of data
in the general direction of the recipient and closing your eyes.  You know
you sent it, but you don't know if it got there and you don't know if the
ball broke on the way. TCP is what's called (in internet terms, anyway)
"reliable"- you open up a connection and what goes in one end comes out
the other.  If what you send doesn't get through or is corrupted, there is
enough going on that the stack realizes it, and re-sends. TCP takes more
processing and is slower (due to the handshakes required).  UDP is good
when you're trying to get a lot of data across and late data would get
thrown away.

This is just barely touching on the subject.  This is really a *huge*
topic- when you start throwing network latencies and the compromises you
have to think about in a microcontroller, it gets even more complex. For
starters, I'd start working with HTTP (which is a protocol on top of TCP)
with a PIC32 and at least 2 sockets and 1KB buffers on transmit and
receive.  You start noticing the difference on buffer size mostly with
longer latency connections (such as communicating outside your local
network).  You'll be able to get things to work first without getting too
deep into the protocol decisions.


Matt Bennett
Just outside of Austin, TX
30.51,-97.91

The views I express are my own, not that of my employer, a large
multinational corporation that you are familiar with.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.