|>I'm searching to for such a protocol too. Ofcourse it's not very difficult
I've seen dozens and dozens of "non-standard" protocols that are variations
on a single, simple theme. Send a SYNC byte, an Address, data and a CRC. Use a
Master-Slave scheme with timeouts and ACKs. Do this, and you are done.
Move on. Works great. Maybe this is a "conceptual standard".
I guess the CRC-16 is a standard...
I'm not sure what another standard buys you. I've written
a variety of PC-based master devices to do the serial, written in VB or C and
the serial protocol part of it is, maybe, 50 lines of code (including comments).
I am not against reuse nor standards, however, I've seen tooooo many systems
that are large, cumbersome and expensive because of slavish adherence to a
standard that was 10 times more complex than required for the simple application
Just my 2-cents. I'm concerned about Fat-Ware and Overdesigned systems I've
been having to deal with lately. My apologies to the original poster..
|Just a small addition to all this packet formatting talk...
And, don't forget the Base-64 tricks. *If* you like ASCII (better for
debugging) and you want to send binary values (like a long int) over
the wire, then use can use Base-64 encoding. You *could* simply use
HEX encoding with a heavy bandwidth penalty. Base-64 is a compromise.
You can define 1-byte, 2-byte and 3-byte base-64 arguments for any
particular field. Base-64 says that all ASCII message characters (except
start and stop framing characters) are constrained to the ASCII range
of '0' thru 'o' (which is 64 characters, which is 6 bits). Then, to encode
a 16 bit binary number, you break it into 3 Base-64 character (6 bits each).
binary Base-64 string (I use ASCII '0' as base character)
Eg. 40233 --> 9dY
0 --> 000
1 --> 001
63 --> 00o
The conversion routines are pretty simple.
If you're happy with binary with ESCAPE coding for the framing characters,
then ignore all the above!
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...