Shop OBEX P1 Docs P2 Docs Learn Events
Need Help: Interfacing PC serial to Propeller — Parallax Forums

Need Help: Interfacing PC serial to Propeller

lynchajlynchaj Posts: 87
edited 2008-12-18 02:12 in Propeller 1
Hi! Thanks for making the Propeller!

I am making a project using the Propeller and run into a problem. I have searched the forum and website but cannot find a solution.

I am building a prototype board using the DIP 40 Propeller with 5 MHz crystal. I am using the Serial interface mentioned here to program the Propeller:

http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/SerialtoPropeller.pdf

The design is similar to the Propeller Demo Board except only the LED w/resistors, the VGA interface, and the PS/2 Keyboard interfaces are implemented. The Propeller prototype board implements the Serial interface rather than the USB interface. It also has a serial EEPROM 24LC256 chip.

The good news is that the Propeller 1.2 software recognizes the Propeller chip and can program it. Simple programs like the LED Blinker programs run fine. I have modified some programs from the forum to make a crude VGA and Keyboard "VGA_Terminal" program that prints keyboard input on the VGA display. That works fine too.

The bad news is that when I tried to get the PC to communicate with the Propeller over the serial line using HyperTerm I cannot get it to work. I tried this example program I found on the forum:

It appears to be a standard serial test program to repeat endlessly the same character to debug the serial port.


CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000


OBJ

console : "FullDuplexSerial"

VAR

PUB main
console.start(31, 30, 0, 9600)
repeat
   console.tx("p")





One thing I think may be a clue: when I program the Propeller with the above program into EEPROM, when I power cycle the Propeller, it comes up running the program. I know this because I can see the serial stream flowing out of the Propeller pin P30 using my oscilloscope.

When I monitor the Propeller when the Propeller 1.2 software is running I noticed DTR (PC serial pin 4) is LOW. However, when ever I reboot the Propeller and try to run HyperTerm on the PC, DTR is HIGH. No data is making it out to the PC serial port pin 2 (RX).

I *believe* this is because the DTR pin 4 is LOW while the Propeller 1.2 software is running (I confirmed this with the oscilloscope) but HIGH while HyperTerm or any other terminal program is running.

I tried these experiments on my test workbench PC (WinXP 766MHz PC) and an old PC laptop running Win95 with the same results.

What am I doing wrong? Is the serial interface circuit above specific to only programming the Propeller? If so, is there a serial interface circuit which is more general in nature I could use to interface to the PC?

Do I have a software setting wrong in the Propeller or HyperTerm?

Thanks and have a nice day!

Andrew Lynch

Comments

  • lynchajlynchaj Posts: 87
    edited 2008-12-10 01:58
    Hi! Sorry for the reply to my own message but after further searching in the forum on the term "DTR" revealed more clues to the situation.

    I downloaded Parallax Serial Terminal (PST) and now I can see the output of the Propeller streaming into the PC as you would expect. It seems the DTR pin is used for /RES on the Propeller which makes sense. I can reset the Propeller using PST by toggling the DTR option.

    However, this is a major problem for my intended design. What I am trying to make is a "Terminal Replacement Board" which is basically a simple ASCII terminal using scrap a VGA monitor, PS/2 Keyboard and "standard" RS-232 for communication with the N8VEM SBC. The N8VEM SBC which a home brew computer based on Z80 running CP/M. My plan is to integrate the Propeller with a 16C550 UART on an ECB board.

    Obviously, the "standard" RS-232 doesn't use DTR for /RES on Propeller. The implementation on the N8VEM SBC uses RX, TX, DTR, DTS, and signal ground.

    What can I do to modify my serial interface circuit to the Propeller so it is compatible with the PC and regular terminal programs like HyperTerm?

    Would a SPST switch inline with the DTR pin do it? (on for DTR /RES capability, off for regular PC compatible three wire serial)?

    Thanks!

    Andrew Lynch

    PS, more information on the N8VEM home brew Z80 CP/M project at http://groups.google.com/group/n8vem
  • grasshoppergrasshopper Posts: 438
    edited 2008-12-10 02:52
    I never needed to use the DTR / RES etc. Just send the data at a constant time or some other type of loop with the propeller.

    On the computer side you might need to program a small interfacing application. If you need help PM me and I can program you up a little application that runs on windwos.
  • StefanL38StefanL38 Posts: 2,292
    edited 2008-12-10 07:35
    Helo Andrew,

    Parallax made the PST.EXE that way that it is NOT toggling the DTR-line when opening the COM-Port.
    This toggling starts a reset of the propeller.

    ALL other PC-Terminal-softwares toggle the DTR-line when opening the COM-Port.

    One solution is to have a switch that disconnects the DTR-line. After programming switch it of
    and open the comport AFTER switching of and then it should work

    You could even automize this:

    If you use one propeller-IO-Pin to drive the base of a transistor and your propellercode controls this IO-PIN
    after the starting of the your propellerprogramm it will be switched of

    When opening the COM-Port with hyperterminal or whatever (except PST.EXE) the DTR-toggling is starting a reset
    and in the bootprocess of the propellerchip the content of the EEPROM is loaded into RAM

    And if you never stored your actual code in the EEPROM it gets overwritten by the content that is inside the EEPROM

    best regards

    Stefan
  • AribaAriba Posts: 2,690
    edited 2008-12-10 18:13
    Hello lynchaj

    You can simply connect the resistor from RX to Ground instead of DTR. This works for most RS232 Receivers on the PC side.
    Attached is a picture which I have posted before (so a search in the forum should bring some threads about this problem).

    Andy
    488 x 328 - 5K
  • lynchajlynchaj Posts: 87
    edited 2008-12-11 00:35
    Hi!· Thanks to all who replied!· I much appreciate your help!

    After more review of the Parallax circuit and Andy's alternate circuit, I think I·better grasp the situation.· The Propeller seems to require a non-standard serial interface due to its need for control of the /RES line associated with programming·*and* for a RS-232 HIGH voltage reference, I believe.· Please correct me if I am saying something wrong.

    Normally DTR is not used on most serial PC interfaces as they use RTS/CTS for hardware handshaking and DTR is available for other uses.· However, in this case is the host DTR pin also serves as a voltage reference for the Propeller's serial HIGH signal (-3v to -12v)·for its serial interface.· That is is the "normal" range for RS-232 serial HIGH state.· For the Propeller's serial interface to work with "normal" serial voltage values DTR has to be asserted HIGH.

    It appears the alternative serial interface is using the Propeller's 3.3v for LOW and GND for HIGH. Those are non-standard and probably would work with many serial interfaces but it surely is not a general RS-232 solution.· The intended host I am developing for is the N8VEM SBC which uses a 16C550 UART.· Possibly it might work with the non-standard LOW and HIGH values but since the actual hardware varies between builders there is no way to say for certain what UART hardware would be present or if it would be compatible.

    Based on the above, I am now thinking the best solution is to just accept·the fact the Propeller requires a non-standard serial interface and pick the easiest implementation to adapt to it.· Since the DTR pin output on the 16C550 UART is controlled by registers (MCR bit 0) probably the most direct route is to just code it into a special N8VEM serial driver just for the Propeller based peripheral.· I believe this is·similar to the approach·Parallax does by releasing their PST program -- it allows direct control of the DTR line by the user.

    The alternative to the software fix would be to make a rather substantial change to the serial interface circuit to put in a level shifter circuit like the MAX232 but for 3.3v compatible circuits.· However·a hardware change approach is the circuit still needs to deal with the DTR to /RES connection in some manner so even a level shifter doesn't completely resolve the issue.

    Where I went wrong is assuming that the Parallax serial interface circuit was a general RS-232 interface not a proprietary serial implementation.· This makes me glad I am making the hardware prototype *before* ordering manufactured PCBs!· It is good to discover these things while it is still in the design & prototype phase before I order·a batch of PCBs!

    Thanks for all your help!· Have a nice day!

    Andrew Lynch
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2008-12-17 11:28
    I am working on this project as well but I'm a few days behind Andrew Lynch. Propeller chip arrived this afternoon. 1/2 hour on the protoboard with the RS232 download circuit using transistors and it can flash a led. I like this chip!

    The project is an RS232 dumb terminal like the ones made in their millions in the '80s. CRT VGA monitors are giveaways. Keyboards are $3.90. And the propeller chip seems to have all the parts with VGA drivers, keyboard drivers and serial port drivers all sitting in the code section. Has anyone pulled it all together?

    I'd like to throw a slightly different design specification into the mix. I want to leave the download circuit exactly as it is, and put the serial port on P0 and P1 with a max3232 to talk to another board. There is code in the download section for serial comms up to 19200 which is plenty fast enough.

    A dumb terminal keyboard is very simple. You push a key on the keyboard and it scans the code, converts it into an ascii character and sends it out on pin 3 of a male D9. I think that is a combination of the keyboard program and the serial program.

    The display part is a bit more complex. It listens to pin 2 of a male D9 and when a byte arrives, it stores it in memory and moves the cursor over by one. When the cursor gets to the end of the line, it scrolls the line up by one. Or if a <CR><LF> arrives. I think that is a combination of the simple_serial code, the vga driver code, and then also the routines to scroll.

    I have written this code for a 20x4 LCD display in Z80 machine code and understand the programming concepts. It ought to be possible to convert to spin. I think (hope) there is enough memory. 40 columns ought to be enough. 80x25 would be awesome.

    Down the track, it would be great to code the ANSI/VT100 escape sequences that move the cursor around etc.

    Many microcontroller projects need a display. Given the cost of the larger LCD text displays (eg 20x4 and up) vs the cost of a Propeller and freebie CRT VGAs, I think the latter could actually be cheaper.

    Has anyone built such a project? Help and advice would be most appreciated!

    James Moxham
  • Beau SchwabeBeau Schwabe Posts: 6,566
    edited 2008-12-17 15:47
    lynchaj,

    As it has been indicated, the DTR line is used to signal the Propeller to reset and accept data from the PC. The fact that you can communicate and identify the Propeller means that you have everything connected properly. I designed the RS232 version for the Propeller after, on a business trip, I forgot to bring my USB connector with me. The design was derived from a tried and true circuit that we have been using for many years with the BS2. Ariba's solution will work in most circumstances, alternatively instead of connecting to ground through the 4.7K resistor you can connect to the RTS (Pin #7) and assign this pin a HIGH (-12V) which will provide a negative voltage in cases where 0V may not be enough. The reason I didn't use the RTS was because I wanted to maintain a 4-conductor connection (<- standard telephone cable works well for this) between the PC and the Propeller. Using the RTS would have introduced a 5th wire unless you move the circuit directly at the serial connector on the PC side.



    Only 3 of the 9 pins have a fixed assignment: transmit, receive and signal ground. This is fixed by the hardware and you can't change it. But the other signal lines are controlled by software and may do (and mean) almost anything at all. RS232 standards are defined by EIA/TIA (Electronic Industries Alliance /Telecommunications Industry Association). RS232 defines both the physical and electrical characteristics of the interface. RS232 is practically identical to ITU V.24 (signal description and names) and V.28 (electrical). RS232 is an Active LOW voltage driven interface and operates at +12V to -12V where:

    * Signal = 0 (LOW) > +3.0V
    * Signal = 1 (HIGH) < -3.0V


    Reference:
    www.aggsoft.com/rs232-pinout-cable/pinout-and-signal.htm

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.

    Post Edited (Beau Schwabe (Parallax)) : 12/17/2008 3:55:34 PM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2008-12-17 16:05
    Andrew,
    Just to clarify ... The 2-transistor RS232 interface circuit was never presented as obeying the RS232 standard. It provides a simple, cheap interface that is compatible with a standard RS232 serial port and RS232 voltage levels. To get proper RS232 voltage levels, you have to use something like a MAX3232. The use of DTR to force a reset is a perfectly legitimate use of DTR.

    James,
    As you said, all the pieces are there. People have used them already for various display terminals. Andrew recently posted a VGA terminal program (http://forums.parallax.com/showthread.php?p=598350) using the I/O routines in the Propeller OS.
  • OwenSOwenS Posts: 173
    edited 2008-12-17 16:42
    From what I gather, your implementing this on a board with a 16C550 UART, correct?

    If that is the case, why do you need the complexity of RS-232 level translation? A resistor on the Propeller inputs will provdie adequite protection against the 16C550's 5V outputs. I'd recomend using a seperate set of pins to connect to the UART as you use to program it.

    If the resistor method is not fast enough, then 74LVC gates are cheap.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2008-12-17 23:23
    Thanks for the prompt replies!

    Andrew will probably post some answers soon too.

    1) Re the 16C550 uart, yes this could easily be done directly. This project is being built in stages and while this means it is less "efficient", it is easier to build a board that has standard RS232 signal levels and then build a second board also with RS232 signal levels. This means two level translators are needed and these might be considered a wasted resource. It is not until recently that I personally appreciated what RS232 does - and it does two things that are very useful. The first is that it is very hard to zap an input with the sorts of voltages you might have on a board. You can feed +12V in and not damage anything. Or you can completely muddle the pins up including the earth pin and feed in -12V even when you only had +12V on a board and still not zap anything. The second thing is that you can feed volts into a board when the board is not powered up. Another reason RS232 is useful is that any terminal board can be used on other equipment, and on a serial port of another PC for testing purposes. Down the track, if the propeller works, it may well end up directly connected to the uart. Heck, it even might end up replacing the uart...

    2) The transistor circuit seems to work fine, and it is great that it is included in the "getting started" documentation, especially for people like myself who don't have a max3232 on hand but do have lots of transistors and resistors etc. It seems to comply with RS232 standard (just) as the RS232 is +/-3V and the prop will be +/-3.3V. Anyway, it works fine.

    3) My impression is that trying to do comms and downloads via one circuit may add a level of complexity that gets too confusing especially with the DTR, and it is easier to add another dedicated comms port. I've tried doing download and comms on other circuits in the past and one is constantly swapping back and forth in software on the PC as only one program can own the comms port. I got another old PC and use that for comms debugging. Is it overkill to have two PCs on one's workbench?!

    4) Thanks for the link to the other thread - that is Andrews partially completed terminal program. There is a lot more to go though before this is working - storing characters in an array and moving up lines and redrawing the screen and escape sequences etc. If this hasn't been done yet, then we will write it up and publish it!
  • soshimososhimo Posts: 215
    edited 2008-12-17 23:39
    I'm a noob to the propeller chip so forgive my ignorance, but can't you just disable hardware handshaking at the terminal end? DTR/DSR and RTS/CTS are used during hardware handshaking I've not had any issues communicating to other USART devices (specifically PIC, bit-banged and hardware) that do not use hardware handshaking at all. As long as you are not going full-duplex it shouldn't be a problem. All you need is Tx, Rx, and Gnd for basic RS232 communication. I could be way off here though as I just started on the propeller myself.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2008-12-17 23:46
    I agree with soshimo - and to me RS232 = 3 wires - ground, Tx and Rx. It just makes things a whole lot simpler. There are always software ways of handling data as it comes in, eg the xmodem protocol where you know exactly how many bytes should be coming through. PC terminal programs give you the option of xon/xoff or hardware or none. Just choose none. A null modem cable can loop back the other wires if a particular device is fussy about it. But I still like to use the max232 or max3232 level converters - for a start you get longer range at these voltage levels and that is an issue once the baud rate goes up.
  • lynchajlynchaj Posts: 87
    edited 2008-12-18 01:57
    Hi!· Thanks everyone for all the great help!· With some more experimenting and the information from here, I think I better understand the Propeller programming interface is quite different than an general purpose serial interface.· As a result, I have changed my approach on the terminal board and now believe the dual interface approach makes more sense.·

    I'll leave the programming interface as is and use two of the Propeller's unassigned pins with a level shifter, probably a MAX3232, to implement three wire serial for the communications interface.· This appears to be a cleaner approach as the programming interface is specialized but the communications channel can be the usual RS-232 compatible three wire serial interface.· I have a couple MAX3232's on order and will implement the interface when they arrive and post results here.

    Thank you all very much for your help!· Parallax is doing great things with the Propeller and I think it is great.· I enjoy working with it very much!· I appreciate your help in getting me to better understand its principles.·

    Andrew Lynch

    PS, as James has noted elsewhere, there appears to be great synergy between the Z80 home brew computers with the Propeller.· The Propeller's reprogrammable nature and powerful built in IO capabilities offer much for home brew computing hobbyists.
  • soshimososhimo Posts: 215
    edited 2008-12-18 02:12
    I agree about the homebrew feeling lynch and at 160MIPS it's about twice as the Z80, not much of a leap considering todays's microprocessor standards which are getting closer and closer to 100k MIPS (Intel Core i7 runs at 76k MIPS!). Also, good luck with your level shifter - I have a whole tube of those guys laying around with about 4 different break out boards, one can never have enough RS232 wink.gif. Just stay away from the DS175, as Dr Acula noted, they don't provide true RS232 levels and at higher baud rates and/or longer cords you will run into trouble (though the lower part count is tempting, just buy a bunch of caps from mouser or digikey and be done with it). Also, in case you didn't know, the cap values in the data sheet are minimum values, you can really use any cap values above the rating as they are just working as a charge pump.
Sign In or Register to comment.