>=20 > This is rarely the problem you make it out to be. Almost always, I send > commands starting with a opcode byte and followed by data bytes dependent= on the > opcode. This does mean both ends need to understand the command set else= they > will get out of sync. However, this is no different from any of a 100 ot= her > things that have to be right else they are bugs. Usually you test each c= ommand > and response (I call these same packets coming from the small system to t= he host > "responses" as apposed to "commands", although they may not all be in dir= ect > response to commands) individually right after having written the code. = Once it > works, it's going to stay working. There is really very little problem w= ith > this in practise. >=20 > That's doesn't mean I always totally ignore the problem though. Very sim= ple > things you can do is to make 0 and 255 unused opcodes or specifically def= ine > them as NULL opcodes. That means each end can tolerate any number of 0s = or 255s > without problem. Most unwanted bytes due to startup or whatever will be = 0 or > 255. >=20 > Sometimes I have deliberately used this to sync on startup. The embedded > system may send out 16 NULLs on startup, knowing that the longest possibl= e > response totals less than 16 bytes, for example. If in doubt, send 256 0 > bytes on startup. Startup time is rarely a issue. >=20 > Another trick that I have used occasionally is to add a timeout. If noth= ing has > been received for 100mS, for example, then the current packet will be abo= rted > and the next received byte interpreted as a opcode. This means that any = command > or response needs to be sent without a 100mS gap anywhere between its byt= es, but > that usually happens anyway such that it would be work to prevent it. Ev= en on a > PC with a desktop operating system, the app would generally be stuffing a > command into its own buffer, then pass the whole buffer to the OS to send= .. The > app might get interrupted for more than 100mS while stuffing the buffer, = but > once the low level driver deep in the OS gets the buffer, it's going to g= et > chugged out the serial line without gaps. >=20 > In a few cases I did have to implement a packet protocol with checksums, > ACK, etc, for the reasons you cited. This has been quite rare though. >=20 For a master/slave protocol over a serial line there is no need to reinvent= =20 something new. Use the modbus (RTU) protocol. If this is for a RS485 network with a PC as the master you need a RS232 to= =20 RS485 converter with automatic turnaround between TXing and RXing on the PC= =20 side since the PC might not have time to do that manually (using RTS or DTR= ). One of the benefits with using the modbus protocol is that you can use any = of=20 the modbus test/debug applications that exists out there to directly test t= he=20 slaves before the master software is done. Another benefit is if your slave device gets popular enough, there is alway= s=20 someone else that wants to handle the master side without your PC applicati= on.=20 Almost all PLCs and SCADA applications can handle modbus out of the box and= you=20 don't have to write up a lot of protocol specifications for other programme= rs. /Ruben =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Ruben J=F6nsson AB Liros Electronic Box 9124, 200 39 Malm=F6, Sweden TEL INT +46 40142078 FAX INT +46 40947388 ruben@pp.sbbs.se =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .