Using FullDuplexSerial from another cog

jbalat

I was wondering if I can use the full duplex commands from another cog to report my global variables back to ther Terminal program on my laptop for some debuggin.

The issue is that I dont want to slow down any of the processing going on in my main routine ?
I assume this will then use 2 cogs..

Mike Green

You can, but you have to ensure that only one cog at a time can write to the transmit buffer at a time. You can do this using the LOCKxxx statements or by the way your program is designed.

If you just use FullDuplexSerial by itself, you don't need to use yet another cog since FullDuplexSerial normally launches the actual I/O routines in their own cog and the routines you normally call just put stuff into the buffer. By default, the buffer is only 16 bytes long which may not be long enough for you. There are other versions of FullDuplexSerial in the Object Exchange that have larger buffers, up to 512 bytes long.

MagIO2

Sure you can. It only gets complicated if both want to use the same full duplex object. Then you need to synchronize.

MagIO2

@Mike:
I guess I did not have a closer look to full duplex or have forgotten those details, but if I remember right things like number conversion are not done in the PASM driver, but in the SPIN part. So, if jbalat want's to send a lot of numbers converted to a string, using a different COG might be a good idea.

Mike Green

Yes, you can do it that way as well. It all depends on how tight you are for time. You can also have a debug buffer that holds lots of LONGs so that the calling code just has to plug in the LONG value and advance the pointer and the separate cog pulls the LONGs out of the buffer, formats them, and puts the serial data into the large buffer used by FullDuplexSerial. At some point, you'll run out of buffer space if the comm channel isn't fast enough.

Botdocter

I did just that a few days ago. It works perfectly! Just do: cognew(<your PUB or PRI>, @<your stack>)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1 Parallax Propeller Robot Control Board
1 Memsic MX2125 accelerometer/ tilt
1 Parallax Ping))) ultrasonic sensor

a few motors and a whole lot of chaos!

jbalat

Do I really need to do a lock ?

In the new cog I was just going to do a repeat loop with a 1 second wait

within the loop I can copy the Global variables to local variables (only 4 off I want to track)

Then print them onto the Terminal via the fullduplex command



At the end I wanted to cut and paste the data from the Terminal program into a text file and load it into excel for analysis


Please see my program attached. I have added the new section called 'Show_PC'

Post Edited (jbalat) : 5/10/2010 8:50:26 AM GMT

StefanL38

when ever TWO cogs can write to the sendbuffer

sooner or later it WILL happen that the writing to the sendbuffer get's mixed up.
Even if you think it will never happen. It WILL happen. Believe a programmer with 25 five years of programming-experience.

As long as only this other cog sends everything is ok but if two cogs send the messed up sendbuffer WILL happen FOR SURE.

If you are just debugging and one of a hundred debuglines is messed up doesn't matter. In all other cases I recommend using a lock-mechanism.

best regards

Stefan

Dave Hein

Your program should print fine from the second cog.· You do need to fix the spelling of pulsewidth in Show_PC for it to compile.· If you decide to print from cog 0 as well you will need to add a lock.

Dave

jbalat

Dave thanks for your feedback

I found the error with the spelling and I also noticed my Leanfactor uses the already modified pulse instead of the original input.. Will fix this tonight

BTW Data logging went great.

From the data I figured out that going up a hill at low speed will still lean 100% (OH NO) , so now I need to monitor TPS as well and back off leaning at higher throttle

--- Updated Program attached ---

Post Edited (jbalat) : 5/11/2010 12:18:40 PM GMT