prop programming question

jchuchla

Supporting Member
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--
 
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:
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?
 
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.
 
Back
Top