PASM and local variables...

Chris_D

Hi everyone,

I am confused about variables within a PASM program.·· There was a recent post that, while at first seemed to clarify the situation, ended up confusing me more.

Here is what I am doing...

I have a PASM object that needs to be loaded into 3 different COGS (eventually 4 COGs).· Within that object, there are a number of "local" variables that are used in calculations etc.· I need to make sure that these variables are exclusive to that COG so that the other COGs running the same oject don't change the values.

Currently, I am declaring variables two ways within my PASM object...

Method #1
··· SlowVel················ Long··· 600_000
··· McmReady·············Long··· 99· 'Default to not ready
··· mSecDelay············ Long··· 80_000 'equals one millisecond
Method #2
··· mSecElapsed··········· Res···· 1
··· mSecPrevCnt··········· Res···· 1
··· mSecIntCnt············· Res···· 1
I suspect I could use either method, with Method #1s advantage being that I can preset the value at the time of declaration.· However, it would be very easy to use Method #2 and simply set the variable to a preset value at the start of the program.

As mentioned, the gray area is the "protection" of these variables from being changed by other COGs running the same code.· Furthermore, is using one type of variable declaration faster (during program execution) than the other?·

Chris

·

Ale

Each COG copies to its local RAM the code you point via coginit. If you modified those variables before coginit then you get those new values when you do the coginit. Each COG has its own copy and cannot access other COG's memory at all. so any modifications you do in a running cog's memory can only be seen from within that cog.
LONG is used to have an initialized constant, RES for a not initialized (means it will contain the garbage hat follows for DAT section or the rest of it when copied to cog memory. So do not place any value in a RES defined variable (because it is only a placeholder, a trick for the compiler: there is no space reserved in HUB memory).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Chris_D

Thanks Ale,

I guess what had me confused is the other thread made mention of Full Duplex Serial not being able to run in two COGs, wasn't sure I understood why.· But I susect it was because of the addressing used back to the hub memory variables.



Thanks!

Chris

localroger

fullduplexserial most certainly can run in multiple cogs at the same time.· I've used it that way in several applications that are working fine.

ericball

Presetting values from SPIN before the COGINIT is an easy way to set initial values to local variables. Just be careful if you are starting multiple COGs with different initial values that you don't overwrite them before the COGINIT completes (~8K clocks).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum