Shop OBEX P1 Docs P2 Docs Learn Events
PPDB + PocketPC serial terminal? — Parallax Forums

PPDB + PocketPC serial terminal?

CrosswindsCrosswinds Posts: 182
edited 2011-09-13 08:56 in Propeller 1
Hello guys!


Trying to get a simple terminal setup between the PPDB RS3232 and an old iPaq pocket pc.

Have installed pocketPUTTY terminal program. And setup to the right speed and everything. Using a sample code for the parallax serial terminal. i dont get any sign of life at all on the pocket-pc side!

The code:

CON

_CLKMODE = XTAL1 + pll16x

_xinfreq = 5_000_000

OBJ

PPC : "FullDuplexSerial"

Pub Main

PPC.start(16,17, 3, 115200)

repeat

PPC.str(string("testare", 13))
waitcnt (clkfreq + cnt)



Iam using a gender changer between the PPC dock-cable and the board. But dont think that is the problem.

Any one got any experience with this?

Thanks!

(EDIT: I have tried every mode there is 0-3!)

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-10 10:25
    Without knowing more about the Pocket PC's dock cable, it's hard to tell what's going on. Some serial ports default to the use of CTS / RTS and DTR / DSR for the serial port to work. Check your Pocket PutTTY program's options for an option to disable this. Use mode 0 since the MAX3232 inverts the signals for you.

    Also, make sure you have pins 16 and 17 wired correctly. RX and TX are relative to the Pocket PC. RX is an output from the Propeller to the Pocket PC's receive line. TX is an input to the Propeller from the Pocket PC's transmit line. The first pin number (16) in PPC.start is for receiving from the Pocket PC. The second pin number (17) is for transmitting to the Pocket PC. Pin 16 should be connected to TX and pin 17 should be connected to RX.

    Ooops. I was reading the schematic and they've got RXs connected to TXs and TXs connected to RXs and I think I have it backwards. In any event, line #2 of connector X22 on the last page of the schematic should be connected to pin 17 (transmit to PPC) and line #4 of connector X22 should be connected to pin 16 (receive from PPC).
  • CrosswindsCrosswinds Posts: 182
    edited 2011-09-10 15:41
    Hi Mike and thanks for your reply!

    Actually i have done all of that. Still no go!

    Will try to yank out an old pc with a native serial port and try communicating that way with the ppc.

    Getting a bit tired of trying to get this to work now!:)
  • localrogerlocalroger Posts: 3,452
    edited 2011-09-11 13:14
    This is one of the big things I do a lot. There are a lot of little things that can go wrong with serial comms and flailing about in the dark can be very unproductive.

    First thing to do is disconnect the Prop from the PPC and short TX to RX on the PPC cable. With this done anything you type on the PPC terminal should appear on the screen as received; if you unshort TX and RX this should stop. (This is called a "loopback" test.) If this fails you are full stop on troubleshooting the prop -- the problem (or at least a problem) is in your PPC or cable.

    As Mike suggests, you may need to add some jumpers. The BIOS was famous for locking if you tried to direct output to a serial port without handshaking, but most terminal programs either defaulted or allowed you to ignore those lines. Again, the loopback test will not work if handshake signals are not satisfied.

    Once you get loopback, use a voltmeter to determine which pin is TX from the PPC. Trust me, you have about an 80% chance of reversing TX and RX on a serial cable. Properly implemented RS232 always has voltage on the TX pin, either +V or -V where V=3 to 15V. If it's TTL you might need to hold a key down on the terminal to make it transmit to see voltage. If you get voltage on the same pin from both directions, you are hooking TX to TX and that doesn't work very well.

    Finally, most apps will give you not silence but garbage data if you have something like the signal inverted, wrong baud rate, or wrong parity. If you're not getting ANYTHING don't bother with those settings; your first imperative is to prove the port is working with a successful loopback test. Once you have loopback and make sure TX and RX are properly crossed you should get SOMETHING, then you can mess with the settings until it looks right.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-11 15:14
    Another thing you can do is attach a small LED and resistor across the Rx and Tx lines to make sure you've got the polarities and signal lines right.
  • CrosswindsCrosswinds Posts: 182
    edited 2011-09-12 07:35
    localroger wrote: »
    This is one of the big things I do a lot. There are a lot of little things that can go wrong with serial comms and flailing about in the dark can be very unproductive.

    First thing to do is disconnect the Prop from the PPC and short TX to RX on the PPC cable. With this done anything you type on the PPC terminal should appear on the screen as received; if you unshort TX and RX this should stop. (This is called a "loopback" test.) If this fails you are full stop on troubleshooting the prop -- the problem (or at least a problem) is in your PPC or cable.

    As Mike suggests, you may need to add some jumpers. The BIOS was famous for locking if you tried to direct output to a serial port without handshaking, but most terminal programs either defaulted or allowed you to ignore those lines. Again, the loopback test will not work if handshake signals are not satisfied.

    Once you get loopback, use a voltmeter to determine which pin is TX from the PPC. Trust me, you have about an 80% chance of reversing TX and RX on a serial cable. Properly implemented RS232 always has voltage on the TX pin, either +V or -V where V=3 to 15V. If it's TTL you might need to hold a key down on the terminal to make it transmit to see voltage. If you get voltage on the same pin from both directions, you are hooking TX to TX and that doesn't work very well.

    Finally, most apps will give you not silence but garbage data if you have something like the signal inverted, wrong baud rate, or wrong parity. If you're not getting ANYTHING don't bother with those settings; your first imperative is to prove the port is working with a successful loopback test. Once you have loopback and make sure TX and RX are properly crossed you should get SOMETHING, then you can mess with the settings until it looks right.

    Hello! Good to see that you have great experience in this!

    I remember when i last attempted this ( i did not use the PPDB) i managed to loop the TX and RX to give me an output. But trying to do this no dont give me anything. I think this is because i use a different terminal program on the ppc now.

    (I cannot for the life of me find the otherone) But this is called pocketputty and is a port of the original putty program. And i think this will need to use handshaking or at least RTS and that stuff. because i just have the ability to adjust speed, and flow control, stop bits and so on in putty.

    The other program actually marked if those pins where connected etc.

    If i were to wire this up correctly to meet exact what a RS232 needs, what would i need then?
  • localrogerlocalroger Posts: 3,452
    edited 2011-09-12 07:45
    If your ppc has a standard 9-pin PC style serial port you might need to jumper pins 1, 4, and 9 (CD, DSR, DTR) and separately jump pins 7 and 8 (RTS to CTS). If the serial connector is different you will have to find the pins those signals are on to jump them. Of course you will be jumping 2 to 3 (RX, TX) to make the loopback connection.
  • CrosswindsCrosswinds Posts: 182
    edited 2011-09-12 09:28
    localroger wrote: »
    If your ppc has a standard 9-pin PC style serial port you might need to jumper pins 1, 4, and 9 (CD, DSR, DTR) and separately jump pins 7 and 8 (RTS to CTS). If the serial connector is different you will have to find the pins those signals are on to jump them. Of course you will be jumping 2 to 3 (RX, TX) to make the loopback connection.

    Hello again!

    Have just now tried to connect it to a standard com port on a pc, with a native serial port.

    Works great with the terminal program,.,, So something is off with the wiring. Could it be the gender changer i have to use to get it hooked up? Dont really understand why they have a female connector on the PPDB?

    When i last experimented with this, i didnt use the max circuit. And hardwired everyting, that didnt work either. I could in some cases recieve Smile letters, but no matter how i tried different speeds, it still was the same thing.

    So, what is circuit different than a standard pc´s? :S
  • CrosswindsCrosswinds Posts: 182
    edited 2011-09-12 14:35
    I think i will try to skip the gender changer.

    Cross those wires you say, but use simple jumperwires from the PPDB db9 socket to the ppc db9 socket. That way i know nothing there can screw with it!
  • CrosswindsCrosswinds Posts: 182
    edited 2011-09-13 08:56
    Crosswinds wrote: »
    I think i will try to skip the gender changer.

    Cross those wires you say, but use simple jumperwires from the PPDB db9 socket to the ppc db9 socket. That way i know nothing there can screw with it!

    Woho! got it to work!!


    But encountered a new problem! ;)

    Tried the the example code for the parallax serial terminal, with sending and recieving.
    And when the code wants to get for example a dec number, the ppc, gets crazy and spews out Smile!

    Should this be in some other way when not communicating with the parallax serial terminal?

    The code is:

    value := debug.getDec

    and the obj used is the fullduplexserialplus!



    Edit:

    i changed the mode to 3, the sending still work, and when it get to getDec, it down break down, but still no luck in recieving, it probably waits for something :S

    edit again: got that too work too, needed to slow down the speed! Not it all works great.
Sign In or Register to comment.