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.)
Anyone got any suggestions or observations?
Reply by Joe●March 13, 20052005-03-13
with the short delay, it is CORRECT 20% of the time.
Reply by Michal Machowski●March 16, 20052005-03-16
U�ytkownik "Joe" <firstname.lastname@example.org> napisa� w
> with the short delay, it is CORRECT 20% of the time.
I also needed delay when slave, (ATmega32) responsed to master, ( PC ) by
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
Reply by Joe●March 17, 20052005-03-17
the setup is a normal RS232 serial port - not a master/slave setup.
"Michal Machowski" <email@example.com> wrote in message
> U�ytkownik "Joe" <firstname.lastname@example.org> napisa� w
> wiadomo�ci news:email@example.com...
> > 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..