Off topic?...TCP/IP embedded simple data transfer

[Dan Mullin]

I've implemented Bentham's TCP/IP lean via the Microchip PICDEM.net board to start learning about TCP/IP for embedded applications.

My app basically involves replacing a half-duplex serial control/monitor stream (Machine, do this...OK, I did that and here's my status...Now, machine, do this...Did that and here's my status.) Each packet is small, maybe 18-24 bytes on the top end. I don't need HTTP pages or support. It is expected that the PC program controlling this device will NOT be a browser but an application that opens a socket, sends the equivalent of the original serial packet to the device, then receives a packet back. I guess what I'm saying is that I wish to take a currently defined serial data protocol and simply wrap it up in an Ethernet connection. I know about things like the Moxa serial adapters but would like to keep the PC more on an Ethernet rather than driven pseudo-serial port footing. I don't have a problem with allowing the PIC and attached Ethernet controller to be a front-end for the actual embedded device-controlling PIC.

I've been reading more and more about the stack and, in Bentham's book, find that something like the "Daytime" port would work well for this type of transaction. Instead of the complexity of HTTP we are simply requesting data and getting a small data response.

Anyone have any sources or directions for this concept? Any port numbers that should be specifically used? Is it legitimate to simply place this data into the TCP packet, then parse it out on the distant end and consider it a TCP transaction or does this need to end up encapsulated in some higher level protocol like PPP or something.

As you can tell, I'm hunting but only because most of the info I have (including Bentham's book) concentrate on the browser/HTTP aspect of things.

Any help would be appreciated.

Dan
___________________________
This message was ported from CCS's old forum
Original Post ID: 1231

[Dale Botkin]

:=As you can tell, I'm hunting but only because most of the info I have (including Bentham's book) concentrate on the browser/HTTP aspect of things.
:=

I know, and I can't figure out this fixation with trying to wedge an HTTP serve into a PIC when probably 99\% of the tasks that need to be done could be done using UDP. Must be just to sell books and demo boards. UDP has far less overhead than TCP. UDP does not have provisions for guaranteed delivery, packet or fragment re-ordering and such -- but most of the time who needs it? You're going to fling 20-odd-byte packets back and forth.

Pick a port, any port -- for the sake of compatability with existing IP hosts it should preferably be one above 1023. Use UDP, be happy. If you need to be absolutely sure every packet is received, build in some sort of error detection, retransmit, whatever -- your existing serial protocol may already have that built in.

Hope this helps...
Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 1242