PWM mit Duty-Cycle 0%?

[David (Gast)]

Hallo!

Bin gerade am Experimentieren mit einem 8051-Mikrocontroller-Board. 
Möchte eine LED per PWM mit wechselndem Tastgrad an und aus "dimmen". 
Klappt so weit eigentlich auch, nur gibt es an dem Punkt, an dem die LED 
kurz ausgeschaltet sein sollte, einen kurzen, sehr hellen Impuls.
Ich schätze der µC hat einfach Probleme, eine PWM mit Duty-Cycle nahe 0% 
zu liefern? Gibt es einen Trick um dieses kurze Aufblitzen der LED zu 
umgehen?
Für die PWM benutze ich das PCA in 16bit-PWM-Betrieb.

Danke schonmal für eure Hilfe!

[Jonathan S. (joni-st)]

Ein µC kann mit der PWM komplett an 0% und 100% rangehen. Kommt dann 
halt Gleichstrom raus. Bestimmt hast Du in deinem Programm irgendwo 
einen Überlauf, sodass Du deine PWM versehentlich auf 100% fährst. Ohne 
Programm und Schaltplan können wir aber nur raten.


Gruß
Jonathan

[Dominik S. (dasd)]

Jonathan Strobl schrieb:
> Kommt dann
> halt Gleichstrom raus

So eine PWM erzeugt immer Gleichspannung, die Polarität ändert sich ja 
nicht.

David schrieb:
> Ich schätze der µC hat einfach Probleme, eine PWM mit Duty-Cycle nahe 0%
> zu liefern?

Wenn dann hat dein Code ein Problem damit :)
Duty-Cycle 0 heißt für den Controller einfach PINx=0, für den µC ist das 
das kleinste Problem.

> Gibt es einen Trick um dieses kurze Aufblitzen der LED zu
> umgehen?

Wie Jonathan sagt: Mehr Infos rausrücken xD

[ich (Gast)]

David schrieb:
> Gibt es einen Trick um dieses kurze Aufblitzen der LED zu
> umgehen?
PWM abschalten.

Ich denke mal, das funktioniert wie bei einem AVR: beim Hochzählen bis 
zum maximalen Wert ist der Ausgang 0 - Beim Erreichen umschalten auf 1 - 
jetzt weiterzählen bis zum eingestellten 'PWM-Wert' - wieder 
ausschalten. Und das dauert eben von 'Max' bis '0' einen Timertakt.

[David (Gast)]

Danke euch schonmal!
Kompletten Code hier jetzt reinposten wäre denk ich übertrieben...
Also das ganze funktioniert so:
Das PCA zählt permanent von 0x0000 bis 0xffff hoch (mit 3MHz), dazu gebe 
ich im Programm einen Compare-Wert vor, am Anfang soll dieser 0 sein. 
Sobald der Counter über diesen Wert läuft schaltet der Port auf high, 
LED ist dann aus.
Dachte auch erst ich hab nen Fehler in der Zählschleife drin (dass ich 
den Compare-Wert öfter verringere als ich ihn vorher erhöht habe). 
Allerdings hab ichs in Einzelschritt durchprobiert und komme da immer 
wieder bei 0 raus, dann beginnt die Zählschleife von vorne. Das störende 
Aufblinken ist auch ab einem Compare-Startwert von ~0x40 nicht mehr da, 
ich erhöhe Compare aber bei jedem PCA-Interrupt um 0xfa, kann also nicht 
einen ganzen Schritt zu viel runterzählen...
Hoffe das war einigermaßen verständlich was ich meine, fällt mir 
bisschen schwer das in Worte zu fassen ;)

[Jonathan S. (joni-st)]

Dominik S. schrieb:
> So eine PWM erzeugt immer Gleichspannung, die Polarität ändert sich ja
> nicht.

Doch: Das ist eine Wechselspannung, die mit einer Gleichspannung 
überlagert ist. Wenn Du auf 12V Welchselspannung 20V Gleichspannung 
drauflegst, ändert sich die Polarität ja auch nicht mehr, aber die 
Wechselspannung ist trotzdem noch vorhanden. Wenn Du vom PWM-Signal den 
Gleichanteil wegfilterst, bleibt auch nur noch die Wechselspannung 
übrig.

Aber ich glaube, das wird jetzt ein Bisschen Off-Topic und ist auch eine 
Definitionsfrage ;)


David schrieb:
> Kompletten Code hier jetzt reinposten wäre denk ich übertrieben...

Nein, ohne Quellcode vor der Nase kann man keine Fehler finden. Zeig 
schon her ;)


Gruß
Jonathan

[Hinz (Gast)]

Dominik S. schrieb:
> So eine PWM erzeugt immer Gleichspannung, die Polarität ändert sich ja
> nicht.

Da würde dich eine FFT eines belehren. Eine Gleichspannung hat nur einen 
Beitrag bei 0 Hz, d.h. sie ändert sich zeitlich nicht.

[David (Gast)]

Also, dann hier mal der Code...

CSEG AT 0H              ;Legt absolute Codesegmentadresse auf 0h
call Init_Device    ;Aufruf zur Initialisierung der Controller Funktionen
jmp INIT
;
;------------------------------------------------------------------------
;Interrupt-Vektoren
;------------------------------------------------------------------------
ORG 05Bh ;PCA Interrupt-Adresse
clr CF  ;Interrupt-Flag rücksetzen
call PCAINT  ;springe in Interrupt-Serviceroutine

;------------------------------------------------------------------------
;Initialisierungsteil fuer On-Chip Peripherie
;------------------------------------------------------------------------
ORG 100H                ;Programmstart bei 100H
INIT:
setb P3.2    ; LED ausschalten
clr 20h.0     ; Bits (Flags) rücksetzen
clr  20h.1
clr 20h.2
clr 20h.3
SCHRITTE EQU 255 ; Anzahl der Gesamtschritte bei PWM (so oft wird Compare erhöht...)
SCHRITTW EQU 255; Wert, um den Compare bei jedem Interrupt erhöht wird
mov R2, #SCHRITTE ; R2 mit Anzahl d. Schritte laden



;------------------------------------------------------------------------
;Programmschleife
;------------------------------------------------------------------------

ABFRAGE:
jnb P1.1,SETF1  ; Abfrage Taster T1
jmp ABFRAGE 

SETF1:
setb 20h.0  ;Merken, dass T1 bereits gedrückt wurde... 

jmp ABFRAGE


PCAINT:        ; Interrupt_Routine
jb 20h.0, PWM     ;falls T1 bereits gedrückt wurde: PWM starten...
reti

PWM:
jb 20h.2, DUNKLER 
djnz R2, HELLER
setb 20h.2       ; falls R2=null: Ab nächstem Durchlauf in "DUNKLER" springen...
mov R2, #SCHRITTE  ; R2 neu laden
reti


HELLER:
mov A, PCA0CPL0   ; Compare-Lowbyte in Akku schreiben
clr C       ; evtl. noch vorhandenes Übertragscarry nullen
add A, #SCHRITTW  ;Compare-Lowbyte erhöhen (Duty-Cycle wird kleiner /LED heller)
mov PCA0CPL0, A    ; zurückschreiben
mov A, PCA0CPH0     ;Highbyte in Akku
addc A, #0h    ; evtl. aufgetretenes Carry zu Highbyte addieren
mov PCA0CPH0, A   ; Highbyte zurückschreiben

reti



DUNKLER:
djnz R2, DUNKLER_SCHL  ; Wenn R2 nicht 0 springen...
clr 20h.2 ; wieder erhöhen
mov R2, #SCHRITTE
reti

DUNKLER_SCHL:    ; LED abdunkeln
mov A, PCA0CPL0    
clr C
subb A, #SCHRITTW  ;Compare-Wert Lowbyte verringern -> Duty-Cycle wird größer /LED dunkler
mov PCA0CPL0, A
mov A, PCA0CPH0     
subb A, #0h    ; evtl. aufgetretenes Carry von Compare-Highbyte abziehen
mov PCA0CPH0, A
reti



;------------------------------------
;-  Generated Initialization File  --
;------------------------------------



; Peripheral specific initialization functions,
; Called from the Init_Device label
PCA_Init:
    mov  PCA0CN,    #040h
    anl  PCA0MD,    #0BFh
    mov  PCA0MD,    #009h
    mov  PCA0CPM0,  #0C2h
    mov  PCA0CPL0,  #0h       ; Startwert für Compare-Lowbyte
    mov  PCA0CPH0,  #0h       ; Startwert für Compare-Highbyte
    ret

Timer_Init:
    mov  TCON,      #010h
    mov  TMOD,      #001h
    ret

Port_IO_Init:
    ; P0.0  -  Skipped,     Push-Pull,  Digital
    ; P0.1  -  Skipped,     Push-Pull,  Digital
    ; P0.2  -  Skipped,     Push-Pull,  Digital
    ; P0.3  -  Skipped,     Push-Pull,  Digital
    ; P0.4  -  TX0 (UART0), Push-Pull,  Digital
    ; P0.5  -  RX0 (UART0), Push-Pull,  Digital
    ; P0.6  -  Skipped,     Push-Pull,  Digital
    ; P0.7  -  Skipped,     Push-Pull,  Digital

    ; P1.0  -  Skipped,     Push-Pull,  Digital
    ; P1.1  -  Skipped,     Push-Pull,  Digital
    ; P1.2  -  Skipped,     Push-Pull,  Digital
    ; P1.3  -  Skipped,     Push-Pull,  Digital
    ; P1.4  -  Skipped,     Push-Pull,  Digital
    ; P1.5  -  Skipped,     Push-Pull,  Digital
    ; P1.6  -  Skipped,     Push-Pull,  Digital
    ; P1.7  -  Skipped,     Push-Pull,  Digital

    ; P2.0  -  Skipped,     Push-Pull,  Digital
    ; P2.1  -  Skipped,     Push-Pull,  Digital
    ; P2.2  -  Skipped,     Push-Pull,  Digital
    ; P2.3  -  Skipped,     Push-Pull,  Digital
    ; P2.4  -  Skipped,     Push-Pull,  Digital
    ; P2.5  -  Skipped,     Push-Pull,  Digital
    ; P2.6  -  Skipped,     Push-Pull,  Digital
    ; P2.7  -  Skipped,     Push-Pull,  Digital

    ; P3.0  -  Skipped,     Push-Pull,  Digital
    ; P3.1  -  Skipped,     Push-Pull,  Digital
    ; P3.2  -  CEX0  (PCA), Push-Pull,  Digital
    ; P3.3  -  CEX1  (PCA), Push-Pull,  Digital
    ; P3.4  -  CEX2  (PCA), Push-Pull,  Digital
    ; P3.5  -  CEX3  (PCA), Push-Pull,  Digital
    ; P3.6  -  CEX4  (PCA), Push-Pull,  Digital
    ; P3.7  -  T0  (Timr0), Push-Pull,  Digital

    mov  P0MDOUT,   #0FFh
    mov  P1MDOUT,   #0FFh
    mov  P2MDOUT,   #0FFh
    mov  P3MDOUT,   #0FFh
    mov  P0SKIP,    #0CFh
    mov  P1SKIP,    #0FFh
    mov  P2SKIP,    #0FFh
    mov  P3SKIP,    #003h
    mov  XBR0,      #001h
    mov  XBR1,      #055h
    ret

Oscillator_Init:
    mov  OSCICN,    #083h
    ret

Interrupts_Init:
    mov  EIE1,      #030h
    mov  IT01CF,    #010h
    mov  IE,        #080h
    ret

; Initialization function for device,
; Call Init_Device from your main program
Init_Device:
    lcall PCA_Init
    lcall Timer_Init
    lcall Port_IO_Init
    lcall Oscillator_Init
    lcall Interrupts_Init
    ret

end

Hoffe es ist nachzuvollziehen wie das funktionieren soll... ;-)

[Jim M. (turboj)]

> Hoffe es ist nachzuvollziehen wie das funktionieren soll

Wenn man wissen würde welchen SiLabs 8051 Du denn verwendest, wäre es 
einfacher. Ich tippe mal auf 8051F020 o.ä.

[David (Gast)]

Jim Meba schrieb:
>> Hoffe es ist nachzuvollziehen wie das funktionieren soll
>
> Wenn man wissen würde welchen SiLabs 8051 Du denn verwendest, wäre es
> einfacher. Ich tippe mal auf 8051F020 o.ä.

Sorry, wusste nicht dass das wichtig ist...Ist ein 8051F340...
Gruß David

[spess53 (Gast)]

Hi

>;---------------------------------------------------------------------- --
>;Interrupt-Vektoren
>;---------------------------------------------------------------------- --
>ORG 05Bh ;PCA Interrupt-Adresse
>clr CF  ;Interrupt-Flag rücksetzen
>call PCAINT  ;springe in Interrupt-Serviceroutine

An dieser Stelle sollte ein Sprung zur ISR stehen. Oder ist das beim 
8051 anders.

MfG Spess

[Peter D. (peda)]

David schrieb:
> Sorry, wusste nicht dass das wichtig ist...Ist ein 8051F340...

Naja, es gibt ja nur über 500 Typen des 8051 von etwa 50 Herstellern.
Das die alle irgendwelche Unterschiede haben, sollte klar sein.

Auch muß man ja zu Anfang das entsprechende Include reinschreiben, damit 
der Assembler/Compiler überhaupt die richtigen Adressen findet.
Geht daraus nicht eindeutig das verwendete Target hervor, schreibt man 
es als Kommentar mit rein.

In die Vektortabelle schreibt man immer nur den Sprung zur 
Behandlungsroutine rein, keinen sonstigen Code!
Dein Sprung zum Main kollidiert mit dem ersten Interruptvektor.
Vielleicht willst Du ihn später mal verwenden und dann krachts.


Peter

[Jobst M. (jobstens-de)]

spess53 schrieb:
> An dieser Stelle sollte ein Sprung zur ISR stehen. Oder ist das beim
> 8051 anders.

Anders als wo?


Gruß

Jobst

[spess53 (Gast)]

Hi

>Anders als wo?

Bei anderen µCs?

MfG Spess

[Jobst M. (jobstens-de)]

Also bei den Z80 basierten Controllern im IRQ-Mode 2 ist es anders :-)

Nein, der 8051 hat vorne eine Vektortabelle, wie AVRs z.B. auch.


Gruß

Jobst

[Route_66 H. (route_66)]

Hallo!
Ohne jetzt den Code komplett analysiert zu haben fällt auf den ersten 
Blick dieses auf:
> call PCAINT  ;springe in Interrupt-Serviceroutine
Das ist kein Sprung, sondern ein Unterprogrammaufruf. Wenn jetzt in der 
Service-Routine das RETI kommt, was macht dann der Controller?

[David (Gast)]

Route 66 schrieb:

>> call PCAINT  ;springe in Interrupt-Serviceroutine
> Das ist kein Sprung, sondern ein Unterprogrammaufruf. Wenn jetzt in der
> Service-Routine das RETI kommt, was macht dann der Controller?

Ich bin davon ausgegangen er springt wieder dahin im Programm wo er war, 
als der Interrupt aufgetreten ist...was ist daran falsch?

[spess53 (Gast)]

Hi

>Ich bin davon ausgegangen er springt wieder dahin im Programm wo er war,
>als der Interrupt aufgetreten ist...was ist daran falsch?

Normalerweise ja. Wenn ein Interrupt auftritt wird die aktuelle Adresse 
auf den Stack gelegt und der Sprung zur ISR, der an der zum Interrupt 
gehörenden Stelle in der Interrupttabelle steht, ausgeführt. Bei dir 
steht aber dort kein Sprung, sondern ein Call. Und bei einem Call wird 
automatisch die Adresse des Befehls nach dem Call automatisch auf den 
Stack gelegt. Beim RETI der ISR wird dann die Rückkehradresse vom Stack 
geholt. Dank deinem Call ist das aber nicht die Adresse an der Stelle 
des Interrupts sondern die nach 'call PCAINT'. Und damit geht es bei 
dem, was dort zufällig steht weiter.

MfG Spess

[David (Gast)]

spess53 schrieb:
> Hi
>
>>Ich bin davon ausgegangen er springt wieder dahin im Programm wo er war,
>>als der Interrupt aufgetreten ist...was ist daran falsch?
>
> Normalerweise ja. Wenn ein Interrupt auftritt wird die aktuelle Adresse
> auf den Stack gelegt und der Sprung zur ISR, der an der zum Interrupt
> gehörenden Stelle in der Interrupttabelle steht, ausgeführt. Bei dir
> steht aber dort kein Sprung, sondern ein Call. Und bei einem Call wird
> automatisch die Adresse des Befehls nach dem Call automatisch auf den
> Stack gelegt. Beim RETI der ISR wird dann die Rückkehradresse vom Stack
> geholt. Dank deinem Call ist das aber nicht die Adresse an der Stelle
> des Interrupts sondern die nach 'call PCAINT'. Und damit geht es bei
> dem, was dort zufällig steht weiter.
>
> MfG Spess

Danke, jetzt hab ich das Problem erkannt...d.h. ich müsste entweder das 
"call" durch ein "jmp" ersetzen, oder das reti in die Zeile unterhalb 
von "call PCAINT" schreiben, richtig?
So im Nachhinein wundert es mich aber, dass das Programm überhaupt 
funktioniert - er müsste doch jetzt wenn er nach dem call wieder 
zurückspringt wieder weitergehen im Code, also wieder zu "Init:" und den 
darauf folgenden Befehlen oder?
LG David