- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Ergebnis 1 bis 10 von 14

Thema: ATtiny2313 ISR wirft mein Timing durcheinander

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    23.07.2011
    Beiträge
    16
    Das ist ja sehr merkwürdig. Worin könnten sich unsere Aufbauten denn unterscheiden... Ich hab den 2313 auf einem Steckbrett mit Leitungen von den Pins zu vier Transistoren (versorgen die LEDs mit Strom, da ich nicht wusste ob mir sonst irgentwann noch der Chip durchbrennt) und als Board das DFRobot USBTinyISP.
    Jetzt bin ich noch verwirrter als vorher^^. Aber danke fürs Austesten.
    Eigentlich war das sowieso nur eine Art Verständnistest; ums mal gemacht zu haben.
    Ich denke mal diese Wartefunktion wird man in der Praxis, also einem etwas "sinnvolleren" Vorhaben sowieso möglichst nicht einsetzen. Inzwischen hab ich die rausgenommen und statt der einen blinkenden jetzt drei LEDs angeschlossen, die im Zeitabstand der Reihe nach leuchten sollen. Dieser Abstand kommt aber nicht mehr durchs Warten zu stande, sondern ist an die Variable, die ich für den OCR0A-Wert hab, gekoppelt. Das funktioniert auch alles so wie ichs mir vorgestellt hab.


    Code:
    #define F_CPU 1000000UL
    
    #include <avr/io.h>
    #include <util/delay.h>
    #include <avr/interrupt.h> 
    
    volatile  uint8_t OCR0Adirection=0, OCR0Avalue=1; 
    			 //0->OCR0A raufzählen 1-> OCR0A runterzählen
    
    	ISR(TIMER0_COMPA_vect){
    
    		if(OCR0Adirection==0){
    			OCR0Avalue += 1;
    			if(OCR0Avalue==254) OCR0Adirection=1;
    		}else
    
    		//if(OCR0Adirection==1){ //kann eingespart werden
    		{
    			OCR0Avalue -= 1;
    			if(OCR0Avalue==1) OCR0Adirection=0;
    		}
    		OCR0A = OCR0Avalue; //nur einmal schreiben, statt zweimal lesen und einmal schreiben
    	}
    
    uint8_t CurrentLED=0;
    
    void LEDleuchten(){
    
    	if(OCR0Avalue==1 || OCR0Avalue==64 || OCR0Avalue==128 
    					|| OCR0Avalue==192 || OCR0Avalue==254){//wenn timer0 am endpunkt
    
    		switch(CurrentLED){//erst die betroffene LED aus
    			case 0: PORTB &= ~(1<<PB4); break;
    			case 1: PORTD &= ~(1<<PD5); break; 
    			case 2: PORTA &= ~(1<<PA0); 
    		}
    
    		CurrentLED++;//dann zur nächsten wechseln
    		if(CurrentLED==3)CurrentLED=0;
    		
    		switch(CurrentLED){//und diese anschalten
    			case 0: PORTB |= (1<<PB4); break; 
    			case 1: PORTD |= (1<<PD5); break; 
    			case 2: PORTA |= (1<<PA0); 
    		}	
    
    		while(OCR0Avalue==1 || OCR0Avalue==64 || OCR0Avalue==128 
    		   || OCR0Avalue==192 || OCR0Avalue==254){}//weil sonst sofort weitergeschaltet wird		
    	}	
    }
    
    int main (void)
    {
            
                   
                    TCCR0A = (1 << COM0A1) | (1 << COM0A0) | (1 << WGM00) | (1 << WGM01);
                    
    
                    //TCCR0B = (1 << CS01);
                    //Prescaler auf CPU/8 -> perfekt^^
    				TCCR0B = (1 << CS00) | (1 << CS01);
    
                    OCR0A = 1; //Startwert, pendelt dann zwischen 0..255
    
                    DDRB = (1 << PB2); //pin PB2 auf Ausgang (das ist OC0A)
    				
    				//blinkende led PB4, PD5, PA0
                   	DDRD |= (1 << PD5);
    				DDRB |= (1 << PB4);
    				DDRA |= (1 << PA0);
    
    				TIMSK = (1 << OCIE0A);
    			   	
    				sei();
    
                    while(1){
    
    					LEDleuchten();
                           
    					
                   		
    
              
                    }
    
    }

  2. #2
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Ein Unterschied könnten die Optionen beim compilieren sein. Wenn man delay verwendet sollte man unbedingt mit Optimierung übersetzen. Auch kann sich die Länger der ISR dadurch verändern. Es macht da schon einen Unterschied ob die ISR 40% oder 90 % der Rechenzeit benötigt.

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    23.07.2011
    Beiträge
    16
    Bei Optimierungen steht bei mir im Avr-Studio 4 -Os aber weiß nicht was das genau bedeutet. Dass man die bei delay an haben sollte, hab ich auch schonmal gelesen, und dachte die wären default-mäßig an.

  4. #4
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.220
    Mit -Os kompiliere ich auch. Muss doch was mit dem Aufbau zu tun haben. Ich habe das Eval-Board von Pollin.
    Wie nach deinem letzten Code die Led an PortA leuchtet würde mich interessieren.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    23.07.2011
    Beiträge
    16
    Die leuchtet eigentlich wie die anderen auch, oder hast du irgenteine Unstimmigkeit entdeckt?
    Das Einzige was mich etwas wundert ist, wieso am Anfang die an PD5 leuchtet. Es sollte doch mit PB4 anfangen..

  6. #6
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.220
    Ich habe einen Quarz dran, daher ist der PortA bei mir nicht verfügbar, das ist die Unstimmigkeit.
    Du schaltetst die Leds aus, erhöhst und schaltest dann ein.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    23.07.2011
    Beiträge
    16
    Ja, so kriegt man zwar nicht ohne Weiteres die perfekten Zeitabstände hin (bei delayms gibt mans ja direkt an), aber das auch nicht besonders schlimm.
    Kann es sein, dass wenn man bei einem 0..255-Timer, bei dem man sowohl die OCR-Compare-Match ISR, als auch die Overflow-ISR verwenden will und man einen PRescaler von 0 oder 8 nimmt, die Compare-Match ISR gar nicht mehr zum Zug kommt?

    Ich hab nämlich versucht eine Hardware-PWM und und eine Software-PWM gleichzeitig am selben Timer zu benutzen. Wenn ich den 64er Prescaler benutze (damit fadet die LED an der Hardware-PWM optimal) und die selbst gemachte Counter-Variable der Software-PWM immer von der Overflow-ISR weiterzählen lasse, läuft selbiges natürlich 256mal langsamer ab, als alles an der Hardware-PWM; aber es läuft.
    Als ich die Software-PWM dann aber beschleunigen wollte, indem ich den Prescaler runtersetzte (egal, dass die LED an der Hardware-PWM dann nur noch flackert), hat sich an der Software-PWM-LED gar nichts mehr getan.
    Ist es vielleicht so, dass die OCR-Compare-Match-ISR eine höhere Priorität hat, als die Overflow-ISR und sich die Overflow-ISR dann schon jedesmal anstellt, aber dass die Compare-Match-ISR selber so lange läuft, dass die nächste schon ansteht, sobald eine fertig ist und sich somit immer die Compare-Match-ISRs vordrängeln?

    So siehts bei mir aus:
    Code:
    #define F_CPU 1000000UL
    
    #include <avr/io.h>
    #include <util/delay.h>
    #include <avr/interrupt.h> 
    
    volatile  uint8_t OCR0Adirection=0, OCR0Avalue=1; 
    			 //0->OCR0A raufzählen 1-> OCR0A runterzählen
    
    	ISR(TIMER0_COMPA_vect){
    
    		if(OCR0Adirection==0){
    			OCR0Avalue += 1;
    			if(OCR0Avalue==254) OCR0Adirection=1;
    		}else
    
    		//if(OCR0Adirection==1){ //kann eingespart werden
    		{
    			OCR0Avalue -= 1;
    			if(OCR0Avalue==1) OCR0Adirection=0;
    		}
    		OCR0A = OCR0Avalue; //nur einmal schreiben, statt zweimal lesen und einmal schreiben
    	}
    
    
    /*	Erstmal mit nur einer LED, nämlich PB4.Nachgebildet werden soll eine Fast PWM. Bei jedem
    	Overflow des Timers wird die Funktion einmal ausgeführt und erhöht den Counter (softTCNT).
    	Trifft dieser den OCR-Wert der LED, wird diese angeschaltet. Erreicht der Counter sein max.
    	und wird wieder auf 0 gesetzt, wird die LED wieder ausgeschaltet.
    	Bei der Hardware-PWM kann man wählen, ob man den OCR-Wert in der Hauptschleife mit im Abstand
    	von z.B. 12ms um einen bestimmten Wert heraufsetzt oder das (besser) in einer ISR macht.
    	In letzterem Fall muss darauf geachtet werden, dass die den OCR verändernde ISR nicht zu
    	schnell hintereinander aufgerufen wird, da man sonst wesentlich weniger als 12ms zwischen
    	den LED-Helligkeiten haben kann und sie somit viel zu schnell fadet. Deshalb sollte der
    	Prescaler so hoch eingestellt werden, dass die LED gerade noch nicht-flackernd aussieht
    	und der Wert um den der OCR jedes Mal verändert wird, sollte möglichst klein sein.
    	Bei gleichzeitiger Verwendung einer Hardware- und einer Software-PWM kann dieser hohe
    	Prescaler zum Problem werden. Denn während die Hardware-PWM ihren Counter 256 mal erhöht, tut
    	dies die Software-PWM (bei Verwendung des selben Timers) nur einmal.
    */
    volatile uint8_t softLED1direction=0, softLED1OCR=0, softTCNT=0;
    	ISR(TIMER0_OVF_vect){ //software PWM
    		softTCNT++;//counter bei jedem aufruf weiterzählen
    		if(softTCNT==255){//einmal pro counter-runde, also am ende, bei 255
    			softTCNT=0;//wird der counter auf anfang gesetzt
    			PORTB &= ~(1<<PB4);//die led geht aus
    			if(softLED1direction==0){//und es wird der OCR-wert der LED weitergezählt
    				softLED1OCR++;//und zwar entweder rauf
    				if(softLED1OCR==255) softLED1direction=1;
    			} else{//oder runter, je nach direction
    				softLED1OCR--;
    				if(softLED1OCR==0) softLED1direction=0;
    			}
    		}
    
    		if(softTCNT == softLED1OCR){//sobald der counter in einer runde (0..255) den OCR der
    			PORTB |= (1<<PB4);//LED erreicht, wird diese angeschaltet
    		}
    		
    
    	}/*	Theoretisch sollte diese soft-PWM genauso schnell faden wie die Hardware-PWM (oben)
    		denn auch hier wird der OCR einmal pro Counter-Zyklus verändert. Jedoch läuft das Ganze
    		255 mal langsamer ab, sofern man nichts am Prescaler ändert oder nicht einen Timer 
    		verwendet, mit einem Modus, dessen obere Zählgrenze kleiner (in OCR gesetzt) ist
    		und der diese Overflow-ISR somit ofter, als alle 255 Takte ausführt.
    		*/
    
    
    /* //zum Testen von Hard- und Software-PWM gleichzeitig, erstmal diese Funktion rausnehmen
    uint8_t CurrentLED=0;
    
    void LEDleuchten(){
    
    	if(OCR0Avalue==1 || OCR0Avalue==64 || OCR0Avalue==128 
    					|| OCR0Avalue==192 || OCR0Avalue==254){//wenn timer0 am endpunkt
    
    		switch(CurrentLED){//erst die betroffene LED aus
    			case 0: PORTB &= ~(1<<PB4); break;
    			case 1: PORTD &= ~(1<<PD5); break; 
    			case 2: PORTA &= ~(1<<PA0); 
    		}
    
    		CurrentLED++;//dann zur nächsten wechseln
    		if(CurrentLED==3)CurrentLED=0;
    		
    		switch(CurrentLED){//und diese anschalten
    			case 0: PORTB |= (1<<PB4); break; 
    			case 1: PORTD |= (1<<PD5); break; 
    			case 2: PORTA |= (1<<PA0); 
    		}	
    
    		while(OCR0Avalue==1 || OCR0Avalue==64 || OCR0Avalue==128 
    		   || OCR0Avalue==192 || OCR0Avalue==254){}//weil sonst sofort weitergeschaltet wird		
    	}	
    }*/
    
    int main (void)
    {
            
                   
                    TCCR0A = (1 << COM0A1) | (1 << COM0A0) | (1 << WGM00) | (1 << WGM01);
                    
    
    				//TCCR0B = (1 << CS00);//no Prescaler
                    TCCR0B = (1 << CS01);//Prescaler CPU/8 
    				//TCCR0B = (1 << CS00) | (1 << CS01);//Prescaler CPU/64 
    				//TCCR0B = (1 << CS02);//Prescaler CPU/256
    				//TCCR0B = (1 << CS00) | (1 << CS02);//Prescaler CPU/1024
    
                    OCR0A = 1; //Startwert, pendelt dann zwischen 0..255
    
                    DDRB = (1 << PB2); //pin PB2 auf Ausgang (das ist OC0A)
    				
    				//blinkende led PB4, PD5, PA0
                   	DDRD |= (1 << PD5);
    				DDRB |= (1 << PB4);
    				DDRA |= (1 << PA0);
    
    				//ISRs für OCR0A Compare Match und für Timer Overflow aktivieren
    				TIMSK = (1 << OCIE0A) | (1 << TOIE0);
    			   	
    				sei();
    
                    while(1){
    
    					//LEDleuchten();
                           
    					
                   		
    
              
                    }
    
    }

Ähnliche Themen

  1. Atmega8 identify wirft wechselnde id
    Von apohero im Forum AVR Hardwarethemen
    Antworten: 8
    Letzter Beitrag: 20.03.2008, 14:16
  2. AVR controller.. bin durcheinander
    Von Robin1508 im Forum AVR Hardwarethemen
    Antworten: 19
    Letzter Beitrag: 11.11.2007, 21:35
  3. Antworten: 6
    Letzter Beitrag: 09.09.2006, 10:46
  4. Motor bringt Controller durcheinander
    Von scales im Forum Elektronik
    Antworten: 8
    Letzter Beitrag: 01.09.2006, 18:36
  5. RN-Control piept bei Programmablauf - kommt durcheinander
    Von robinhh im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 5
    Letzter Beitrag: 10.02.2006, 09:53

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Labornetzteil AliExpress