Forum: Mikrocontroller und Digitale Elektronik Software-PWM nicht störfest


von Andy (Gast)


Lesenswert?

Hallo!

Ich habe ein Problem mit meiner Software-PWM-Lösung. Grundsätzlich 
funktioniert alles einwandfrei - ich erzeuge damit 3 voneinander 
unabhängige PWM-Signale, die direkt einen LED-Treiber ansteuern. Als 
Auflösung habe ich 8bit bei einer Frequenz von ca. 305Hz. Der uC 
empfängt nebenbei DALI-Signale und wertet diese aus. uc ist ein 
ATMega328p.
Nun zu meinem Problem: Wenn ich ein niedriges Dimm-Level eingestellt 
habe (ca. 10%) und ich viel Daten von der DALI-Schnittstelle 
hintereinander bekommen, dann flackern die LEDs ein bisschen. Es ist 
nicht so viel, aber genug, um als störend empfunden zu werden. Was 
könnte das sein? Die PWM-Erzeugung läuft ganz in einer Timer-Routine ab 
- sollte also in gleichmäßigen Abständen ausgeführt werden. Aber 
irgendetwas scheint da zu stören.
Mir ist klar, dass ihr mir keine Ferndiagnose stellen könnt, aber 
vielleicht hat von euch irgendwer Erfahrung damit und hatte schon so ein 
Problem.

Vielen Dank!

mfg Andy


PS: Hier noch meine Soft-PWM - vielleicht hilfts:
1
SIGNAL(TIMER0_OVF_vect)
2
{
3
  static uint8_t pwm,channelTmp[3];
4
5
  //PWM-Signale erzeugen
6
  pwm -= 1;
7
  if(pwm == 0)
8
  {
9
    LED_PORTD &= ~(0x60);
10
    LED_PORTB &= ~(0x08);
11
    pwm = PWM_RESOLUTION;
12
        for(uint8_t i=0;i<3;i++)
13
            channelTmp[i] = channel[i];
14
  }
15
16
  // CHANNEL 1
17
  if(pwm <= channelTmp[0])
18
    sbi(LED_PORTD, CHANNEL1);
19
20
  // CHANNEL 2
21
  if(pwm <= channelTmp[1])
22
    sbi(LED_PORTD, CHANNEL2);
23
24
  // CHANNEL 3
25
  if(pwm <= channelTmp[2])
26
    sbi(LED_PORTB, CHANNEL3);
27
}

von Εrnst B. (ernst)


Lesenswert?

Hat denn der übrige Code größere Blöcke, die mit cli/sei oder 
ATOMIC_BLOCK gesperrt sind?

Aber auch wenn nicht: etwas Jitter ist immer bei soft-pwm, allein wg. 
der unterschiedlichen Ausführungszeit einzelner Opcodes.

von Falk B. (falk)


Lesenswert?

@  Andy (Gast)

>Nun zu meinem Problem: Wenn ich ein niedriges Dimm-Level eingestellt
>habe (ca. 10%) und ich viel Daten von der DALI-Schnittstelle
>hintereinander bekommen, dann flackern die LEDs ein bisschen.

>könnte das sein? Die PWM-Erzeugung läuft ganz in einer Timer-Routine ab
>- sollte also in gleichmäßigen Abständen ausgeführt werden. Aber
>irgendetwas scheint da zu stören.

Sind noch andere Interrupts aktiv? Die können dein Timing beeinflussen.

>Mir ist klar, dass ihr mir keine Ferndiagnose stellen könnt, aber

Ach was?

>PS: Hier noch meine Soft-PWM - vielleicht hilfts:

Nö. Poste VOLLSTÄNDIGEN Code im ANHANG. Siehe Netiquette.

MFG
Falk

von Falk B. (falk)


Lesenswert?

@  ?rnst B? (ernst)

>Aber auch wenn nicht: etwas Jitter ist immer bei soft-pwm, allein wg.
>der unterschiedlichen Ausführungszeit einzelner Opcodes.

Ja, das sind beim AVR max. 3 Takte Jitter, die sieht kein Mensch an 
einer LED.

MFG
Falk

von Εrnst B. (ernst)


Lesenswert?

Falk Brunner schrieb:
>>Aber auch wenn nicht: etwas Jitter ist immer bei soft-pwm, allein wg.
>>der unterschiedlichen Ausführungszeit einzelner Opcodes.
>
> Ja, das sind beim AVR max. 3 Takte Jitter, die sieht kein Mensch an
> einer LED.

Stimmt natürlich auch...

Beim Video-Signal-Erzeugen sieht man da öfter Tricksereien, um diesen 
Jitter loszuwerden, wär aber bei einer 300Hz LED PWM wohl wirklich 
overkill ;)

von Andy (Gast)


Lesenswert?

Danke für eure Antworten.
Ich kann leider nicht den gesamten Code posten (Teil eines 
Firmenprojekts).
Mit cli/sei bzw. ATOMIC_BLOCK ist nichts gesperrt.
Was ich mir nicht ganz erklären kann: Warum kann es durch anderen Code 
zu solchen Störungen kommen? Sollte ein Timer nicht immer gleichmäßig 
ausgeführt werden? Und der Code in der Timer-Interrupt-Routine ist doch 
auch nichts aufwändiges....
Gibt es vielleicht eine andere Methode, um störsicherer PWM-Signale zu 
erzeugen??

lg
Andy

von Peter (Gast)


Lesenswert?

Andy schrieb:
> Sollte ein Timer nicht immer gleichmäßig
> ausgeführt werden?

ja, aber nur so lange kein andere Interupt aktiv ist. Wenn du noch 
weiter interupts hast die eventuell zu lange brauchen dann könnte 
soetwas passieren.

von Karl H. (kbuchegg)


Lesenswert?

Andy schrieb:

> Mit cli/sei bzw. ATOMIC_BLOCK ist nichts gesperrt.

Das kannst nur du wissen.

> Was ich mir nicht ganz erklären kann: Warum kann es durch anderen Code
> zu solchen Störungen kommen? Sollte ein Timer nicht immer gleichmäßig
> ausgeführt werden?

Das tut er auch, solange man ihn lässt.

Wenn er es daher nicht tut, dann hat ihn anderer Code 'behindert'. Und 
das geht wiederrum nur wenn an den Konfigurationsregistern oder am 
globalen Interrupt Flag rumgespielt wird oder eine andere ISR zuviel 
Zeit gebraucht hat.

Aber da du den Code ja nicht herzeigst ...

von Andy (Gast)


Lesenswert?

OK, das ist ein guter Hinweis. Kann man beim 328er Prioritäten vergeben, 
z.B. dass dieser Timer-Interrupt immer sofort ausgeführt werden muss??

lg

von Karl H. (kbuchegg)


Lesenswert?

Andy schrieb:
> OK, das ist ein guter Hinweis. Kann man beim 328er Prioritäten vergeben,
> z.B. dass dieser Timer-Interrupt immer sofort ausgeführt werden muss??
>

Nein

von Peter D. (peda)


Lesenswert?

Da der AVR keine Interruptprioritäten hat, verzögern alle anderen 
Interrupts Deine SW-PWM.

Welche Interrupts benutzt denn das Dali?
Du solltest versuchen, diese Interrupts so kurz wie möglich zu halten.
Also alles was geht, ins Main auslagern.

Das Attribut ISR_NOBLOCK ist leider bei UART, I2C usw. nicht möglich, da 
diese das Interruptflag nicht automatisch löschen und der Stack läuft 
sofort über.


Peter

von Andy (Gast)


Lesenswert?

Danke für die Tipps.
Nebenbei werden noch 2 andere Timer-Routinen und ein externer Interrupt 
benutzt. Mal sehen, was sich da noch optimieren lässt...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.