RS232 is an async protocol, there's no need for any synchronization in the application (that's what the "start bit" is for). Just send the data you want and it will come out the other side. If you saw an
It's for byte sync not bit sync.
application doing this in the past, it's probably one that was trying to do "autobaud" detection, which is a rats nest you don't need to worry about for custom hardware. Or maybe it was transmitting to broken hardware that wasn't fast enough to handle real RS232.
You might want to put a "magic number" at the top of a packet to handle dropped bytes gracefully, but that's a slightly different problem. You certainly don't want to embed padding bytes in the message itself.
Has nothing to do with dropped bytes, has to do with figuring where the start is in a repeating variable length data stream. If I send you a few thousand FF's how do you propose to tell which ones are starts and how many channels? Did it start at the beginning or was it already running when hooked up? You have to have repeating patterns and then change the patterns for sync if you have full value data, or have output data to start and synchronize the packets, which is more trouble over just reading a sync. Just a magic number at the top can easily fail with full range data.
You don't have to have repeating spacers but a nice simple easily understood format is always a good idea, and it's only the high bit anyway, the lower bits can still be used. I do microcontroller code, so I could easily change it to be as terse as possible and still easily synced to, but the bandwidth is so low for a controller vs what else is going on in a 3D PC it's hardly worth worrying about. Overall it's no different than sending IR data streams, you require a reliable sync signal to get started if you want to know where you are. Yep you can autobaud to it if done correctly, but you still need it for general sync unless you limit your data value range in some way.
And it was really just a simple generic example anyway. No doubt if someone is up for it we will discuss it a bit and take it down to a minimum but expandable data format.
Alan
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
