RS232 (bits)

[johnpoo]

Does anyone know what is the meaning of "bits=8" in this code below ?

[Ttelmah]

Have a look at some basic sites about async serial, like:
http://www.wcscnet.com/Tutorials/SerialComm/Page1.htm
http://www.taltech.com/TALtech_web/resources/intro-sc.html

Best Wishes

[johnpoo]

Thanks .. I have read through the link.

Want to confirm that the "bits" that we can set is maximum 8? or I want to set it as bits = 24 also can ?

[Ttelmah]

Maximum bits=9.
Look in all the links. 5,6,7,8, & 9 are mentioned.

Seriously, with 'async', you would have real problems, even if you wrote your own driver, going to higher numbers.

Basically, your clocks are synchronised with the start bit, and start to drift apart as you move along the word. The timing accuracy required depends on the word length, and how much error is acceptable in the _last_ bit. You normally have to sample in the centre of the bit, and on some PIC's multiple samples are taken at 1/3rd, and 2/3rd the bit time, so maximum clock error is allowed to be about 0.33/8 = 4% _total_. Given that this is the sum of the timing errors at both ends, both from the BRG, and the clock sources, CCS limits the allowable error from the BRG to somewhere below 3%. If you went to 24bit, the allowable timing margin, would drop to around 1%, and it would become increasingly hard to maintain synchronisation...

If you want to send 24bits, just send three bytes. This way you get three start bits to maintain sync.
Alternatively, use a synchronous link like SPI, where there is an extra clock wire sent with the data.

Best Wishes

[johnpoo]

Thank you very much ...

[jbmiller]

I have to disagree (there is a first time !) with Ttelmah about having problems with higher bit lengths.
I've been using my own 22 bit driver for a proprietary system since the mid 80s for remote energy management. It has been rock stable 24/7 as the saying goes. Able to communicate over standard Bell telephone solid copper raw lines for over 20 miles. Heck I'm even using Mother Nature as the ground between systems. Sure I don't get super fast speed, but I do get 100% reliable communications, something no other system (Rs232,Rs485,Ethernet,FO) can accomplish even with one wire removed!
No, it's not smoke and mirrors, just 'old school' technology.
Cheers
Jay

[Ttelmah]

Look carefuly at what I say.
I don't say it is not possible, _but_ your clock accuracies will _have_ to be tighter than for using shorter word lengths, and your sampling strategies will also need to be chosen to suit.
One of the 'points' about the standard async format, is that it allows significant timing errors at both ends. Your's won't allow nearly as much.
You also seem to be confusing signalling formats with protocols. RS232, 485, etc., are signalling standards, _not_ protocols, a confusion that 'reigns' here...
20 miles, is not even very far at all...

Best Wishes

[jbmiller]

Yeah, I copped out about the 'standards vs.protocols' stuff, seeing how most people know about those names as a means of serial data transfer. Timing errors are somewhat based upon bit rate, so the slower the rate, the easier the error correction routines. The original circuit used an R-C oscillator setup, now it's a crystal.
However, as 'something to think about', I'd like to see what you come up with in communicating over 20 miles of solid copper wire from point 'A' to point 'B'. That's solid copper wire, NO transformers, just straight DC signalling is allowed. So that will rule out Etherent and FO.
I have gone as far as 45 miles, again on solid copper wire (Bell telephone leased lines, NO amplification, no electronics between point 'A' to Point 'B').
Looking forward to seeing what you can dreamup.
Cheers
Jay