pwm libs

[Rob Hamerling]

Hi Seb,

You've probably read issue 67.
I was experimenting with your pwm sample, modified for the 18f2455. I
have leds connected to both cpp1 and ccp2 (just a 'lucky' co-incidence)
and wanted to see the fading of both leds. So I copied the code for pwm1
and modified it for pwm2. But I made an error with the modification and
saw stange effects with the second led.... This is how I discovered the
bug. I've not checked with Stef's original....

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

[Rob Hamerling]

Hi Seb,

Rob Hamerling wrote:

> I was experimenting with your pwm sample, modified for the 18f2455. I
> have leds connected to both cpp1 and ccp2 (just a 'lucky' co-incidence)
> and wanted to see the fading of both leds.

Regardless the issue with the pwm libs I have an additional remark.
A comment in your sample says that when turning of pwm the LED lights at
max. In the datasheet of the 18f2455 which I'm using on my test-board I
found (on page 146):

"Clearing the CCP2CON register will force the RB3 or RC1 (...) to the
default low level. This is not the PORTB or PORTC I/O data latch."

With some experimenting with the mentioned PIC I found that after
pwm_off() the LEDs light full up (only) when the pin has been set (= on)
explicitly (before initializing pwm). When I reset the pin (= off) the
LEDs stay off after pwm_off().
Maybe you could repeat this test on your own board (and change the text
if needed).

[a.f...@chello.nl]

Hi,
I also want to use both PWMs on a 18f4550, this device has a standard
and an enhanced PWM module, by default only PWM2 is included, since
CCP1CON is not defined. I can get around the issue by adding the
following alias

var byte CCP1CON is ECCP1CON

before including pwm_hardware file

This seems to work OK, but was wondering if there is a better
solution, because it makes to code less portable

Regards Albert

[Sebastien Lelong]

Hi Rob,

You've probably read issue 67.
I was experimenting with your pwm sample, modified for the 18f2455. I
have leds connected to both cpp1 and ccp2 (just a 'lucky' co-incidence)
and wanted to see the fading of both leds. So I copied the code for pwm1
and modified it for pwm2. But I made an error with the modification and
saw stange effects with the second led.... This is how I discovered the
bug.  I've not checked with Stef's original....

I'll include your fix proposed in issue 67.

Cheers,
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[Sebastien Lelong]

Hi again,

I'll try to test this, but have very few time these days :(

Cheers,
Seb

[Sebastien Lelong]

Hi Albert,

I can include this test in the pwm libs, so you don't have to alias anything before include them:

if defined(CCPCON1) or defined(ECCPCON1) then
    include pwm_ccp1
end if


But I don't know is these libs work as expected with enhanded pwm... From what you say, it seems to.


Cheers,
Seb

[a.f...@chello.nl]

Hi Seb,

> if defined(CCPCON1) or defined(ECCPCON1) then
> include pwm_ccp1
> end if

That won't work, because the library itself uses CCPON1 rather than
ECCPCON1, however, defining the alias can work

if !defined(ECCPCON1) then
var volatile byte CCP1CON is ECCP1CON
end if

>
> > before including pwm_hardware file
>
> > This seems to work OK, but was wondering if there is a better
> > solution, because it makes to code less portable
>
> > Regards Albert
>
> --

> Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org- Hide quoted text -
>
> - Show quoted text -

[a.f...@chello.nl]

Hi Seb,
Also noticed another issue in the comment

-- This means if duty1 = 0, there's no pwm, if duty1 = 255, you're
closed to
-- (but not at) the maximum pwm

This is not true, the duty cycly ratio is also dependent on the PR2
setting, the statement above is only true
if the maximum resolution is use (e.g by using the pwm_max_resolution
call)

Furthermore, in the procedure pwm1_set_percent_dutycycle(byte in
percent), since the percentage calculation should be
indendent of the pre-scaler setting , I think you can just evalute PR2
rather than _pr2_4 /_pr2_4 / _pr2_16, this will reduce the amount of
calculations (DWORD multiplications and divisions are expensive) and
code size

Albert

[Rob Hamerling]

Hi Seb and others,

Since the control of PWM (esp. contents of [E]CCPxCON) is more
complicated and the MPLAB .dev files more inconsistent than on first
sight, I have extended the FindCCPCON wiki with the bit names for each
CCPxCON register. The layout is now similar to the FindADCON.
I expect this gives a better insight for improvements of the PWM libs.

Regards, Rob.

PS: The blue question marks in the table are added by Google! I don't
now why and how to avoid it.

[Sebastien Lelong]

Hi Albert,

I just read this, didn't not noticed this mail, sorry...
About the comment, I'll modify it, obsivously it's wrong !
About percentage calculation, I'll see what I can do.

Thanks for reporting this.

Cheers,
Seb

[Sebastien Lelong]

Hi,

I've made the fix according to your suggestion. I did not tested yet, but will ASAP. Other issues are under progress ! (but ADC lib is also maturing and marinating.


Cheers,
Seb

[Sebastien Lelong]

Hi,


Looking at Rob's wiki page and device files, it appears some PICs (18f4480.jal, 18f448.jal, 18f4580.jal, 18f4585.jal, 18f458.jal, 18f4680.jal, 18f4682.jal, 18f4685.jal) have both a CCP1CON *and* ECCP1CON register.

If CCP1CON has precedence over ECCP1CON, then in pwm_hardware.jal, I can create your alias as:


if(defined(CCP1CON) == true) then
   include pwm_ccp1
elsif(defined(ECCP1CON)) == true then

   var byte CCP1CON is ECCP1CON

   include pwm_ccp1
end if


If not, that is, if ECCP1CON has precedence over CCP1CON, I can't create any aliases ("ECCP1CON is CCP1CON") since it already exists. If precedence depends on PICs, I need to parse datasheets :)


Cheers,
Seb

That won't work, because the library itself uses CCPON1 rather than
ECCPCON1, however, defining the alias can work

if !defined(ECCPCON1) then
var volatile byte CCP1CON is ECCP1CON
end if

[Rob Hamerling]

Sebastien Lelong wrote:

> Looking at Rob's wiki page and device files, it appears some PICs
> (18f4480.jal, 18f448.jal, 18f4580.jal, 18f4585.jal, 18f458.jal, 18f4680.jal,
> 18f4682.jal, 18f4685.jal) have both a CCP1CON *and* ECCP1CON register.

I noticed many 'irregularities', mainly in the names of bitfields, but
not this one!

On first sight I thought it would be nice to rename (in the device
files) CCPxCON registers which apparently control an enhanced CCP module
to ECCPxCON. That would make it possible to (partly) split standard and
enhanced PWM libraries. But I don't think this is feasible because of
duplicate names.
However normalizing the names of the bit fields of [E]CCPxCON registers
looks possible without problems.

Maybe we should check how MCC18 solved this problem (if it does).