I need some help understanding how to perform an echo test with RS-232 and a Prop
I'm trying to set up a Propeller to perform an RS-232 echo test through a Max3232 chip (which is the same kind of chip used on the Propeller Professional Dev Board for RS232 communications), but I'm confused about a few things.
First, I'm hoping to use Kye's "RS232 Communications Engine" and have been looking at his "RS232 COMEngine Demo", both of which can be found here:
http://obex.parallax.com/objects/397/
Kye's demo appears to be performing an echo by transmitting a string but I'm confused on how Kye's demo actually confirms that an echo has occurred. I don't see any place where it displays the echo. Or is it supposed to? What am I missing here?
Also, I don't understand what the following bit of code is doing, especially how the IF statement works:
I'm mostly puzzled by what this part does:
How is that part of an AND statement?
Oh, heck, I might as well confess: I don't really know how this RS-232 stuff works at all. I just want my Prop to send out a string to the Max3232 chip, then have the chip bounce it back and have the same Prop read the string to confirm I've got things working up to that point, at least. Eventually, I will have this Prop talking to a device that is operating at only 2400 baud, so I don't think speed is an issue.
Can somebody please explain to me how this code might work for an echo test?
thanks!
First, I'm hoping to use Kye's "RS232 Communications Engine" and have been looking at his "RS232 COMEngine Demo", both of which can be found here:
http://obex.parallax.com/objects/397/
Kye's demo appears to be performing an echo by transmitting a string but I'm confused on how Kye's demo actually confirms that an echo has occurred. I don't see any place where it displays the echo. Or is it supposed to? What am I missing here?
Also, I don't understand what the following bit of code is doing, especially how the IF statement works:
repeat
if((temporary := com.receivedByte) and (index < constant(4_096 * 4)))
array.byte[index++] := temporary
while((temporary <> com#carriage_return) and (temporary <> com#line_feed) and (temporary <> com#null))
com.transmitString(@array)
I'm mostly puzzled by what this part does:
(temporary := com.receivedByte)
How is that part of an AND statement?
Oh, heck, I might as well confess: I don't really know how this RS-232 stuff works at all. I just want my Prop to send out a string to the Max3232 chip, then have the chip bounce it back and have the same Prop read the string to confirm I've got things working up to that point, at least. Eventually, I will have this Prop talking to a device that is operating at only 2400 baud, so I don't think speed is an issue.
Can somebody please explain to me how this code might work for an echo test?
thanks!
Comments
It's a bit like saying if(true) or if(false), where the true and false state are determined by the success or failure of the variable assignment being evaluated.
You can look at that line of code as...
if ( (this is true) AND this (is also true) ) then do this here thing...
The next line can be read...
while ( (this is true) AND (this is true) AND (this is true) ) then keep doing this here thing...
I'm not sure if the repeat..while construct creates an embedded loop. My Spin skillz are w34k.
Kevin,
thanks very much for explaining this part of it to me. It makes sense now. Unfortunately I was just told that Kye's "RS232 Communications Engine" has some bugs in it so it looks like I'll have to figure out how to use the Full Duplex Serial object, I suppose. Bummer.
If what ever is attached to the trm and rcv pins is echoing back it will show on the tv. Maybe this can get you started.
Con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rcv = 3 trm = 4 Var Obj com : "fullduplexserial" tv : "tv_text" Pub main | a com.start(rcv, trm, 0, 2400) tv.start(12) repeat com.str(string("Test ")) tv.hex(com.rx,2)
Dave,
thanks very much. This is the kind of thing I need right now, just something simple to get the hang of things. Any idea about how to decide which mode to use? I see in your code that you selected 0, but would you happen to know if that's the right mode for working with a Max3232 chip? Maybe I'll get around to testing this tonight.
cheers!
Mark
Cool. That gives me some reassurance I won't blow up my chip on the first try. I'm always a little afraid of wiring things up until I've got a nod or two from the 'hood here.
thanks again!
I.E. com.start(rcv, trm, %0001, 2400)
Okay, I'll be sure to make that change. Wow, thanks for checking that out!
Okay, will do.
One quick question: did you only have to jump the Max3232 pin 8 (R2in) to the Max3232 pin 14 (T1out) directly or was it necessary to add any other components? For example, the data sheet shows a 1000pF cap connected from the jumper to ground but I'm guessing that won't be needed for such a low baud rate. True?
http://datasheets.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf
Thanks so much!
Is there any way to have it send a string and then echo back a string? Or send a normal number and echo back that same number? I'm not sure why the code is set up to receive a hex after it sends a string.
Con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rcv = 3 trm = 4 Var Obj com : "fullduplexserial" tv : "tv_text" Pub main | a com.start(rcv, trm, 0, 2400) tv.start(12) repeat com.str(string("Test ")) tv.hex(com.rx,2)
repeat com.tx(com.rx)
It's sole purpose is to send back what it just received.kuroneko,
Okay, I'll give it a try. It certainly looks simple enough, almost looks like one of those philosophical riddles, like Everything I say is a lie.
thanks for the late night help! My side of the world has already fallen asleep on me! :-)
Maybe I should have double checked that the Max3232 chip actually had power going to it. Duh-uh!
It seems to be working now. They will let me out of the cave of shadows now that I've got an echo going.
Thanks everyone!
I want to describe how I'm testing new things.
The basic rules are:
keep everything constant except for one thing.
use things that are well known as working
So in case of serial communiation this is:
taking an existing piece of code that is well known as working
I don't know why you were so keen on using Kye's serial enginge. To be not misunderstood. Kye has done a lot of good work and his comenginge evolved to version 1.6
So I guess it is good working.
But for other serial objects like FullDuplexSerial, FullDuplexSerialPlus there are a lot of working demos.
So first step is to take one of those demos and re-check personally if they work when using them with the USB-to-serial-converter.
Yes. I mean the cable between propeller-board and PC you are using to download programs to the EEPROM or to RAM.
If this works you know the code works.
Then change the IO-Pins to any free IO-pins except PIN 28,29 (used by the EEPROM)
connecting them directly to have a direct loop-back.
Testing it with a code-variant that lights up an LED if the received character is the same as the sended.
or sending debut-out through the (second) serial connection on PINs 30,31 (standard debug-output)
If this is working taking the MAX3232 keep it disconnected from the prop and the RS232-device, applying supply-voltage and then
- applying alternating 0.0V/3.3V to the TTL Tx-pin measuring the output-voltage on the other side which has to change acordingly -12V and +12V (V24-side)
- applying alternating -12V/+12V to the V24-side measuring the out-voltage on the TTL-side which has to change acordingly between 0.0V and 3.3V
maybe even including a current-measuring at each PIN to make sure there are no shortcuts or half-short-cuts.
after that you are knowing the MX3232 is working properly
then including the MAX3232 into the loop back.
Which means connecting the TTL-side of the Max3232 with the propeller-IO-pins and connecting the Tx/Rx-pins on the V24-side with each other for a "hardwired" echo.
After all these tests you know test-code, MAX3232 are working properly. Then connecting the real RS232-device to test the whole thing.
This may take 2 or 3 hours if some problems like forgot to connect power, connected Rx/Tx the wrong way or something simialr and but then you are done.
And the most important thing: if something does not work the possabilities that are causing the bug are reduced to one or two things, because you know all
other things are working.
keep the questions coming
best regards
Stefan
Hi Stefan,
for the most part what you are saying is a good way to approach something new and, more or less, that is what I have been doing. In the case above, I just fell victim to a bad solder joint that was causing intermittent failures of the power supply - and we all know that intermittent failures are one of the worst problems to track down no matter how meticulous you are.
thanks for the encouragement,
Mark
Sorry for not updating the object in a while. I wanted to hold off however until I'd had some time to test it more extensively. You'll find the demo puts the driver though its paces and it still works. I've also used the new version for about a month now and have not had problems.
Kye,
hey, that's great news! Thanks for taking the trouble to fix it. I owe you a Kit Kat bar. :-)