Shop OBEX P1 Docs P2 Docs Learn Events
Problems using FullDuplexSerial — Parallax Forums

Problems using FullDuplexSerial

parts-man73parts-man73 Posts: 830
edited 2007-01-19 00:27 in Propeller 1
I just made a program that sends a few different strings to a serial port with the FullDuplexSerial Object. I ran into a problem when I attempted to send a string that contains the word "string". I first used the following...

ser.str(string("This is a test String"))

and I received "This " on Hyperterminal

Then I tried to split the sentence into words and send them all separately...

ser.str(string("This "))
ser.str(string("is"))
ser.str(string("a "))
ser.str(string("test "))
ser.str(string("String"))

I then received "This is a test " and nothing more.

I then tried only ser.str(string("string")) and Hyperterminal just moves the cursor ahead 1 space every time I hit the reset button

any other string contained within the quotes works fine, I only have a problem when sending the word "string"

I have in my OBJ section "ser : "fullduplexserial" and my PUB block begins with "ser.start(31,30,0,9600)"

Am I missing something obvious here??? doing anything wrong???

Also, is there a limit to the size of a string?

Thanks in advance for the help

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade

"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2007-01-18 02:42
    There must be something else you're doing that you're not showing in your posting. There is nothing you are doing wrong regarding the string function. There is no practical limit to the size of a string. I suspect you actually have a double quote missing somewhere. The Propeller Tool color codes what you see on the screen to help you there. String contents are normally in red.
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2007-01-18 03:00
    I ran the test myself to ensure there was nothing magical about "string" the prop tool was getting confused with. It ran fine... though I do my terminal emulation wirelessly so I can program and monitor without bouncing back and forth (XBee's * cough * )

    -Martin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel
    StampPlot - Graphical Data Acquisition and Control
    AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
  • Oliver H. BaileyOliver H. Bailey Posts: 107
    edited 2007-01-18 03:59
    Brain,
    Check your terminal settings on HyperTerm. It needs to be set to TTY to work properly, it defaults to ANSI. I've used the FullDuplexSerial to the max and using all different speed crystals with no problems.

    Oliver
  • parts-man73parts-man73 Posts: 830
    edited 2007-01-18 04:48
    I'll have to play with it some more tommarrow. I'm not sure where my error is coming from. Other commands in the object work, such as tx, I made a loop that runs through the values 1-100 and outputs them using the tx command. Hyperterminal displayed the corresponding characters correctly.
    I also ran a short program that I found elsewhere on this forum that transmits "It's alive....It's alive" through the same pins, no problems with that program. So my hardware setup is working properly. I'm stumped. It must be some silly error, I'm sure I'll slap my forehead when I find it.

    Thanks all!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian Meade

    "They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2007-01-18 05:30
    Are you using the most recent version of the Propeller Tool? Maybe there was some bug that was fixed using the word "string"?
    -Martin
  • RytonMikeRytonMike Posts: 12
    edited 2007-01-18 10:47
    My experiments with this object, which does not use flow control, is that you have to have
    a fast enough data rate because the calls are non blocking.

    What speed are you using? At least 115,200 is needed which is also
    the highest that my hyper-terminal on XP will configure to.


    Mike
  • parts-man73parts-man73 Posts: 830
    edited 2007-01-18 13:43
    I was using 9600, I'll try a higher rate today after work and see if that helps.

    Funny, I remember working with microcontrollers with max data rates of 9600!

    I thought about that when I was opening Hyperterm, It asks if you want hardware flow control, Xon/Xoff or no flow control. I chose no flow control, because the only lines connected to the serial port are rx/tx/DTR and GND.

    Also, the third value passed in the Start command, what is the correct value to use in that field? The first 2 are the pins to use, and the 4th is the data rate, prehaps my problem lies in that value???

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian Meade

    "They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
  • Oliver H. BaileyOliver H. Bailey Posts: 107
    edited 2007-01-18 14:36
    Brian,
    9600 baud works fine. I've been using it with XP and Windows 2000 versions of HyperTerm with no problems. Is flow control set to none on HyperTerm? If you want I can send you my settings that work for hyperterm. In fact this is the first project in the propeller book, and it works on all of my machines (and Linux too). I'll email you the spin program. It uses the latest FullDuplexObject. If it doesn't work then you have another problem.

    Oliver
  • parts-man73parts-man73 Posts: 830
    edited 2007-01-18 15:35
    Oliver, I'd appreciate that, you already have my email from our recent conversation.

    I also found an old thread today about a "pc-debug" object, I think I'll try that one as well...

    I think I already know the answer to this next question. But when I use string("this is a string"), does it automatically append a 0 to the end of the string. I assume it does, but if it didn't, it would certainly explain the ability to tx a byte, but not a string.

    I'll have a fresh start on the problem today after work.

    I've been working on the hardware aspect so long, I haven't had alot of extra time to play with code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian Meade

    "They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
  • QuattroRS4QuattroRS4 Posts: 916
    edited 2007-01-18 21:28
    ser.start(8, 7, 2, 9600) 'rxpin,txpin,mode,baud
    ser.str(string("Test String",13,10))

    sends a Test String followed by a CR,LF (carriage Return and Line Feed)

    Ran the test to a laptop using a USB to serial adapter - all fine
    note my mode though !!! i.e. the '2' in line 1

    also just posted another reply noting to ensure to check

    _xinfreq = 5_000_000

    check it just in case..


    http://forums.parallax.com/forums/default.aspx?f=25&m=166079
  • QuattroRS4QuattroRS4 Posts: 916
    edited 2007-01-18 21:30
    .... again another thought 'FullDuplexSerial' references a 'Timing' object

    OBJ
    DELAY : "Timing"

    did you change this ?
  • parts-man73parts-man73 Posts: 830
    edited 2007-01-18 23:36
    I figured it out! turn.gif

    The last line of my code is a ser.stop. This line was right after the ser.str command that sent my text string. I surmise that it was stopping the cog before it finished sending the string. It was a coincidence that it failed on the word "string" nothing more. I may have thought I saw symptoms the I didn't.

    When I put a wait before the ser.stop call, it finishes the string before the cog is stopped, and problem solved.

    Thank you all for you help.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian Meade

    "They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
  • rokickirokicki Posts: 1,000
    edited 2007-01-18 23:56
    Good catch! I think this is a candidate for "tricks and traps". There are a lot of things on the propeller
    that are async (including starting a new cog, and methods like the full duplex send) and people need to
    be aware of the async nature so they don't mess things up.
  • parts-man73parts-man73 Posts: 830
    edited 2007-01-19 00:06
    My question is.... why didn't anyone else have this problem???

    Do others omit the stop command? It of course is not necessary, but good practice.

    If you start it, stop it. If you open it, close it... My wife even taught me to put the seat of the toilet down nono.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Brian Meade

    "They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2007-01-19 00:16
    Well, yeah, that would explain it [noparse]:)[/noparse]

    I see no reason to stop it. When I use serial data, it's typically a continual process of monitorin values or interacting with some device. The only time I might consider it is if I am running on battery and require the power savings. I don't want to wait the time it takes to re-load a cog simple to send another byte or 2 of data.

    So, my question would be the oppposite, why stop it under normal use?
    -Martin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel
    StampPlot - Graphical Data Acquisition and Control
    AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
  • Mike CookMike Cook Posts: 829
    edited 2007-01-19 00:22
    Actually your post of "I figured it out!" jogged my memory. I ran across this in the May Nuts and Volts article, can be found here:

    http://www.parallax.com/dl/docs/prod/prop/NVSA-2006-05.zip

    I believe the problem of not outputting all the data showed up when I lowered the baud rate; either set it to 9600 or 115200

    I think the reason most people have not experienced this is that most programs are running a loop and are outputting·serial data and there was not a need to stop the serial data output.

    Usually when I write a 'linear' program that does something, output serial data or whatever, and stops,·I just put a repeat at the bottom of the code. I guess it all depends on what your doing.

    Congratulations on sticking with it and finding your problem.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Mike

    Post Edited (Mike Cook) : 1/19/2007 12:36:29 AM GMT
  • rokickirokicki Posts: 1,000
    edited 2007-01-19 00:27
    Right, I never stop anything; I figure most code I write runs a "perpetual" program that just
    interacts with the user or devices or whatnot.

    On power savings, I'm thinking of making my SD card routines sleep in their poll loop to
    make the idle cog (that just spins on a memory location waiting for a command) take something
    like 1% of the running current. This will introduce a small latency, but it will be a small fraction
    of the total latency for a block operation anyway.
Sign In or Register to comment.