Shop OBEX P1 Docs P2 Docs Learn Events
General question about cogs, methods, and objects — Parallax Forums

General question about cogs, methods, and objects

yamazukiyamazuki Posts: 8
edited 2010-06-24 07:22 in Propeller 1
The way I understand the propeller is that:
--Simply put it is 8 processors on one chip, each has its own memory (2K)
--each cog has access to hub memory (32K)
--if a program (obj, method, whatever) is run in spin, the cog loads the spin interpreter into its 2k of memory and runs the spin code, which is stored in hub memory.
--if a cognew command is sent with an address of asm code, the new cog will load the asm code (into cog memory) and run independently of all other cogs and cannot be affected by the other 7......

the last one is what has me stumped.....I can load a cog, one cog, and have my method run flawlessly. However, when I load a second cog with an entirely different batch of asm from a different object.....the first, which is time sensitive, stops working as intended......
The second cog is doing a "rdlong" from hub memory, but the first is only being used to toggle the high low state of output pins based on button press combinations.....

example: cog 1,
--test the state of 1 pin (pin 0)
--test 3 other pins to see if they are high.
----if none of these 3 pins are high, match output on pin (pin 1) to input of pin 0
----If one of these 3 pins are high, read hub memory and output bit sequence on pin 1, these sequences are stored in hub memory as individual longs

****this works perfectly when loaded on its own*****

cog 2,
simply measure the state of 3 inputs (momentary buttons) and toggle the state of 5 other pins based on the combination of buttons pressed, only one of the pins toggled by the first cog is tested by the second

****this also works correctly when run alone****

If I do a simple:

Pub Go

Power.power(param1, param2)
display.display(param1, param2)

as my top object, with 2 other objects:
object 1
Pub Power(param1, param2)

cognew(@whatever, 0)

Dat

whatever org
ect

and
object 2
Var
long mydata[noparse][[/noparse]32]

Pub Display

cognew(@somthing_or_other, @my_data)

Dat

Something_or_other org
ect


everything gets messed up

if the cogs run independently from one another, why is this happening?
confused.gifconfused.gif

Post Edited (yamazuki) : 6/23/2010 6:46:21 AM GMT

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2010-06-23 06:55
    @yamazuki: Firstly, welcome to this fantastic forum.

    The two cogs will indeed run separately. Your explanation of the cogs and hub are excellent. Remember, if more than one cog output to the same pin, the combination will be an OR of the two cog pins (there cannot be a hardware conflict). So there must be a bug in your code, or something which interacts between then via the pins.

    One problem with posting your code is that the forum software messes up your code listing. So, use the "Post Reply" button, not the "Quick Reply" box. You will see a set of additional icons. One of those is for posting code within the thread. You can also attach your code. Zip the project up with PropTool and post this. That way, we can try your code and find the bug or at least point you in the right direction.

    Can you please repost the code and we will see if we can find your problem.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • yamazukiyamazuki Posts: 8
    edited 2010-06-23 07:55
    As requested here are the spin files associated with my dilemma (the "power control" object is not complete but the result is the same). If I posted the code, it would be lengthy.....

    I'm sure there are more efficient ways to write these but for now, this is what I know

    The issue is that when the "Display Control" object comes around to read the second long of memory, the data is getting corrupted and there is a good 1/2 second pause in the output of that data to my display when the "power control" object is running......when "display control" is run by itself, there is no noticeable delay in the output to the display(other than what was intentionally placed there)

    FWIW.....I've read on here to always use the "cognew" but i prefer the "coginit"......I have verified that cognew in this case makes no difference with the problem i am experiencing, the result is the same.

    This has been an on going issue for me for about the last six weeks.....I have written and re-written these programs probably 50 times now, trying different tactics and learning as I go, I've read just about everything I can find on the prop and asm, tutorials, ect, but this I just can't seem to get by on my own......

    Needless to say, I'm tired and frustrated! smile.gif I am also stubborn, but we're just about to the point of finding out how well my propeller flies.......out the window that is! shocked.gif

    Post Edited (yamazuki) : 6/23/2010 8:03:51 AM GMT
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-06-23 10:06
    Here is one possibility...

    Out_Mt2······ =············· 28······················ 'mute pin 2

    This is the EEPROM pin and possibly an issue.

    The way you are setting the parameters in Power_Control is unconvenctional but should be ok nevertheless. However, this code goes into an endless loop which does nothing (:loop) as the source values will never change within this loop. They reside within the cog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • kuronekokuroneko Posts: 3,623
    edited 2010-06-23 13:07
    yamazuki said...
    The issue is that when the "Display Control" object comes around to read the second long of memory, the data is getting corrupted and there is a good 1/2 second pause in the output of that data to my display when the "power control" object is running......when "display control" is run by itself, there is no noticeable delay in the output to the display(other than what was intentionally placed there)
    I have a hard time with that corruption thingy. SPIN cog 0 exits and only the 2 PASM cogs stay alive. Nothing is using wrxxxx so maybe I'm just misunderstanding the issue here. Is it that you get unexpected data?

    The only difference the power cog makes is that it sets 7 bits to output ($0000_076C) but only drives 6 of them high ($0000_072C). AFAICS this stays well away from the display cog except that the latter monitors one of the power pins. So maybe take a step back and start with an endless loop in the power cog doing nothing, then enable/drive one power line at a time or something along those lines.
  • bill190bill190 Posts: 769
    edited 2010-06-23 14:30
    Perhaps this is what is going on?

    Following from propeller data sheet (page 7)...

    4.4. Hub
    To maintain system integrity, mutually-exclusive resources must not be accessed by more than one cog at a time. The Hub controls access to mutually-exclusive resources by giving each cog a turn in a “round robin” fashion from Cog 0 through Cog 7 and back to Cog 0 again. The Hub and its bus run at half the System Clock rate, giving a cog access to mutually-exclusive resources once every 16 System Clock cycles. Hub instructions, the Propeller Assembly instructions that access mutually-exclusive resources, require 7 cycles to execute but they first need to be synchronized to the start of the Hub Access Window.

    It takes up to 15 cycles (16 minus 1, if we just missed it) to synchronize to the Hub Access Window plus 7 cycles to execute the hub instruction, so hub instructions take from 7 to 22 cycles to complete...
  • yamazukiyamazuki Posts: 8
    edited 2010-06-23 19:40
    bill190 said...
    Perhaps this is what is going on?

    Following from propeller data sheet (page 7)...

    4.4. Hub
    To maintain system integrity, mutually-exclusive resources must not be accessed by more than one cog at a time. The Hub controls access to mutually-exclusive resources by giving each cog a turn in a “round robin” fashion from Cog 0 through Cog 7 and back to Cog 0 again. The Hub and its bus run at half the System Clock rate, giving a cog access to mutually-exclusive resources once every 16 System Clock cycles. Hub instructions, the Propeller Assembly instructions that access mutually-exclusive resources, require 7 cycles to execute but they first need to be synchronized to the start of the Hub Access Window.

    It takes up to 15 cycles (16 minus 1, if we just missed it) to synchronize to the Hub Access Window plus 7 cycles to execute the hub instruction, so hub instructions take from 7 to 22 cycles to complete...

    I can understand this as a possibility....but the hub is in control of this......even if it takes 22 cycles that should not be anywhere close to the 5_886_340 clock ticks before the idle period ends.......or is it??
  • yamazukiyamazuki Posts: 8
    edited 2010-06-23 19:46
    kuroneko said...
    yamazuki said...
    The issue is that when the "Display Control" object comes around to read the second long of memory, the data is getting corrupted and there is a good 1/2 second pause in the output of that data to my display when the "power control" object is running......when "display control" is run by itself, there is no noticeable delay in the output to the display(other than what was intentionally placed there)
    I have a hard time with that corruption thingy. SPIN cog 0 exits and only the 2 PASM cogs stay alive. Nothing is using wrxxxx so maybe I'm just misunderstanding the issue here. Is it that you get unexpected data?

    The only difference the power cog makes is that it sets 7 bits to output ($0000_076C) but only drives 6 of them high ($0000_072C). AFAICS this stays well away from the display cog except that the latter monitors one of the power pins. So maybe take a step back and start with an endless loop in the power cog doing nothing, then enable/drive one power line at a time or something along those lines.

    Correct. Data is not what is stored in the variabe at the beginning of the object.
    I have also done as you suggested....as I 'or' the pins high...when I get to the 5th pin is where the issues begin...the actual pin or its number make no difference....but the quanity of pins does.....
    Also noted that data from the monitored pin in display does not match the input pin when 5 or more pins are high by power.....
  • yamazukiyamazuki Posts: 8
    edited 2010-06-23 19:52
    Cluso99 said...
    Here is one possibility...

    Out_Mt2 = 28 'mute pin 2

    This is the EEPROM pin and possibly an issue.

    The way you are setting the parameters in Power_Control is unconvenctional but should be ok nevertheless. However, this code goes into an endless loop which does nothing (:loop) as the source values will never change within this loop. They reside within the cog.

    Currently the out_mt2 is being used as a simple place holder. Prop tool will not compile without there being a value there.. all constants that I will need were listed so I can see what I am working with...sometimes I'm easily confused!!!

    Unconvential you say?? I was unaware of any other way to set aside fom lising in each individual object....which would only confuse me more....or atleast open up more chances for error on my part. Can you suggest a better method??

    Power here was also done merely for testing....it was here that I found the more pins that I set high...the slower things went......therefore the endless loop of do nothing except keep those pins high
  • kuronekokuroneko Posts: 3,623
    edited 2010-06-24 01:23
    yamazuki said...
    I have also done as you suggested....as I 'or' the pins high...when I get to the 5th pin is where the issues begin...the actual pin or its number make no difference....but the quanity of pins does.....
    Also noted that data from the monitored pin in display does not match the input pin when 5 or more pins are high by power.....
    I assume there is some h/w connected to those "power" pins. You said that the display cog runs fine on its own. What happens when you disconnect the power pins but still run the power cog (i.e. have the pins set high but not affecting anything off-prop)? It seems to me that the connected h/w - when powered - has a negative side effect.
    • display cog on its own works (equivalent to unpowered h/w)
    • display and power cog together have issues (h/w is powered)
    • display and power cog together but h/w disconnected (should be equivalent to point 1) ???
    Out of curiosity, when you say 5 pins or more, did these always include Pwr_V1 (the only link to the display cog) or is it really just the pin count?
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-06-24 01:41
    The convenctional way is to pass a pointer (which is loaded into PAR). This pointer points to a hub location where a list of parameters resides. The cog program usually fetches these parameters on startup. See FullDuplexSerial. BTW, this is sort of what you are doing with the Display cog.

    The hub window (as quoted by bill190) is only relevant for hub access. It has no bearing on each cog's local DIRA, OUTA and INA, etc. As I said above, if more than 1 cog sets a DIR pin as output, then the pin will be an output and the output level will be an OR between these cog's OUT pin value (i.e. if any =1, then a =1 will be output), and there can be no hardware conflict. Any cog can read this pin using IN.

    Without going through the code closely, I suggest you minimise each cog to just output a single pin and build up from there. As you add back some code, hopefully you will find the bug. It is usually the simplest bugs that stump us because we tend to overlook the simplest steps and read into it something that isnt there. Often explaining each step to someone can help you find your own problem.

    I am really trying to help without having to load your program and debug it as I currently have other things I must do. Maybe someone else can find the time, or I will help a little later.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • yamazukiyamazuki Posts: 8
    edited 2010-06-24 02:35
    Cluso99 said...
    The convenctional way is to pass a pointer (which is loaded into PAR). This pointer points to a hub location where a list of parameters resides. The cog program usually fetches these parameters on startup. See FullDuplexSerial. BTW, this is sort of what you are doing with the Display cog.

    The hub window (as quoted by bill190) is only relevant for hub access. It has no bearing on each cog's local DIRA, OUTA and INA, etc. As I said above, if more than 1 cog sets a DIR pin as output, then the pin will be an output and the output level will be an OR between these cog's OUT pin value (i.e. if any =1, then a =1 will be output), and there can be no hardware conflict. Any cog can read this pin using IN.

    Without going through the code closely, I suggest you minimise each cog to just output a single pin and build up from there. As you add back some code, hopefully you will find the bug. It is usually the simplest bugs that stump us because we tend to overlook the simplest steps and read into it something that isnt there. Often explaining each step to someone can help you find your own problem.

    I am really trying to help without having to load your program and debug it as I currently have other things I must do. Maybe someone else can find the time, or I will help a little later.

    And all your help, everyone's help, is greatly appreciated!! When I got the propeller, I had only worked with the Basic Stamp briefly before I realized it was not capable of doing what I wanted it to. Prior to that, no microchip experience. One of the biggest reasons for me choosing to stay with a Parallax product, specifically the Propeller was the excellent documentation and knowing that this forum was here if I got to a point where I was at a total loss.

    So once again, thank you all!

    As you also mentioned, it is the simplest things that stump us the most! The previous post by "kuroneko" actually helped solve my issue! During my code writing process here, the only thing that I have been powering off of these power pins has been LED's...since I wanted to make sure the code was solid before I found out that I had somehow wired something incorrectly or added the hardware variable into things. The only things that were actually connected were the display unit and the component that is sending the majority of the data to that display. In essence, the prop is interrupting that data to send alternate data based on inputs from 2 other devices, but only when there is a need to.

    I work in service and all day people call and ask for advise on how to fix something....we go back to the basics.....they tell us that part is fine and won't try it. So, despite the fact that I felt there was no way my LED's could be affecting this (I was correct about the LED's as they are connected again) I figured I would strip my breadboard and re-connect everything......not entirely sure what was causing the issue (since I just pulled everything off the board and started over) but once everything was reconnected.....Everything works as intended. Somewhere, I had created my own hardware issue without realizing it and with minimal and trivial components.
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-06-24 07:22
    I am pleased you have found your problem smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Sign In or Register to comment.