EmbeddedRelated.com
Forums

ATmega8535 and USART post-initialisation delay required?

Started by Joe March 13, 2005
Is there a requirement to delay using the USART (at least for asynchronous
transmission) for a period of time after initially setting it up and
enabling interupts until transmitting the first character?


I ask, because when I set it up and then immediately use it to output a
character (or string of characters), they are consistently wrong.  I tried
outputing the following string: "sys initialised".  If I do this immediately
after the setting up, I get (consistently) the output on the right (see
below).  However, if I wait for 128 microseconds (gcc _delay_loop_1(255)), I
sometimes get the correct output and sometimes the wrong output (about 20%
of the time, it's wrong).  If I wait for approx. 43ms (gcc
_delay_loop_2(65535)), then I seem to get the correct result each time I
'boot' my system.

The ATmega8535 datasheet does not seem to say that a delay is required.

The system runs in an infinite loop but uses interupts to write the
characters from a software circular buffer into the USART.  Each time the
USART signals that its own buffer is empty, then the data from the circular
buffer is transferred to the UDR a character at a time.

The necessity for this delay was not noticed before, since the previous
owner of the project was writting some stuff to eeprom before outputting the
first USART character and the problem didn't show - except occasionally I
did notice some corrupted characters being output at startup.

The system does have 2 DC motors that spin for less than a second as power
is applied until the I/O ports are set up, but the wrong column is always
the same data - so, I don't think it is noise.

The system is running with a 6.000MHz crystal with the external clock pin
enabled.   I'm using: 1200baud, 8-bits, 1 stop, no parity.

(binary representation given because there are patterns that can be
detected - the right side of the 'wrong' columns are generally the same as
the left side of the 'correct' columns.)

correct        wrong
01110011  10101110
01111001  10101111
01110011  00101110
00100000  10100100
01101001  01011010
01101110  00101011
01101001  10001011
01110100  10100101
01101001  10000101
01100001  10110001
01101100  10100101
01101001  11001101
01110011  10010101
01100101  10010001
01100100  11111101

Anyone got any suggestions or observations?

Thanks.


correction:
with the short delay, it is CORRECT 20% of the time.



U&#4294967295;ytkownik "Joe" <ffffh.no.spam@hotmail-spammers-paradise.com> napisa&#4294967295; w
wiadomo&#4294967295;ci news:d11ulf$umv$1@news7.svr.pol.co.uk...
> correction: > with the short delay, it is CORRECT 20% of the time. > > >
I also needed delay when slave, (ATmega32) responsed to master, ( PC ) by rs485 wire. In my case it was coused by fact that other side of rs cable (PC) didn't manage to switch back to recive mode fast enough Michal M..
the setup is a normal RS232 serial port - not a master/slave setup.


"Michal Machowski" <machowsk@interia.pl> wrote in message
news:d1b8to$mtj$1@nemesis.news.tpi.pl...
> > U&#4294967295;ytkownik "Joe" <ffffh.no.spam@hotmail-spammers-paradise.com> napisa&#4294967295; w > wiadomo&#4294967295;ci news:d11ulf$umv$1@news7.svr.pol.co.uk... > > correction: > > with the short delay, it is CORRECT 20% of the time. > > > > > > > I also needed delay when slave, (ATmega32) responsed to master, ( PC ) by > rs485 wire. > In my case it was coused by fact that other side of rs cable (PC) didn't > manage to switch back to recive mode fast enough > Michal M.. > >