USART Rx - exact sample time

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi forum,

 

upon receiving a byte on its Rx pin, at what time within a bit does the USART module sample the input voltage level?

 

Background: In an attempt to let my ATtiny2313 communicate with a home theatre PC, I chose to connect its USART pins Rx and Tx to the main board's IrDA header. It also conveniently provides the tiny's supply voltage of +5V even when PC is powered off. That's important for the purpose of tiny. It shall wake PC at a defined time. PC defines it prior to shutting itself down. Time may be a few hours or two weeks, whenever the next scheduled recording is going to be aired.

 

Being an IrDA interface, PC side cuts every bit into 16 equally long slices and sets high bits only during slices 8, 9, 10. So slices 0-7, 11-15 are low no matter what. Receiver will recognize a Start Bit from its edge, which is at slice 8. But receiver doesn't know that. So for it, There are slices 0, 1, 2 set (or not) and all others are always clear.

 

Bytes 0x00 and 0x4C will look this:

 

_________^__^__^__^__^__^__^__^__^_________________^__^__^________^__^_____^____________

 IDLE    S  0  1  2  3  4  5  6  7  T     IDLE     S  0  1  2  3  4  5  6  7  T       IDLE

 

Idle low

S - Start bit

T - Stop bit

 

So if USART module would check its Rx pin exactly in the middle of any bit, I'd reliably get zeroes. Can I get USART module to sample within the first 3/16 of any bit?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hello, Luker -

 

Welcome to AVR Freaks!

 

It has been my understanding that historically, UARTs test bit status multiple times (an odd number) during each expected bit time, and uses a majority to determine the bit value. My recollection is something like 16 UART clock bits per data bit, and tested on clock edges 5, 9, and 13, or something like that.  Whether or not "modern" UARTs still do that is unknown, but I suspect that they do. The U2X bit in AVR UARTs halves the number of UART clocks per data bit (from 16 to 8?).

 

So, at least "classically", there is NOT just one sample time.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Jan 4, 2018 - 11:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

luker wrote:

So if USART module would check its Rx pin exactly in the middle of any bit, I'd reliably get zeroes. Can I get USART module to sample within the first 3/16 of any bit?

 

No.

 

The datasheet shows you exactly where the bits are sampled.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 2313 data sheet says 16 clocks per bit and sample on bit 8, 9 and 10 (for U2X: 8 clocks, sample on 4, 5 and 6). Pages 124-126 in my copy of the data sheet.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
... It has been my understanding that historically, UARTs test bit status multiple times (an odd number) during each expected bit time, and uses a majority to determine the bit value....
Redundant bit-sampling was a later refinement. The original UARTs only sampled each bit, just once, in the center of the bit time. Here is the start of the receiver flowchart for the widely copied Western Digital TR1602A, with the start and data bit sampling:

 

tr1602a start and data bit sampling

 

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a similar question about ATtiny816

 

 

may I ask here or should I start new thread ?

 

 

 

 

 

 

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, the question here seems to have been answered - so if you have the same question, then it is already answered!

 

If your question is not already answered, then it must be  a different question - so a new thread would be in order ...

 

 

EDIT

 

In summary, they key answers were:

 

Brian Fairchild wrote:
The datasheet shows you ...

and

JohanEkdahl wrote:
The [device] data sheet says ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jan 5, 2018 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:
Redundant bit-sampling was a later refinement

But I think it was standard practice by the time the AVR came along ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

luker wrote:
So if USART module would check its Rx pin exactly in the middle of any bit, I'd reliably get zeroes. Can I get USART module to sample within the first 3/16 of any bit?

 

One could write a bit-bang serial function to sample at the needed time!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

jfiresto wrote:
Redundant bit-sampling was a later refinement

But I think it was standard practice by the time the AVR came along ?

Could be, but I stopped following the UART market in the early '90s.

 

If you look at, say, the Philips's SC28L92, their latest and greatest dual UART of 1998, you will find that it still samples each data bit, just once – well into the third decade of the UART.

 

ADDENDUM: Or the fourth decade, if you include the UARTs that DEC included in their minicomputers.

- John

Last Edited: Fri. Jan 5, 2018 - 03:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Well, the question here seems to have been answered - so if you have the same question, then it is already answered!

Except that the answer is likely different for tiny816:

 

It looks like there is a IRCOM module in the new tinys (IrDA 1.4 compliant), and even the possibility to change the pulse sample duration (search the datasheet for registers TXPLCTRL and RXPLCTRL).

I haven't tried to use IRCOM at all, so I have no experience with it, but from what I can read in the datasheet, it looks promising.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much. I'd never sought that in "Asynchronous Clock Recovery".

 

Seems like I would have to build something in software instead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Svuppe wrote:
Except that the answer is likely different for tiny816:

No - the general answer, as noted, is: look in the datasheet for the device in question.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I think the voting system confuse me a bit

Tolerance of main clock will tolerance of baud,
for Attiny816 it is +-2% for factory stored calibration
0-70 °c will slow down or rise up baud rate, So the total frame will expand or shrink,

So just one sample at middle of bit would be sufficient, because %2 tolerance never rich middle point of 1bit

Or two adjacent samples would be reasonable

But voting majority includes two non-adjacent combination

İt means I need to concern something more than tolerance in baud

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m.majid wrote:
Tolerance of main clock will tolerance of baud

I think you might be confusing the tolerance with the systematic error in the calculation of the baud rate?

 

Yes, variations of the source clock will cause variations of the baud rate derived from it.

 

That is why it is generally recommended to use a crystal - which has a good tolerance - rather than the internal RC oscillators - which have (relatively) poor tolerance.

 

just one sample at middle of bit would be sufficient

I think you've missed the point of the multiple samples - it is to avoid false readings due to noise.

 

But voting majority includes two non-adjacent combination

Pardon?

 

İt means I need to concern something more than tolerance in baud

No, it doesn't.

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
multiple samples - it is to avoid false readings due to noise.

This is what I missed in datasheet "noise spikes"
I thaught three sample is because of interfering two adjacent bits, affected from tolerance

awneil wrote:
But voting majority includes two non-adjacent combination

Pardon?

I meant the combination of for example 1.0.1 majority is 1
0 is spike not data, reasonable after "noise spike"

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IrDa is a collection of a bunch of different communication standards with widely varying protocols and baud rates.

https://en.wikipedia.org/wiki/In...

 

For Low baud rate signals (dcf77) I've had good results by using a combination of the pin change interrupt and a free running timer to measure pulse widhts and then interpret the data in software from there.

If your baudrate is too high for that then irDA specific hardware is probably the best option.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com