Re: UART design considerations

On Mar 6, 11:46 am, Keith M <kmo...@xxxxxxxxx> wrote:
On Mar 5, 3:28 pm, rickman <gnu...@xxxxxxxxx> wrote:

I have never seen a UART that samples a bit more than once.

http://datasheets.maxim-ic.com/en/ds/MAX3100.pdf

From PDF page 7,

"An internal clock samples data at 16
times the data rate. The start bit can occur as much as
one clock cycle before it is detected, as indicated by
the shaded portion. The state of the start bit is defined
as the majority of the 7th, 8th, and 9th sample of the
internal 16x baud clock. Subsequent bits are also
majority sampled."

I must not be reading this right. Or is this just the exception?

No, you are reading this right and I am learning something (or maybe
relearning...). Personally, I am surprised they implement this. I
would deal with noise issues in the analog domain, either by improving
my SI design or adding a filter (that's what the oversampling is
doing, low pass filtering). Improving the SI of the design works on
all frequencies of noise not just the higher freqs.


So how much resolution do you get when you "wait" for the start bit
transition? What is the time of the loop?

Great question. I hoping to get into the down and dirty with this.

I'm at 50mhz, so my instruction execution cycle is 20ns. My bit
period is 500ns for 2mbps baud rate. And remember this is _not_
RS232, so forget about inverting stuff.

waitforstartbit:

SNB receivepin (if receivepin is LOW, skip the next instruction)
JMP waitforstartbit

The execution time would be 2 cycles (2*20=40ns) if receivepin was low
at the top of the code, or 4 cycles (4*20=80ns) if it had loop back.
I _think_ this gives me a jitter of 40ns, the difference. Does this
sound right?

I think so. The loop is 40 ns, so that is your resolution. At less
than 10% of the bit time, this should be good enough.


Even if I am slightly early or slightly late, this problem won't
continue to slip (given a fixed transmit bit period), I'd just end up
consistently sampling slightly off center on each bit. IE, its just a
problem getting started, not a continuing problem.

Clock mismatches will cause the timing to slip more with each bit. If
you sample perfectly in the middle of the start bit, a 2.5% error in
the clock of each end will just be reaching a bit boundary at the end
of ten bits.


Try testing it by waiting
for the start bit and then toggling an output bit. In fact, you can
replace the "sample the bit" with "toggle output" to see how
consistently you find the middle of the bit. A scope won't lie.

Great idea.

BTW, by resonator, do you mean one of those ceramic things?

I think so. CSTLS50M0X51-B0 http://www.murata.com/catalog/p16e.pdf

The specs on this part seem to be good enough for UART timing at less
than 1% total accuracy over temperature.


Just so everyone knows, this uart code of mine actually functions as
is, so I'd hope there aren't any MAJOR issues with it. I am in the
process of doing a code review and want to stress test it. I'm
looking to see if there are major design flaws in my code, since I've
never written a UART before....

The problem with testing is that it can't prove that a design works
under all conditions because it is hard to create "all conditions".
But I would say this design should be pretty easy to verify by
testing.

.

Relevant Pages

  • Re: Question about multi write ports RAM in FPGA?
    ... Somehow mentioning Superscaler just told me your clock is headed down ... How many LUT levels of logic do you expect and what is your ... A very fast n cycle design can run at the limit of the BRAM or a16b ...
    (comp.arch.fpga)
  • Re: UART design considerations
    ... "An internal clock samples data at 16 ... times the data rate. ... so my instruction execution cycle is 20ns. ...
    (comp.arch.embedded)
  • Re: UART design considerations
    ... "An internal clock samples data at 16 ... times the data rate. ... so my instruction execution cycle is 20ns. ...
    (comp.arch.embedded)
  • Re: data transfer design
    ... This depends on the "10MB/s" data source on the 100 MHz clock. ... if you can guarantee that the input Data Valid indicator is never ... at least two cycles between each valid cycle. ... If your average data rate is 10 MB/s, but your peak data rate is ...
    (comp.lang.verilog)
  • Re: async clock design
    ... I stuck with the clock signal again. ... I am designing hamming encoder of code. ... If the clock signal is 10MHz and input data rate is 2 MHz, ... ASIC/FPGA Design Services ...
    (comp.dsp)