Multiple PWM and port C

[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....

[HenrikOlsson]

Hi,
Took a quick look at the code you PM'd me and found this:

'If light=1 then                         ' If the variable is 1 then output full PWM to lights
'    hpwm 1,255,200        
'    hpwm 2,255,200
'endif
'If light=0 then                       ' If the variable is low then set value to 0 an turn off the lights
'    hpwm 1,0,200        
'    hpwm 2,0,200    
'endif

If this is where you're trying to set 100% dutycycle but ends up with a "jumpy" signal not at 100% then the problem is most likely that you're trying a frequency (200Hz) far below the specified minimum. If you look at the manual you'll see that for a 18F device running at 20MHz the minimum frequency is 1221Hz.

The only other place in the code where HPWM was used had a frequency of 5kHz so that should've worked - did it?

/Henrik.

[Scampy]

Hi,
Took a quick look at the code you PM'd me and found this:

'If light=1 then                         ' If the variable is 1 then output full PWM to lights
'    hpwm 1,255,200        
'    hpwm 2,255,200
'endif
'If light=0 then                       ' If the variable is low then set value to 0 an turn off the lights
'    hpwm 1,0,200        
'    hpwm 2,0,200    
'endif

If this is where you're trying to set 100% dutycycle but ends up with a "jumpy" signal not at 100% then the problem is most likely that you're trying a frequency (200Hz) far below the specified minimum. If you look at the manual you'll see that for a 18F device running at 20MHz the minimum frequency is 1221Hz.

The only other place in the code where HPWM was used had a frequency of 5kHz so that should've worked - did it?

/Henrik.

Hi,

That section had been commented out from when I was using the hardware modules. It was intended as a manual over-ride so that I could turn the lights on or off via the push of a button. I never ran the module at high frequencies as the LED driver requires a PWM frequency of 100 hz - 1khz and at 1 Khz they resonated with a high pitched sound.

The original code had

'*******************************************************************************
'Send pulses to drivers

    hpwm 1,W_PWM,200        
    hpwm 2,B_PWM,200
    
'*******************************************************************************

Where W_PWM and B_PWM increased from 0 to 255 or decreased from 255 to 0 to fade the LEDs up and down

[Scampy]

Changing ADCON0 to a value of 7 and changing the SW PWM pins to C1 and C2 made the clock to something, but it's still not running. The clock displayed 45:00 and then counted up in seconds (45:01, 45:02 etc) until it reach 14:10 and then displayed the 45:51. It remained displaying this "time", then changed to 45:52 a minute later, followed by 45:53 etc but there was no change in the case and the LEDs didn't light.

Not sure if changing ADCON0 to 7 (all digital) had a bearing on things