rs 232 time calculation

[microlab]

rs232 timing

hai
is it possible to calculate the time required to send/receive the rs232 communication?
ie.when a system is transmitting at the baud rate of 1200,how much time will it take to send a charector?with 8 bit data 1 start and 1 stop bits(total 10 bits)and no parity?
the crystal frequency is 11.0592mhz and using 8051 processor.
is there any equation available for calculating the timr for different baud rates?
we know that the start bit is a 0 and the stop bit will be a 1.after sending the stop bit, the out put will be o level ie space.when it will come to the mark(1) to give the 0 for the start bit?
the confusion is becausethe baude rate is about the signal changes,not the bits pesr second.can we calculate the minimum and maximum number of charectors will be send/receive in 1 second with a specific baud rate?


thanking you


ml

 

[budhy]

rs232 bit timing

when a system is transmitting at the baud rate of 1200,how much time will it take to send a charector?with 8 bit data 1 start and 1 stop bits(total 10 bits)and no parity?

1200 baud = 1200 bit/second
1 bit time = (1000/1200) = 0.8333333333333 ms
1 start bit, 8 data bit, 1 stop bit total of 10 bit = 10 * 0.8333333333333 ms = 8.333333333333 ms

the crystal frequency is 11.0592mhz and using 8051 processor.

the time calculation independent with xtal frequency

 

[ds18s20]

rs232 time

the time calculation independent with xtal frequency

@budhy

Your answer was very in-depth, hence my follow-up question:

Do you have info on the internals of a typical UART IC. What I really want to know is the algorythm for cathing the async clock and then clocking all bits. I assume that a classic UART is implemented as simple logic, but it must be pretty complex since Verilog implementation still takes few pages of code to come up with FPGA UART.

Anyway, just curious

Thanks
~B

 

[budhy]

rs232 bittime

ds18s20 wrote:

Your answer was very in-depth

Once the baudrate is defined, the time calculation independent with xtal frequency

Do you have info on the internals of a typical UART IC. What I really want to know is the algorythm for cathing the async clock and then clocking all bits

RX clock frequency normally is 16 times the baud rate. At the beginning of start bit the curcuitry delay 8 clock cycles, after that delay 16 cycles to get each bit data.

 

[ds18s20]

how to calculate rs232 timing

RX clock frequency normally is 16 times the baud rate. At the beginning of start bit the curcuitry delay 8 clock cycles, after that delay 16 cycles to get each bit data

Thanks, so to summarize: if we are dealing with 9600 then the UART sampling frequency would be 153.6 kHz and the duration of start bit half-delay which you spoke of (being 8 cycles in lenght) would be 52.08 uS correct?

So far so good, but I really need to know the OOF error handling algorythm. What happens when it's time to receive the stop bit and the signal level points to the wrong polarity - say stop bit is alwys supposed to be 1 but we are reading 0. I assume the logical thing then is to assume that next bit is start bit and clock as normal until we finally find a sequence which ends with the correct stop bit. But by then we have discareded a lot of BYTES? How is this resolved in a more effective way?


Thanks
~B

 

[budhy]

rs232 baudrate calculate

the OOF error handling algorythm

What do you mean with OOF error? Out of Frame -> Framing error?

I assume the logical thing then is to assume that next bit is start bit and clock as normal until we finally find a sequence which ends with the correct stop bit

Start bit is a '0' bit after '1' bit!

But by then we have discareded a lot of BYTES? How is this resolved in a more effective way?

Yes. I think no other way to resolve that error, as Framing error mainly caused by woring baudrate.

 

[ds18s20]

baud rate time calculation

budhyStart bit is a '0' bit after '1' bit!

Ooops my bad, by OOF I meant out of frame. So then if the sender is sending an endless stream of 1010101 the receiver will never be able to re-sync. Sure, if we are sending an endless stream of 10101 then who cares if we are in frame of out of frame but just for the purpose of the discussion I wanted to mention that

~B

 

[waterman]

rs232 baud calculation

RX clock frequency normally is 16 times the baud rate. At the beginning of start bit the curcuitry delay 8 clock cycles, after that delay 16 cycles to get each bit data

Although the sampling clock is 16X, but generally only three samples in the middle are taken into account for voting. See datasheet/application note from Microchip or Atmel.

 

[ds18s20]

baud rate timer calculator

Although the sampling clock is 16X, but generally only three samples in the middle are taken into account for voting. See datasheet/application note from Microchip or Atmel.

I have looked at both, the problem is they all focus on the TX part of the process and no one talks about the RX - exactly what is the timing and sequence. What is the voting process and how are the votes aggregated into a decision rule.

Also the RX opens the door for interesting situations where repeated sequences of specific characters can casue errors to occur and NOT be auto-corrected or detected.

None of this is addressed in the app note of those vendors?

 

[echo47]

rs-232 timing

Most UART receivers are pretty simple, and don't try to do any fancy error recovery. As described earlier, the receiver basically triggers on the start bit, and then samples each data bit near the centers of the expected bits. The receiver may also flag a parity error or framing error if the parity bit or stop bit aren't as expected.

It takes only a few lines of HDL to do that, but some people spread it out over several pages of code.

It's easy to confuse a UART receiver with a continuous stream of simple ASCII characters and carriage returns (such as from some measurement sensors). The UART receiver can't distinguish the start bit from the zero bits in the ASCII characters, so we sometimes get continuous gibberish, and have to unplug and plug the RS-232 cable a few times until the receiver locks on to the true start bit. By occasionally inserting a small delay between transmitted bytes, or by occasionally transmitting a byte that breaks up the repeating zero bits, the UART receiver will automatically slip to the correct start bit. Unfortunately, some product manufacturers don't know that.

I think some UART receivers detect the start bit by looking for a 1 bit followed by a 0 bit, instead of simply looking for a 0 bit. That reduces the problem of locking on to false start bits.

 

[ds18s20]

calculattion rs232 byte durattion

Cool, that is what I am looking for --> a non-glorified example of how this works. You indicated you have this in few lines of HDL? Could that be in Verilog?

I'm interested in seeing it as Verilog example and I mean a real example, NOT using # xx statements to generate delays that would not compile anyway in the real world.

Most text books that show the "typical" example of HDL uart implementation are simply... academia BS, not to mention that none would compile due to other simple syntax errors but to keep focused on the core issue: I would love to see a simple and real example in Verilog, if you happened to have one.

Thanks
~B