AsuroLib V2.8.0rc1 veröffentlicht

Hallo,

Eine neue Release der ASURO Library steht zum Download auf Sourceforge bereit. Noch ist es keine endgültige Version sondern nur ein Release Candidate. Große Änderungen sind aber nicht mehr zu erwarten.

Die wichtigsten Änderungen gegenüber der Vorgänger Version sind:

* Unterstützung für ATmega168 Prozessoren
* neue Funktion ReadADC zur A/D Wandler Abfrage
* neue Funktion PrintLCD_p zur Ausgabe von Strings aus dem Programmspeicher
* neue Funktion SetCharLCD zum Setzen von Sonderzeichen
* neue Funktion PollSwitchLCD zur Abfrage der Tasten des Arexx LCD
* neue Funktion MyMotorSpeed die Korrekturwerte aus der myasuro.h berücksichtigt.
* neue Funktion SerPrint_p zur Ausgabe von Strings aus dem Programmspeicher
* UART Baudrate einstellbar durch Define
* Interrupt User Funktionen für Timer und A/D Wandler
* AVR Studio Projektfiles für alle Beispielprojekte

Viel Spaß beim Ausprobieren.
Eine Exe Installer Version mit der AsuroFlash IDE folgt in Kürze.

schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?

Zitat:

---

schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?

---

Ich denke das hat noch Zeit.

Die Win32 Installer Version der Version 2.8.0rc1 mit der AsuroFlash IDE (aka eierlegende Wollmich-Sau) von Osser steht nun ebenfalls zum Download bereit.

Hallo,

(... Nachbarn, bitte verzei mir fur meiner deutch. Englisch geht mir ganz leichter ab, und ich habe keine ahnung wo ich die deutche special zeichen wie umlaut und so auf mein klavier finden kan. Ich hoffe sie konnen es ohne auch verstehen.)

Also, zur sache. Die AFSetup_v280rc1.exe sagt er wurde Asuro Library 2.7.1 installieren wenn ich mit meiner maus uber dieser component bewegt. Dah stimmt etwas nicht, oder?

Hallo,

danke für die Info. Das ist noch ein kleiner Fehler im Install-Skript. Es wird aber die richtige Version installiert.

Hallo,

Gut, ich werde es mal weiter ausprobieren.

Hello Valen. if it is easier for you, you can speak english also, most of us will understand and ill try to translate. Welcome to the forum!

---

Hallo Valen. wenn es einfach er ist, kannst du auch gern eglisch sprechen. die meisten von uns werden es wohl verstehen, und ich werde versuchen zu übersetzen.

Danke, aber ich wölte doch versuchen deutsch zu schreiben. Ich bin auch schön for einiger zeit angefangen 'Das Boot' von Lothar-Günther Buchheim zu lesen. Geht leider nicht so schnell wie english aber gut genug. Und habe nuhn auch herausgefunden wie ich die korrekte zeichen aus meinen UK-klavier tasten zauberen muß. Ich denke ich werde es schön klappen. Übung, übung, übung.

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

ich finde es schade, dass man immer noch die Werte für

• MY_ODO_DARK_VALUE_R
  MY_ODO_LIGHT_VALUE_R
  MY_ODO_DARK_VALUE_L
  MY_ODO_LIGHT_VALUE_L

selbst ermitteln muss. Dabei wurden doch im Thread "Regelung fürs Geradeausfahren" schöne Ideen gesammelt wie's besser gehen könnte. Und dabei auch noch Umgebungslichtstabil ist. Hier einfach mal mein Vorschlag. Vielleicht findet er ja seinen Weg in die nächste Lib ?!

Code:

---

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 = FALSE;

  if (autoencode)
  {
    int sensor = ADCH;
        ADMUX =        admux[toggle];

    tmp[toggle]+=(sensor-tmp[toggle])>>2;
    if (flag[toggle]*(sensor-tmp[toggle]) > 2)
    {
            encoder[toggle]++;
              flag [toggle] = -flag [toggle];
    }
        toggle^=1;
  }
}

---

Bei mir macht der Code (auch bei schlechten Sensorwerten) eine gute Figur und ist auch bei allen Lichtverhältnissen und sogar bei starken und plötzlichen Lichtschwankungen stabil. (Also, mechanisches abdecken der Sensoren, um sie vor störendem Umgebungslicht zu schützen, ist nicht mehr nötig.)

Hallo rossir,

Zitat:

---

Vielleicht findet er ja seinen Weg in die nächste Lib ?!

---

Die Chancen, dass eine Funktion in die Asuro Lib übernommen wird, steigen natürlich, je besser diese dokumentiert ist. In deinem Fall also praktisch 0 :wink:

Schließlich sollen gerade auch Anfänger die Lib nicht nur benutzen, sondern auch verstehen, wie die Funktionen arbeiten.

Hallo m.a.r.v.in,

nichts leichter als das:

Code:

---

/****************************************************************************/
/*
  \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 ;-)

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 \:D/ .


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 O:).
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

Hallo rossir,

Zitat:

---

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. O:)

Hallo Sternthaler,

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

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

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 ;-)

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

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

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. :wink:

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

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

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?

Zitat:

---

# 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.

Danke, ich habe mal in meiner eigener systemvariablen gekückt. Stimmt, genau. Ich wuste nicht das PATH automatisch eingestellt war.

ich habe eine kleine Frage. Wo wird die F_CPU Variable, die in der Datei asuro.c bei der Funktion Init() benutzt wird, deklariert? es wäre sehr nett, wenn mir da jemand weiterhelfen könnte.

Code:

---

#if defined(__AVR_ATmega168__)
  UBRR0L = (uint8_t)(F_CPU/(BAUD_RATE*16L)-1);
  UBRR0H = (F_CPU/(BAUD_RATE*16L)-1) >> 8;
  UCSR0B = (1<<RXEN0) | (1<<TXEN0);
  UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);
#else
  UBRRH = (((F_CPU/BAUD_RATE)/16)-1)>>8;        // set baud rate
  UBRRL = (((F_CPU/BAUD_RATE)/16)-1);
  UCSRB = (1<<RXEN)|(1<<TXEN);  // enable Rx & Tx
  UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);  // config USART; 8N1
#endif

---

Sorry, ich habe das jetzt gefunden. Wird in dem Makefile definiert.

Das ist eine die erste werten die im makefile deklariert werden. Schau mal in die makefile im lib examples.

Hallo marvin,

weshalb ist den asuro.c (hier konkret die Init()-Funktion) nicht in der libasuro.a aufgenommen? Gibt es technische Gründe dafür?

Hallo rossir,

einen driftigen Grund dafür gibt es nicht. Bei Bedarf kann man Erweiterungs Module (LCD, Ultraschall) gleich mit initialiseren, ohne die Lib neu zu übersetzen müssen.

Mit der nächsten Version ist das sowieso alles hinfällig, dann benötigt man keine extra Objekt Library mehr.
Man übersetzt zukünftig einfach alles und über ein paar spezielle Compiler und Linker Optionen im Makefile entfernt der GCC dann alle nicht verwendeten Funktionen und Daten aus dem übersetzten Programm.
Wie das funktioniert, kann man hier nachlesen:
http://www.mikrocontroller.net/topic/103306

Hallo Marvin,
noch was: Wie kann ich eine eigene IsrEnc(void) zum Einsatz bringen ohne die Lib neu zu erzeugen (bzw. anfassen zu müssen)? Irgendwie sieht die Lib heute so aus als könnte man dies erreichen (denn welchen Sinn macht die Variable AdcIntFunc sonst?) aber ich weiß nicht wie ich dies anstellen soll.

Hallo rossir,

eine eigene IsrEnc Funktion einbinden ist recht einfach. Du schreibst deine Funktion (wichtig ist Parameter und Rückgabwert muß void sein)

Code:

---

void myIsrEnc(void)
{
  // tu was
}

---

Deine Funktion bindest du dann einfach mit der folgender Zeile ein:

Code:

---

AdcIntFunc  = myIsrEnc;

---

Genauso wird es in der EncoderInit Funktion gemacht.

Danke!! Bin ich nicht drauf gekommen, war zu einfach ;-). Also, dann immer die folgende Reihenfolge:

Code:

---

EncoderInit();
AdcIntFunc  = myIsrEnc;

---

Ich dachte, ich brauche nur eine gleichnamige Funktion schreiben und schwupps ... würde meine genommen.
Schade eigentlich, denn wenn Du dann demnächst mit den angekündigten speziellen Compiler und Linker Optionen kommst sind beide Funktionen im HEX-File: IsrEnc und myIsrEnc. Oder?

Zitat:

---

Zitat von rossir

Ich dachte, ich brauche nur eine gleichnamige Funktion schreiben und schwupps ... würde meine genommen.

---

Hmm, das könnte sogar funktionieren. Habe ich aber selbst noch nicht ausprobiert.

Zitat:

---

Zitat von rossir

Schade eigentlich, denn wenn Du dann demnächst mit den angekündigten speziellen Compiler und Linker Optionen kommst sind beide Funktionen im HEX-File: IsrEnc und myIsrEnc. Oder?

---

Das wäre mit der Objekt Lib genauso.

Dachte ich eben auch zuerst. Aber es funktioniert nicht. Es gibt dann die dubiose Fehlermeldung:

Code:

---

???1\avr\bin\ld.exe: Warning: size of symbol `IsrEnc' changed from 152 in ./subsumption.o to 154 in ???2\lib\libasuro.a(encoder_low.o)

---

Müsste mit der Objekt Lib eigentlich nicht genauso sein - glaub' ich. Wenn man ca. wie folgt seine Interruptfunktion wählen könnte:

Code:

---

EncoderInit(myIsrEnc);

---

Dann käme IsrEnc nie als verwendete Funktion bzw. Adresse vor und könnte durch -Wl,--gc-sections etc. raus geschmissen werden. Weiß aber nicht genau. Immerhin ... die Chance besteht.

Aber, viel mehr stört mich etwas anderes.
Die Idee hinter "DLR ASURO Flash" -> "flash only new pages" ist zwar schön. Aber, leider wird die LIB immer hinter meinen Programmtext geschrieben. Wenn ich also in meinem Programm etwas ändere, wird es ein wenig kürzer oder (meist) etwas länger. Dadurch ändern bzw, verschieben sich oft alle folgenden Pages (die LIB). Schade eigentlich! Kann man das ändern? Und die Reihenfolge umdrehen?

Hallo marvin,

ich glaube da gibt es ein heftiges Problem in der Lib.

Denn PollSwitch() beeinflußt unangenehm die encoder[]-Werte. Obwohl dies doch die Verwendung von autoencode verhindern sollte.

Ich habe mal die Werte von WHEEL_LEFT und WHEEL_RIGHT in Deiner Interrupt-Routine recorded. Während dessen habe ich 6 mal (um den Effekt hier deutlicher zu zeigen) PollSwitch() aufgerufen. In der angehängten Grafik sieht man den desaströsen Effekt auf die WHEEL_LEFT- und WHEEL_RIGHT-Werte. Entsprechend falsch erhöhen sich dadurch die encoder[]-Werte rasant.

(In meiner konkreten Anwendung, flippt mein PID Regler durch diesen falschen Input, genau in dem Augenblick aus, wo er eigentlich vor einer Wand zum halten kommen sollte :( )

Hallo rossir,

das Problem ist bekannt, leider gibt es dafür (noch) keine Lösung. Die PollSwitch Funktion und die Encoder ISR beharken sich trotz der Verwendung von autoencode. Eine mögliche Lösung wäre es, alle A/D Wandler interrupt gesteuert auszulesen. Dazu müßte die IsrEnc Funktion entsprechend umgebaut werden.

Eine andere Lösung sieht so aus, PollSwitch einfach nicht zu verwenden. Das der Asuro auch ohne Tasterabfrage Kollisionen erkennen kann, hat Stochri in seinem genialen Geheimprogramm bewiesen.

Hallo marvin,
ok.
Aber, welche Gründe verhindern den Umbau/Korrektur der IsrEnc Funktion gleich in der Lib?

Hallo rossir,

Zitat:

---

Aber, welche Gründe verhindern den Umbau/Korrektur der IsrEnc Funktion gleich in der Lib?

---

Es muss sich halt jemand finden der Zeit und Muse hat das zu tun. Vielleicht machst du es ja, ich habe nämlich keine Zeit dafür.
Einen Ansatz, wie man das machen könnte gab es schon mal von RN-User Rakke:
https://www.roboternetz.de/phpBB2/ze...rag.php?t=7571
https://www.roboternetz.de/phpBB2/download.php?id=5106

Hallo marvin,

ok, habe ich gemacht. Siehe patch.zip Datei im Anhang.

Ich bin ausgegangen von eurer SVN Revision 192. Im Patch befinden sich nur die Änderungen welche relativ zu dieser Revision notwendig sind. Das sind 7 geänderte Dateien plus eine readme.txt.

Durch diese Änderung sind alle ADC auf Interrupt umgestellt. Dabei habe ich besonders auf die Rückwärtskompatibilität geachtet.
Die encoder werden weiter unterstützt allerdings so verbessert wie von mir hier in
https://www.roboternetz.de/phpBB2/ze...=367880#367880
vorgestellt.

Die gesammelten Kommentare zum Patch finden sich in der Datei readme.txt.

Ich hoffe es gefällt Dir.

Hallo rossir,

ich habe mal einen Blick in deinen Code geworfen.
Schon mal vorab: Mir gefällt vor allem deine intergrierte Gleitwertberechnung für die TIK-Zählerei.

Eine Anmerkung zu der Reihenfolge in asuro.c Init() beim Setzen von ADCSRA und ADMUX. Sollte man nicht umgedreht vorgehen da du mit ADFR und ADSC den Wandler ja schon im 'free running'-Mode startest ohne vorher explizit den Kanal ausgewählt zu haben.
Das folgende sei() erlaubt dann ja nur noch, dass der ADC auch in der Interruptfunktion ankommt.

Ansonsten finde ich extreme Ähnlichkeiten in deinem Aufbau wie ich es schon seit einiger Zeit auch mache.
Auslagern der Datenermittlung in den Interrupt und die 'alten' Funktionen liefern nur noch die Ergebnisse aus der Variablen adcValue[].

Hierzu noch ein Tip. Diese Variable sollte als volatile angelegt werden und in den 'alten' Funktionen sollte vor dem Zugriff auf die Variable der Interrupt gesperrt und danach wieder zugelassen werden.
Liegt daran, dass du sinnvollerweise int-Daten nutzt, die aber dann mehrere Maschinenzyclen zum Auslesen benötigen und somit vom ADC-Interrupt mittendrin unterbrochen werden können. Ein Byte also vom vorletzten ADC-Wert, das andere Byte aber schon vom letzten ADC-Wert.
Hat mich etliche graue Haare gekostet diesen Sachverhalt in der ATmega-Doku zu finden um diese unerwarteten falschen ADC-Werte zu finden.

Ansonsten könnte ich hier noch etwas zu Zeiten beim Ein-/Ausschalten der Sensorbeleuchtungs-LEDs und anderem los werden, aber da kannst du mal bei mir nachsehen. Kommentare sind reichlich vorhanden.

Vorsicht falls du das Programm laufen lässt. Der Asuro fährt mit ein paar Kurven ca. 3-4 Meter weit.

Gruß Sternthaler

Hallo rossir,

toll, das sieht super aus. So kann man das in die Lib übernehmen.

@sternthaler schön, das es dich auch noch gibt. Deine Quellen schau ich mir auch noch durch. Vielleicht kann man ja beides kombinieren.

Hallo m.a.r.v.i.n, und auch alle anderen.

Ja, ich hatte etwas länger einen 'Durchhänger' aufgrund persönlicher Überlastung. Ich will mich aber wieder bessern.

Und nun aber hurtig auch von mir ein direktes Lob an rossier. Von der ersten Idee, dass du die ADCs per Int lesen willst, bis zu deinem Code, sind ja nur ein paar Tage vergangen. Grandios! Ich werkel an meiner Version schon seit 11.2005 rum.

Kombination wäre nicht schlecht.
Vor allem die von mir angedeuteten Probleme beim Umschalten der Sensorbeleuchtung bringt einen Haufen Code mit sich, der wahrscheinlich in den meisten Fällen nicht relevant ist. Ich bremse bewust die Wandler-Neustart-Geschwindigkeit, damit die LEDs auch sicher AN bzw. AUS sind. (Die CPU ist einfach schneller als die LED hier in der Asuro-Hardware)

Hierdrin liegt der hauptsächliche Unterschied zwischen rossir (und allen Interrupt-Vorgängern) und meinem Code. Ich steuer den ADC-Start selber, anstatt den 'free Willy' äh 'free running'-Mode zu nutzen.

Mein Code ist schon seit 'Jahren' immer wieder mal im Forum aufgetaucht. Jedesmal wenn es dann Fragen gab, wurde aber meistens nach ersten Erklärungsversuchen abgewunken, da die Komplexität 'etwas' größer ist. Viel Spaß beim durchsehen. Ansonsten jederzeit PN-Nachricht. Oder hier für alle ;-).

Gruß und schönes Wochenende für euch alle
Sterntahler

P.S.: Und noch etwas.
Weiss jemand, warum ich nur noch selten Mails bekommen, wenn sich in den Thread mit meiner Beteiligung etwas ändert?
Zu deinem Eintrag m.a.r.v.i.n habe ich auch schon wieder keine E-Mail bekommen. (Zu 2 anderen Threads aber schon!) Ich stolper im Moment sporadisch durch die Beiträge in denen ich mich verewigt hatte um neue Beiträge zu suchen.