How can you tell which cog pub main is using in your parent object?

turbosupra

I believe I'm only using 7 cogs and cannot get my 8th object to start, so I'm wondering if their is a variable assignment I can do to find out which cog pub main in my parent object is using? Or does parent object pub mail always use cog0?

If so, I am missing cog1

I'm also using this and am not sure why, it was just something I saw someone else doing. Why do you add the +1 at the back of the return value?
return l_cog := cognew(@simulatecrank, @l_cog) + 1

Here are my current objects and the numeric cog number value assigned to them. The bottom/bolded one is not starting.

simCrank: 3
simCam: 4
simMaf: 5
calcCrank:6
calcCam: 7
simVvtli: 8
simSol: 0

Heater.

From the manual cognew returns: The ID of the newly started cog (0-7) if successful, or -1 otherwise.
So adding one to the reulst gives you a cog number 1 to 8 or zero on error.
That means you can the use a test for zero or false to see if the thing worked or not. So if you cognew was in a method called "start" you can do a simple

if  objectFoo.start
    ' Everything OK
else
    ' It failed 

Your top level object starts first in cog 0.

As you only have 7 uses of cogs listed there and the initial top level cog uses another one that is only 8 and all should be well.
Are you sure simSol can be started correctly by itself?

Mike Green

The only way to tell for sure what cog is being used for the main / default method is to have the main routine do a COGID. The bootloader starts up in cog 0 and starts up any program downloaded from a PC or copied in from the EEPROM in the same cog, which would be cog 0. If your program is executed by some other program, like an SD card loader, the initial cog could be anything.

The +1 is to make testing easier for whether the cog has already been started. COGNEW returns -1 if it can't start a new cog or the cog number (0-7) if one is started. By adding 1, this becomes a 0 if there's no cog running or 1-8 if a cog is started. This value can be stored in a byte and tested for zero / non-zero.

Your simSol is probably not starting because you're already using all the cogs. I don't know what your program is doing, but one of your objects may be using another cog. If your main program is using FullDuplexSerial for example, that takes a cog for the assembly part of its operation.

Heater.

Yes, just occurred to me that if those cog numbers are with the one added on, must be because you have an 8 in there, then simSol is not starting and the only reason for that is that you have run out of cogs. There must be some object starting a sub object of it's own.

turbosupra

I'm using the PST and I'd bet that's what's doing it. Good call Mike

Mike Green wrote: »

The only way to tell for sure what cog is being used for the main / default method is to have the main routine do a COGID. The bootloader starts up in cog 0 and starts up any program downloaded from a PC or copied in from the EEPROM in the same cog, which would be cog 0. If your program is executed by some other program, like an SD card loader, the initial cog could be anything.

The +1 is to make testing easier for whether the cog has already been started. COGNEW returns -1 if it can't start a new cog or the cog number (0-7) if one is started. By adding 1, this becomes a 0 if there's no cog running or 1-8 if a cog is started. This value can be stored in a byte and tested for zero / non-zero.

Your simSol is probably not starting because you're already using all the cogs. I don't know what your program is doing, but one of your objects may be using another cog. If your main program is using FullDuplexSerial for example, that takes a cog for the assembly part of its operation.

turbosupra

Hi Heater,

Thanks for the reply, I think it is the pst that is hogging my "phantom cog" . I commented out the cognew for simMaf and then got the quoted results below.

Any ideas on how to combine the functionality of pub main which besides being responsible for starting the other objects only manages comm data ... and the pst object?

simCrank: 3
simCam: 4
simMaf: 0
calcCrank:5
calcCam: 6
simVvtli: 7
simSol: 8

Heater. wrote: »

Yes, just occurred to me that if those cog numbers are with the one added on, must be because you have an 8 in there, then simSol is not starting and the only reason for that is that you have run out of cogs. There must be some object starting a sub object of it's own.

Heater.

If your main had nothing to do except start other objects then you could start the last object with coginit and specify 0 as the cog id (or better used cogid which will be zero anyway in this case). That will cause main to die and be replaced by whatever it started.

The issue then is to find a place to put your com code.

Alternatively are you sure you can't combine two of your lower level cogs code into one?

Mike Green

For Bauds up to 9600, particularly where there's no input buffering necessary, you could use Simple_Serial for your debugging which doesn't need a separate cog.

turbosupra

@ Heater, I could probably combine two of the objects using the counters if I was a better programmer but alas I am very new to PASM and not very good at it. I may try to combine the comm code and the simMaf (which is the only one of my objects written in spin) if they don't slow each other down too too much. Ugh this is the worst thing to have happen when you are trying to go from bench to real world testing.

@ Mike, I probably need a higher baud speed as I will be sending a lot of and infrequently receiving serial data over that. I may try that though, thank you.

Duane Degn

I add the following method to a lot of my programs (at least while I'm debugging them).

PUB DebugStr(localPtr)
'' display cog ID at the beginning of debug statements
  if debugLock == -1
    return
  if byte[localPtr] == 13
    Debug.tx(13)
    Debug.dec(cogid)
    Debug.tx(":")
    Debug.tx(32)
    localPtr++
  Debug.Str(localPtr)  
 

If then have the following code in my program:

DebugStr(string(13, "Hello World"))

I get the following output in the terminal window:

2: Hello World

In this example, I'd know that cog #2 called the "DebugStr" method. If I have more than one cog using a serial object I use locks so I don't get gibberish from two cogs sending data to the serial driver at once.

I think there's a multicog debug object that keeps track of the locks for you, but I haven't tried it or looked at the code.

Edit: I just read a bunch of what I had just skimmed over. It looks like my post is way off of what you're trying to figure out. Sorry about that.

turbosupra

Duane, have you ever combined the pst object with another object? I'm guessing that since timing is so crucial that probably isn't a good idea?

I'm timing my com object and it's about 6M cycles without all of the extras.

Maybe I'll have to call that and the other object together? That's about the only idea I have besides trying to combine two of the PASM objects of which I don't want to do.

turbosupra

Looks like if I add the adc code it only adds 1M cycles for a total of 7M cycles (7084880) and that's not bad I guess if it updates 11 times a second, but certainly far from optimal.

I remember in previous threads that there were more optimized serial comm objects, maybe I should consider one of those?



Now it is configured as

main/simMaf: 1
pst object: 2
simCrank: 3
simCam: 4
calcCrank:5
calcCam: 6
simVvtli: 7
simSol: 8

Mike Green

A "better" serial object won't help you. If it's buffered, it uses a cog. The newest serial object provides multiple serial ports in one cog along with some other improvements, none of which you need for this project.

Duane Degn

Brad, I notice you have several "sims". I assume these are to simulate actions caused by the motor you wish to monitor. Could some of these be moved to a second Prop with wires attaching appropriate output pins from the sims to inputs on the Prop running your main program?

turbosupra

Good eye Duane. Actually I have (you'll like this) two quickstarts and one is feeding the other.

The problem is this, the sims will still be used in "production" because I want to read the sensor signal, intercept it and then send a new "simulated" signal to the ECU so I still need the simulation portion.

I really didn't want to complicate this project by having two props and a serial rx/tx combining circuit. I'm not even sure how to do that?

Duane Degn wrote: »

Brad, I notice you have several "sims". I assume these are to simulate actions caused by the motor you wish to monitor. Could some of these be moved to a second Prop with wires attaching appropriate output pins from the sims to inputs on the Prop running your main program?

turbosupra

Ok thanks Mike. I thought I had read that they were more efficient with wait timing, which could make my loop more efficient but it seems not from your post.

Mike Green wrote: »

A "better" serial object won't help you. If it's buffered, it uses a cog. The newest serial object provides multiple serial ports in one cog along with some other improvements, none of which you need for this project.