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�ytkownik "Joe" <ffffh.no.spam@hotmail-spammers-paradise.com> napisa� w
> wiadomo�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..
>
>
Reply by Michal Machowski●March 16, 20052005-03-16
U�ytkownik "Joe" <ffffh.no.spam@hotmail-spammers-paradise.com> napisa� w
wiadomo�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..
Reply by Joe●March 13, 20052005-03-13
correction:
with the short delay, it is CORRECT 20% of the time.
Reply by Joe●March 13, 20052005-03-13
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.