Shop OBEX P1 Docs P2 Docs Learn Events
Conflicting Serail Objects — Parallax Forums

Conflicting Serail Objects

davidpzkdavidpzk Posts: 19
edited 2012-01-13 13:41 in Propeller 1
Has anyone else had problems with serial objects conflicting with each other?

I am using "Full-Duplex_COMEngine" to send commands at 300 baud to a serial device.
I am simultaniously using "Parallax Serial Terminal" at 9600 baud to do code troubleshooting and debugging.

When both are started, I get conflicts/unwanted characters/noise on both of them.

If I comment out one or another, all is well.

Anyone else see this happen?

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 10:08
    Yes, This is to be expected.

    You should only use one serial driver per set of IO pins. You can use the same serial driver from multiple cogs by using locks to keep the output from mixing together.

    I believe there's a multicog debug object that takes care of this for you (I haven't used it).

    Kye's objects often use locks, "Full-Duplex_COMEngine" might be usable from multiple cogs (I haven't used it in a long time).
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-01-13 10:15
    Welcome to the forum David.

    While I have not used either of the serial objects you mention - I use FullDuplexSerial or my modified version (..._rr004) and do not have any problems at 115,200 baud.

    It may be better to post your code. You can zip it with proptool and post that, or if short, post the code between {code} ... {/code} tags using square brackets instead of the braces shown here.

    A guess could be as simple as not enough stack space.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 10:32
    David,

    Are the serial objects sharing IO pins? If not, then there's some other problem like Cluso99 suggests.
  • davidpzkdavidpzk Posts: 19
    edited 2012-01-13 11:33
    Howdy guys... Here is my sample code. If you run this, you can see on your terminal window part of the string that is intended to send to pin 7 clearly makes it to pin 30.
    CON
   _clkmode = xtal1 + pll16x
   _xinfreq = 5_000_000
OBJ
  term : "Parallax Serial Terminal"
  Serial : "Full-Duplex_COMEngine"
VAR
  Byte RecievedBufferCount [3]
PUB BootUp
  term.start(1200)
  Serial.COMEngineStart(5,7, 1200)                    'rxpin, txpin, baud
  RecievedBufferCount :=  Serial.receivedNumber
  repeat
    RecievedBufferCount :=  Serial.receivedNumber
    term.str(string("Message to terminal. This is a long looping test to see if we can spot some conflicts or errors between the serial objects",13))
    Serial.WriteString (string("Message to *******************  serial device. This is a long looping test to see if we can spot some conflicts or errors between the serial objects.",13))
    term.str(string("How much info is in Serial recieve buffer \\\"))
    term.str(RecievedBufferCount) '<<<<<<<<<<<<<<<<<<<<<<<<<<<< If you comment out this line, the problem changes
    waitcnt (99999999+cnt)
    waitcnt (99999999+cnt)
    term.str(string("///",13))
  • Mike GMike G Posts: 2,702
    edited 2012-01-13 11:44
    RecievedBufferCount is a pointer like RecievedBufferCount[0] assigned to the result of Serial.receivedNumber 
    RecievedBufferCount :=  Serial.receivedNumber

    I believe you want something like 
    RecievedBufferCount[0] :=  Serial.receivedNumber

    The line below says print from the address RecievedBufferCount until we see a terminating zero. 
    term.str(RecievedBufferCount)
  • davidpzkdavidpzk Posts: 19
    edited 2012-01-13 11:54
    Hi Mike G.

    I made your code suggesion chage(s) but still have the same problem. Part of the string that is clearly intended for pin 7 is making it to pin 30.

    See updated code...
    CON
   _clkmode = xtal1 + pll16x
   _xinfreq = 5_000_000
OBJ
  term : "Parallax Serial Terminal"
  Serial : "Full-Duplex_COMEngine"
VAR
  Byte RecievedBufferCount [3]
PUB BootUp
  term.start(1200)
  Serial.COMEngineStart(5,7, 1200)                    'rxpin, txpin, baud
  
  RecievedBufferCount[0] := Serial.receivedNumber
  RecievedBufferCount[1] := 0
  'RecievedBufferCount := Serial.receivedNumber
  repeat
    RecievedBufferCount[0] := Serial.receivedNumber
    term.str(string("Message to terminal. This is a long looping test to see if we can spot some conflicts or errors between the serial objects",13))
    Serial.WriteString (string("Message to *******************  serial device. This is a long looping test to see if we can spot some conflicts or errors between the serial objects.",13))
    term.str(string("How much info is in Serial recieve buffer \\\"))
    term.str(RecievedBufferCount) '<<<<<<<<<<<<<<<<<<<<<<<<<<<< If you comment out this line, the problem changes
    waitcnt (99999999+cnt)
    waitcnt (99999999+cnt)
    term.str(string("///",13))
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 11:54
    Google return zero hits for "Full-Duplex_COMEngine".

    Could you provide a link?
  • kwinnkwinn Posts: 8,697
    edited 2012-01-13 12:01
    I would suggest using the four port serial object if you need multiple serial ports. In your case it sounds like you nedd at least 2 ports, one for your 300 baud device and another for debugging with PST.
  • Mike GMike G Posts: 2,702
    edited 2012-01-13 12:02
    This line... 
    term.str(RecievedBufferCount)

    Says go to the memory address RecievedBufferCount, which is whatever was in Serial.receivedNumber, then start transmitting until we find a zero. Anything can be in memory starting at Serial.receivedNumber
  • Mike GMike G Posts: 2,702
    edited 2012-01-13 12:08
    Take a look at this... 
    CON
   _clkmode = xtal1 + pll16x
   _xinfreq = 5_000_000


VAR
  Byte buffer[3]


OBJ
  pst : "Parallax Serial Terminal"
  serial : "FullDuplexSerial" 

PUB Main
  serial.start(5, 7, %0000, 9600) 
  pst.start(115200)
  Pause(500)

  ' Lets pretend we received some serial data
  buffer[0] := $41
  buffer[1] := $42
  buffer[2] := $00

  pst.str(@buffer)   

PRI Pause(Duration)  
  waitcnt(((clkfreq / 1_000 * Duration - 3932) #> 381) + cnt)
  return
  • davidpzkdavidpzk Posts: 19
    edited 2012-01-13 12:24
    Ive included the Full-Duplex_COMEngine.spin below.

    In the mean time, Im looking into kwinn's suggestion and seeing if I can make use of the 4port serial object instead...
    spin
    spin
    Full-Duplex_COMEngine.spin
    27K
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 12:33
    David,

    Thanks for posting the driver.

    I like to think I improved a good thing. I have a couple of modified versions of Tim Moore's four port driver here. The 128 byte rx buffer version gives you a bigger buffer at the cost of a few longs in increased program size. (Most of the increase is due to fixing the Dec method's bug in the original.)
  • Mike GMike G Posts: 2,702
    edited 2012-01-13 12:36
    Changing the driver is not going to fix the problem. This is a conceptual issue. 
    CON
   _clkmode = xtal1 + pll16x
   _xinfreq = 5_000_000
OBJ
  term : "Parallax Serial Terminal"
  Serial : "Full-Duplex_COMEngine"
VAR
  Byte RecievedBufferCount [3]
PUB BootUp | i
  term.start(1200)
  Serial.COMEngineStart(5,7, 1200)                    'rxpin, txpin, baud
  
  RecievedBufferCount[0] := Serial.receivedNumber
  RecievedBufferCount[1] := 0
  'RecievedBufferCount := Serial.receivedNumber
  repeat
    RecievedBufferCount[0] := Serial.receivedNumber
    term.str(string("Message to terminal. This is a long looping test to see if we can spot some conflicts or errors between the serial objects",13))
    Serial.WriteString (string("Message to *******************  serial device. This is a long looping test to see if we can spot some conflicts or errors between the serial objects.",13))
    term.str(string("How much info is in Serial recieve buffer \\\"))
    'term.str(RecievedBufferCount) '<<<<<<<<<<<<<<<<<<<<<<<<<<<< If you comment out this line, the problem changes

    repeat i from 0 to 2
      term.dec(RecievedBufferCount[i])
      
    waitcnt (99999999+cnt)
    waitcnt (99999999+cnt)
    term.str(string("///",13))
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 12:47
    Yes, Mike G's got the fix (to the main problem). You need to use the "dec" method of PST.

    I don't see the need for:
    repeat i from 0 to 2
      term.dec(RecievedBufferCount[i])

    I think the above code would adds two zeros after number of bytes in the buffer.

    I think this would work.
    term.dec(RecievedBufferCount[0])

    Since only one byte of data was stored. (I think that's what the program is doing.)
  • Mike GMike G Posts: 2,702
    edited 2012-01-13 12:50
    Whatever is clever. I dumped the entire buffer simply for illustration.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-13 12:55
    Mike G wrote: »
    Whatever is clever. I dumped the entire buffer simply for illustration.

    Which is a good idea.

    I'd suggest separating the bytes.
    repeat i from 0 to 2
      term.dec(RecievedBufferCount[i])
      term.str(string(", "))

    Or adding a carraige return between bytes.
  • davidpzkdavidpzk Posts: 19
    edited 2012-01-13 13:15
    Wow thanks guys.

    The 4 port serial object is really cool. Preliminary tests show it is pretty good at serial traffic control across multiple ports. I dont think I need it for this project but its nice to have around for larger serial project needs. Very good to know it exists!

    Turns out the heart of the problem was me needing to use the term.dec command instead of the term.str command.

    Problem solved.
  • max72max72 Posts: 1,155
    edited 2012-01-13 13:41
    As a side note consider the 4 ports serial object has been shown by Tracy Allen to work better if you start all the ports.
    In case just use -1 as rx/tx pin for the dummy ports..

    http://forums.parallax.com/showthread.php?129776-Anybody-aware-of-high-accuracy-%280.7-or-less%29-serial-full-duplex-driver

    Massimo
Sign In or Register to comment.