18B20 and Multi_SPWM issue

Hi Guys,

I've had a project running for some time now (http://www.picbasic.co.uk/forum/showthread.php?t=18456) which uses DT's Multi_SPWM routine to fade up the LEDS over a marine fish tank. The project uses an 18F4520 running from a 20Mhz xtal with the HS_1 fuse setting, and runs fine until recently, when one of the constant current LED drivers seems to miss-read the PWM value when fading down (the remain three drivers, including sharing the same PWM pin work fine). First thoughts were that the driver was faulty so I fitted a replacement but the issue still happens.

Checking the datasheet for the driver, the minimum PWM frequency is 100 Hz, which was set in the PBP code, but I've been advised by fellow fish keepers that the drivers perform better at higher frequency so I changed the variable value for the frequency from 100 to 1000 but found I got a warning stating that I need to changes the settings or reduce the number of PWM channels etc - anyway entering a value of 400 was the maximum that would compile without error. However on loading this to the PIC the temperature displayed on the LCD is screwed up, with varying values from 155c, 237, 568, 233, mostly random three digit values. Setting the frequency variable back to 100 and the temperature is displayed fine.

Here's the section of code for the temperature:

Code:

---

'Get and display the temperature

OWOUT DQ, 1, [$CC, $44]                ' Start temperature conversion
OWOUT DQ, 1, [$CC, $BE]                ' Read the temperature
OWIN DQ, 0, [temperature.LOWBYTE, temperature.HIGHBYTE]
temperature = temperature */ 1600
lcdout $FE,$D4+0,"TEMP ",dec(temperature / 100),$DF,"C"

---

Any ideas ?

Interrupt is messing up timing for OWOUT and OWIN.
Even 100Hz interrupt can cause problem. You must disable int before OWOUT.

But would disabling the interrupt cause issues with the PWM ?

Well disabling interrupts works... and the RTC seems to be keeping time, but I had to set the frequency to 200 as 400 seems to make the code run slow

OK now something else is upset.

I have the PWM delay in seconds set by the following code:

Code:

---

blue_delay_in = fadesetHR[0] * 3600 + fadesetMN[0] * 60 / 255
white_delay_in = fadesetHR[1] * 3600 + fadesetMN[1] * 60 / 255
blue_delay_out = fadeoutHR[0] * 3600 + fadeoutMN[0] * 60 / 255
white_delay_out = fadeoutHR[1] * 3600 + fadeoutMN[1] * 60 / 255

---

This basically, takes the value for hours (0,1,2 etc) multiplies it by 3600 to convert to seconds, then takes the value for minutes and multiples this by 60 to convert to seconds and then adds them together and divides the result by 255. Having just set the white fad in to zero hours and 5 minutes the PWM should take 1.1 second. OK I know there is no floating point so I would expect some dependency, but it's taken 28 minutes to reach 100% (255), so each step was taking over 5 seconds....Reducing the frequency shortens the delay, a frequency of 100 takes 7 minutes, which allowing for the lack of floating point in PBP would be about right.

I could compensate by increasing the divider from 255 to 700 or something until I get close to the correct timings, but I'm sure there must be a better way