Hallo

Es war ja zu befürchten, dass das Programm nicht funktioniert. Es sollte eigentlich die Autoencoder-Funktion aktivieren und dann auf die Flankenwechsel der Odoscheiben warten. Wenn der Wechsel erkannt wird (das jeweilige Rad muss man dazu natürlich von Hand drehen), sollte der aktuelle Zählerstand und die vergangene Zeit seit dem letzten Flankenwechsel ausgegeben werden. Wenn die StatusLED immer rot bleibt (und nichts zu Terminal gesendet wird) sind die Pegel möglicherweise ungünstig gewählt (orginal: 140 für fallend, 160 für steigend).

Auf den ersten Blick scheint hier ein kleiner Bug versteckt zu sein:

Code:
SIGNAL (SIG_ADC)
{
	static unsigned char tmp[2],flag[2],toggle;
	if (autoencode){
	tmp[toggle]= ADCH;
	if (toggle)	ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_RIGHT;
	else ADMUX = (1 <<ADLAR) | (1 <<REFS0) | WHEEL_LEFT;

	if ( (tmp[toggle] < 140) && (flag[toggle] == TRUE)) {
		encoder[toggle] ++;
		flag[toggle] = FALSE;
	}
	if ( (tmp[toggle] > 160) && (flag[toggle] == FALSE)) {
		encoder[toggle] ++;
		flag[toggle] = TRUE;
	}
	toggle ^= 1;
}
(Aus der Datei asuro.c der 2.3er Lib)

tmp[toggle] wird mit dem letzten Messwert des ADC geladen. Allerdings wird nur das Highbyte geladen. Da aber ADLAR in ADMUX ebenfalls gesetzt ist und das Ergebniss deshalb vom ADC linksbündig ausgegeben wird, passt das schon. Weil du aber eh nicht mit dieser Version der Lib arbeiten sollst/willst, kannst du das alles vergessen ;)

Versuchen wir also einen anderen Ansatz:

Ich habe ein Programm geschrieben das mir die Odometriedaten im hyperterminal ausgibt.
Kann dieses Programm schon die Segmente der Codescheiben zählen oder gibt es nur die gemessenen Helligkeitswerte am Terminal aus? Wenn es Segmente zählt, kannst du den nächsten Absatz überspringen.

Die Odo-Sensoren messen die Helligkeit des Codescheibenbereichs, der sich direkt vor den Sensoren befindet. Diese Helligkeit schwankt zwischen einem maximalen (dunkles Segment) und einem minimalen Wert (helles Segment), der Werteverlauf bei drehender Codescheibe ist in etwa sinusförmig. Um in diesen Werten die Flanken der Codesegmente zu erkennen kann man entweder prüfen, ob der aktuell gemessene Wert, im Vergleich zu zuletzt gemessenen Wert,von der unteren Wertebereichshälfte in die obere Wertebereichshälfte gewechselt ist (, oder entsprechend von der oberen in die untere Hälfte). Diese Methode wird am häufigsten angewand, z.B. auch im Codeschnippsel der ADC-ISR oben. Alternativ kann man den Flankenwechsel auch daran erkennen, dass mehrere aufeinander folgende Messungen immer steigende oder fallende Werte ergeben. Wichtig bei allen Anwendung ist die axiale Fixierung des Codescheibenzahnrads, weil eine Abstandsänderung der Scheibe zu den Sensoren die Messwerte beinflussen. Günstig ist zusätzlich eine Abschirmung der Sensoren gegen Fremdlicht.

Um mit den erkannten Flanken die Geschwindigleit zu messen, könnte man blockierend auf aufeinander folgende steigende (oder fallende) Flankenwechsel warten und gleichzeitig eine Zählvariable hochzählen. Der Zählwert steht dann im umgekehrten Verhältniss zur (relativen) Geschwindigkeit. Zur Messung der absoluten Geschwindigkeit ist eine Funktion auf Timerbasis nötig. Bei diesem Ansatz wird die Zählvariable in der ISR des Timers erhöht und beim Flankenwechsel vom Hauptprogramm ausgelesen.

Viel Spaß und Erfolg beim Umsetzen...

Gruß

mic

PS zum homer-Programm:
Der TRIGGERLEVEL sollte etwa der Mittelwert der gemessenen Werte sein. Welchen Wert hat "speed"?