cog and object timing and activity

CannibalRobotics

To access data in an object running on another cog one can either; create a PUB it to return/set the value or pass the memory location up and read/write to it directly.
In the latter, access timing is just a matter of cog rotation. In the former the 'delivering' cog must actually execute some code to return the value.
The question is timing and activity. If the TopObject calls this in another object on another cog,

PUB GetValue(i)
    return Value[i]

Then the cog running the object with GetValue has to respond. Does it drop what ever it is doing at that nanosecond and run GetValue? This would destroy the timing reliability of a loop, yes?
What happens if GetValue is a little more elaborate and get's called several times and does not have time to finish the first call?

Bobb Fwed

The cog never stops doing what it was doing. Depending on how is it programmed, most likely the call for the value is happening in the "upper" cog.

An object doesn't get loaded to a cog, the SPIN "interpreter" does (or custom PASM code). The interpreter executes a specific method in that object. When the upper cog/object executes a method in the lower object, the method gets executed in the originating cog.

All that's happening in the method you gave (above) is the originating cog is getting the value from the lower object. A value that is probably being populated by the lower cog.

(please note the differences between cogs and objects)

Did that make any sense?

CannibalRobotics

Well, clarifies my thinking actually. But it does beg the question, which is the better technique?

Bobb Fwed

CannibalRobotics wrote: »

Well, clarifies my thinking actually. But it does beg the question, which is the better technique?

What are the options?

1) The most common use of this is for drivers. For example, I have a ADC driver that runs custom PASM code. It populates HUB RAM variables that are declared in the lower object. When the parent object needs those values, it asks the lower object for them using a method (as you showed above). You would call a method like this: getval(3)
2) A second option (in my driver, and in programming in general) where the parent object feeds the lower object memory addresses. Instead of the PASM cog filling the lower object's memory space, it fills the newly supplied memory space. This uses more memory, but accessing the values is quicker because it doesn't have to call a method in the ADC object, it's just calling local variables. It would just need this: variable[3]
3) Another option would be to have a return from the start/init method (or a different one) with the address of the memory being populated in the lower object. Then access the memory like this: long[address][3]

They each have their different purposes, but the first is probably the most common, and the third is the easiest to implement, while the second makes it easy to access the values in the parent object in a simple manor.