Shop OBEX P1 Docs P2 Docs Learn Events
Can one instance of Full-Duplex serial by accessed by multiple methods? — Parallax Forums

Can one instance of Full-Duplex serial by accessed by multiple methods?

JohnR2010JohnR2010 Posts: 431
edited 2011-09-27 10:38 in Propeller 1
I’m Using the Full-Duplex Serial Driver v1.2 from Chip Gracey and Jeff Martin and I may be miss using it. I have an application that uses Full-Duplex serial to talk with an xBee. My Main method starts Full-Duplex Serial and then launches two methods into two cogs. The first cog’s method sends out serial data to the xBee continually ever second. The second cog’s method sits and waits for input from the xBee and then process the input and then returns to wait again for the next command. This seems to work great but I have problems with my app randomly resetting. Is this an appropriate use of Full-Duplex serial? Can you have two methods running in COGs access this object at the same time if one is dedicated to RX and the other to TX?

Full-Duplex serial uses two different buffers for RX and TX so I thought this would be ok? However, the description about multiple nested objects in SerialMirror.Spin is causing me to question the way I’m using Full-Duplex serial. And maybe some type of memory conflict is causing my reset problem?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-27 09:41
    Once the FullDuplexSerial object finishes its initialization, the receive and transmit sides of the communications are mostly independent, so you should be able to handle the receive side from one cog and the transmit side from another cog unless you've got bit 3 of the mode set. This causes the transmit routine to call the receive routine ... not something you want to do in your case.

    Most likely you've got too small a stack space set aside for one or both of your extra cogs.
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-09-27 10:38
    Mike Green wrote: »
    Once the FullDuplexSerial object finishes its initialization, the receive and transmit sides of the communications are mostly independent, so you should be able to handle the receive side from one cog and the transmit side from another cog unless you've got bit 3 of the mode set. This causes the transmit routine to call the receive routine ... not something you want to do in your case.

    Most likely you've got too small a stack space set aside for one or both of your extra cogs.

    Thanks Mike for the quick response. I’m running in Mode 0 so that shouldn’t be a problem. As for the stack space I think I’m okay here. I have given each COG’s method a ton of space and I also have a way of monitoring the stack space it is using. I have another method I can call that looks at each stack and reports the amount of space used. I do this by searching from the end of the stack back to the beginning address until I find a non-zero value in memory. I can call this method remotely to keep an eye on the stack space. Right now I have each stack set 100% larger than it needs to be since I have the room in RAM anyway.

    So I understand things correctly with FullDuplex: As long as my multi Cog application calls RX and TX independently I should be Okay? What if I have two Cogs that want to transmit close to the same time? I know this works you just get scrambled data out, but I suspect it is not a wise thing to do. Could it cause my reset if I was doing this? Would best practice be to use a lock on the TX side to make sure only one COG can TX at a time? So in other words Method 1 in Cog 1 wants to Xmit a string and method 2 in Cog 2 wants to Xmit a string. Each Cogs method should wait for a lock to be free before it is allowed to call fullduplex.tx? Or is this overkill and not necessary?
Sign In or Register to comment.