Shop OBEX P1 Docs P2 Docs Learn Events
Quick question about Arrays and Cog Stopping and starting. — Parallax Forums

Quick question about Arrays and Cog Stopping and starting.

James LongJames Long Posts: 1,181
edited 2010-01-05 02:42 in Propeller 1
I haven't tried this yet, since I really don't have the time right at this moment.......

If a cog is started, and an array is loaded with the newly started cog, will the array still contain the information if the cog is stopped?

I figure so, since this memory is shared between the cogs. This would have to be a passed parameter.....correct?

I'm checking for my own sanity.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services

Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-04 19:32
    "an array is loaded with the newly started cog"? Do you mean that "an array is filled by the newly started cog"? If so, the data will remain in the array if the cog is stopped. The address of the array will have to be passed somehow to the cog.
  • James LongJames Long Posts: 1,181
    edited 2010-01-04 19:36
    Mike Green said...
    "an array is loaded with the newly started cog"? Do you mean that "an array is filled by the newly started cog"? If so, the data will remain in the array if the cog is stopped. The address of the array will have to be passed somehow to the cog.

    Mike,

    Yes that is what I meant. Thanks for the translation (I rarely ask it correctly).

    I appreciate the answer. That is what I had in my head, but wanted to make sure I wasn't dreaming.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-01-04 19:57
    Just to clarify: the array exists and is modified directly in hub RAM, right? An array that is loaded from the hub and modified only in cog RAM will not have its values updated in the hub, unless those values are explicitly written back to hub RAM using wrlong/word/byte. When the cog is stopped, the values in cog RAM effectively cease to exist.

    -Phil
  • James LongJames Long Posts: 1,181
    edited 2010-01-04 20:03
    Phil Pilgrim (PhiPi) said...
    Just to clarify: the array exists and is modified directly in hub RAM, right? An array that is loaded from the hub and modified only in cog RAM will not have its values updated in the hub, unless those values are explicitly written back to hub RAM using wrlong/word/byte. When the cog is stopped, the values in cog RAM effectively cease to exist.

    -Phil

    Phil,

    The method I was going to use......

    Declare the Array in the parent cog. When needing to fill the array, start a new cog to drop in all the information, then stop it when finished. I would be passing the array's address to the newly started cog.

    That would work.....right??

    I didn't answer you directly, because I haven't got hub ram or cog ram totally figured out in my head yet (hammer and chisel may be needed). Those still confuse me.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!

    Post Edited (James Long) : 1/4/2010 8:08:19 PM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-04 20:13
    It sounds like you're mixing up the way Spin programs access memory and the way assembler programs access memory. When you write programs in Spin, all the memory you can refer to is hub memory (except for the I/O registers like INA, DIRA, OUTA, CNT, etc.) You can't really refer to the cog's memory since that's all used by the Spin interpreter.

    For assembly programs, you're really referring to the cog's memory which is only accessible to the cog running the program. The hub memory is kind-of like an I/O device. You can only use special instructions to reference it and there's special timing involved for those instructions.
  • James LongJames Long Posts: 1,181
    edited 2010-01-04 20:27
    Mike Green said...
    It sounds like you're mixing up the way Spin programs access memory and the way assembler programs access memory. When you write programs in Spin, all the memory you can refer to is hub memory (except for the I/O registers like INA, DIRA, OUTA, CNT, etc.) You can't really refer to the cog's memory since that's all used by the Spin interpreter.

    For assembly programs, you're really referring to the cog's memory which is only accessible to the cog running the program. The hub memory is kind-of like an I/O device. You can only use special instructions to reference it and there's special timing involved for those instructions.

    Hmmmmm.......now that didn't help. smile.gif

    Ok....to try and figure this out.......

    So when using spin, basically there is only hub memory (for all practical purpose in this discussion).

    When using pasm, the actions are done with cog memory.

    My speculation..........if using pasm, and wanting to put the information into hub memory, a wrlong (word, byte) is used.

    I think I see....but will wait for your response to chisel that into my memory.


    to expand on this.......I didn't think the item would be accessible from outside the newly started cog, unless the wrlong (word, byte) command was used.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!

    Post Edited (James Long) : 1/4/2010 8:33:01 PM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-04 21:16
    The only way to read or write hub memory in pasm is to use the special instructions for this (RDxxxx and WRxxxx where xxxx = BYTE, WORD, or LONG).
  • James LongJames Long Posts: 1,181
    edited 2010-01-04 21:24
    Mike Green said...
    The only way to read or write hub memory in pasm is to use the special instructions for this (RDxxxx and WRxxxx where xxxx = BYTE, WORD, or LONG).

    Ok, so now I know..... Spin = hub ram (for the most part except the special registers)
    Pasm = cog ram unless written back to the hub with wr**** (Long, Word, Byte).

    That really helps clarify some of the misunderstandings I have had in the past about addresses, parameter passing and such.

    It's amazing I can play with the propeller for so long, and still didn't grasp some of this.........

    I see, that depending on what the newly started cog is using (Spin/Pasm), determines how the information would need to be handled. If using spin, the item would already be in hub ram. If using Pasm, it would have to be written to the hub ram.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!

    Post Edited (James Long) : 1/4/2010 9:31:24 PM GMT
  • SamMishalSamMishal Posts: 468
    edited 2010-01-04 21:36
    James,

    When running cogs with PASM code then for all intents and purposes the 8 cogs are 8 SEPARATE and INDEPENDENT microprocessors that are able to SHARE a central EXTERNAL (from the point of view of the cog) RAM. Each cog of course, just like a true mini-microcontroller, has its own personal seperate and independent RAM too.
    ·
    Also as far as each cog is concerned the I/O pins are separate too (each cog has it sown DirA and OutA and InA registers). However, the I/O pins are tied to each cog using OR gates from each cog’s registers….so they appear as shared….but by Oring them. Also each cog has its own independent and separate counters….but are synchronized since they share the same clock.
    ·
    So in PASM you can think of the HUB RAM as an External RAM where all the cogs share the same Data and Address Bus and where the read/write operations are automatically resolved for contention…..but….it is still and EXTERNAL memory that the cog (mini-microprocessor) can write to and read from using the RdLong and WrLong op-codes (or word or byte).
    ·
    On the other hand when running SPIN you can think of the 8 cogs not as separate processors but rather as 8 THREADS (like on a computer) where the threads can do things in parallel and independently…..but…..they all are sharing the same memory and that is the ONLY memory they have. (Counters are still separate and I/O registers too are still separate ie. DirA OutA and InA….but again tied by Oring)
    ·
    When writing SPIN code you do not need special instructions to access the HUB RAM, that is the ONLY RAM you have any way. HOWEVER, you do need the ADDRESS of the RAM area you need to access.
    ·
    If the RAM area is OWNED by the cog due to being started from an object that has its own VAR and DAT variables then you do not even need the addresses you just access the memory using the NAMES of the variables.
    ·
    But….if you are going to SHARE memory areas between cogs then ONE cog owns the memory and has NAME access to it….but the other Cogs need to be given the ADDRESS to that memory in order to be able to access that agreed upon SAME MEMORY.
    ·
    Another mechanism for sharing memory between cogs running SPIN is to use GET and SET METHODS within the object and then the OBJECT’s GET/SET methods are called from other COGS (objects) to access the private VARs of the object.
    ·
    Any variables declared in the VAR section of an object are private to the object and if you have multiple instances of the object you get multiple copies of these variables and are not the same variables and they occupy different areas in the Hub Ram....
    ·
    However, variables declared in the DAT section are not duplicated and therefore are sharable and is another way to share the same memory area (TRICK). Although, this only works for multiple instances of the same object, not between different objects.
    ·
    ·


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Samuel

    www.RobotBASIC.com


    Post Edited (SamMishal) : 1/4/2010 9:44:12 PM GMT
  • kwinnkwinn Posts: 8,697
    edited 2010-01-04 22:23
    Being somewhat visually oriented I made myself a block diagram of the architecture and data flow when I first started with the prop. Hope it helps.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-01-04 22:46
    kwinn,

    Your diagram is okay except for one thing: each cog has independent access to the I/O pins. That access does not go through the hub.

    -Phil
  • James LongJames Long Posts: 1,181
    edited 2010-01-04 23:03
    kwinn said...
    Being somewhat visually oriented I made myself a block diagram of the architecture and data flow when I first started with the prop. Hope it helps.

    I understand the flow, what I didn't understand was the cog ram/hub ram relationship. That being that for the most part in Spin there is no cog ram control (except for the special registers).

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • SamMishalSamMishal Posts: 468
    edited 2010-01-05 00:04
    James Long said...
    Ok, so now I know..... Spin = hub ram (for the most part except the special registers)
    Pasm = cog ram unless written back to the hub with wr**** (Long, Word, Byte).

    That really helps clarify some of the misunderstandings I have had in the past about addresses, parameter passing and such.

    It's amazing I can play with the propeller for so long, and still didn't grasp some of this.........

    I see, that depending on what the newly started cog is using (Spin/Pasm), determines how the information would need to be handled. If using spin, the item would already be in hub ram. If using Pasm, it would have to be written to the hub ram.
    You must have written this while I was writing mine....well....mine was a waste of time then.cry.gif ...
    because it seems you now have it EXACTLY RIGHT.....jumpin.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Samuel

    www.RobotBASIC.com
    ·
  • James LongJames Long Posts: 1,181
    edited 2010-01-05 00:15
    SamMishal said...
    James Long said...


    Ok, so now I know..... Spin = hub ram (for the most part except the special registers)
    Pasm = cog ram unless written back to the hub with wr**** (Long, Word, Byte).

    That really helps clarify some of the misunderstandings I have had in the past about addresses, parameter passing and such.

    It's amazing I can play with the propeller for so long, and still didn't grasp some of this.........

    I see, that depending on what the newly started cog is using (Spin/Pasm), determines how the information would need to be handled. If using spin, the item would already be in hub ram. If using Pasm, it would have to be written to the hub ram.
    You must have written this while I was writing mine....well....mine was a waste of time then. cry.gif ...
    because it seems you now have it EXACTLY RIGHT..... jumpin.gif

    No problem.....I'll take any help I can get. There are a few things which always give me a problem when doing programming on the propeller. Passing addresses is one of them. I just don't program enough to get real good at it. I wish I had more time to program, but other things get in the way.

    I'm getting ready to finish the programming on a big project, maybe that will help me "burn" some of this to memory.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • kwinnkwinn Posts: 8,697
    edited 2010-01-05 02:42
    @PhiPi True, the pins are or'ed together, and I was aware of that when I drew the diagram but there was no clear simple way to show that. That is why I put the dashed line through the center of the hub block to remind me that it did not really go "through" the hub.
Sign In or Register to comment.