ATmega168A: Software PWM Periodendauer verändert sich, woran kann das liegen?

[oberallgeier]

.. ein Programm .. das analoge Spannungswerte per ADC-Wandlung einliest und abhängig von diesen ein PWM Signal ausgibt .. Bei genauerem Nachsehen fiel mir auf, dass sich bei kleineren Eingangsspannungen am ADC Pin die Periodendauer des Software-PWM Signals verlängert ..

Kann es sein, dass Du bei Deiner Software PWM die Pulsdauer veränderst und die Pause gleich lang lässt? Dann ändert sich natürlich die Periode im gleichen Maß wie der Puls.

[Dracyria]

...bei Deiner Software PWM die Pulsdauer veränderst und die Pause gleich lang lässt?

Hi danke schonmal für die schnelle Anregung aber ich glaube dass sich die Periodendauer eigentlich nicht verändern sollte, ich zähle ja in meiner For-Schleife immer wieder von 0 bis 511 und schalte den Pin dann für eine bestimmte Zeit auf High und für den Rest der Schleife auf Low.
Müsste dann nicht exakt das herauskommen, was mir die Hardware PWM liefert, nur langsamer eben? Oder gibt es Effekte, die auftreten können, wo mein Zähler dann nicht jeden Takt +1 zählt, sondern auf dem Wert bleibt und sich so die Periodendauer ungewollt verlängert?

[oberallgeier]

.. ich zähle ja in meiner For-Schleife immer wieder von 0 bis 511 ... Oder gibt es Effekte, die auftreten können, wo mein Zähler dann nicht jeden Takt +1 zählt ..

Leider zeigst Du nicht alle Initialisierung(en), nur Dein main-Modul. Was der ADC tut sieht man nicht, da auch die Funktion readADC ein GEheimnis bleibt.

Wie wird der ADC ausgelesen? Vermutlich über ne ISR. Nun kann der Controller zwar auf einer separaten WErkbank analoge Daten wandeln - oder Timer incrementieren, aber ne ISR ist ein separater Maschinencode-Abschnitt - der seine Zeit braucht. Sobald aber ISR mit im Spiel sind, ist es mit der zeitlichen Konstanz von Schleifen vorbei - abgesehen von sonstigen Einflüssen wie z.B. unterschiedlichen Laufzeiten von if-Schleifen . . .

[Dracyria]

Hi, stimmt ich hätte ja auch mal den kompletten Code nehmen können.
Ist alles der Reihe nach aufgebaut, ohne Interrupts.
Hier noch einmal das, was vor meiner Hauptschleife steht:

#define F_CPU 8000000UL //Geschwindigkeit des MCs 10MHz da 3.3V Versorgungsspannung
#include <util/delay.h> //Damit Verzögerungszeiten angegeben werden können
#include <avr/io.h> //Für Ein- und Ausgänge
#include <avr/pgmspace.h>
#include <inttypes.h>
#include <math.h>

//////////////////////////////////////////////////////////////////////////

//ADC Messung mit Dummyreadout
uint16_t readADC(uint8_t channel) 
{
	//Variablendefinition ohne Vorzeichen
	uint8_t i;
	uint16_t result = 0;
	
	// Den ADC aktivieren, kein Prescaling
	ADCSRA = (1<<ADEN);
	
	//Kanal des Multiplexers wählen, AVcc als Referenzspannung einstellen
	ADMUX = channel | (1<<REFS0); 
	
	// Dummyreadout
	ADCSRA |= (1<<ADSC);
	while(ADCSRA & (1<<ADSC));
	
	//Spannung auslesen und Durchschnittswert ausrechnen.
	for(i=0; i<3; i++) 
	{
		
		//Einmalige Wandlung
		ADCSRA |= (1<<ADSC); 
		
		//Auf Ergebnis warten
		while(ADCSRA & (1<<ADSC)); 
		
		//Ergebnis in Variable "result" speichern
		result += ADCW;
	}
	
	// ADC wieder deaktivieren
	ADCSRA &= ~(1<<ADEN);
	
	result /= 3;
	
	return result;
}

Ahh klasse habs nun gerafft wie das mit der Box geht...immerhin schonmal das ^^

[schorsch_76]

Fällt dir da was auf?

#define F_CPU 8000000UL //Geschwindigkeit des MCs 10MHz da 3.3V Versorgungsspannung

[oberallgeier]

Gute Frage, schorsch! Hatte ich übersehen. Aber das ist ja ein fester Bezugswert. Wie sollten daraus variable Ergebnisse entstehen? Ausserdem ist heut sowieso der Termin des TO.

[schorsch_76]

Na ich dachte mir, wenn im Kommentar eben 10 MHz stehen und mit 8 MHz dann die usleep etc Funktionen arbeiten kann daraus dann schon ein Unterschied entstehen ....