Stuck on porting code to 18F4520

[Scampy]

Richard, many thanks for your continued support. That gives me something to work with

[Scampy]

guys, I have a strange issue which I can't seem to resolve - It's probably my maths, but on paper it seems to work out, but falls over when running.

I have 4 word variables for setting the fade in and fade out duration of the two LEDs, the duration between steps in the duty cycle stems from the assistance I had above. Here's the code

blue_delay_in = (((fadesetHR[0]*60)+fadesetMN[0])*60)/255   'takes hours and minutes, converts to minutes, then converts to seconds
white_delay_in = (((fadesetHR[1]*60)+fadesetMN[1])*60)/255  'takes hours and minutes, converts to minutes, then converts to seconds
blue_delay_out = (((fadeoutHR[0]*60)+fadeoutMN[0])*60)/255  'takes hours and minutes, converts to minutes, then converts to seconds
white_delay_out = (((fadeoutHR[1]*60)+fadeoutMN[1])*60)/255 'takes hours and minutes, converts to minutes, then converts to seconds

This works fine if the delay is less than an hour. Setting a delay of 0 hours and 59 minutes gives a value for the variable of 13, which is close to the 13.88 seconds when using a calculator. But if I set the duration to 1 hour and zero minutes the value for the variables is shown as 0 and the leds remain at the max setting. My maths suggest it should be 14. (1 hr * 60 = 60 minutes, add zero minutes, total minutes still = 60. * 60 to convert to seconds = 3600 seconds / 255 = 14.11s delay)

I'm using the following to display the value for these variables, but can't see why it would be that which relates to the issue

lcdout $FE,$80,"B.FO ",DEC blue_delay_out,"   W.FO ",dec white_delay_out

Any Ideas guys ?

[Demon]

Is your variable a byte or word?

60 x 60 = 3600

Not sure things will go as expected before dividing by 255 if using a byte (guessing here).

Robert



Edit: That's not it: 59 minutes x 60 = 3540 seconds and that works...


Edit some more: Got it, your brackets are screwed up.

(((fadeoutHR[1]*60)+fadeoutMN[1])*60)/255

|
|
V

((fadeoutHR[1]*60)+(fadeoutMN[1]*60))/255

[HenrikOlsson]

Robert,
I don't think that's it.
With your version of the formula one hour "is worth" as much as one minute. Try it out with 1h 0min, then try it again with 0h 1min - if I'm not mistaken you'll get the same result.

Not that *I* see any real problem with the original formula but you could try:

blue_delay_in VAR WORD
blue_delay_in = (fadesetHR[0] * 3600 + fadesetMN[0] * 60) / 255

/Henrik.

[Scampy]

Morning guys,

Thanks for the suggestions. Yes the variable is a word, sorry should of pointed that out.

I haven't tried the suggestions yet, but wondered if Henrik's suggestion could be modified to

blue_delay_in = (fadesetHR[0] * 3600) + (fadesetMN[0] * 60) / 255

In my mind this will work out the seconds for both hours and minutes then add them together and divide the result by 255 ??

I never have been good at calculations with lots of brackets when programming !!

[Scampy]

Tried both Henriks version and my revised version and both give a zero value for the variable when the delay is set to 1 hr. Works fine if set to 59 minutes.

Thinking it might be something to do with the menu option to set the delay times, I used the data statements that contain preset settings to set the delay to 1 hr and still got zero for the result.

It seems PBP must handle bracketed equations different to "normal"

EDIT - Most illogical captain...

I tried it without the brackets

blue_delay_in = fadesetHR[0] * 3600 + fadesetMN[0] * 60 / 255

Setting the delay to 1 hour gives a value of 14 for the variable !!!!!

[Demon]

Darn, Henrik is right, again. Shoot, my formula makes things worse.

I was sure I figured a math problem, oh well, I suck.

Robert

[Scampy]

Darn, Henrik is right, again. Shoot, my formula makes things worse.

I was sure I figured a math problem, oh well, I suck.

Robert

Robert... it's fine, just put it down to recovering from the party

[HenrikOlsson]

Hi,

In my mind this will work out the seconds for both hours and minutes then add them together and divide the result by 255 ??

I believe that's exactly what mine does. Multiplication and division has precedence over addition and subtraction. So mine will take the hours and multiply that by 3600, then it'll take the minutes and multiply those by 60. It will then add those two results together because they are enclosed within brackets and THEN divide that result by 255 - which I believe is what you want.

/Henrik.

[Scampy]

Guys, see my edited post above - it works without the brackets - why I have no idea !!