Electronics > Projects, Designs, and Technical Stuff

Much Help needed with 8251 USART Problem.......

<< < (3/3)

oPossum:

--- Quote from: ebastler on August 30, 2020, 06:23:46 pm ---Ouch... Great point; that sounds like a very plausible cause indeed. The datasheet for the newer a8251 (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/ds8251.pdf) mentions this in a very subtle way:


--- Quote ---Divide-by-1 mode. Clock and data rates are identical. External logic is responsible for synchronizing the rxd signal to the nrxc signal.
--- End quote ---

That's a nice way to state "doesn't really work"...  ::)

--- End quote ---

The 1985 and 1993 data sheets both say...


--- Quote ---In asynchronous mode the baud rate is a fraction of the RxC frequency.

--- End quote ---

So the info is there, but not as clear as is could be.

The description of reset polarity is quite confusing.

homemadecpu1986:

--- Quote from: oPossum on August 30, 2020, 06:12:30 pm ---
--- Quote from: homemadecpu1986 on August 30, 2020, 05:29:07 pm ---I am initializing the USART correctly I think, the mode byte is 0x4D

--- End quote ---

1X baud rate factor does not work reliably for async mode. 16X or 64X will work.

This is not well documented in the datasheet, but it is 'common knowledge' that a 4X or higher clock is typically needed for reliable async receive.

--- End quote ---


You are a hero !!!! This was exactly the problem. I tried it now and it works solidly and without any issues. I can't believe this. Really can't. I have been trying to trace this problem down for days now without success. I assumed I was somehow initializing the UART wrong. But I doubled checked and couldn't find anything wrong. Oh boy. I am so happy and relieved now. You lifted a weight from my shoulders. I have made a 16bit cpu/minicomputer from 74HC logic, and I am installing some peripherals to it, one of them is this UART. It would send characters no problem, but when receiving.... it had been a nightmare.

When did you first hear about this? What bad luck on me to use the UART straight at 1x!! I thought about testing at 16x or 64x but somehow didn't. It would still perplex me why it would work at higher x.

I just want to thank you very much for your kind help. You wouldn't believe how happy I am !!

homemadecpu1986:
That is an interesting fact. Agrees with some of the logic I was trying to use to find this bug. I found it strange that the baud clock would be exactly the same as the baud given the 8251 cannot divide it into smaller chunks by just any divisor. So if it divides say by 16, then it has 16 steps to decide whether it is valid.

That is great information you have given. Thank you for that!

Ian.M:
The reason for this is inherent in the design of any UART with an external clock.   For asynchronous serial data with normal 'RS232 style' byte framing, the start bit is the same width as the data bits.  The UART can only act on its detection of the start bit at a clock edge, so if the clock frequency is the same as the baud rate, assuming 50% duty cycle clock, there is inevitably half a bit time uncertainty.  The UART needs to sample the data bits in the middle of each bit time, so it should ideally delay 1.5 bit times from the leading edge of the startt bit before sampling D0.  Unfortunately that half bit time uncertainty + propagation delays can push the sampling point into the transition to the next bit.   Therefore you can see that its impossible to design an externally clocked UART using internally synchronous logic that works reliably with less than three active clock edges per bit.   Binary divisors are vastly preferable in logic design and its easier to only sample on a single clock edge, so typically UARTs require a minimum clock of 4x the baud rate, or higher if they oversample each bit.

homemadecpu1986:

--- Quote from: Ian.M on August 31, 2020, 10:57:43 am ---The reason for this is inherent in the design of any UART with an external clock.   For asynchronous serial data with normal 'RS232 style' byte framing, the start bit is the same width as the data bits.  The UART can only act on its detection of the start bit at a clock edge, so if the clock frequency is the same as the baud rate, assuming 50% duty cycle clock, there is inevitably half a bit time uncertainty.  The UART needs to sample the data bits in the middle of each bit time, so it should ideally delay 1.5 bit times from the leading edge of the startt bit before sampling D0.  Unfortunately that half bit time uncertainty + propagation delays can push the sampling point into the transition to the next bit.   Therefore you can see that its impossible to design an externally clocked UART using internally synchronous logic that works reliably with less than three active clock edges per bit.   Binary divisors are vastly preferable in logic design and its easier to only sample on a single clock edge, so typically UARTs require a minimum clock of 4x the baud rate, or higher if they oversample each bit.

--- End quote ---

That makes a lot of sense indeed. When I started using this UART I had never used one before, and after thinking about the baud rate clock I started to think I was somehow misunderstanding baud because to me it didn't make sense the baud clock should be the same frequency as the data rate clock. So what you are makes complete sense to me and is nice to know. 

Must have caused a lot of headache for many beginners!!

Best wishes

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod