Shop OBEX P1 Docs P2 Docs Learn Events
cognew and vga output question — Parallax Forums

cognew and vga output question

waltsailingwaltsailing Posts: 40
edited 2011-01-29 23:01 in Propeller 1
Hi,

Here is my code, see below, sorry i dont know how to upload this as code, so i pasted it in, new to the propeller here. This is the problem.

I wrote two routines called updatevga and updatevga1, both operate on seperate variables, i and j.

If i run these, individually, or in the first loaded cog, without cognew, the program works fine. Individually they work in cognew also. But if I try to run these two in two different cogs, I get a mess on the screen. Both are accessing the same vga device. What I want to do is to update the screen at two different locations from two different Cogs. Is this possible or should I just have one cog do the screen updates. Seems to be getting out of wack results on the screen. This is part of a larger program that multiplexes multiple serial data sources in, so i just got it down to the root of this problem. Any suggestions or help would be great.

Thanks,
Walt,

''***************************************
''* VGA Text Multi Question Program *
''***************************************

CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000



VAR
long i
long j

long stack[200]
long stack1[200]


OBJ

text : "vga_text"


Pub start
i:=10
j:=10000
'start term
text.start(16)
text.str(string(13,"MR BIGGS IS A CAT",13,"TEST message to VGA .. ",13,13,$C,5))


cognew(updatevga,@stack) ' comment this line out

cognew(updatevga1,@stack1) ' or comment this line out




pub updatevga
repeat
text.str(string($A,12,$B,14))
text.hex(i++, 8)
pub updatevga1
repeat
text.str(string($A,12,$B,12))
text.hex(j++, 8)

{{
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ TERMS OF USE: MIT License │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │
│files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │
│modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│
│is furnished to do so, subject to the following conditions: │
│ │
│The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│
│ │
│THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │
│WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │
│COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │
│ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
}}

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2011-01-29 20:18
    The main problem is that the display device isn't designed for concurrent access. Basically one update cog interferes with the other. This is where locks can be useful to serialise the output. The following example should resolve your issue (untested due to lack of VGA screen).

    Also, code should be posted within [noparse]
    
    [/noparse] tags.
    
    CON
      _clkmode = xtal1 + pll16x
      _xinfreq = 5_000_000
    
    VAR
      long i
      long j
    
      long stack[200]
      long stack1[200]
    
      [COLOR="red"]long  lock[/COLOR]
    
    OBJ
    
      text : "vga_text"
    
    Pub start
    
      i:=10
      j:=10000
      'start term
      text.start(16)
      text.str(string(13,"MR BIGGS IS A CAT",13,"TEST message to VGA .. ",13,13,$C,5))
    
      [COLOR="red"]lock := locknew[/COLOR]
      
      cognew(updatevga,@stack) ' comment this line out
      cognew(updatevga1,@stack1) ' or comment this line out
    
    pub updatevga
    
      repeat
        [COLOR="red"]repeat while lockset(lock)[/COLOR]
        text.str(string($A,12,$B,14))
        text.hex(i++, 8)
        [COLOR="red"]lockclr(lock)[/COLOR]
        
    pub updatevga1
    
      repeat
        [COLOR="red"]repeat while lockset(lock)[/COLOR]
        text.str(string($A,12,$B,12))
        text.hex(j++, 8)
        [COLOR="red"]lockclr(lock)
    [/COLOR]
    DAT
    
  • waltsailingwaltsailing Posts: 40
    edited 2011-01-29 20:47
    Hi,

    lock = locknew

    I changed the line above to be lock := locknew , which let it run as expected. Thank you.

    Walt,
    lock: = locknew
    
  • kuronekokuroneko Posts: 3,623
    edited 2011-01-29 20:48
    Ouch, sorry about that. Need more coffee! I also edited the code section.
  • waltsailingwaltsailing Posts: 40
    edited 2011-01-29 21:17
    Thanks

    It works pretty good. The vga screen is just a cheap 19 inch Insigna flatscreen TV with a vga cable. Much easier than any LCD display and you can just plug it right into the Demo board. This is amazing for putting outputs out for debugging.

    Anyways, i modified the program to see how this would work, and got a slightly different issue. Just trying to understand exactly what is going on here. So i put in a difference between the i and j which are being incremented in each seperate cog. The code is identical from that i can tell, other than a couple of different positions on the screen. But the difference between i and j will tend to change, and drift up. What started out as a difference of 9999 between the two starting values, is growing, and after a few minutes, it ends up as high as 10250... and changing a few minutes later it was at 10140. Sometimes it drifts downwards. Is this a sampling issue with the cogs spining around, who ever gets to the lock, can end up with it twice in a row, sometimes? There must be some slight difference in the processing time in the two routines when they are down in their subroutines.. Likely due to the jmps with different branch timing. I am guessing here. But maybe someone can explain this.

    Thank You,
    Walt,
    CON
      _clkmode = xtal1 + pll16x
      _xinfreq = 5_000_000
    
    VAR
      long i
      long j
       long k
      long stack[200]
      long stack1[200]
    
      long  lock
    
    OBJ
    
      text : "vga_text"
    
    Pub start
    
      i:=1
      j:=10000
      k:=00
      'start term
      text.start(16)
      text.str(string(13,"MR BIGGS IS A CAT",13,"TEST message to VGA .. ",13,13,$C,5))
    
      lock:= locknew
      
      cognew(updatevga,@stack) ' comment this line out
      cognew(updatevga1,@stack1) ' or comment this line out
      
      
    pub updatevga
    
      repeat
        repeat while lockset(lock)
        text.str(string($A,12,$B,14))
        text.hex(i++, 8)
        text.str(string($A,12,$B,10))
        k:=j-i
        text.dec(k)
        lockclr(lock)
        
    pub updatevga1
    
      repeat
        repeat while lockset(lock)
        text.str(string($A,12,$B,12))
        text.hex(j++, 8)
        text.str(string($A,12,$B,8))
        k:=j-i
        text.dec(k)
        lockclr(lock)
    
    DAT
    
  • waltsailingwaltsailing Posts: 40
    edited 2011-01-29 21:25
    no problem on the = vs :=. I dont understand programming language design syntax rules sometimes... Why not just take in = or :=, most people who program know that the = works for assignment. The = works in the con section. I am sure there is a good reason for := vs = but I just dont get it yet.

    Thanks,
    Walt,
  • kuronekokuroneko Posts: 3,623
    edited 2011-01-29 21:47
    Regarding drifting delta, the most likely reason (without actually looking at the code involved) are minor differences in runtime (one more loop cycle here, some special case handling there). If this irks you you could try sync'ing both cogs to a specific cnt sequence, e.g. each cog displays once a second but cog two has an offset of 1/2 a second.
    cog one: 1     2     3     sec
    cog two:   3/2   5/2   7/2 sec
    
  • kuronekokuroneko Posts: 3,623
    edited 2011-01-29 23:01
    I don't know where you're going with your update methods but you could just let them update their respective variables (no display) and delegate the display functionality to a 3rd cog which then doesn't require a lock as it's the only one accessing the display device.
    • cog A: write/update variable A
    • cog B: write/update variable B
    • cog C: read/display variables A and B
Sign In or Register to comment.