Stuck on porting code to 18F4520

[Scampy]

Tried that and the steps are too much, almost rising in 5% increments - this is why I'm looking for an alternative. Shame PBP doesn't support FP and recognise 0.073s as a value

[EarlyBird2]

The only issue is timing!

You have set TMR0 at 1/2 second intervals

ClockLoop: IF intcon.2=0 THEN ClockLoop	'Poll for TMRO overflow
INTCON.2=0 ' Clear TMRO overflow flag

HzTimer=HzTimer-$1000	'decrement timer count

IF HzTimer < $1000  THEN
IF Col=10 THEN    ' update time'
SS=SS+1
        
IF SS=60 THEN   ' minute
SS=0 
MM=MM+1
IF MM=60 THEN    ' hour            
MM=0
HH=HH+1
IF HH=24 THEN HH=0
ENDIF                           
counter1 = (HH*60)+MM
ENDIF
ENDIF
Col=Col+1

HzTimer=HzTimer+$7A12	' Add 0.5 seconds to count
ELSE
    ' Do something here but must be less than 65.5 mSec
ENDIF

And again this code works every second

case DAWN 
lcdout $FE,$80+13,"DAWN "   
if ss//1= 0 then
if ss != old_ss then
B_PWM=B_PWM+1
old_ss=ss
endif
endif
if B_PWM = b_max then
Blue_Day_Cycle = DAY
endif

Change your TMR0 code +$7A12 to a lower value for say 1 msec. Then include for milliseconds in your clock and change all of the ss//1=0 instructions to trigger every 73 ms. I guess there will be more issues thrown up but looks easy to me.

[HenrikOlsson]

Hi,
I'll admit, I don't quite follow what you're doing here but (as far as I can see) with the increased resolution you must change either "step change" per update (what Richard suggest but which basically defeats the incresed resolution) OR change the update rate if you want to keep the orignial "cycle time".

If the CASE code, which is what's actually updating the PWM dutycycle, is currently executed at 1Hz then changing that to 16Hz will allow B_PWM to reach 4095 in the same amount of time as it's currently taking to reach 255.

/Henrik.

EDIT: Ah, Steve posted while I was typing and retyping....