Shop OBEX P1 Docs P2 Docs Learn Events
Commiunicating [PC to Propeller] then [PC to Microcontroller to Propeller] — Parallax Forums

Commiunicating [PC to Propeller] then [PC to Microcontroller to Propeller]

stevetronikstevetronik Posts: 15
edited 2010-01-22 05:57 in Propeller 1
What i have here is a propeller demo board. the propeller demoboard is connected to control a robot thru P2.

What i have managed to is to control the robot from the PS/2 keyboard and mouse driver that are connected to the propdemoboard, with displays information on the VGA text.

I want to attempt in doing a control interface on the PC (likely using hyper terminal or written C programs, suggestion for others are welcome) to achieve something like a control and monitoring interface on the PC to the propeller to the robot.

Equipments that i have are, Propeller Demo Board, USB to Serial Com (comes with prop), USB to RS232

What pins can i use, and what drivers are available to be use.

Thanks in advance
Steve,

Comments

  • StefanL38StefanL38 Posts: 2,292
    edited 2010-01-16 10:51
    Easiest way is to use the USB-connector with wich you download code into the propeller.

    When the downloading of the code has finished you can open the virtual comport - that is provided through the USB-connection to the demoboard -
    by any PC-software that is able to talk to a comport. And then you simply send and receive bytes from/to the propeller.

    here is a small example-code

      'Debug.Str(string(""))
      'Debug.Str(string("",13))
      'Debug.Dec()
      'Debug.Rx()
      'Debug.Tx()
    
    'it's very important for serial communication
    'that the constants "_clkmode" and "_xinfreq"
    'are set up properly
    'serial datatransfer needs a precise timing
    'with wrong timing settings you will only send and receive garbage
    'if you don't set the constants at all
    'you can download programs but the propeller will run in
    'RCSLOW-mode or RCFAST-mode wich is too unprecise for serial
    'communication
    CON
      _clkmode      = xtal1 + pll16x ' use crystal x 16
      _xinfreq      = 5_000_000
    
      'defining constants makes code selfexplaining
      'see line with Debug.Start(.... 
      DebugTx_Pin = 30
      DebugRx_Pin = 31
      Baudrate    = 115200
      FDX_Mode    = 0  
      
    VAR
      long MyVar
      
    OBJ
      Debug   : "FullDuplexSerialPlus"    'short name FDX+
    '               
    '   │            └thise is the filename WITHOUT extension ".spin"
    '   │
    '   └this is the objectname
    
    'to use the functionality of FDX+ you have to code a line like the above
    'then you can use the subroutines inside the file FullDuplexSerialPlus.spin
    'with this syntax OBJECTNAME.METHODNAME
    'example: Debug.tx("A") where "debug" is the objectname
    'and "tx" is the name of a "PUB"-method INSIDE the file "FullDuplexSerialPlus.spin" 
    'in SPIN the word method is used in the sense of sub-routine  
    
    PUB Main 'any program starts with the first PUB-method found inside the *.spin-file
      StartSerialDebugging
    
      MyVar := 0
      repeat
        Debug.Dec(MyVar)
        Debug.tx("A")
        Debug.Str(string(" Hello World",13))
        MyVar := MyVar + 1
        Debug.tx(13)
        
        WaitCnt(ClkFreq + cnt)   'wait for ONE second 
    
    
    Pub StartSerialDebugging
      Debug.Start(DebugRx_Pin,DebugTx_Pin,FDX_Mode,Baudrate)
    
      Debug.Str(string("FullDuplexSerialPlus-Driver started with ",13))
      Debug.Str(string("Start(DebugRx_Pin="))
      Debug.Dec(DebugRx_Pin)
      Debug.Str(string(",DebugTx_Pin="))
      Debug.Dec(DebugTx_Pin)
      Debug.Str(string(",FDX_Mode="))
      Debug.Dec(FDX_Mode)
      Debug.Str(string(",Baudrate="))
      Debug.Dec(Baudrate)
      Debug.Str(string(13,13))
    
    
  • SamMishalSamMishal Posts: 468
    edited 2010-01-16 17:32
    Steve,

    Have a look at this PDF ocument and·have a look at this posting in this forum.
    I think with both these links along with·Stephan's program you should have a GOOD head start.

    Good luck


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Samuel

    www.RobotBASIC.com


    Post Edited (SamMishal) : 1/16/2010 5:37:10 PM GMT
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2010-01-17 00:23
    I second the above posts. Further information would be to look at the SerialTerminal object - I believe that is the correct name. When you installed the Propeller Tool did you also install the Parallax Serial Terminal (PST)? The PST is similar to HyperTerminal, but think a bit easier to use.

    In doing a design like this I recommend first creating a list of what data is going to go from the PC to the Robot and then from the Robot to the PC. Think through commands like move forward, left, creep, fast, stop, reboot, etc. Also think through data like sensor feedback, position, object detection, etc. Does the robot just send data all the time or does it only send data when requested too by the PC? Once you have data/commands listed you can then create some protocol or packet format. Don't get discouraged by these words, they simple mean setting up and describing how the data is transfered so that the robot and the PC both understand the data. Start easy with a SerialTerminal/FullDuplexSerial objects. Get data to show up in a terminal application first. Once that works you can then upgrade to an application and program it in any language that can access the serial port such as VB.Net, C, Java, Realbasic, etc.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, E.I.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
    www.tdswieter.com
  • stevetronikstevetronik Posts: 15
    edited 2010-01-20 02:50
    Thanks for the recommendation, I manage to go thru the RobotBASIC and bunch of stuff, I guess i have no problem with the Propeller to PC communication using Debug.tx, But i cant seem to find any information on the other way round; PC to prop, with the use of debug.rx or other rx object functions in the FullDuplexSerialPlus.spin, could point me to any guides on thoes, because i'm attempting to use PC to 'talk' to the prop demo board. If that talking works. I'm going to use my microcontroller with serial com port output to let the microcontroller to 'talk' to the prop demo board.

    EDIT: I would like to mentioned that my Microcontroller's is using an UART port.

    Advice is greatly appreciated

    Steve,

    Post Edited (stevetronik) : 1/20/2010 3:01:13 AM GMT
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-01-20 03:01
    Somewhere in this forum you'll find a little demo I did with RobotBASIC that sends a message to the Propeller which will respond when the correct string is sent. Sadly, the forum search engine doesn't work very well so it might be tough to track down. I uninstalled RobotBASIC so I no longer have the source for that demo.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon McPhalen
    Hollywood, CA
  • ratronicratronic Posts: 1,451
    edited 2010-01-20 03:13
    stevetronik, here is a program I use that uses robotbasic to read the usb joystick on the pc· and send the info from that via rs232 to the·programming port on the prop. Maybe you can get some ideas from these. My demo board is set to com5 for this but you can change it to whatever you need.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ···································Fix it, if ain't broke!


    D Rat

    Dave Ratcliff N6YEE
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,720
    edited 2010-01-20 03:39
    This should help: Communicating RobotBASIC With The Propeller Chip

    www.robotbasic.org/resources/RobotBASIC_To_PropellerChip_Comms.pdf

    Sample Text:
    "The Propeller Chip (propeller) is a an advanced microcontroller that can be programmed using Assembly language or a fascinating and pleasure to use proprietary language called Spin. We shall develop programs to achieve serial communications between a PC running a RobotBASIC program and the propeller running a Spin program.
    The article will not attempt to explain the nuances of Spin. You are assumed to be familiar with Spin and the propeller. However, the article will explain options for connecting the propeller to a PC so as to be able to communicate with an RB program running on it.
    The developed programs will be of sufficient complexity to illustrate the communication most likely to be needed with projects that require communicating a PC and the propeller using RB and Spin.
    The Layout:
    Figure 1 is taken from page 5 in the Propeller Data Sheet and it shows the connection the Propeller Tool (programming IDE) assumes in order to program the propeller.
    Figure 1: Propeller Programming Setup (Propeller Data Sheet page 5)"
  • SamMishalSamMishal Posts: 468
    edited 2010-01-20 06:06
    JonnyMac said...
    Somewhere in this forum you'll find a little demo I did with RobotBASIC that sends a message to the Propeller which will respond when the correct string is sent. Sadly, the forum search engine doesn't work very well so it might be tough to track down. I uninstalled RobotBASIC so I no longer have the source for that demo.

    Here is the program Jonny is referring to.....it is a GREAT little program and illustrates the point NICELY

    The program is the SPIN side.....BUT....the RobotBASIC program is included in the Spin code as Comments
    just cut and paste it into the RB IDE to run it.

    ·

    Rartronic's program is ALSO a GREAT program.

    The PDF also has some nice examples....

    I hope all this has been good enough....if you need more let me know.

    Here is an image of Jonny's program running



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Samuel

    www.RobotBASIC.com


    Post Edited (SamMishal) : 1/20/2010 6:17:46 AM GMT
    1280 x 1024 - 317K
  • stevetronikstevetronik Posts: 15
    edited 2010-01-22 05:37
    Thanks for the guide, just a quick question, why does John uses
    clrbuf in the following segment.

    repeat
    buf[noparse][[/noparse]bufPntr++] := term.rx
    if strcomp(@cmd, @buf)
    term.str(string("Propeller here!"))
    clrbuf
    if bufpntr == 5
    clrbuf

    isit necessary to do a clear buffer. will something overload if I don't or is it just a precaution. otherwise everything seems fine and fun to 'speak' with prop.
    RobotBASIC is awesome but I don't think I would have the time to learn RobotBASIC for the time being, having a tight schedule to follow, the next step would be trying to link up with teammates microcontroller board, probably still figuring out the microcontroller baud rate at the moment.
    "What if the baudrate of the microcontroller and propeller don't match, can they still work?"

    EDIT: i believe I'm using 115200 br for most cases. If i want to reduce the speed, where in prop and spin should i edit.

    Post Edited (stevetronik) : 1/22/2010 5:58:23 AM GMT
  • StefanL38StefanL38 Posts: 2,292
    edited 2010-01-22 05:57
    It's nescessary to do the clrbuf because otherwise in case of missing a byte the strings would NEVER match again.

    If you read my code-example carefully there is precise timing mentioned. The baudrate determines the timing.
    You can adjust the baudrate of the propeller to ANY value.
    baudrate=13, baudrate=9601, baudrate=9599, baudrate=109678 or whatever you like.

    BUT ! the baudrate of two devices HAVE TO BE the SAME. Otherwise the other device will read just garbage.

    You need two serial connections. Therefore you start twi DIFFERENT cogs and then it is possible to adjust the
    TWO baudrates to any values you want.

    best regards

    Stefan
Sign In or Register to comment.