FullDeplex Xbee Communication. / global variables

Dgswaner

I just wanted to get some feed back on something to make sure I'm clear and that it's even possible.

This is for my "Pink Base Station" (pink + propeller + Xbee) to transmit commands for web control, and receive and display sensor data.
I have everything working, on the bot side and web side. but I'm trying to work out a good method of transferring data.

The Xbee is capable of full duplex communication, the pink isn't but I don't think that's a problem. what I would like to do is:

have 3 cogs running all the time, 1 for Xbee TX, 1 for Xbee RX, and one to handle the PINK.

all 3 of these will read/write to a set of global variables

this is were It gets a little gray, from what I can tell I don't really need to sync the reading/writing because the structure of the propeller basically does that for you.... all 3 cogs can't refresh the same variable (memory location) at once. Is this correct? I'm not sure how to go about this, if I do.

Thanks for any comments.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

groggory

I'm a beginner, so take my thoughts with a grain of salt...

I think it depends on why you want to sync. If you're worried about two cogs writing to the same variable at the same time, then no bother...the hub cog takes care of this.

I don't think you need to sync anything for full duplex serial communication

You may need to sync cogs for proper control...depending on your application exactly.

Is your question just, will the propeller lock variables when they are in use?

Mike Green

If you use the FullDuplexSerial driver, you already get both transmit and receive using only one cog.

I think you're jumping ahead too much. First figure out what kinds of data you want to flow from one device to another and document that. Then you can work on figuring out which pieces can function independently. From that will come the description of how these pieces communicate with each other. Pay attention to your quote from Jamie.

Each cog gets a turn at memory for reading or writing and the act of reading a byte or word or long is indivisible as is the act of writing a byte or word or long. Anything else is possible. In particular, if you increment a location, another cog can sneak in between the read and the write and write something else there.

Dgswaner

I am using the fullduplex object. it only uses 1 cog for RX and TX but if I want to do both at the same time I would need 2 cogs, correct? forgive my ignorance I'm getting familiar with with the propeller but everything I have done to this point has been with one cog (not counting objects). I can get the gist of what's going on in spin objects but I can't make heads or tales of assembly.

I have experimented with the data that I need to send.. I do need to do a little more, I haven't decided weither to send all of the data reguardless of change or only send the data that changes. there are a few complication of each method, that I won't get into now.

I think I got a little worried about having a delay while sending and receiving. also my code seemed to be a little cumbersome, Thanks for the advice, I'll do some more testing and go from there. and yes I always to to listen to Jamie. a reminder is always good too.

my main question about writing to a variable was answered.

thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Mike Green

The FullDuplexSerial object does both receive and transmit functions in one cog by taking turns. It does a little work on the receive function, then does a little work on the transmit function since the cog is much faster than it needs to be for serial I/O up to around 230KBaud.

One question is how much data do you need to send or receive at a time. The FullDuplexSerial object has a 16 character receive and 16 character transmit buffer. It might help to make these larger. You can make them any power of 2. In the Completed Projects forum, I posted a sound sequencer for a pair of VMusic2 players that included a modified FullDuplexSerial object with a 64 byte buffer each way and a couple of extra Spin methods that might be useful for you.

Dgswaner

that might be the best option I don't have a lot of data to send, in fact In most cases the description of what is being sent is longer than the data.

move command single digit 1-8
2 servos 0-255
ping readings in 5 locations all 1-8 or actual distance to be converted when sent to the pink.
and a few future add ons like compass readings tilt nothing to extensive.

so I'm thinking the 64 byte buffer is the way to go. I could make a single fixed length string from the data and then send it. that way I wouldn't have to send data descriptions. I would know what the data way from it's location in the string.

I'm going to experiment with this method using one cog, (not trying to do every thing at once) that will make thing a lot less complicated.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Post Edited (Dgswaner) : 4/8/2008 11:27:36 PM GMT