Multiple PWM and port C

[Scampy]

Hi,

Still working on my aquarium lighting controller as I've discovered an issue with using the hardware PWM on the 18F4520. I've opted to use Darrels multi-SWPM files, and after a littler re-write the code compiles and runs, but with some strange quirkyness that I can't seem to get my head round.

As I already have PCB's made I need to keep the two PWM pins on port C1 and C2. Now when I use these, the RTC clock displays a stupid time of 48:85 and everything locks up as the clock is not out putting the correct time. If I change the multi-spwm pins to port D1 and D2, the clock runs fine with the correct time. Here is the settings I've used for Darrels include file

define SPWMFREQ  100                    ' PWM frequency in Hz    

SPWM1PIN  VAR PORTC.1                   ' SPWM channel 1
define SPWM1VAR  _B_PWM

SPWM2PIN  VAR PORTC.2                   ' SPWM channel 2
define SPWM2VAR  _W_PWM

I've obviously commented out the port settings for the hardware PWM register

'*******************************************************************************
'Port and Register settings
'*******************************************************************************

'CCP1CON = %00001100                     'Set CCP1 to PWM 
'CCP2CON = %00001100                     'Set CCP2 to PWM     
TRISA  = %11101111              
TRISB  = %00000011 
TRISD  = %00000011              
T0CON  = %11000111

I basically need to configure portC so that C0, C1 and C2 are digital, C3 and C4 are used for the RTC (SDA and SCL), but I'm struggling

[HenrikOlsson]

Hi,
I don't know much about I2C but I suspect that the issue you're having could be timing related. If you're using the PBP commands for I2C then then the communication is bit-banged and software timed. Darrels SPWM routines uses interrupts to do its thing which will disturb the timing of the I2C communication.

I'm curious what the issue with using hardware PWM actually means. Since the hardware is built to use the CCP modules I'd do everything I possibly could to actually make use of them instead of reverting to bit-banging PWM.

/Henrik.

[Scampy]

Hi Henrik,

The issue with the hardware PWM was that it doesn't produce a nice square wave, and even at 100% (255) duty is still sending a signal rather than full line level. The net result was that the LED drivers were running around 60% when the PIC was outputting full duty cycle. Using Darrels software PWM I get a nice square wave, which at 0 duty cycle I get 0 volts, at 255 duty I get 5v and full Mark to Space ratio. (ie a solid line with no pulses), which is what you would expect.

I don't think it's a timing issue as I've knocked up a version where the RTC works, and port C1 and C2 drive the LEDs, just when I copy that code to my main program, comment out the reference to CCP registers the resulting HEX causes the clock to function as described.

My only option is to manually modify the PCB to use port E1 and E2....

[Scampy]

Interestingly, I have the temp sensor (18B20) on port RA5. If I use RA4 and RA7 as the PWM pins the temperature reading goes heywire, displaying random temperatures like 163C but is often trying to over write the display. With RA4 and RA7 set as the pins for pWM, the clock on C3 and C4 runs fine....

[HenrikOlsson]

OK, so then it's some kind of interference between the SPWM routines and the rest of the program, perhaps a read-modify-write issue, I don't know. But then you say that you had a version with both SPWM and I2C on the same port (different pins of course) which DID work so I don't know. Hopefully Darrel or someone else who's been using the routines in quesiton will jump in.

Back to the hardware PWM.... Did you set the registers manually or did you use the HPWM command?
If you set the registers manually then the number of bits of resolution you get depends on the frequency you select so a dutycycle value of 255 doesn't neccesarily mean 100% - it depends.
If, on the other hand, you DID use the HPWM command then you should have got 100% with a duty of 255 - given you had told the compiler the correct operating frequency, ie DEFINE OSC xx.

I still think you should concentrate on getting the CCP modules to do the PWM for you. Post the code for that and I'll take a look.

/Henrik.

[Scampy]

Well I just re-loaded the test code that uses port C for both clock and PWM pins and that appears to do the same thing, with 10:10 shown as the time. Mind you I've been cutting and pasting bits of code from one to the other to try and resolve this.

When using CCP modules I simply used CCP1CON = %00000000 and CCP2CON = %00000000 to set the register and then used PBP HPWM command to drive the pins....

I'll drop you a PM with the code....

[richard]

all the spwm interrupts will muck up the i2c and onwire timing . you will probably need to disable the ints during the actual data transfers

[HenrikOlsson]

Hi Richard,
That was my initial thought as well but then Scampy wrote:

Interestingly, I have the temp sensor (18B20) on port RA5. If I use RA4 and RA7 as the PWM pins the temperature reading goes heywire, displaying random temperatures like 163C but is often trying to over write the display. With RA4 and RA7 set as the pins for pWM, the clock on C3 and C4 runs fine...

Which indicates that as long as the PWM is not on the same port as the I2C it does seem to work - only when the PWM and I2C (or 1Wire) is on the same port does it act up.
If it was a timing issue then I can't see how moving the I2C to a different port than the PWM would make it work. I'm leaning more towards some kind of port or tris register overwrite causing the issue, perhaps a R-M-W but of course I can't say for sure.

/Henrik.

[richard]

hi henrick
it could be that the port value gets changed by the int routine between a read modify write action in the i2c or onewire routines, or vice versa
simply stetting the timer int off before the i2c and one wire transactions and restoring it afterwards should be easy enough to try . if that works its an easy fix

[HenrikOlsson]

Hi,
I agree, it's easy to try and and an easy fix provided it doesn't result in any obvious glitches or blinking effect on the LEDs being driven by the PWM.
But why would the PWM routine change bits that it (the PWM routine) has nothing to do with. Something is going on for sure but I can't really figure out a real good reason.

/Henrik.

[Scampy]

OK guys you've lost me.

I think the work around for now is to simply use pins D1 and D2 as the output and solder links on the PCB - This way I get a working solution of true square wave of 0-5v running at a frequency that suits the LED drivers, and code that runs at a suitable speed.

Thanks again for all your input....

[Demon]

Have you tested different caps to filter that noise on square waves?

Robert

[Scampy]

Ok, for the past few days I've been running the code on the development board using D2 and D3 as the output pins for the PWM - all was fine so I placed the chip in the controller and over the weekend it's been running fine, and with the added bonus that the LDD LED drivers don't sing like they used to when using the hardware generators on the PIC.

So I've now started to add in the next module for the project, serial communications. Thanks to Robert's post in my other thread I've used MisterE's tool to generate the port definitions etc, and after a slight hardware issue with the USB/serial cable used a simple echo program to test the comms - it worked fine, using the Comms tool in Microcode Studio I was able to connect to the port, and whatever I sent from the PC was echoed back in the RX panel...I then opened the current working version of my code and simply inserted the line

Hserout ["Blues  ",DEC(B_PWM * 100)/255, 13, 10] ' Send text followed by carriage return and linefeed

which should simple send the value of B_PWM as a percentage to the PC. However when I compiled the code and ran it, then set the clock to the time the lights were on, the PWM remained at 0 and didn't increase. The RTC ran, and the menu options worked so the code was looping, but for some reason I never got an output from the software pins or the LCD. If I commented out the Hserout line the code works perfectly.

It seems another conflict when running DT's multi_pwm with port C, and again its coms related.