[[basicstamps] Strange serial problems]
Archiver
Posts: 46,084
Polled I/O will drop data. Interrupt-driven data, even with FIFOs will drop
data.
Maybe you could set up a simple protocol, if both have receive and transmit
wired up.
A sends 0xAA to B, waits 1 sec checking for 0x55 from B, repeats
B sends 0x55 to A when it receives 0xAA from A
One thought:
A sends 0xAA 0x00, waits 1 sec for 0x55 0xFF from B
if no answer, send 0xAA 0x01, wait a sec looking for 0x55 0xFE
B receives data from A, returns the complemented data back to A
Well, something to play with perhaps. Think of a state machine on either
side.
"Mark Lamond" <lists@m...> wrote:
>
> Hi there,
>
> I have a BS2 set up to send and recieve serial data from a microcontroller.
> The BS2 sends a single byte to the device, then listens for a single byte
> reply. For instance if i send $FF to the device it should return $FF. For
> the moment i am displaying the recived data via the debug output. Comms are
> running at 19200bps, and both devices are talking TTL levels with the
> Stamp's I/O lines directly connected to the serial port of the target
> device's microcontroller.
>
> Pin 0 is connected to the target's RX
> Pin 5 is connected to the target's TX
>
> Here is my code:
>
> Byte VAR BYTE
> Byte = 0
>
> DEBUG "Sending Data", CR
> SEROUT 0, 110, [noparse][[/noparse]$FF]
> SERIN 5, 110, [noparse][[/noparse]Byte]
> DEBUG "Recieved Data", CR
> DEBUG Byte, CR
>
> I am using a PC to sniff both serial lines between the target device and
> Stamp so i can see in real time what is happening. When the program is
> started running it sends $FF to the device as expected, and the device
> replies with $FF - however the stamp seems not to have noticed this and
sits
> waiting for a serial input.
>
> If i use my PC to "inject" an $FF into the line connecting to Pin 5 while
> the Stamp is waiting for input, the stamp correctly recieves the byte,
> displays it via the debug output and the program stops.
>
> This makes me think that the Stamp isn't quick enough to catch the data on
> Pin 5 after it has processed the SEROUT command and misses the data from
the
> target device? Can anyone throw any light on what i might be doing wrong,
or
> how to get round the problem? Perhaps i need a faster Stamp?
>
> Many thanks,
>
> Mark.
>
>
> 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.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
data.
Maybe you could set up a simple protocol, if both have receive and transmit
wired up.
A sends 0xAA to B, waits 1 sec checking for 0x55 from B, repeats
B sends 0x55 to A when it receives 0xAA from A
One thought:
A sends 0xAA 0x00, waits 1 sec for 0x55 0xFF from B
if no answer, send 0xAA 0x01, wait a sec looking for 0x55 0xFE
B receives data from A, returns the complemented data back to A
Well, something to play with perhaps. Think of a state machine on either
side.
"Mark Lamond" <lists@m...> wrote:
>
> Hi there,
>
> I have a BS2 set up to send and recieve serial data from a microcontroller.
> The BS2 sends a single byte to the device, then listens for a single byte
> reply. For instance if i send $FF to the device it should return $FF. For
> the moment i am displaying the recived data via the debug output. Comms are
> running at 19200bps, and both devices are talking TTL levels with the
> Stamp's I/O lines directly connected to the serial port of the target
> device's microcontroller.
>
> Pin 0 is connected to the target's RX
> Pin 5 is connected to the target's TX
>
> Here is my code:
>
> Byte VAR BYTE
> Byte = 0
>
> DEBUG "Sending Data", CR
> SEROUT 0, 110, [noparse][[/noparse]$FF]
> SERIN 5, 110, [noparse][[/noparse]Byte]
> DEBUG "Recieved Data", CR
> DEBUG Byte, CR
>
> I am using a PC to sniff both serial lines between the target device and
> Stamp so i can see in real time what is happening. When the program is
> started running it sends $FF to the device as expected, and the device
> replies with $FF - however the stamp seems not to have noticed this and
sits
> waiting for a serial input.
>
> If i use my PC to "inject" an $FF into the line connecting to Pin 5 while
> the Stamp is waiting for input, the stamp correctly recieves the byte,
> displays it via the debug output and the program stops.
>
> This makes me think that the Stamp isn't quick enough to catch the data on
> Pin 5 after it has processed the SEROUT command and misses the data from
the
> target device? Can anyone throw any light on what i might be doing wrong,
or
> how to get round the problem? Perhaps i need a faster Stamp?
>
> Many thanks,
>
> Mark.
>
>
> 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.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Comments
writes:
> Polled I/O will drop data. Interrupt-driven data, even with FIFOs will drop
> data.
>
> Maybe you could set up a simple protocol, if both have receive and transmit
> wired up.
>
> A sends 0xAA to B, waits 1 sec checking for 0x55 from B, repeats
> B sends 0x55 to A when it receives 0xAA from A
>
> One thought:
>
> A sends 0xAA 0x00, waits 1 sec for 0x55 0xFF from B
> if no answer, send 0xAA 0x01, wait a sec looking for 0x55 0xFE
>
> B receives data from A, returns the complemented data back to A
>
> Well, something to play with perhaps. Think of a state machine on either
> side.
>
OK, I admit it. I am a dummy when it comes to serial communication. Through
various literature and that above, I often see "0xAA" and the like. I assume
the AA portion is a hexidecimal value/address? What does each bit of "0xAA"
represent?
Thanks
[noparse][[/noparse]Non-text portions of this message have been removed]
>OK, I admit it. I am a dummy when it comes to serial communication. Through
>various literature and that above, I often see "0xAA" and the like. I assume
>the AA portion is a hexidecimal value/address? What does each bit of "0xAA"
>represent?
Hex number system is 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f
0xAA is binary 10101010
Note the alternating 10 pattern.
Another useful pattern is 0x55 - binary 01010101
Don't be afraid to ask even basic questions. There are *no* stupid questions.
dwayne
--
Dwayne Reid <dwayner@p...>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax
Celebrating 19 years of Engineering Innovation (1984 - 2003)
.-. .-. .-. .-. .-. .-. .-. .-. .-. .-
`-' `-' `-' `-' `-' `-' `-' `-' `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.
mode will do conversions from hex to decimal, octal and binary. 0xAA or $AA
is 10101010 in binary or 170 in decimal.
Original Message
> OK, I admit it. I am a dummy when it comes to serial communication.
Through
> various literature and that above, I often see "0xAA" and the like. I
assume
> the AA portion is a hexidecimal value/address? What does each bit of
"0xAA"
> represent?
daweasel@s... writes:
> Windows calculator (click START, RUN, type CALC, click OK) in scientific
> mode will do conversions from hex to decimal, octal and binary. 0xAA or $AA
> is 10101010 in binary or 170 in decimal.
Thanks, I already completely understood how to convert, hex, binary &
decimal, without a calculator. The hex designator 0x is what threw me off.
Speaking of which, in the Intel world, if I correctly understand 0x
designated a hex value follows.
In the same vain, (Intel world) how to you designate decimal and binary?
[noparse][[/noparse]Non-text portions of this message have been removed]
dwayner@p... writes:
> Hex number system is 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f
>
> 0xAA is binary 10101010
> Note the alternating 10 pattern.
>
> Another useful pattern is 0x55 - binary 01010101
>
> Don't be afraid to ask even basic questions. There are *no* stupid
> questions.
>
> dwayne
Not afraid to ask questions. I COMPLETELY understand hex, binary, decima, and
how to convert. The 0x designator is what I did not know, Thanks.
[noparse][[/noparse]Non-text portions of this message have been removed]