sending UART signals : from a Atmega128 to a basicstamp
Archiver
Posts: 46,084
I am interfacing 2 MCUs Basic stamp BS2sx and the Atmega128. The link
is via LED/Photodiodes. The atmega128 has a software UART code running
on it. and i have successfully interfaced the Stamp sending data to
the Atmega using a *9600 Baud 8N1 Inverted(direct connection)*. Now
when i send data from the atmega128 to the stamp thats when the
problem occurs. I have thouroughly checked the waveform on the scope
and backannotated the waveform to its bit value the atmega is
generating a correct waveform.
I am using a hanshaking protocol:
1)Sender(atmega) sends a `request to send' by making its
outgoing link High;
2)Receiver(stamp) sends a `ready to receive' by making its
outgoing link High and waits
3)Sender(atmega) makes its outgoing link low signaling the data will
be sent when the reciever(stamp) makes its outgoing link low
4)Reciever(stamp) makes it outgoing link low
5)Data is communicated serially using RS-232 protocol (serin for
stamp)
all the steps are done again in a continous loop
When i send data from the stamp to the atmega128(16Mhz) it runs fine ,
the data is received correctly. But other way around the problem
occurs.
If send the character 'A' ASCII = 65. the reciver(basic stamp) reads
it as a ASCII 208.
I tried drawing correlations on how 208 is related to 65. But my guess
was that the atemga was sending data too fast right after step 4 in
the handshaking protocol.i though that the stamp was taking time
between the steps 4 -> 5. So i put a delay at the atmega's
code to wait for 30ms or so after the stamp made its outgoing line
low.But the problem still existed. There is ample time for the stamp
to get into its serin mode after handshaking. but it still gets the
wrong data. I am sure the waveform generated by the Atmega is clean. I
have checked for many characters by backannotating them to their ASCII
values.
Thanks for ure help and time.
Regards
here is the stamp code
****************************************************************
'{$STAMP BS2sx}
'VARIABLES
ruffer var byte
BAUD9600 CON 16624 'BSX (84 for BS2)
TX_Port CON 9
looper: 'main
wait_for_rts: 'wait for a request to send
if IN14=1 then acknowledge_rts
goto wait_for_rts
acknowledge_rts: 'tell atmega that u shall service his rts
high TX_PORT
wait_for_rx_go_low:
if IN14=0 then get_ready
goto wait_for_rx_go_low
get_ready:
low TX_PORT 'tell atmega send now
serin 14,BAUD9600,[noparse][[/noparse]ruffer]
debug bin ruffer , cr
GOTO looper 'do whole step again...this makes sure experiment is
repeatable and error free
is via LED/Photodiodes. The atmega128 has a software UART code running
on it. and i have successfully interfaced the Stamp sending data to
the Atmega using a *9600 Baud 8N1 Inverted(direct connection)*. Now
when i send data from the atmega128 to the stamp thats when the
problem occurs. I have thouroughly checked the waveform on the scope
and backannotated the waveform to its bit value the atmega is
generating a correct waveform.
I am using a hanshaking protocol:
1)Sender(atmega) sends a `request to send' by making its
outgoing link High;
2)Receiver(stamp) sends a `ready to receive' by making its
outgoing link High and waits
3)Sender(atmega) makes its outgoing link low signaling the data will
be sent when the reciever(stamp) makes its outgoing link low
4)Reciever(stamp) makes it outgoing link low
5)Data is communicated serially using RS-232 protocol (serin for
stamp)
all the steps are done again in a continous loop
When i send data from the stamp to the atmega128(16Mhz) it runs fine ,
the data is received correctly. But other way around the problem
occurs.
If send the character 'A' ASCII = 65. the reciver(basic stamp) reads
it as a ASCII 208.
I tried drawing correlations on how 208 is related to 65. But my guess
was that the atemga was sending data too fast right after step 4 in
the handshaking protocol.i though that the stamp was taking time
between the steps 4 -> 5. So i put a delay at the atmega's
code to wait for 30ms or so after the stamp made its outgoing line
low.But the problem still existed. There is ample time for the stamp
to get into its serin mode after handshaking. but it still gets the
wrong data. I am sure the waveform generated by the Atmega is clean. I
have checked for many characters by backannotating them to their ASCII
values.
Thanks for ure help and time.
Regards
here is the stamp code
****************************************************************
'{$STAMP BS2sx}
'VARIABLES
ruffer var byte
BAUD9600 CON 16624 'BSX (84 for BS2)
TX_Port CON 9
looper: 'main
wait_for_rts: 'wait for a request to send
if IN14=1 then acknowledge_rts
goto wait_for_rts
acknowledge_rts: 'tell atmega that u shall service his rts
high TX_PORT
wait_for_rx_go_low:
if IN14=0 then get_ready
goto wait_for_rx_go_low
get_ready:
low TX_PORT 'tell atmega send now
serin 14,BAUD9600,[noparse][[/noparse]ruffer]
debug bin ruffer , cr
GOTO looper 'do whole step again...this makes sure experiment is
repeatable and error free
Comments
in the baudrate, but the Basic Stamp would be very sensitive to this.
What I feel is happening is the Mega128 can receive the data from the
Stamp OK as the UART can compensate for the slight baud rate error. The
Stamp on the other hand can't. If you use a software UART (bit banging)
then the Atmega128 would be very sensitive to slight baud rates errors
too.
16mhz means your about 0.16% off at 9600baud.
One simple method is to use a crystal on the Atmega128 that gives you a
zero percent error for 9600 baud. Such as 4.608mhz, 9.216mhz, 11.059mhz,
etc.
Another method is to adjust the OSCAL on the Mega128 to compensate for
the slight percentage drift error.
A third method, if your using a Stamp other than the BS1, might be, to
tweak the baud rate value a little bit so that it better matches up. But
I have not tried this myself.
Here is a simple example of adjusting the OSCAL on the ATMega8 using
BASCOM AVR to give a 0% baud rate error:
$regfile = "m8def.dat"
$crystal = 1000000
$baud = 19200
Osccal = 146
Here is a another way, using AtMega8 and a serial LCD display.
In this case we keep looping and changing OSCAL, until the display
prints correctly. Then we know what the OSCAL value is that we should
use.
This is out of the samples programs in BASCOM AVR.
$regfile = "m8def.dat"
$crystal = 1000000
$baud = 19200
Dim X As Byte , S As String * 10
Config Portb = Output
Osccal = &HA0
Do
Osccal = Osccal + 1
Portb = Not Portb
Print "hello mega8 " ; Osccal
Waitms 1000
Loop
END
Original Message
From: doodoo902102002 [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=g6thtr1iTe3ptSfvDpG1x5a54d26e_ZIXQbaxuvTk55RnJFaxVni_5EzmSVJub8vxE3Cg9eN9mbd4tNI6Ay_kG4]doodoo902102002@y...[/url
Sent: Saturday, March 13, 2004 2:31 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] sending UART signals : from a Atmega128 to a
basicstamp
I am interfacing 2 MCUs Basic stamp BS2sx and the Atmega128. The link
is via LED/Photodiodes. The atmega128 has a software UART code running
on it. and i have successfully interfaced the Stamp sending data to
the Atmega using a *9600 Baud 8N1 Inverted(direct connection)*. Now
when i send data from the atmega128 to the stamp thats when the
problem occurs. I have thouroughly checked the waveform on the scope
and backannotated the waveform to its bit value the atmega is
generating a correct waveform.
I am using a hanshaking protocol:
1)Sender(atmega) sends a `request to send' by making its
outgoing link High;
2)Receiver(stamp) sends a `ready to receive' by making its
outgoing link High and waits
3)Sender(atmega) makes its outgoing link low signaling the data will
be sent when the reciever(stamp) makes its outgoing link low
4)Reciever(stamp) makes it outgoing link low
5)Data is communicated serially using RS-232 protocol (serin for
stamp)
all the steps are done again in a continous loop
When i send data from the stamp to the atmega128(16Mhz) it runs fine ,
the data is received correctly. But other way around the problem
occurs.
If send the character 'A' ASCII = 65. the reciver(basic stamp) reads
it as a ASCII 208.
I tried drawing correlations on how 208 is related to 65. But my guess
was that the atemga was sending data too fast right after step 4 in
the handshaking protocol.i though that the stamp was taking time
between the steps 4 -> 5. So i put a delay at the atmega's
code to wait for 30ms or so after the stamp made its outgoing line
low.But the problem still existed. There is ample time for the stamp
to get into its serin mode after handshaking. but it still gets the
wrong data. I am sure the waveform generated by the Atmega is clean. I
have checked for many characters by backannotating them to their ASCII
values.
Thanks for ure help and time.
Regards
here is the stamp code
****************************************************************
'{$STAMP BS2sx}
'VARIABLES
ruffer var byte
BAUD9600 CON 16624 'BSX (84 for BS2)
TX_Port CON 9
looper: 'main
wait_for_rts: 'wait for a request to send
if IN14=1 then acknowledge_rts
goto wait_for_rts
acknowledge_rts: 'tell atmega that u shall service his rts
high TX_PORT
wait_for_rx_go_low:
if IN14=0 then get_ready
goto wait_for_rx_go_low
get_ready:
low TX_PORT 'tell atmega send now
serin 14,BAUD9600,[noparse][[/noparse]ruffer]
debug bin ruffer , cr
GOTO looper 'do whole step again...this makes sure experiment is
repeatable and error free
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
Yahoo! Groups Links
What speed are you clocking the Atmel? It is probably too fast for the
Stamp. I have encountered this problem with PIC's and the solution was to
pace the characters as they are sent out. The compliler I use has a handy
"Char_Pacing" define, but you can manually place pauses if you need to.
Also, you are dead sure of the baud settings? Is the signal getting inverted
anwhere?
Hope this helps,
Jonathan
www.madlabs.info
Original Message
From: "doodoo902102002" <doodoo902102002@y...>
To: <basicstamps@yahoogroups.com>
Sent: Saturday, March 13, 2004 12:30 AM
Subject: [noparse][[/noparse]basicstamps] sending UART signals : from a Atmega128 to a
basicstamp
> I am interfacing 2 MCUs Basic stamp BS2sx and the Atmega128. The link
> is via LED/Photodiodes. The atmega128 has a software UART code running
> on it. and i have successfully interfaced the Stamp sending data to
> the Atmega using a *9600 Baud 8N1 Inverted(direct connection)*. Now
> when i send data from the atmega128 to the stamp thats when the
> problem occurs. I have thouroughly checked the waveform on the scope
> and backannotated the waveform to its bit value the atmega is
> generating a correct waveform.
> I am using a hanshaking protocol:
> 1)Sender(atmega) sends a `request to send' by making its
> outgoing link High;
> 2)Receiver(stamp) sends a `ready to receive' by making its
> outgoing link High and waits
> 3)Sender(atmega) makes its outgoing link low signaling the data will
> be sent when the reciever(stamp) makes its outgoing link low
> 4)Reciever(stamp) makes it outgoing link low
> 5)Data is communicated serially using RS-232 protocol (serin for
> stamp)
> all the steps are done again in a continous loop
>
> When i send data from the stamp to the atmega128(16Mhz) it runs fine ,
> the data is received correctly. But other way around the problem
> occurs.
> If send the character 'A' ASCII = 65. the reciver(basic stamp) reads
> it as a ASCII 208.
> I tried drawing correlations on how 208 is related to 65. But my guess
> was that the atemga was sending data too fast right after step 4 in
> the handshaking protocol.i though that the stamp was taking time
> between the steps 4 -> 5. So i put a delay at the atmega's
> code to wait for 30ms or so after the stamp made its outgoing line
> low.But the problem still existed. There is ample time for the stamp
> to get into its serin mode after handshaking. but it still gets the
> wrong data. I am sure the waveform generated by the Atmega is clean. I
> have checked for many characters by backannotating them to their ASCII
> values.
> Thanks for ure help and time.
> Regards
>
> here is the stamp code
> ****************************************************************
> '{$STAMP BS2sx}
> 'VARIABLES
> ruffer var byte
>
> BAUD9600 CON 16624 'BSX (84 for BS2)
>
> TX_Port CON 9
>
> looper: 'main
>
> wait_for_rts: 'wait for a request to send
> if IN14=1 then acknowledge_rts
> goto wait_for_rts
>
> acknowledge_rts: 'tell atmega that u shall service his rts
> high TX_PORT
>
> wait_for_rx_go_low:
> if IN14=0 then get_ready
> goto wait_for_rx_go_low
>
> get_ready:
> low TX_PORT 'tell atmega send now
> serin 14,BAUD9600,[noparse][[/noparse]ruffer]
> debug bin ruffer , cr
>
> GOTO looper 'do whole step again...this makes sure experiment is
> repeatable and error free
>
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
>
>and backannotated the waveform to its bit value the atmega is
>generating a correct waveform.
>
>...
>
>serin 14,BAUD9600,[noparse][[/noparse]ruffer]
Are you checking that waveform right at pin p14 on the Stamp?
transmitting power from the atmega128. The Transmit LED circuit(on the
atmega) wasn't giving enough power to switch the Recieving stamp
phototransistor. The peak to peak on the stamp input pin was just 1.5
Volts: so the Vih requirement for the stamp was not being met. Now its
around 2.5 - 2.8 Volts and works well and the characters are recieved
well by the stamp. I might increase the TX power more to increase
noise immunity.
*However* theres another interesting problem. As I said in my initial
post that I use a handshaking protocol. I notice that I need to make
the atmega pause for 416microseconds right after the receiver(stamp)
makes its tx line low (signaling the atmega to send) and before the
atmega actually sends out the serial data(rs232). It seems that
the stamp needs some time to get its SERIN command ready. This is
understandable since the atmega is much faster. BUT the interesting
thing is that on increasing the baudrate from 2400 baud to 9600 Baud I
have to increase the delay in the atmega just before sending the data.
This seems counter-intuitive: since the time that the stamp takes
between setting its TX pin low to the time it sets up its input pin
for the SERIN command *should* be a constant and it is not ..at least
in this case it isnt.It seems that the stamp needs more time to setup
its SERIN commands as the baudrate goes up. Why is this so?. Am i
interpreting this properly.
the steps 4 and 5 were:
4)Reciever(stamp) makes it outgoing link low : LOW TXPIN
5)Stamp sets up SERIN. Data is communicated serially using RS-232
protocol (serin for stamp) SERIN RXPIN,BAUD9600,[noparse][[/noparse]SERDATAIN]
So the time b/w code lines 4 and 5 in the stamp side seems to be
greater. I say this becuase I have to increase the delay time in the
atmega code from the time the atmega senses a low on the TX pin of the
stamp TO the time i actually send data..Why?
Thanks all for ure answers and help. I appreciate ure time.
--- In basicstamps@yahoogroups.com, Tracy Allen <tracy@e...> wrote:
> >I have thouroughly checked the waveform on the scope
> >and backannotated the waveform to its bit value the atmega is
> >generating a correct waveform.
> >
> >...
> >
> >serin 14,BAUD9600,[noparse][[/noparse]ruffer]
>
>
> Are you checking that waveform right at pin p14 on the Stamp?
receive data in the following sequence after txpin goes low...
LOW txpin
SERIN RXPIN,BAUD9600,[noparse][[/noparse]SERDATAIN]
You observed it took 416 microseconds when the baud rate was 2400 but
longer when the baud rate was 9600, and wondered why.
How much longer? A few microseconds?
Even a small change in program code can affect the timing. The
interpreter stores numbers in memory in a compact form, so it takes
less memory and also less time for the interpreter to read in a small
number. But that is even more counterintuitive to your result,
because the baud rate constant for 9600 baud is smaller than the
constant for 2400 baud. Even things like changing the pin number can
have a small effect on the timing. For example, the reference to a
pin number 0,1,2,4, or 8 is faster than other pin numbers, because of
the particularly efficient way that the Stamp tokenizes the power of
two. (See Brian Forbes' book)
I have some observations on the setup and operation timings of SERIN
at this URL:
http://owlogic.com/BS2rs232.htm#SERIN
-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
>*However* theres another interesting problem. As I said in my initial
>post that I use a handshaking protocol. I notice that I need to make
>the atmega pause for 416microseconds right after the receiver(stamp)
>makes its tx line low (signaling the atmega to send) and before the
>atmega actually sends out the serial data(rs232). It seems that
>the stamp needs some time to get its SERIN command ready. This is
>understandable since the atmega is much faster. BUT the interesting
>thing is that on increasing the baudrate from 2400 baud to 9600 Baud I
>have to increase the delay in the atmega just before sending the data.
>This seems counter-intuitive: since the time that the stamp takes
>between setting its TX pin low to the time it sets up its input pin
>for the SERIN command *should* be a constant and it is not ..at least
>in this case it isnt.It seems that the stamp needs more time to setup
>its SERIN commands as the baudrate goes up. Why is this so?. Am i
>interpreting this properly.
>the steps 4 and 5 were:
>4)Reciever(stamp) makes it outgoing link low : LOW TXPIN
>5)Stamp sets up SERIN. Data is communicated serially using RS-232
>protocol (serin for stamp) SERIN RXPIN,BAUD9600,[noparse][[/noparse]SERDATAIN]
>So the time b/w code lines 4 and 5 in the stamp side seems to be
>greater. I say this becuase I have to increase the delay time in the
>atmega code from the time the atmega senses a low on the TX pin of the
>stamp TO the time i actually send data..Why?
>Thanks all for ure answers and help. I appreciate ure time.
mentioned the reason u sire that the change in baurate casue change in
timings really does not explain it since higher baudrate means a
lower baurate constant so the time to retrieve it should have smaller
not more.
I wonder what the reason is. Moreover i am not changing any pins
..only the baudrate changes.
Thanks
-- In basicstamps@yahoogroups.com, Tracy Allen <tracy@e...> wrote:
> With regard to the time required for the stamp to get itself ready to
> receive data in the following sequence after txpin goes low...
>
> LOW txpin
> SERIN RXPIN,BAUD9600,[noparse][[/noparse]SERDATAIN]
>
> You observed it took 416 microseconds when the baud rate was 2400 but
> longer when the baud rate was 9600, and wondered why.
>
> How much longer? A few microseconds?
>
> Even a small change in program code can affect the timing. The
> interpreter stores numbers in memory in a compact form, so it takes
> less memory and also less time for the interpreter to read in a small
> number. But that is even more counterintuitive to your result,
> because the baud rate constant for 9600 baud is smaller than the
> constant for 2400 baud. Even things like changing the pin number can
> have a small effect on the timing. For example, the reference to a
> pin number 0,1,2,4, or 8 is faster than other pin numbers, because of
> the particularly efficient way that the Stamp tokenizes the power of
> two. (See Brian Forbes' book)
>
> I have some observations on the setup and operation timings of SERIN
> at this URL:
>
> http://owlogic.com/BS2rs232.htm#SERIN
>
> -- regards,
> Tracy Allen
> electronically monitored ecosystems
> mailto:tracy@e...
> http://www.emesystems.com
>
>
>
>
> >*However* theres another interesting problem. As I said in my initial
> >post that I use a handshaking protocol. I notice that I need to make
> >the atmega pause for 416microseconds right after the receiver(stamp)
> >makes its tx line low (signaling the atmega to send) and before the
> >atmega actually sends out the serial data(rs232). It seems that
> >the stamp needs some time to get its SERIN command ready. This is
> >understandable since the atmega is much faster. BUT the interesting
> >thing is that on increasing the baudrate from 2400 baud to 9600 Baud I
> >have to increase the delay in the atmega just before sending the data.
> >This seems counter-intuitive: since the time that the stamp takes
> >between setting its TX pin low to the time it sets up its input pin
> >for the SERIN command *should* be a constant and it is not ..at least
> >in this case it isnt.It seems that the stamp needs more time to setup
> >its SERIN commands as the baudrate goes up. Why is this so?. Am i
> >interpreting this properly.
> >the steps 4 and 5 were:
> >4)Reciever(stamp) makes it outgoing link low : LOW TXPIN
> >5)Stamp sets up SERIN. Data is communicated serially using RS-232
> >protocol (serin for stamp) SERIN RXPIN,BAUD9600,[noparse][[/noparse]SERDATAIN]
> >So the time b/w code lines 4 and 5 in the stamp side seems to be
> >greater. I say this becuase I have to increase the delay time in the
> >atmega code from the time the atmega senses a low on the TX pin of the
> >stamp TO the time i actually send data..Why?
> >Thanks all for ure answers and help. I appreciate ure time.