PDA

View Full Version : Runing the same object in 2 different cogs?



reppig
10-21-2011, 07:56 PM
I am writing a program to read in GPS data from a balloon and convert it to AZ and EZ and then command a computer controlled antenna rotor to move the antenna to stay pointed at the balloon.
I have everything working except for the commanding of the antenna rotor. I am using FullDuplexSerial.spin running in a seperate cog to read the GPS data coming in.
I would like to run FullDuplexSerial.spin in a different cog just to command the antenna rotors.

Since FullDuplexSerial.spin has a start call. Can I call it again with different parameter and expect it to start in a new cog? What is the best way of do this?

Thanks in advance.

Cluso99
10-21-2011, 08:11 PM
The easiest way to do this and be sure you are not going to share common variables is to create another version of the FullDuplexSerial.spin file (i.e. copy to FullDuplexSerial2.spin). Now you can create a second object without any fear of problems, providing of course you start it with different pin numbers. However, this method does waste space in hub, but it is the simplest and safest.

There is also a 4 port serial object in Obex that a number of people are successfully using. I am unsure of its name as I have not used it.

BTW I understand that the altitude is not that accurate for GPS, so are you relaying separate altitude data? For example, I often noticed while sailing in the ocean, that my altitude was not zero.

Phil Pilgrim (PhiPi)
10-21-2011, 08:14 PM
You could declare the object twice:



OBJ

gps : "FullDuplexSerial"
ant : "FullDuplexSerial"


This creates two separate instances. But, if your GPS interface is read-only, and your antenna interface is write-only, you can use the same instance to do both jobs. Just assign the input and output pins accordingly.

-Phil

Phil Pilgrim (PhiPi)
10-21-2011, 08:21 PM
Cluso99,

It is not necessary (nor would it even help) to create two copies of FullDuplexSerial. The reason it's not necessary is that all the object's hub variables are declared as VARs, which are duplicated for each declared instance. The reason it would not help is that the compiler detects identical objects and discards duplicates.

-Phil

Cluso99
10-21-2011, 08:55 PM
Phil: I thought if they were in fact different filenames they would not be detected as being identical. Am I incorrect on this (i.e. the compiler physically compares a 'blob')???

Phil Pilgrim (PhiPi)
10-21-2011, 08:57 PM
Yes, the compiler compares objects byte-for-byte and discards duplicates.

-Phil

kwinn
10-22-2011, 01:32 AM
Look in the OBEX for "Multiple serial port driver". I find it easier to use than multiple instances of FDS.

reppig
10-22-2011, 09:12 PM
BTW I understand that the altitude is not that accurate for GPS, so are you relaying separate altitude data? For example, I often noticed while sailing in the ocean, that my altitude was not zero.

That is true close to the earth the higher it goes the better the accuracy.
Thanks for you help.

reppig
10-22-2011, 09:14 PM
You could declare the object twice:



OBJ

gps : "FullDuplexSerial"
ant : "FullDuplexSerial"


This creates two separate instances. But, if your GPS interface is read-only, and your antenna interface is write-only, you can use the same instance to do both jobs. Just assign the input and output pins accordingly.

-Phil
Thanks this is what I wanted to know. I was going to try it but thought I ask here first. Thanks again.

reppig
10-22-2011, 09:16 PM
You could declare the object twice:



OBJ

gps : "FullDuplexSerial"
ant : "FullDuplexSerial"


This creates two separate instances. But, if your GPS interface is read-only, and your antenna interface is write-only, you can use the same instance to do both jobs. Just assign the input and output pins accordingly.

-Phil
Also, you are right the GPS is read only. However, the antenna interface is read/write. I command it to a position and I can read where it is.

reppig
10-22-2011, 09:19 PM
Thank you all for your help. This forum is really helpful and responses are quick.
I usually work with PIC processors and that forum is just OK and slow with answers.
I am going to move away from PIC's. Thanks again.