Ik heb het volgende probleem:
Een pic 16f648A,(4Mhz interne klok) RB3 ingesteld voor PWM.
PR2 = 15
CCPR1L= 15
CCP1CON = 60 (prescaler = 4)
Dit geeft me een PWM-frequentie van pakweg 15KHz, onderverdeeld in 64 "stappen".

Als ik het programma aan het debuggen ben, merk ik dat pin B3 laag is bij de laatste 4 pulsen, terwijl de duty cycle op max. staat...
Timer 2 loopt gewoon van 0 tot 15, en begint dan opnieuw. Maar zogauw deze dus 15 is, is RB3 uit.....

Wat doe ik verkeerd?

Je gebruikt een pic-ding :-)

Maar alle gekheid op een stokje: max. wil niet altijd 100% zeggen. Zou het kunnen dat het ding 1 (interne) clock non-active is en dat dat in jouw beleving door je prescaler (op 4) effectie neerkomt op de 'laatste 4 pulsen'?

Ik betwijfel dat je wat verkeerd doet, denk eerder dat jij iets van je pic-ding verwacht wat daar botweg niet zo in hardware zit...

[Bericht gewijzigd door Marco69 op ]

Grappig, hij zou alleen bij de laatste klokpuls laag moeten zijn. Het is misschien een foutje in de simulator.
Doet de hardware het wel goed ?

De hardware is er nog niet, enkel de software. Ga eerst kijken of m'n bedoelingen wel haalbaar zijn, voordat er iets gebouwd wordt.

Maare, ik maak uit de datasheet uit dat als je de duty cycle op max. zet, RB3 volledig aangezet word. Er wordt ergens een bit geset (heb even geen tijd om uit te zoeken welke...).
Ik had me dus daarop gebaseerd. Blijkt dat de pin toch zf en toe laag wordt.
Terwijl Timer2 loopt op de achtergrond, loopt het programma wel in een endless loop, waarvan het grootste gedeelte delays zijn. Misschien heeft dat er mee te maken?

Het verhaaltje over de laatste 4 pulsen met prescaler 4 ga ik eens uitzoeken. Het zou kunnen dat ik blijkbaar NIET op 100% zit. Alhoewel...

PR2=15, dus timer2 telt van 0 tot 16. Prescaler =4. 4 x 16 zijn 64 mogelijke standen. Dat is 6 bits breed. Deze 6 bits zijn allen 1 (CCPR1L en CCPCON). Foute redenering? Bij de sturing is max.10 bits mogelijk, waarvan ik er 6 gebruik...

[Bericht gewijzigd door ChrisL op ]

Pas op: bij 8bit PWM heb je een teller die 256 stappen afloopt. Je hebt echter 257 situaties: continue uit, PWM signaal en continue AAN. Een van de situaties kan dus niet voorkomen.
In getallen: dutycycle is 0/256, 1/256, 2/256...255/256 en 256/256. Je mist dus of de 0/256 situatie, of de 256/256 situatie (zoals bij de PIC).
Met PR2 < 256 heb je dit probleem niet want je kan CCRP1L hoger zetten dan PR2.

Mmmmm, ik begin bij CCP1CON (lower bits) op 0X0C, de betreffende 2 bits zijn dan 0. CCPR1L is ook volledig 0.
Dat houdt dus in dat de duty cycle 0% is.

De 64ste stap in m'n programma is CCP1CON op 0X3C (LSB bits op 1), en CCPR1L op 0X0F (bit 3-6 op 1). Dat zijn dus 64 stappen. Ik ga er van uit dat als de 6 gebruikte bits allen 1 zijn, de uitgang continu hoog blijft.

Of ben ik mis en moet ik een 7de bit hoog trekken, en de duty cycle langer maken als de pwm-period? Nu zijn die exact even lang.

Op 1 april 2006 16:05:57 schreef JoWi:
Pas op: bij 8bit PWM heb je een teller die 256 stappen afloopt. Je hebt echter 257 situaties: continue uit, PWM signaal en continue AAN. Een van de situaties kan dus niet voorkomen.
In getallen: dutycycle is 0/256, 1/256, 2/256...255/256 en 256/256. Je mist dus of de 0/256 situatie, of de 256/256 situatie (zoals bij de PIC).
Met PR2 < 256 heb je dit probleem niet want je kan CCRP1L hoger zetten dan PR2.

Bedankt voor de tip, 1 bit extra setten geeft me het resultaat dat ik zocht. In plaats van 64 stappen, had ik er 65 nodig.

Nu de rest nog werkende krijgen....

Tellen......

1+1=1
0+0=1
1+0=0
0+1=0

64=65-1 en dan de nul niet vergeten.
Je telt immers van 0-64 en niet van 1 tot 64.

mvg

Was idd de nul vergeten, entelde van nul tot 63....en sloeg 64 over. In de debugger van mplab lijkt het erop dat je dan 4 stappen overslaat....maar dan spring je van regel naar regel, en geef je geen klokpulsen.