Results 1 to 5 of 5

Thread: prop programming question

  1. #1
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,664
    Post Thanks / Like

    Default prop programming question

    I've been programming various stuff for years, but this is my first propeller project. I'm having some issue with what seems to be fairly basic math. I've been playing with this for 3 nights now and I think i'm stuck. I have a feeling that this has something to do with sign extension or variable size conversion. it seems to have issues with negatives. the odd thing is it works for some color combinations, but not others.

    I'm working on Jim's e681 platform, and using his 2.06 source code as a starting point. I'm adding in code for user customizable internal patterns for basic stuff, for those of us who aren't ready for sequencing yet.

    what i'm trying to do with this is a fading chase.
    If i have a pattern of Red Green Blue White, it would be stored in PatColor as 255 0 0 0 255 0 0 0 255 255 255 255 my code seems to work with this combination.
    If I use Green, Lt Green, White, Lt Green i'm using 0 255 0 64 255 64 255 255 255 64 255 64. this is giving weird problems because the fades seem to sometimes go in the wrong direction and roll over the byte size limits.

    PatColor is a BYTE array of 12 bytes that store R G B values (0-255) for up to 4 pixels. this is the user defined parameters
    PatTempColor is a byte array of 15 bytes that store the same as above, but is larger by one pixel. this is used to do the shift and rotate, e.g. move everything right by 3 and copy bytes 12-14 to 0-2
    these first two will always hold a positive value from 0-255.
    patBlendDelta is a array of 12 LONGs, it stores the difference of each color channel of a pixel, with the same color channel of the next pixel, and divided by the number of steps. this should be a number between -255 and +255.
    then i take this number and multiply by the current step. and add it to the PatTempColor variable.



    here's the relevant declarations:
    Code:
            BYTE          PatColor[12]         '**JC** colors for pattern pixels (R1 G1 B1 R2 G2 B2 etc...)
            BYTE          PatPixels            '**JC** number of pixels to include in the pattern 1-4        
            BYTE          PatFirstRun           'flag to test if it's the first time thru the pattern
            BYTE          PatRGBctr             'used for counting thru 3 colors of each pixel
            BYTE          PatPixCtr             'used for counting thru up to 4 pixels used in a pattern         
            BYTE          PatStepCtr            'used for counting steps in a pattern AND for intermediate delay steps to skip pattern logic while checking webserver 
            BYTE          PatTempColor[15]      'used for chasing pattern
            LONG          PatBlendDelta[12]     'temp array used for fading chase patterns
            BYTE          PatBlendTemp[12]      'temp used for fading chase patterns
    and the code section:
    Code:
          PatSteps:=16                     'constant for testing, number of fade steps 
          IF PatFirstRun==1               'check first run flag to initialize pattern for first iteration.
            PatSetPixels(0)               'copy color params into dmx buffer and fill. 
            PatStepCtr:=0                 'init step counter.
            ByteMove(@PatTempColor,@PatColor,PatPixels*3)   'copy pixel color parameters to temp buffer
          
          case PatStepCtr
            0:
              bytemove(@PatTempColor+3,@PatTempColor,PatPixels*3) 'shift pattern colors right 1px in temp buffer
              ByteMove(@PatTempColor,@PatTempColor+PatPixels*3,3) 'copy last position into first. aka rollover
              debug.str(string(CR,CR,"PatTempColor: "))
              repeat _temp from 0 to (PatPixels*3)-1
                debug.str(string(" "))
                debug.dec(PatTempColor[_temp])
              debug.str(string(CR,"PatBlendDelta: ")) 
              repeat PatPixCtr from 0 to (PatPixels*3)-1
                PatBlendDelta[PatPixCtr]:=(PatTempColor[PatPixCtr]-PatTempColor[PatPixCtr+3]) / PatSteps  'get color difference for each color on all px and divide by number of steps and store in blenddelta array
                debug.str(string(" ")) 
                debug.dec(~PatBlendDelta[PatPixCtr])
              PatStepCtr++               'increment to next step
            1..PatSteps:
              debug.str(string(CR,"Step: ")) 
              debug.dec(PatStepCtr)
              repeat PatPixCtr from 0 to (PatPixels*3)-1
                  PatBlendTemp[PatPixCtr]:=PatTempColor[PatPixCtr]-(PatBlendDelta[PatPixCtr] * PatStepCtr) 'add  blendDeltaValue * step number to previous color value and store in BlendTemp array
                  debug.str(string(" "))                                                         
                  debug.dec(PatBlendTemp[PatPixCtr])
              
              ByteMove(@DMXbuffer,@PatBlendTemp,PatPixels*3)  'copy blendtemp array into first set of pix in dmxbuffer          
              PatFillPixels(0)           'Fill rest of buffer from first bytes
              pausemsec(PatStepTime)     'delay pause to slow fade steps
              PatStepCtr++               'increment to next step
            OTHER:
              ByteMove(@DMXbuffer,@PatTempColor,PatPixels*3) 'copy temp buffer to dmxbuffer for full pix values before moving to next pixel.
              PatFillPixels(0)            'Fill rest of buffer from first bytes       
              pausemsec(PatDwellTime*10)  'delay pause before next fade sequence.      
              PatStepCtr:=0               'increment to next step
    Thanks in advance for your help

    --Jon--

  2. #2
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: prop programming question

    Instead of bytemove to rotate pixel colors, have you tried bitwise Rotate Right (‘->’, ‘->=’) it would save on a buffer and would likely speed things up a bit. That won't solve your issue but I thought it was worth mentioning.
    Last edited by DynamoBen; 09-17-2012 at 11:27 AM.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  3. #3
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: prop programming question

    Are you accounting for this?

    The Propeller is "little-endian" with the least significant byte of a word or long value coming first in memory.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  4. #4
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,664
    Post Thanks / Like

    Default Re: prop programming question

    Thanks Ben for looking at this. It's been driving me crazy. (i didn't realize i'm not allowed to bump my own threads here) This is my first venture into programming on the microcontroller level, so i'm a bit out of my element. Most of my experience has been in higher level languages, so i'm not used to accounting for all the little things.
    I haven't considered (nor know how to use) the bitwise rotate left function. I'll have to take a look into that to see if it'll speed things up. I did start many of these bytemove sections as repeat loops, but then after discovering the bytemove command, i converted to bytemove, and many things got simpler and faster.
    I haven't considered for the little-endian nature of the prop. I have to admit, that's above my head at the moment (though the whole point of this excercise is for self enrichment) Can you explain how this comes into play?

  5. #5
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: prop programming question

    Quote Originally Posted by jchuchla View Post
    Thanks Ben for looking at this. It's been driving me crazy. (i didn't realize i'm not allowed to bump my own threads here) This is my first venture into programming on the microcontroller level, so i'm a bit out of my element. Most of my experience has been in higher level languages, so i'm not used to accounting for all the little things.
    Understood, and here the little things make a big difference. Over time it will make you a better programmer in the higher level languages. (wait until you do ASM)

    I haven't considered (nor know how to use) the bitwise rotate left function. I'll have to take a look into that to see if it'll speed things up. I did start many of these bytemove sections as repeat loops, but then after discovering the bytemove command, i converted to bytemove, and many things got simpler and faster.
    Both ways get the job done, in retrospect rotate left won't work because you are doing it across an entire buffer. In my head I was thinking it was across a single long.

    I haven't considered for the little-endian nature of the prop. I have to admit, that's above my head at the moment (though the whole point of this excercise is for self enrichment) Can you explain how this comes into play?
    Check out this thread.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •