PWM mit zufälligem Duty cycle

[Anonym (Gast)]

Moin,
ich möchte mit meinem Atmega 8515 zwei unterschiedliche PWM Signale 
erzeugen deren Duty-cycle sich alle 5 sec. auf einen (mehr oder weniger) 
zufälligen Wert ändert. Leider bekomme ich zwei Signale mit einem 
konstanten Duty-cycle heraus. Ich hoffe jmd findet meinen Fehler im 
Quellcode.

#include <avr/io.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include <stdio.h>
#include <util/delay.h>
#define F_CPU 1000000UL

int main(void)
{
int i11, i12, i21, i22;
DDRD = 0xff;
DDRE = 0xff;
ICR1 = 64000;    

TCCR1A = (1<<WGM11)|(1<<COM1A1)|(1<<COM1B1);
TCCR1B = (1<<WGM12)|(1<<WGM13)|(1<<CS10)|(1<<CS11);
TIMSK = (1<<OCIE1A)|(1<<OCIE1B)|(1<<TOIE1);

sei();                      
while(1)
{  
  i11=rand()%64;    //Zufall 0-63
  i12=rand()%1000;  //Zufall 0-999
  OCR1A = i11*1000 + i12;
  
  i21=rand()%64;    //Zufall 0-63
  i22=rand()%1000;  //Zufall 0-999
  OCR1B = i21*1000 + i22;
  
  _delay_ms(5000);
}}

[Jürgen S. (jurs)]

Anonym schrieb:
> ich möchte mit meinem Atmega 8515 zwei unterschiedliche PWM Signale
> erzeugen deren Duty-cycle sich alle 5 sec. auf einen (mehr oder weniger)
> zufälligen Wert ändert. Leider bekomme ich zwei Signale mit einem
> konstanten Duty-cycle heraus.

Möchtest Du "zufällige duty cycle Werte" oder "zufällige 
Helligkeitswerte" steuern?

Falls es um Helligkeit geht, wäre zu beachten, dass die Helligkeit NICHT 
linear mit dem duty cycle steigt:
http://www.mikrocontroller.net/articles/LED-Fading

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Anonym schrieb:
> TIMSK = (1<<OCIE1A)|(1<<OCIE1B)|(1<<TOIE1);

Du gibst zwar alle Interrupts des Timers frei, diese werden aber in dem 
sichtbaren Teil deines Programmes gar nicht behandelt. Vermutlich wird 
also der MC bei jedem Versuch, eine ISR anzuspringen, bei Reset wieder 
neu anfangen.
Für so etwas braucht man auch gar keine Interrupts. Du schreibst 
lediglich in OC1A und OC1B werte, den Rest macht der MC alleine. Auch 
der Overflow Interrupt ist unnötig.

[Anonym (Gast)]

Ich habe die Zeile mal auskommentiert und siehe da der Duty cycle ist 
zufällig.
>> TIMSK = (1<<OCIE1A)|(1<<OCIE1B)|(1<<TOIE1);

Allerdings bleibt dieser nicht wie erwünscht über 5 sec konstant. Hat 
die "delay" funktion eine zeitliche Beschränkung

[Karl H. (kbuchegg)]

Anonym schrieb:

> Allerdings bleibt dieser nicht wie erwünscht über 5 sec konstant. Hat
> die "delay" funktion eine zeitliche Beschränkung

Nicht im Bereich 5 Sekunden. Ok, auf die Mykrosekunde wird die 
Verzögerung nicht stimmen, aber ich glaube, darum gehts dir nicht.

Da wird halt das

#define F_CPU 1000000UL

nicht mit der Realität übereinstimmen.

[Anonym (Gast)]

Du hast recht, mir kommt es nicht auf die millisekunde an. Aber das 
auskommentieren von
#define F_CPU 1000000UL
bringt auch keinen Erfolg

[Karl H. (kbuchegg)]

Anonym schrieb:
> Du hast recht, mir kommt es nicht auf die millisekunde an. Aber das
> auskommentieren von
> #define F_CPU 1000000UL
> bringt auch keinen Erfolg

Es geht nicht ums auskommentieren.
Es geht darum, dass die 1 Million, die du da hinschreibst mit der realen 
Taktfrequenz des µC übereinstimmen muss!

Die Angabe bei F_CPU ist die Information an den Compiler wie schnell der 
µC tatsächlich läuft und nicht die Vorgabe wie schnell du den µC gerne 
laufen hättest.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:

> Die Angabe bei F_CPU ist die Information an den Compiler wie schnell der
> µC tatsächlich läuft und nicht die Vorgabe wie schnell du den µC gerne
> laufen hättest.

Beispiel:
Schreibst du da

#define F_CPU 1000000UL

dann berechnet der Compiler die Anzahl an Umdrehungen, die der µC beim 
Däumchen drehen für

   _delay_ms( 5000 );

machen muss für diese Taktfrequenz von 1Mhz, da er ja durch die 1Mhz 
weiß, wie lange der µC für einmal Däumchen drehen braucht.

Ist der µC aber tatsächlich 4 mal schneller, weil er mit 4Mhz getaktet 
wird und nicht mit 1Mhz, dann stimmt die errechnete Zahl an notwendigen 
Umdrehungen natürlich nicht. Der µC muss jetzt wesentlich mehr 
Umdrehungen des Daumens machen (4 mal so viele), damit das wieder 5 
Sekunden dauert.

[Anonym (Gast)]

D.h. wenn ich den Takt zu niedrig angebe braucht er weniger als 5 sec, 
wenn ich ihn zu groß angebe braucht er mehr als 5sec? Ich habe 
verschiedene Takte durchprobiert und es tritt nicht die geringste 
Zeitverzögerung ein.

[Karl H. (kbuchegg)]

Anonym schrieb:
> D.h. wenn ich den Takt zu niedrig angebe braucht er weniger als 5 sec,
> wenn ich ihn zu groß angebe braucht er mehr als 5sec? Ich habe
> verschiedene Takte durchprobiert und es tritt nicht die geringste
> Zeitverzögerung ein.


Dann zeig dein Programm, so wie es jetzt ist.
Das klingt dann stark danach, als ob du immer noch Resets im Programm 
hast, was auf einen weiteren Fehler hindeutet.

ALternativ probiere mal folgendes

#include <avr/io.h>
#include <stdlib.h>
#include <util/delay.h>

#define F_CPU 1000000UL

int main(void)
{
  DDRD = ( 1 << PD5 );

  while(1)
  {
    PORTD |= ( 1 << PD5 );
    _delay_ms( 1000 );

    PORTD &= ~( 1 << PD5 );
    _delay_ms( 1000 );
  }
}

an PD5 hast du offenbar irgendeine Möglichkeit was zu messen (eine 
LED?). Der Ausgang muss 1 Sekunde High und 1 Sekunde Low sein.
WEnn er das ist, dann ist die Taktfrequenz des µC tatsächlich 1Mhz. Wenn 
nicht, dann musst du eben rausfinden, wie schnell der µC wirklich 
taktet. Hast du einen QUarz drann, dann wird der wohl aktiv sein und es 
gilt die Quarzfrequenz. Hast du .... das kann ich aber von hier aus 
nicht sehen.

[Anonym (Gast)]

So sieht mein Programm jetzt aus:

#include <avr/io.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include <stdio.h>
#include <util/delay.h>
#define F_CPU 16000000UL

int main(void)
{
int i11, i12, i21, i22, zahl;
DDRD = 0xff;
DDRE = 0xff;
ICR1 = 64000;    

TCCR1A = (1<<WGM11)|(1<<COM1A1)|(1<<COM1B1);
TCCR1B = (1<<WGM12)|(1<<WGM13)|(1<<CS10)|(1<<CS11);
//TIMSK = (1<<OCIE1A)|(1<<OCIE1B)|(1<<TOIE1);

sei();                      
while(1)
{  
  i11=rand()%64;    //Zufall 0-63
  i12=rand()%1000;  //Zufall 0-999
  OCR1A = i11*1000 + i12;
  
  i21=rand()%64;    //Zufall 0-63
  i22=rand()%1000;  //Zufall 0-999
  OCR1B = i21*1000 + i22;
  
  _delay_ms(5000);
}}

keine Verzögerung zu sehen.
Dein anderer Tipp hat mich bislang auch nicht weitergebracht. Habe 1, 
8,16 und 3,68 MHz probiert und die LED blinkt zu schnell

[Karl H. (kbuchegg)]

Anonym schrieb:

> Dein anderer Tipp hat mich bislang auch nicht weitergebracht. Habe 1,
> 8,16 und 3,68 MHz probiert und die LED blinkt zu schnell


Das stinkt für mich danach als ob dein µC Resets macht.

Was ist dann an den Pins angeschlossen?
LED?
Hoffentlich mit Vorwiderstand.

[Anonym (Gast)]

Ja led´s und na klar mit Vorwiderstand

[Karl H. (kbuchegg)]

Blöde Frage:
Der OPtimizer vom Compiler steht aber schon auf -Os

[Anonym (Gast)]

Kann ich dir nicht sagen, ich benutze das STK500 zum programmieren

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Anonym schrieb:
> #include <util/delay.h>
> #define F_CPU 16000000UL

Ist da nicht die Reihenfolge falsch? Ich definiere meine F_CPU über AVR 
Studio, aber ich kann mich erinnern, das man delay.h erst einbinden 
sollte, nachdem F_CPU definiert ist, damit delay.h eine Chance hat, sich 
zu justieren.

Anonym schrieb:
> Kann ich dir nicht sagen, ich benutze das STK500 zum programmieren

Das hat damit nichts zu tun, die Optimierung wird in den 
Compileroptionen eingestellt, der Programmer kregt nur noch das Ergebnis 
zu sehen. Ein guter Anhaltspunkt ist die Grösse des Codes, falls dir das 
nach dem Kompilieren angezeigt wird.

Hier mal ein Screenshot vom AVR Studio 4

[Anonym (Gast)]

Das AVR Studio benutze ich auch

[Anonym (Gast)]

Aber 5.0

[Anonym (Gast)]

Das Problem ist gelöst. Die Verschiebung von F_CPU und delay.h war der 
Knackpunkt.

Vielen Vielen Dank