Ethernet base protocols on embedded

UDP, TCP, or a custom protocol.

UDP is low overhead but you have to handle retries and whatnot in the application. TCP handles the reliability stuff for you. A custom protocol can have very very low overhead, but it's a bit of a pain when you want to do host-based programs.

Maybe you could take a look at the book: TCP-IP Lean--Web Servers for Embedded Systems Jeremy Bentham it is a 2002 dated book from CMP books

Grant Edwards escreveu:

You need to do some reading.

Whatever you like. I'd suggest using a header that at least says what the body size is, and a body that encapsulates the protocol you use now. In both directions.

No such thing, unless you're talking http. Or unless you're using a standard TCP/IP service, like mail, or telnet, or... etc.

Then you do need to talk http. It's a client-server affair, stateless. Do some reading. Clue: port 80.

Could be worse. Could be apples to oranges.

I suspect you mean peer-to-peer, in which case look into sockets. Define your own packet-based protocol. Use a TCP socket pair (not pear) to exchange packets in a well-defined format.

There are some big conceptual differences between RS-485 and Ethernet/TCP/IP. Read up on TCP/IP. It's kinda like the OSI N-layer model, but simpler.

Steve

This would seem to be a controlling factor. What protocols do these devices understand?

I was going to suggest AppleTalk, but you need "pear-to-pear"(sic) ;)

Regards,

Don't top-post. See the links below. Don't use childish abbreviations, they simply make your article hard to read, and make you look uneducated.

TCP is good for host pc to device communications, it has a concept of sessions (though of course you can open and close them for each operation, as HTTP tends to)

For simply replacing RS485 in a more peer-to-peer environment though, UDP would be the most directly translatable in that you talk whenever your feel like it and wait for an application level reply. You can either take the content you would put in RS485 messages (in whatever addressed formating you had been using) and put it instead in UDP packets addressed to the intended device, or you can actually just encapsulate each entire RS485 message in a UDP packet to the host (or even sent to broadcast)

I've been looking at a device that has a legacy system of RS485 transmittable message packets, that for its ethernet option then sends those through a TCP session. That I don't like. I'd rather open a TCP session and converse, or send each message as a UDP packet.