mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmel, Timer funktioniert nur mit Werten gößer als 0x0A


Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verwende einen ATmega3290p bei 8 MHz. Durch nachfolgende 
Init-Funktion, stelle ich den Timer0 so ein, dass ich einen CTC-Timer 
habe. Den Systemtakt teile ich dafür durch 8.

Lasse ich den Timer nun auf Werte zwischen 0xFF und 0x0A zählen, toggelt 
mein Ausgang beim Eintritt des Interrupts. Ist der Wert jedoch kleiner 
als 0x0A, ist die Zeit bis zum Toggeln genauso kurz, wie wenn ich 0x0A 
in das Compare-Register schreibe jedoch den Systemtakt ungeteilt lasse. 
Ich hoffe ihr könnt mir sagen was ich falsch mache.
void init_timer(void)
{
    // Bit 6, 3 - WGM01:0: Waveform Generation Mode
    TCCR0A |=  (1<<WGM01);      // Clear Timer on Compare Match (CTC); Top=OCR0A;
    TCCR0A &= ~(1<<WGM00);      // Clear Timer on Compare Match (CTC); Top=OCR0A;

    // Bit 5:4 - COM0A1:0: Compare Match Output Mode
    TCCR0A &= ~(1<<COM0A1);     // Toggle OC0A on compare match
    TCCR0A |=  (1<<COM0A0);     // Toggle OC0A on compare match

    //Set Bit4 of PortB as output
    DDRB |= 0x10;

    // TIMSK0 - Timer/Counter 0 Interrupt Mask Register
    // Bit 1 - OCIE0A: Timer/Counter0 Output Compare Match A Interrupt Enable
    TIMSK0 |= (1<<OCIE0A);      // set interrupt enable

    TCNT0 = 0x00;
}
void start(void)
{
    OCR0A = 0x0A; // kleinst möglicher Wert
    TCCR0A |= 2;  // systemtakt/8
}
ISR(TIMER0_COMP_vect)
{   // Ausgang wird getoggelt
}

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute gerade, mein Problem könnte vielleicht daran liegen, dass 
ich das mit dem Teiler des Systemtaktes falsch verstanden habe.

Ich bin davon ausgegangen, dass ich mit dem clk/8-Takt die Werte von 
0xFF (lange Zeit) bis 0x01 (kurze Zeit) einstellen kann. Und wenn ich 
den Teiler einfach auf eins setze, meine Timer-Zeit linear kürzer wird.

Kann es sein, dass ich hier falsch liege? Wenn ja, dann wäre es 
vielleicht auch logisch, dass der uC nicht das tut was ich möchte, da er 
in der Zeit nicht mehr schafft die Interrupts zu bearbeiten.

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt. Habe mir mal die Zeiten ausgerechnet und gegenüber 
gestellt. Bei Werten kleiner 0x0A schafft es der uC nicht mehr die 
Interrupts zu bearbeiten.

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Habe mir mal die Zeiten ausgerechnet und gegenüber gestellt.

Warum erst hinterher? Wenn man mit Timern arbeitet, rechnet man sich 
bereits im Vorfeld die nutzbaren Vorteiler und Arbeitsbereiche aus.

> ISR(TIMER0_COMP_vect)
> {   // Ausgang wird getoggelt
> }

Deine ISR enthält keinen Code. Wenn die ISR keine Arbeit erledigen muss, 
dann wird sie auch nicht gebraucht und kann entfallen. Das Toggeln des 
OC-Pins erfolgt ja durch Hardware (eingeschaltet per COM- und WGM-Bits) 
im Hintergund, also ohne ohne zyklisches Abarbeiten von Code durch den 
Prozessor.

Und mal so nebenbei:

> ...Bei Werten kleiner 0x0A schafft es der uC nicht ...

Warum betrachtest Du Zahlen, die Zählerstände darstellen (und in 1 Byte 
passen), nicht einfach dezimal? Ist doch viel übersichtlicher. Oder 
denkst Du hexadezimal?

Also ich sehe es so:
Zahlen, Zählerstände, Schleifenzähler, betrachtet man am besten dezimal.
Speicher-Adressen betrachtet man meist Hexadezimal.
ASCII-Werte schreibet man (wenn möglich) als lesbares Zeichen.
Bitmuster gibt man möglichst mit Bitnamen an, zumindest aber binär oder 
hex.

Nur so als Anregung.

...

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux wrote:

>> Habe mir mal die Zeiten ausgerechnet und gegenüber gestellt.
> Warum erst hinterher? Wenn man mit Timern arbeitet, rechnet man sich
> bereits im Vorfeld die nutzbaren Vorteiler und Arbeitsbereiche aus.

Er hat seinen Fehler selbst gefunden, er hat daraus gelernt und er hat 
Feedback gegeben, wo er seine Frage gestellt hat - wo siehst du jetzt 
einen Grund, nachtreten zu muessen?

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> einen Grund, nachtreten zu muessen?

Sorry, das sehe ich nicht als Nachtreten, sondern als gut gemeinten 
Hinweis für die Zukunft. Außerdem enthält mein Text auch noch andere 
Hinweise, die vermutlich hilfreich sein könnten.

...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich auch so.
Keine Ahnung was Hans Wurst als Fehler gefunden hat, aber die Ursache 
ist es nicht, denn wie Hannes Lux schrieb: Das Pin toggeln geschieht in 
Hardware. Selbst wenn sich der µC komplett aufhängt toggelt der Pin noch 
weiter.
Davon abgesehen passen die Einstellungen aber. Es muss also an etwas 
anderes liegen.
0x0A und Prescaler 8 ergibt einen Teilerfaktor von 88. Das sollte der µC 
locker schaffen (ganz grob müsste ein leerer Interrupt etwa 10-20 Takte 
brauchen)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.