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
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
The only issue is timing!
You have set TMR0 at 1/2 second intervals
And again this code works every secondCode: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
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.Code: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
Steve Earl www.datageo.co.uk
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....
Bookmarks