8051 UART timing

Does anyone know the exact timing of the internal UART on an 8051 based
microprocessor (actually it's a Dallas 80C320)? As I understand it, when
transmitting, the TI bit sets a the _beginning_ of the stop bit of the
byte. So if you wait for the TI bit to go true, and immediately write
another byte to SBUF, does this immediately start transmitting the start
bit of the new byte, cutting short the stop bit of the previous byte and
potentially leading to a framing error in the receiver? If so, do I have to
wait a short 1 bit-time delay after seeing TI before writing the next byte
to SBUF?

If this doesn't happen, why not? What feature of the chip prevents this
from happening?

If this is the last byte, I want to turn off the RS485 driver so I can wait
for the reply. For a similar reason, do I have to wait for 1 bit-time after
seeing TI before turning off the driver?

And if I'm the receiver (and let's say there are several devices listening
to these messages) I understand that the RI bit sets half way through the
stop bit of the character. Does this mean that if I want to reply to the
message, I have to wait 1/2 a bit time (maybe 1 bit-time would be safer)
after seeing RI before turning my RS485 driver on to avoid corrupting the
stop bit, which could lead to receive errors in other listeners?

If they're necessary, what's the best way of implementing these delays for
reliable RS485 operation?

Thanks - Rowan

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

"rowan.bradley" <rowan@n_o_s_p_a_m.sylvester-bradley.org> wrote in message news:EJOdnU4X4Y_6ZP7QnZ2dnUVZ_j6dnZ2d@giganews.com...
> Does anyone know the exact timing of the internal UART on an 8051 based
> microprocessor (actually it's a Dallas 80C320)? As I understand it, when
> transmitting, the TI bit sets a the _beginning_ of the stop bit of the
> byte. So if you wait for the TI bit to go true, and immediately write
> another byte to SBUF, does this immediately start transmitting the start
> bit of the new byte, cutting short the stop bit of the previous byte and
> potentially leading to a framing error in the receiver? If so, do I have to
> wait a short 1 bit-time delay after seeing TI before writing the next byte
> to SBUF?
>
> If this doesn't happen, why not? What feature of the chip prevents this
> from happening?
>
> If this is the last byte, I want to turn off the RS485 driver so I can wait
> for the reply. For a similar reason, do I have to wait for 1 bit-time after
> seeing TI before turning off the driver?
>
> And if I'm the receiver (and let's say there are several devices listening
> to these messages) I understand that the RI bit sets half way through the
> stop bit of the character. Does this mean that if I want to reply to the
> message, I have to wait 1/2 a bit time (maybe 1 bit-time would be safer)
> after seeing RI before turning my RS485 driver on to avoid corrupting the
> stop bit, which could lead to receive errors in other listeners?
>
> If they're necessary, what's the best way of implementing these delays for
> reliable RS485 operation?
>
> Thanks - Rowan


You worry too much, just use RI and TI bits without any delays. There are
a few internal delays that will take care about your concerns.

Anyway, look here (http://www.nxp.com/acrobat_download2/various/80C51_FAM_HARDWARE_1.pdf).
Figure 14. will explain everything.

- while (1);

On Feb 23, 6:59=A0am, "rowan.bradley" <rowan@n_o_s_p_a_m.sylvester-
bradley.org> wrote:
>
> If they're necessary, what's the best way of implementing these delays fo=
r
> reliable RS485 operation?

If you are not using 9 bit mode already, then enabling that and
sending a HI in TB8, will give the TI at the end of that bit (your
stop bit).
You have 2 stop bits, which is also a good idea to tolerate timing
variations.

Note on TX, time ticks are always /16 , whilst on RX there is a
monostable-reset on the start bit; That means you can have a phase
shift between TX and RX.

Some 8051 info indicates a TX lead in, of always one whole bit clock
(like a start bit preamble), and some other info says Start starts on
the first bit tick after write.

Because of these variations, it is a good idea to toggle a pin on TI/
RI and scope the actual effects, and allow a comfortable turn-around
time.

I am wondering which of MCU would work to best for video play back on two
screens. I already have basic experience with PIC, AVR, and ARM MCUs;
however, I have never used LCDs with them so I don't know how well each of
them will work. If anyone has any advice on the matter I would be very
happy to hear it.
Thanks

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Mar 1, 1:23=A0pm, "Colten141" <colt-141@n_o_s_p_a_m.hotmail.com>
wrote:
> I am wondering which of MCU would work to best for video play back on two
> screens. I already have basic experience with PIC, AVR, and ARM MCUs;

It depends on the video format. In the real world, ASSPs or ASICs are
used for these sorts of applications (MPEG etc) - they often have an
ARM or MIPS core, and special hardware to accelerate video decode. You
won't be able to get your paws on those chips, though, the NDAs are
onerous.

As a data point for you, I decoded a 320x240 MPEG-1 stream (no audio)
at about 12fps on a 74MHz ARM7. That did not include colorspace
conversion, it was a straight decode of the compressed stream to YUV
and display of the luminance channel onscreen. It also wasn't
optimized - I just pulled the code out of mplayer and massaged it
vigorously to fit the application. On a more modern frisky ARM9 you'll
be able to do it realtime with audio, no problem. It won't be
efficient compared to the ASSP solution, but it will work.

If you don't want to jump up to that sort of large hardware, look at
other video formats like AMV, which are much less stressful to decode.

On Mar 1, 10:23=A0am, "Colten141" <colt-141@n_o_s_p_a_m.hotmail.com>
wrote:
> I am wondering which of MCU would work to best for video play back on two
> screens. I already have basic experience with PIC, AVR, and ARM MCUs;

Unless you are doing postage stamps, you can rule out PIC and AVR.
ARM can goes up to 2GHz and beyond.

Il 01/03/2011 19:23, Colten141 ha scritto:
> I am wondering which of MCU would work to best for video play back on two
> screens. I already have basic experience with PIC, AVR, and ARM MCUs;

at91sam9m10 seems ok; it has an hardware video decoder (h264, mpeg4 and 
mpeg2) and color conversion.
Atmel provides also a "software package" which contains lots of project 
for keil, iar and gnu, useful if you don't want to use wince or linux.

L