NIBOBee und Timer- für Anfänger

led_init();

Alles klar. Hat mich schier zur Verzweiflung gebracht. Ich habe nämlich _dein_ Progrämmchen auch dahingehend geändert, dass ich die LED über die Bibliotheksfunktion led_set aufrufe, und es glimmte auch nur.
Ich hatte absichtlich noch nichts reingeschrieben, was der Interupt auslösen soll, ich finde es günstiger, ein Problem nach dem anderen anzugehen, je komplizierter ein Programm ist, umso schwerer findet man Fehler.
Dass ich beim Prescaler was falsch gemacht habe, hatte ich befürchtet, und an deinem Beispiel habe ich auch gesehen, wie das richtig aussehen muss.

Was _ich_ aber nun noch nicht weiss, ist z.b. woher der "Zeittakt" für beispeilsweise delay() kommt, deswegen hab ich mich auch erst nicht an die Timer herangetraut.
Wenn ich an einem bereits benutzten Timer einfach den Prescaler ändere (wenn mans weiss, kann man es ja umgehen), dann ändere ich ja gleich mehrere Dinge.
Werden nicht die Liniensensoren auch getaktet?
Odometrie auch, oder?
Da _muss_ doch einer der Timer (ausser dem 01, der ja die PWM für die Motoren bereitstellt) noch mitspielen, oder geht das alles über ebendiesen?

Nuja, eben habe ich die fehlende Zeile (in dem Code von dir, wie gesagt, ich spreche die LED mit led_set() an, ergänzt: funktioniert.
Werd nun da mal was in die Hauptschleife schreiben, auch, um zu testen, ob sich nun andere Dinge geändert haben.
Naja, und zum üben halt..;)

Hallo

Zitat:

---

woher der "Zeittakt" für beispeilsweise delay() kommt, ...

---

...weiß ich selbst nicht genau. Wenn ich mich recht erinnere macht AVRGCC daraus eine Zählschleife mit NOPs. Aber bei mir hat das nie richtig funktioniert. Die Ausführungszeiten schwanken enorm, deshalb verwende ich meist einen Timer (zusätzlich zu seiner eigentlichen Funktion) als eigene Zeitbasis.

Die Liniensensoren verwenden die Analog-Lib um an die Werte der Sensoren zu kommen. Die Analog-Lib liest zyklisch alle ADC-Kanäle ein, die Liniensensoren sogar zweimal, je einmal unbeleuchtet und einmal beleuchtet. Dazu wird der ADC-Interrupt eingesetzt.

Die Odometrie funktioniert mit den externen Interruptquellen INT0 und INT1.

Gruß

mic

Ich denke, die Odometriesensoren und die Liniensensoren arbeiten Frequenzmoduliert?
Dann muss man ja auch dafür irgendwo einen Takt hernehmen...

delay() beeinflussen die Einstellungen des Timers0 übrigens offenbar nicht, habs gerade mal mit nem anderen Prescaler-Wert probiert:

Code:

---

// LED3 ansteuern mit Timer 0                                          14.3.2010 mic

#include <nibobee/iodefs.h>
#include <nibobee/led.h>
#include <nibobee/delay.h>
//#include <avr/interrupt.h>

int main(void)
{
  TCCR0 = (1<<CS02)| (1<<CS00);              // Normal Mode, kein OC0-Pin, prescaler /1024
  TIMSK |= (1<<TOIE0);                                // Timer0 Overflow-Interrupt erlauben
   
  enable_interrupts();
  led_init();
   
 
   
  while(1)
  {                                                                                // LED 2 u.3 treiben ihr eigenes Spiel
              int ledNr;
                led_set(ledNr,0);
                delay(100);
                for (ledNr=1;ledNr<3;ledNr++)
                        {
                        led_set(ledNr,1);
                        delay(50);
                        }
                delay(50);
                for (ledNr=2;ledNr>1;ledNr--)
                        {
                        led_set(ledNr,0);
                        delay(50);
                        }
}
}
ISR(TIMER0_OVF_vect)
{
  static uint8_t count=0;

  count++;
  if(count == 57)
  {
    led_set(LED_R_YE,1);                                    // LED an
        led_set(LED_L_YE,1);
        }
  if(count > 2*57)
  {
      led_set(LED_R_YE,0);                              // LED aus
          led_set(LED_L_YE,0);
      count=0;
  }
}

---

Zitat:

---

Zitat von Rabenauge

... delay() beeinflussen die Einstellungen des Timers0 übrigens offenbar nicht ...

---

Wenn ich das richtig im Kopf habe, dann wird über die Nibobee-lib durch

Code:

---

#include <nibobee/delay.h>

---

die Standard-AVRGCC-Bibliotheksroutine eingebunden. Bei mir liegt die lokal auf
C:\Programme\WinAVR-20090313\avr\include\util

Diese Routine dreht nur eine Warteschleife, sprich: sie zählt etliche ticks des Controllers und benutzt keinen Interrupt. Die Millisekunde wird durch die Anzahl der gezählten ticks (die wird aus der Controllerfrequenz errechnet) und die Anzahl der Millisekunden durch den aufrufenden Parameter festgelegt. Läuft also ohne jegliche Interrupt-Initialisierung und beeinflusst keinen Timer.
Nachteil 1: der Controller ist während der Wartezeit blockiert.
Nachteil 2: InterruptServiceRoutinen können die Laufzeit verlängern, sodass die Verzögerungszeit nicht unbedingt genau und auch nicht in allen Fällen reproduzierbar gleich ist.

Gut, wenn man von den beiden Nachteilen weiss, ich halte eh nix von Warteschleifen, in denen "nichts" getan wird. Meine Güte, wir haben Prozessoren, die einige Millionen Befehle pro Sekunde (wann immer ich mir _das_ vor Augen führe, erstarre ich eine halbe Sekunde vor Ehrfurcht ;) ) abarbeiten können, und uns fällt nix besseres ein, als sie mit Warteschleifen auszubremsen..

Als nächstes (um Timer1 mache ich erst einmal vorsichtshalber einen Bogen) werde ich mal mit dem Timer2 spielen, der kann ja wieder ein paar _andere_ Dinge, mal gucken, wozu`s gut ist.

Ich habe im NIBObee-Wiki eine kleine Tabelle zu den verwendeten Resourcen erstellt:
http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen

JAAaah - schön, sehr hilfreich. Das findet man sogar mit "suche [Interrupt]". Nur nicht über "suche [Odometrie]" - das wird ja im restlichen Wiki immer mit "..ie" geschrieben. Sorry für die Pingeligkeit.

Ja, super. Danke.

Hallo Leute;
mache auch die ersten Experimente mit der Biene und den vorhandenen Libs.
So wie Fühler nach vorne, Drehzahl vorwärts hoch bis max; Fühler nach hinten, verzögern bis null, danach rückwärts bis max. Drehzahl;
Damit man das bedienen kann war auch erst ein delay(200) in der mainloop.
Um dann aber die Leds im Takt der Odometer blinken zu lassen, funktioniert das mit delay(200) nimmer, je schneller die Räder drehen, desto langsamer wird das Blinken.

In den Sourcen zur NiboBee gibt es auch eine clock.c und .h, aber ..?

Im Tutorial "Hinderniserkennung" wird aber auch eine Lösung geboten: counter_ms.

Also sieht's bei mir jetzt erstmal so aus:

Code:

---

int main()
{
uint8_t  timer_1 = 0;  // ein Timer von x beliebigen
uint8_t  LedFlag = 0; // Demo Blinker
while(1==1)
{
delay(1); // Schleife ca. alle ms durchlaufen
if (timer_1 != 0) timer_1--; //Timer pro ms Zyklus runterzählen

if (timer_1 == 0) // Wartezeit abgelaufen
{
timer_1 = 200; // neuen Verzögerungswert laden

// hier dann der Code der nur alle 200ms ausgeführt werden soll
// Sensorabfrage, Beschleunigen und Verzögern

LedFlag ~≃ LedFlag;
led_set(LED_L_YE,LedFlag);
}
// und hier wieder weiter im ms Zyklus
}
return(0);
}

---

Ich versuche rauszufinden, ob und wie man die Drehzahl mit Bordmitteln regeln könnte.
Auch das Beschleunigen sollte etwas sanfter gestaltet werden, mein Bienchen hat hinten Mignonakkus drauf, und das Anfahren vorwärts sieht immer wie ein Kickstart aus..

Ich glaube, du hast etwas falsch verstanden.
Wir benutzen einen der Hardware-Timer des ATMega.
Der ist fest eingebaut, man muss ihn nur aktivieren.:)
Wie das geht, steht weiter oben.

Du könntest den durchaus auch benutzen, um sanfter zu beschleunigen, z.B. (oder baust, wie ich, um auf nen leichten LiPo-Akku ) dann hast du erstmal genug Strom an Bord.

Timer, die auf delay() basieren, sind immer ungenau.
Probier mal den Code, den ich gepostet hatte, er ist eigentlich unspektakulär, aber nach einer Weile wirst du sehen, dass die gelben LED`s im Gegesatz zu den roten (letztere blinken per delay() schrecklich genau funktionieren.