Shop OBEX P1 Docs P2 Docs Learn Events
I need some help understanding how to perform an echo test with RS-232 and a Prop — Parallax Forums

I need some help understanding how to perform an echo test with RS-232 and a Prop

ElectricAyeElectricAye Posts: 4,561
edited 2011-07-30 16:42 in Propeller 1
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:
   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

  • Kevin WoodKevin Wood Posts: 1,266
    edited 2011-07-29 15:19
    That statement assigns the value of com.receivedByte to temporary, then evaluates it in the context of the if statement. So if there is a valid assignment made, the if statement should evaluate as "true", otherwise it will evaluate as "false".

    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. :)
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 16:25
    Kevin Wood wrote: »
    That statement assigns the value of com.receivedByte to temporary, then evaluates it in the context of the if statement. So if there is a valid assignment made, the if statement should evaluate as "true", otherwise it will evaluate as "false"....

    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.
  • ratronicratronic Posts: 1,451
    edited 2011-07-29 16:54
    ElectricAye - I'm not sure this what your looking for but here is a simple demo that outputs a 2 digit hex # of what's received in fds on the tv while at the same time outputting a string via fds.
    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)
    
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 17:59
    ratronic wrote: »
    ... Maybe this can get you started....
    ...

    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
  • ratronicratronic Posts: 1,451
    edited 2011-07-29 18:09
    If you look at the start method of FDS it will show the modes. IRRC thats the mode I used with the max3232 on the PPDB.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 19:03
    ratronic wrote: »
    ...IRRC thats the mode I used with the max3232 on the PPDB.

    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!
  • ratronicratronic Posts: 1,451
    edited 2011-07-29 19:22
    ElectricAye, I just tried communicating thru the max3232 on the PPDB to the Parallax serial terminal and I had to use mode%0001 to invert the serial receive for proper communication.
    I.E. com.start(rcv, trm, %0001, 2400)
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 19:39
    ratronic wrote: »
    ... I had to use mode%0001 to invert the serial receive for proper communication.
    I.E. com.start(rcv, trm, %0001, 2400)

    Okay, I'll be sure to make that change. Wow, thanks for checking that out!
  • ratronicratronic Posts: 1,451
    edited 2011-07-29 19:54
    Just to let you know I have tried inverting the transmit and receive, you will probably need to experiment with the different modes.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 19:57
    ratronic wrote: »
    Just to let you know I have tried inverting the transmit and receive, you will probably need to experiment with the different modes.

    Okay, will do.

    ratronic wrote: »
    ElectricAye, I just tried communicating thru the max3232 on the PPDB to the Parallax serial terminal...

    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!
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 21:51
    Well (insert sounds of weeping here), I've tinkered with the various modes and even tried switching Rx and Tx around but so far I can't get anything on the screen except 0's.
    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)
    
  • kuronekokuroneko Posts: 3,623
    edited 2011-07-29 21:57
    Well, the various string sending and receiving methods are not exactly symmetric (terminator isn't sent, string receive requires CR IIRC). But if a simple byte/char echo helps you (setup omitted):
    repeat
        com.tx(com.rx)
    
    It's sole purpose is to send back what it just received.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 22:03
    kuroneko wrote: »
    Well, the various string sending and receiving methods are not exactly symmetric (terminator isn't sent, string receive requires CR IIRC). But if a simple byte/char echo helps you (setup omitted):
    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! :-)
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-29 23:11
    ...I've tinkered with the various modes and even tried switching Rx and Tx around but so far I can't get anything on the screen except 0's. ....

    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!
  • StefanL38StefanL38 Posts: 2,292
    edited 2011-07-30 00:59
    Hi ElectricEye,

    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
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-30 09:20
    StefanL38 wrote: »
    ...
    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...

    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
  • KyeKye Posts: 2,200
    edited 2011-07-30 09:49
    Hey all - I've posted the updated version of the object in the OBEX now. It fixes the bugs in the previous version. The interface has changed however to be more like my file system driver. Thanks,

    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.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-07-30 16:42
    Kye wrote: »
    Hey all - I've posted the updated version of the object in the OBEX now. It fixes the bugs in the previous version.....

    Kye,

    hey, that's great news! Thanks for taking the trouble to fix it. I owe you a Kit Kat bar. :-)
Sign In or Register to comment.