NS16C2552: Sampling timing

Kenji,

Sorry for the delay here. The expert for these parts is out of office but will be back tomorrow.

Regards,

Eric Hackett

Hi Kenji-san,

We actually don't have the internal design files for this device (device was adopted into TI portfolio after acquiring National Semi in 2011) so I can't say for certain what the internal 16x clock is going to be sampling at. I would also assume some low nanosecond delay after the falling 6th edge of the 16x clock. 

Generally, I usually hear UART sampling is done on the 8th 16x clock pulse since its the mid point of the 16x clock. So seeing the data being sampled using the mid point of the 6th and 7th appears odd. I'm not 100% sure why the device would be spec'd to use 6/7 are the sample point for data. Maybe using the start bit for the 8th pusle and then 6/7 for the data bits would offset some kind of sampling error if the incoming/received data on RX was a little slow (Baud rate was slower than device's baud rate) by a very small %. 

-Bobby

Hi Bobby-san,

Thank you for your answer.

I have one more question to add.

When data is received with a clock that is earlier than the set clock of the receiver that does the sampling, after sampling the stop bit (6/16 points), the falling edge of the next start bit comes in before the completion of 16 clocks.

In such a case, which will be (1) or (2)?

(1) At the time of the falling edge, the stop bit clock is cancelled and the start bit starts counting.

(2) After the 16th point clock of the stop bit, the clock of the start bit starts.

Regards,

Kenji

Bobby-san,

We look forward to your quick response.

Thank you in advance.

Kenji

Hi Kenji,

I believe the first condition you provide:

Kenji Ohno1 said:

(1) At the time of the falling edge, the stop bit clock is cancelled and the start bit starts counting.

should be true. If the device samples the stop correctly, this should stop the 16x clock and it would wait to see another falling edge of a start condition. Otherwise what we would see is as more data packets are sent, the difference between the two clocks (true baud rates) of the communicating UART devices would begin to desync faster as more data packets are sent.

-Bobby

Hi Bobby,

How much difference in baud rate between sending and receiving is allowed in practice?

If there is a large difference in communication speed between transmission and reception, a communication error will occur.

Device A -> Device B　(Device A: NS16C2552, Device B: SCI communication with built-in CPU)

　Transmission: 9600 bps

　Receiving: 9700bps

Does this difference in communication speed cause a problem?

Regards,

Kenji

Hi Bobby,

I have an additional question and a correction to make.

・Device A←Device B (Device A: NS16C2552, Device B: SCI communication with built-in CPU)

　　Device A: 9600bps setting

　　Device B: 9700 bps setting (error of about 1% against 9600 bps)

　　Data is sent from Device B and received by Device .　Parity error occurs in Device A.

The error occurs when the error in the baud rate of Device B exceeds 0.95%, and communication is normal when it is less than this.

[Question]

What are the allowable baud rate errors for PC16552DV/NOPB and NS16C2552TVA/NOPB?

Regards,

Kenji

Baudrate mismatches should be very similar across both devices since they both run 16x sampling.

The main contributor would be the mismatch error between the two UART devices. From what I've read, 4% difference between both should be the maximum allowable difference assuming 1 start bit 8 data bits and 1 stop bit (meaning individual differences should be 2% max). This % error would change if you had more or less total bits though. 

-Bobby