PCA9685 control

[Tabsoft]

Have you thought of using a Flag variable?
During your checking routine, set a Flag if you need to write to the PCA.
Check the Flag to determine if you need to do the gosub to write to the PCA chip.

[Scampy]

Have you thought of using a Flag variable?
During your checking routine, set a Flag if you need to write to the PCA.
Check the Flag to determine if you need to do the gosub to write to the PCA chip.

Can't get my head round it, at least because the condition at which the PCA get written to will be true.

I thought of

If Counter1 => CH1_on_Time and counter1 < CH1_off_time then                     ' check to see if the time in minutes since midnight matches the Channel on time
CH1_PWM  = fadeset1
flag=1  
endif

with a IF Flag=1 then gosub update... but that would still cause the update subroutine to be updated on each pass of the loop...

[tumbleweed]

Instead of just setting a flag, keep a copy of the last thing written to the PCA and only call the sub if it's different from CH1_PWM

If Counter1 => CH1_on_Time and counter1 < CH1_off_time then                     ' check to see if the time in minutes since midnight matches the Channel on time
CH1_PWM  = fadeset1                                                             ' and of so set the PWM value (0 to 4095) to match the fadeset value (also 0 - 4095)
endif                                                                           
If Counter1 => CH1_off_Time or Counter1 < CH1_on_time then                      ' check to see if the time in minutes since midnight matches the channel off time
CH1_PWM  =0                                                                     ' and if it does, then set the PWM value to 0, this turning the channel off
endif
...
' check to see if CH1_PWM is different from last programmed value
if (CH1_PWM <> PCA_PWM) then
    gosub SetPCA
endif



SetPCA:
    PCA_PWM = CH1_PWM
    pcaChannel = 0                                            
    i2cControl = $6 + 4*pcaChannel                            
    I2CWRITE SDApin,SCLpin,i2cWriteAddress,i2cControl,[0,0,PCA_PWM.lowbyte,PCA_PWM.highbyte]
    return

[Scampy]

Instead of just setting a flag, keep a copy of the last thing written to the PCA and only call the sub if it's different from CH1_PWM

If Counter1 => CH1_on_Time and counter1 < CH1_off_time then                     ' check to see if the time in minutes since midnight matches the Channel on time
CH1_PWM  = fadeset1                                                             ' and of so set the PWM value (0 to 4095) to match the fadeset value (also 0 - 4095)
endif                                                                           
If Counter1 => CH1_off_Time or Counter1 < CH1_on_time then                      ' check to see if the time in minutes since midnight matches the channel off time
CH1_PWM  =0                                                                     ' and if it does, then set the PWM value to 0, this turning the channel off
endif
...
' check to see if CH1_PWM is different from last programmed value
if (CH1_PWM <> PCA_PWM) then
    gosub SetPCA
endif



SetPCA:
    PCA_PWM = CH1_PWM
    pcaChannel = 0                                            
    i2cControl = $6 + 4*pcaChannel                            
    I2CWRITE SDApin,SCLpin,i2cWriteAddress,i2cControl,[0,0,PCA_PWM.lowbyte,PCA_PWM.highbyte]
    return

thanks, that seems logical as the only change will be if the ON or OFF condition is met. Thanks, I'll give that a try

[Scampy]

It must be something to do with the internals of the PCA chip as the modified code that includes Tumbleweed's suggestion has the same effect, even though the PIC code isn't running the subroutine (I have a led that is lit whilst the sub routine is being accessed and that pulses once when the lights come on, and once again when the lights go off)

Would there be anything to gain if the code in the SetPCA: section above is placed in the check section like this

If Counter1 => CH1_on_Time and counter1 < CH1_off_time then                     ' check to see if the time in minutes since midnight matches the Channel on time
CH1_PWM  = fadeset1                                                             ' and of so set the PWM value (0 to 4095) to match the fadeset value (also 0 - 4095)
endif                                                                           
If Counter1 => CH1_off_Time or Counter1 < CH1_on_time then                      ' check to see if the time in minutes since midnight matches the channel off time
CH1_PWM  =0                                                                     ' and if it does, then set the PWM value to 0, this turning the channel off
endif
...
' check to see if CH1_PWM is different from last programmed value
if (CH1_PWM <> PCA_PWM) then
PCA_PWM = CH1_PWM
    pcaChannel = 0                                            
    i2cControl = $6 + 4*pcaChannel                            
    I2CWRITE SDApin,SCLpin,i2cWriteAddress,i2cControl,[0,0,PCA_PWM.lowbyte,PCA_PWM.highbyte]    
endif

[tumbleweed]

Would there be anything to gain if the code in the SetPCA: section above is placed in the check section like this

It'll save you the call/return (so slightly less time/code), but it won't really change the timing much in the grand scheme of things.

If the flicker is caused by writing too often to the PCA it won't change that at all.

[Scampy]

I took delivery of a logic analyser today and thought I would test it to see what the outputs are like at different brightnesses. I've got some really strange traces and wondered if anyone has any ideas as to why the PCA chip is behaving like this.

I set the brightness to 10%, and did a scan and this was the result



I was expecting to see eight traces the same as channel 7 at the bottom, but the other channels seems to have a strange artefact, so I zoomed in to see if it was just something to do with the way the traces were being displayed on the screen, but this was the result



The "normal" pulse was itself split up into a series of multiple pulses, so I zoomed in again and took a measurement



I have no idea what's happening, and I still can't find any evidence of the chip refreshing momentarily once a second which would tie in with the regular 1sec flicker that is noticeable to the eye