AsuroLib V2.8.0rc1 veröffentlicht

[rossir]

Hallo m.a.r.v.in,

nichts leichter als das:

/****************************************************************************/
/*
  \brief
  Interrupt-Funktion fuer den AD-Wandler. Kann ueber autoencode gesteuert\n
  die Odometrie-Zaehler in encoder hochzaehlen.

  \param
  keine

  \return
  nichts

  \see
  Die globale Variable autoencode wird hier ausgewertet. Ist sie nicht FALSE,\n
  dann wird der AD-Wandler-Wert zum Zaehlen der Odometriewerte in der globalen\n
  Variablen encoder benutzt.\n
  Es wird auch der AD-Wandler-Kanal auf die 'andere' Seite der Odometrie\n
  umgeschaltete und der AD-Wandler neu gestartet.\n
  Somit wird erreicht, dass zumindest die Odometriemessung automatisch erfolgt.
  
  \par  Beispiel:
int main(void) {
	int lSoll=60, rSoll=30, lPwm=lSoll, rPwm=rSoll, delta=50;
	Init();	
	EncoderInit();
	EncoderStart();	
	
	while(1) {
		int lIst=encoder[LEFT],	rIst=encoder[RIGHT];
		EncoderSet(0, 0);	
		
		lPwm+=(delta*lSoll - 1000*lIst)/300;		
		rPwm+=(delta*rSoll - 1000*rIst)/300;
		
		SetMotorPower(lPwm, rPwm);
		Msleep(delta);		
	}
}
*****************************************************************************/
SIGNAL (SIG_ADC) 
{ 
  const static unsigned char admux[]={ 
     (1 << ADLAR) | (1 << REFS0) | WHEEL_LEFT, 
     (1 << ADLAR) | (1 << REFS0) | WHEEL_RIGHT}; 

  static int tmp [2], flag [2]={1,1}; 
  static unsigned char toggle = 0; 

  if (autoencode) 
  { 
    // Aktuellen Sensorwert vom AD-Wandler entnehmen (hier nur high-order-byte).
    int sensor = ADCH;
    // Der AD-Wandler wird schon mal auf den übernächsten Analogkanal eingestellt.
    ADMUX = admux[toggle]; 

    // In tmp wird ein gleitender Mittelwert mitgeführt.
    tmp[toggle] += (sensor-tmp[toggle])>>2;

    // Weicht der aktuelle Sensorwert um mehr als +/- 2 vom gleitenden Mittel ab?
    if (flag[toggle]*(sensor-tmp[toggle]) > 2) 
    { 
       // Dann zähle einen Tick weiter.
       // Und nächster Tick erst wieder bei -/+ 2 Abweichung vom gleitenden Mittel.
       encoder[toggle]++; 
       flag[toggle] = -flag [toggle]; 
    } 
    toggle ^= 1; 
  } 
}

Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal

[Sternthaler]

Hallo m.a.r.v.i.n

schöne neue Funktionen vor allem auch für die LCD-Erweiterung.
Ich selbst nutze diese Erweiterung zwar nicht, aber die Attraktivität der LIB wird dadurch ja nur größer.

Was ich aber besonders gut finde ist der Punkt:
* Interrupt User Funktionen für Timer und A/D Wandler
Damit kann ja wunderbar in das Interruptgeschehen eingegriffen werden, ohne jedesmal die LIB neu zu übersetzen.
Projektbezogene INT-Funktion wird super möglich. Klasse Idee, diese Technik in die LIB zu bringen \/ .


Hallo rossir,

leider muss ich auch m.a.r.v.i.n zustimmen. Seit gestern Nacht starre ich auf deine Funktion und erst durch ein heutiges ECEL-Blatt bin ich schlauer geworden.
Die in tmp[] gebildete Historie in dieser Form zu nutzen, da wollte ich schon vor 'Jahren' selber drauf kommen. Vor allem geht auch der erste Tik fast nie im Excel-Simulator verloren. (Wenn man nicht zu stark an den Schrauben dreht.)
Aber trotz mangelnder Kommentare: Hut ab
(Für den tmp-Startwert würde ich max(ADC-Wert - 20; 0) einsetzen, jedesmal wenn autoencode 'frisch' eingeschaltet wird. Damit wird die 'Anlaufphase' in tmp drastisch reduziert.
Auch den Teiler 2 bei der tmp-Berechnung würde ich auf 8 (mein Spielwert) erhöhen. Damit schrumpt der Abstand zwischen Min- und Maxwerten am ADC von ca. 40 auf nur noch 6 ADC-Einheiten.)
Als Dankeschön gibt es dafür mein EXCEL-Blatt .
Und ausserdem sehe ich gerade deinen Beitrag mit Kommentaren. Die allerdings sind auch nur knapp bemessen. Die Details stecken ja doch 'zwischen' den Semikolons. Motz, Mecker, Schimpf. Das ist leicht

Gruß Sternthaler

[m.a.r.v.i.n]

Hallo rossir,

Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal

ja, so gefällt mir das gleich viel besser. Da habe ich im Gegensatz zu sternthaler nichts mehr zu meckern.

Hallo Sternthaler,

es freut mich, wenn du mal nichts zu meckern hast.
Dein Diagramm macht den Programm Ablauf noch deutlicher.

Vielleicht sollte man den Teiler und den Startwert als Userdefinierbare Konstanten in die myasuro.h aufnehmen.

[rossir]

Hallo Sternthaler,

ich bin da nicht so pingelig: So kannst Du gerne den Code um erhellende Kommentare ergänzen . Vielleicht um Ausschnitte aus diesem Thread?

1)
Anmerkung: Ich habe keinen Teiler 2 zur tmp-Berechnung sondern ich shifte um 2 und deshalb einen Teiler von 4. (Also nicht mehr ganz so weit weg von Deiner 8.) Ich shifte hier, weil ich vermute, dass eine Division zu teuer ist.

2)
Ich wollte der Interruptroutine Platz und Zeit ersparen und habe deshalb auf eine Initialisierung von tmp verzichtet. Statt dessen habe ich den kleinen Teiler 4 gewählt. Dadurch passt sich tmp sehr rapide den ADC-Werten an. (Doppelt so schnell wie ein Teiler 8.) Und verliert in der Realität auch "nie" den ersten Tick. (So muss ASURO auch meist erst mal anfahren.)

3)
Bei Deiner starken Stauchung von 0,025 (im EXCEL-Simulator) kommt der Vorteil von einem Teiler 8 natürlich zur Geltung. Aber, erstens: ist in der Realität die tatsächliche Sensorkurve in solchen Fällen sowieso zu stark verrauscht und zweitens kommt so eine starke Stauchung in der Realität nicht vor. Dann ist eher was kaputt. Ich meine, selbst bei viel Pech beim Löten und mit den Bauteilen, liegt die kleinste realistische Stauchung bei ca. 0,2. ( Übrigens macht der Teiler 4 erst bei einer Stauchung von 0,06 schlapp. )

4)
Allerdings - und hier habe ich noch nicht probiert - könnte es damit (Teiler 8 ) zum ersten mal gelingen, bei Tageslicht, auch ohne eingeschaltetem Encoder-LED, Ticks zu sammeln (allerdings verrauscht). Und das spart Energie - falls es wirklich darauf ankommt.

5)
Vielen Dank für Deinen EXCEL-Simulator. Ich hatte das seinerzeit mit mitgeloggten Orginaldaten durchprobiert, die Daten und Grafiken aber weggeschmissen. Vielleicht reiche ich die noch nach.


Zusammenfassend: Teiler 8 (also shift um 3) geht auch


Und Dankeschön zurück.



Hallo m.a.r.v.i.n,

von den userdefinierbare Konstanten in myasuro.h will ich ja gerade weg

[farratt]

Hallo Leute!

Auch auf die Gefahr hin zu nerven, möchte ich doch noch einmal auf den Schalter-im-Interrupt-Betrieb-Bug hinweisen, der im Thread "Asuro: PollSwitch im Interrupt betrieb" diskutiert wird/wurde. Es wäre sehr schön, wenn einer von den Lib-Leuten mal seine Meinung dazu kund tun könnte...

Gruß farratt

[Sternthaler]

Hallo farratt,
genervt wird hier nicht.

Für die, die den Thread suchen: Asuro: PollSwitch im Interrupt betrieb
Und darin das Beispiel von farrett mit Lösungsvorschlag ist hier.

Die dort von dir gefundene Lösung ist mir nicht einleuchtend.
Spätestens wenn mit dem Aufruf von StartSwitch(), nachdem ein Schleifendurchlauf erfolgte, darin wieder SWITCH_OFF aufgerufen wird, sollte das Verhalten so sein, als ob dein eingebautes SWITCH_ON nicht ausgeführt worden wäre.
Außerdem wird mit dem SWITCH_xxx ja nur? die Datenrichtung vom Interrupt-Pin kontrolliert. Dies deutet mir auf ein Timing-Problem hin.
Ich habe gerade etwas mehr als nur ein Stündchen zu dem Thema hinter mir, und kann auch keine andere Lösung finden, die ich dann auch noch erklären könnte.

Eventuell hilft hier anderen der Hinweis, dass der Interrupt im über das Register MCUCR im Low-Level-Mode betrieben wird, und in diesem Mode das Interrupt-Flag INTF1 im Register GICR nie gesetzt wird. So hat man auch keine Chance dieses Flag selber zu beeinflussen.

@m.a.r.v.i.n
Hast du hier eine andere Lösung in der Tasche? Oder kannst du das erklären?

Gruß Sternthaler

[m.a.r.v.i.n]

Hallo,

ja ich hab ein andere Lösung, die ich auch schon im Thread PollSwitch im Interrupt Betrieb gepostet habe. Ich denke, diese Lösung ist einleuchtender.

Die Änderung ist auch schon im SVN eingecheckt und damit in der nächsten Version drin.

[Sternthaler]

Danke m.a.r.v.i.n,

mit der Lösung, direkt unter die Nase gehalten, kann ich jetzt endlich wieder schlafen. Nur so kann sich das Brett vorm Kopf anfühlen

Gruß Sternthaler

[Valen]

Hallo wieder,

In die install.txt wird gesagt das nur auf einer stelle Pfad angabe geändert werden muß in de Makefile (sicher wenn neue Projekte nicht in der gleiche Verzeichnisebene befinden):

# additional Include path for libraries
LIBPATH = C:/ASURO_SRC/AsuroLib/lib

Aber wenn leute die AVR Compiler auch auf eine 'nicht-default' platz installiert haben mußen sie auch die fölgende stelle ändern denke ich schön:

# Define directories, if needed.
#DIRAVR = C:/WinAVR

Richtig?

[m.a.r.v.i.n]

# Define directories, if needed.
#DIRAVR = C:/WinAVR

Richtig?

Nein, das ist nicht notwendig. Der AVR Compiler wird über die Pfadangaben in der Systemvariablen PATH gefunden. DIRAVR usw. werden zwar im Makefile gesetzt, aber nirgendwo verwendet.