www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie lange dauert ein Schleifendurchgang


Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute.

Ich möchte eine unkomplizierte Methode zum Überprüfen, wie lange ein 
bestimmter Portpin auf low/high ist.
Meine Idee wäre eine for-Schleife, die eine Variable hinaufzählt. Da ich 
aber nicht weiß wieviele Clock-Schläge die Schleife benötigt um einmal 
durchzulaufen, stehe ich vor einem Problem.
for(i=0;PB0 == 0;i++);

Auch für das Problem hätte ich einen Lösungsvorschlag. Im Datenblatt des 
ATmega32 stehen so ziemlich am Ende die Dauer aller Assembler-Befehle. 
Da ich in Assembler nun gar nicht bewandert bin, wollte ich euch fragen 
wieviele Clock-Schläge der obige Code pro Durchlauf braucht.

Ich hoffe ihr versteht mein Anliegen und könnt mir helfen =)

Mfg
Christoph

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:

> for(i=0;PB0 == 0;i++);

Da PB0 fest für den Wert 0 steht dauert diese Schleife ewig.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm.. einfach ein Timer und ein externer Interrupt geht nicht?

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Christoph A. schrieb:
>
>> for(i=0;PB0 == 0;i++);
>
> Da PB0 fest für den Wert 0 steht dauert diese Schleife ewig.

Ändert sich der Wert des Pins nicht wenn der Eingang sich ändert?
Sollte ich PORTB verwenden?

Ja ginge natürlich schon, aber da müsste ich mich in die Interrupts 
einearbeiten. Ich suche hier eine unkomplizierte Lösung.. ^^

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:
> A. K. schrieb:
>> Christoph A. schrieb:
>>
>>> for(i=0;PB0 == 0;i++);
>>
>> Da PB0 fest für den Wert 0 steht dauert diese Schleife ewig.
>
> Ändert sich der Wert des Pins nicht wenn der Eingang sich ändert?
Doch, das tut er.

> Sollte ich PORTB verwenden?
PINB wäre sinnvoller.

> Ja ginge natürlich schon, aber da müsste ich mich in die Interrupts
> einearbeiten. Ich suche hier eine unkomplizierte Lösung.. ^^
Du wirst dich wohl auch in 'Grundlagen AVR' einarbeiten müssen.
Schleifen sind unberechenbar, daher eigenen sie sich nicht zur 
Zeitmessung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:

> Ändert sich der Wert des Pins nicht wenn der Eingang sich ändert?

Tut er. Aber PB0 ist nur die Nummer des Pins, nicht dessen Zustand. 
Folglich steht da
  for(i=0;0 == 0;i++);

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay dankeschön!

Ich habe ja irgendwie schon damit gerechnet dass ich nicht drumrum 
komme, etwas neues zu lernen.

Mfg
Christoph

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Christoph A. schrieb:
>
>> Ändert sich der Wert des Pins nicht wenn der Eingang sich ändert?
>
> Tut er. Aber PB0 ist nur die Nummer des Pins, nicht dessen Zustand.
> Folglich steht da
>   for(i=0;0 == 0;i++);

Sry, keine Ahnung was ich da für einen Blödsinn gedacht habe.

Autor: FlipFlop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kenne mich mit Assembler zwar nicht aus, deshalb wirst du wohl selbst im 
datenblatt nachsehen, wie lange so ein einzelner befehl dauert, aber 
lange zeit abstände wirst du damit nicht messen können, bevor die 
variable überläuft, würde mal bei 1Mhz takt auf eine knappe millisekunde 
tippen.

while(PINB&0x01)i++;
  44:  01 96         adiw  r24, 0x01  ; 1
  46:  b0 99         sbic  0x16, 0  ; 22
  48:  fd cf         rjmp  .-6        ; 0x44 <__SREG__+0x5>

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das beste wär den pin in einem Timerinterupt mit geeigneter Auflösung zu 
pollen und dort eine ausreichend breite Variable hochzuzählen

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht es um AVRs? Die Ausführungszeiten zeigt der Simulator im AVR Studio 
wunderschön an, in Takten und in µs.

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schonmal für die Ideen!

Ich mache es folgendermaßen:

Ich schaue zuerst ob die Flanke nach unten geht ( ich möchte die Dauer 
eines low-levels messen). Wird dieses Interrupt ausgelöst, so fängt der 
Counter an zu zählen. Geht die Flanke nach oben wird wieder ein 
INterrupt ausgelöst. Die Zeit des Counters wird danach abgelesen und 
fertig.


Eine Frage hätte ich noch: Was genau ist das I/O Clock? Im Datenblatt 
steht, dass ich diese Art von Clock benötige um diverse Interrupts 
möglich zu machen.

Mfg
Christoph

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:
> Ich schaue zuerst ob die Flanke nach unten geht ( ich möchte die Dauer
> eines low-levels messen). Wird dieses Interrupt ausgelöst, so fängt der
> Counter an zu zählen. Geht die Flanke nach oben wird wieder ein
> INterrupt ausgelöst. Die Zeit des Counters wird danach abgelesen und
> fertig.

das sagt dir ja aber nicht viel über die Zeit, da du ja nicht weißt, 
wieviele Takte ein Schleifendurchlauf  braucht. Man könnte sich 
höchstens das assembly anschauen und nachzählen.

Autor: S. T. (cmdrkeen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es kommt auch immer ganz darauf an wie genau man eine Messung 
durchführen will.

man kann das auch ohne weiteres in einer Pollingschleife machen.
Um die Zeit von einem Polling-aufruf zum nächsten zu messen, nimmt man 
einfach den AVR-Simulator, setzt sich einen Haltepunkt beim 
Polling-aufruf und schaut wieviel Taktzyklen zwischen den 
Polling-aufrufen liegen.
Deine Zeitliche Auflösung ist dann halt diese Zeit und messen kannst du 
so lange, bis deine Zählvariable überläuft.

Compileroptminierung würde ich ausschalten, weil die manchmal auch gerne 
schleifen optimiert in einer Weise, die nicht optimal ist :P

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> Christoph A. schrieb:
>> Ich schaue zuerst ob die Flanke nach unten geht ( ich möchte die Dauer
>> eines low-levels messen). Wird dieses Interrupt ausgelöst, so fängt der
>> Counter an zu zählen. Geht die Flanke nach oben wird wieder ein
>> INterrupt ausgelöst. Die Zeit des Counters wird danach abgelesen und
>> fertig.
>
> das sagt dir ja aber nicht viel über die Zeit, da du ja nicht weißt,
> wieviele Takte ein Schleifendurchlauf  braucht. Man könnte sich
> höchstens das assembly anschauen und nachzählen.

Bei dieser Methode gibt es keine Schleifen^^
Es werden nur Interrupts angewendet. Natürlich gehen für den Aufruf des 
Interrupts auch ein paar Clock-Schläge drauf, aber so extrem genau muss 
das Ergebnis nicht sein. Im 100 µs Bereich bei 8 Mhz reicht das locker 
=)

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine Frage hätte ich noch: Was genau ist das I/O Clock? Im Datenblatt
> steht, dass ich diese Art von Clock benötige um diverse Interrupts
> möglich zu machen.

Der Takt, der für die I/O-Hardware da ist. In manchen Stromsparmodi ist 
dieser ausgeschaltet.

> Compileroptminierung würde ich ausschalten, weil die manchmal auch gerne
> schleifen optimiert in einer Weise, die nicht optimal ist :P

Würde ich nicht tun. Besser ist es, zu verstehen, warum diese 
Optimierungen gemacht werden und - sofern man das wirklich mal brauchen 
sollte - wie man sie umgeht.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jetzt habe ich glaube verstanden was du willst, das Zauberwort ist ICP, 
Input Capture Pin. Der Zählerstand von einem freilaufenden Counter (per 
internem Hardwaretakt) wird bei Flanken am ICP in einem Register 
eingefroren. Das ist dann die genaueste Möglichkeit mit dem µC 
Pulse/Pausenzeiten zu messen.

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:
> jetzt habe ich glaube verstanden was du willst, das Zauberwort ist ICP,
> Input Capture Pin. Der Zählerstand von einem freilaufenden Counter (per
> internem Hardwaretakt) wird bei Flanken am ICP in einem Register
> eingefroren. Das ist dann die genaueste Möglichkeit mit dem µC
> Pulse/Pausenzeiten zu messen.

Exakt genau das habe ich gesucht!

Gibts das schon fertig wie du es beschrieben hast, oder muss man sich 
das so wie ich es beschrieben habe selbst mit Interrupts 
"zusammenbasteln"?

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hängt von dem µC ab den du nutzt, welcher ist es denn? Die meisten 
ATMegas haben das in der Hardware drin, ein Blick ins Datenblatt hilft. 
Ist in der Timer Beschreibung drin.

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:
> hängt von dem µC ab den du nutzt, welcher ist es denn? Die meisten
> ATMegas haben das in der Hardware drin, ein Blick ins Datenblatt hilft.
> Ist in der Timer Beschreibung drin.

Ich nutze den ATmega32.
Laut Datenblatt hat der sowas wie ICP.
Nja, da werde ich mich jetzt einarbeiten ;)

Falls es nicht auf Anhieb klappt, werde ich hier weiterfragen. Wäre nett 
wenn ein paar diesen Thread sich abonnieren könnten.

Vielen Dank für eure Hilfe!

Mfg
Christoph

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier bin ich wieder^^

Ich hätte da eine ganz kleine Frage, bezogen auf das Datenblatt des 
ATmega32.
Dieser besitzt ja einen 16bit Counter, und dess Register müsste man laut 
Datenblatt in Assembler geteilt auslesen. Bei "C" ist das anscheindend 
nicht der  Fall?

"Note that when using “C”, the compiler handles the 16-bit
access."

Ist das für jeden Compiler gleich bzw. funktioniert das auf meinem?
(AVR GCC)

Vielen Dank im Voraus!

Mfg

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>"Note that when using “C”, the compiler handles the 16-bit
access."

Das heisst auf deutsch: Bei "C" kümmert sich der Compiler darum.

Dadurch ist es EINFACHER.

Klaus

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
>>"Note that when using “C”, the compiler handles the 16-bit
> access."
>
> Das heisst auf deutsch: Bei "C" kümmert sich der Compiler darum.
>
> Dadurch ist es EINFACHER.
>
> Klaus

Ja ich kann auch Englisch ;)

Meine Frage war aber ob das jetzt bei jedem C-Compiler so ist?

Mfg

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Meine Frage war aber ob das jetzt bei jedem C-Compiler so ist?

schwer zu sagen, wer kennt schon 'jeden' Compiler? Aber die meisten 
Compiler haben die Option ein Assemblerlisting zu generieren, das ist 
meist sehr hilfreich und gibt hier eine eindeutige Antwort. Der gcc zum 
Beispiel 'kennt' den AVR und macht es richtig.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hier ist mal ein Schnippsel um die Zeiten zwischen Flanken in einem 
Array zu sammeln (ohne Gewähr, und verwendet noch die _BV() Makros die 
jetzt nicht mehr in sind):
uint16_t   Timestamps[MAX_TIMESTAMPS];
int8_t   TimestampCount;
uint16_t   TimestampOld;

void init_decoder(void)
{
  TimestampCount = -1;
  TimestampOld = 0;

  TCCR1B |=  _BV(CS11) | _BV(CS10) | _BV(ICNC1) | _BV(ICES1);

  TIMSK |= _BV(TICIE1); 
}


//
// Interrupt handler for Input Capture
//

ISR(TIMER1_CAPT_vect)
{
  uint16_t val = ICR1;    // read timer value
  uint16_t diff = val - TimestampOld;
  TimestampOld = val;

  TCCR1B ^= _BV(ICES1);  // toggle rising/falling edge detection

  if (TimestampCount < MAX_TIMESTAMPS)
    Timestamps[TimestampCount++] = diff;
}

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mein erster Code mit Interrupts. Die folgenden Fehler bringe ich 
nicht weg. Mein erster Verdacht war, dass der Interrupt-Vector falsch 
ist, aber dieser stimmt laut Datenblatt...
Die Zeile ist mit einem Kommentar markiert, um euch die Suche zu 
erleichtern.

../DS1820.c:102: error: expected identifier or '(' before numeric 
constant
../DS1820.c:102: error: expected identifier or '(' before numeric 
constant

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h> 

#define TRANS PB3  //Transistorsteuerung
#define BUS    PB2  //Busleitung
#define PORTx PORTB  //PORT
#define DDRx  DDRB  //I/O Richtungssteuerung


#ifndef F_CPU
#define F_CPU 8000000  //Taktfrequenz definieren
#endif


void ResetPulse();
void EnableInterrupt();
void DisableInterrupt();
void ConfigInterruptICP();
void ConfigInterruptExt();

volatile char helpvar=0;
//Ist die Periode abgeschlossen?

uint16_t time;
//Zeit, in der das Signal low ist


void main()
{    
  DDRx = 0x00;
  DDRx = (1 << TRANS) | (1 << BUS); 
  // Anfangszustand
  
  DDRD = 0xFF;
  PORTD= 0xFF;
  //Alle STK500 LED's bleiben aus  


  PORTx=0xFF;
  //LED's 

  PORTx |= (1 << BUS);
  //Bus wird anfangs nicht auf low gezogen 
  
  ConfigInterruptExt();
  //Interrupt wird richtig konfiguriert

  EnableInterrupt();  

  ResetPulse();
  //Gibt einen Reset Pulse  
  
  while(1);
}

void EnableInterrupt()
{
  sei();
}
void DisableInterrupt()
{
  cli();
}

/*void ConfigInterruptICP()
{
  TCCR1A = 0x00;
  //Alles in diesem Register ist überflüssig =)
  
  TCCR1B = (1<<ICNC1) | (1<<CS10);
  //Reaktion auf negative Flanke
  //Interner Clock Prescaler auf 1
}
*/
void ConfigInterruptExt()
{
  MCUCSR &= ~(1<<ISC2);
  //Auf negative Flanke wird reagiert
  GICR = (1<<INT2);
  //Ext.Interrupt wird auf INT2 aktiviert
}

void ResetPulse()
{
  int i;

  PORTx &= ~(1 << BUS);
  //Bus auf low ziehen
    
  for(i=0;i<50;i++)
    _delay_us(10);
  //Reset Impuls
  
  PORTx |= (1 << BUS);
  //Bus auf wieder high

  DDRx &= ~(1 << BUS);
  //Buspin als Eingang  
}

ISR(INT2)  //Hier meldet der Compiler 2 Fehler im Code
{
  //Eine negative Flanke wurde erkannt
  if(helpvar%2)
    PORTD=0x00;
  else
    PORTD=0xFF;
  
  helpvar++;    
}

Mfg
Christoph

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was soll INT2 bedeuten?

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> was soll INT2 bedeuten?

Der InterruptVector für den Externen Interrupt am Pin INT2. Stimmt der 
nicht?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> was soll INT2 bedeuten?
>
> Der InterruptVector für den Externen Interrupt am Pin INT2. Stimmt der
> nicht?

Wie der Compiler dir schon sagt, stimmt der nicht. In der Doku der 
avr-libc steht, wie dieser Interrupt-Handler eigentlich heißen muß.

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
>>> was soll INT2 bedeuten?
>>
>> Der InterruptVector für den Externen Interrupt am Pin INT2. Stimmt der
>> nicht?
>
> Wie der Compiler dir schon sagt, stimmt der nicht. In der Doku der
> avr-libc steht, wie dieser Interrupt-Handler eigentlich heißen muß.

Dankesehr!

Der Handler heisst wirklich: "EXT_INT2"

Noch eine Anmerkung:
Des Delay ist soo ein Schwachsinn, dass macht echt was es will..
Ich habe mit meinem Oszilloskop nachgemessen, der Wert stimmt weit 
nicht.

Mfg
Christoph

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:
> Noch eine Anmerkung:
> Des Delay ist soo ein Schwachsinn, dass macht echt was es will..
> Ich habe mit meinem Oszilloskop nachgemessen, der Wert stimmt weit
> nicht.

Hast du auch brav die Optimierung eingeschaltet, die richtige 
Prozessorfrequenz eingetragen und die richtige Clock-Source ausgewählt??

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Christoph A. schrieb:
>> Noch eine Anmerkung:
>> Des Delay ist soo ein Schwachsinn, dass macht echt was es will..
>> Ich habe mit meinem Oszilloskop nachgemessen, der Wert stimmt weit
>> nicht.
>
> Hast du auch brav die Optimierung eingeschaltet, die richtige
> Prozessorfrequenz eingetragen und die richtige Clock-Source ausgewählt??

Die Optimierung ist standartmäßig eingeschaltet oder?
Prozessorfrequenz wurde definiert (siehe Code oben)
Würde nicht die richtige Clock-Source ausgwählt, so würde der ATmega 
garnicht laufen oder?^^

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein weiterer Fehler in meinem Code:

Der Interrupt-Handler ist falsch. Er sollte heissen: "INT2_vect".
Nun funktioniert auch mein Programm hervvoragend =)

Und ich glaube der Grund warum dass Delay bei mir nicht funktioniert hat 
ist folgender:

Ich habe F_CPU erst nach dem Einbinden der Delay-Bibliothek definiert. 
Jetzt habe ich util/delay erst nachher eingebunden. Ich kann leider 
nicht mehr überprüfen ob es funktioniert, man braucht ja auch seinen 
Schlaf.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph A. schrieb:
> Die Optimierung ist standartmäßig eingeschaltet oder?

Wenn man einen Fehler sucht, besser alle Fehlermöglichkeiten 
ausschließen, als sich auf Standardwerte zu verlassen ;)

> Würde nicht die richtige Clock-Source ausgwählt, so würde der ATmega
> garnicht laufen oder?^^

Kommt drauf an. Es gibt Fälle, wo der uC dann einfach zu langsam läuft 
und es einem deshalb erstmal nicht auffällt:  Wenn man nämlich einen 
externen Oszillator oder Quarz von z.B. 16Mhz anschließt, aber den 
internen 8MHz Oszillator auswählt.

> Ich habe F_CPU erst nach dem Einbinden der Delay-Bibliothek definiert.
> Jetzt habe ich util/delay erst nachher eingebunden. Ich kann leider
> nicht mehr überprüfen ob es funktioniert

Richtig, das ist auch ein möglicher Fehler. Allerdings sollte in dem 
Fall auch eine Warnung kommen.

> man braucht ja auch seinen Schlaf.

Ich wünsche eine gute Nacht ;)

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieser Tag hat schonmal gut angefangen =). Das Delay-Problem ist gelöst 
(es war tatsächlich der von mir genannte Fehler schuld) und die 
Flankenerkennung funktioniert wie sie soll.

Für alle die es noch nicht erraten haben: Es geht um den DS1820 ^^

Mein nächster Schritt ist die Messung der Zeit in der das Signal low 
ist. Dafür werde ich den Input-Capture-Pin verwenden, der laut 
Datenblatt einen Timer losrennen lässt, bis das Signal ein bestimmtes 
Flankenverhalten aufweist.

Mfg
Christoph

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
>> Ich habe F_CPU erst nach dem Einbinden der Delay-Bibliothek definiert.
>> Jetzt habe ich util/delay erst nachher eingebunden. Ich kann leider
>> nicht mehr überprüfen ob es funktioniert
>
> Richtig, das ist auch ein möglicher Fehler. Allerdings sollte in dem
> Fall auch eine Warnung kommen.
>

Es ist auch eine Warnung gekommen, ich habe sie nur ignoriert und dachte 
das wird schon passen^^.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> den Input-Capture-Pin verwenden, der laut Datenblatt einen Timer
> losrennen lässt, bis das Signal ein bestimmtes Flankenverhalten
> aufweist.

Nicht so ganz, zumindest kenne ich die Funktion so nicht. Den Timer 
lässt du einfach frei rennen. Ein Input-Capture-Ereignis löst dann ein 
Kopieren des aktuellen Timer-Werts in ein separates Register aus. Da 
kannst du dann taktzyklengenau auslesen, wann das Ereingis passiert ist.

> Es ist auch eine Warnung gekommen, ich habe sie nur ignoriert und dachte
> das wird schon passen^^.

Dann hast du jetzt eine wichtige Lektion zum Thema Warnungen gelernt, 
hoffe ich. ;-)

Autor: Christoph A. (shadowrunner93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
>> den Input-Capture-Pin verwenden, der laut Datenblatt einen Timer
>> losrennen lässt, bis das Signal ein bestimmtes Flankenverhalten
>> aufweist.
>
> Nicht so ganz, zumindest kenne ich die Funktion so nicht. Den Timer
> lässt du einfach frei rennen. Ein Input-Capture-Ereignis löst dann ein
> Kopieren des aktuellen Timer-Werts in ein separates Register aus. Da
> kannst du dann taktzyklengenau auslesen, wann das Ereingis passiert ist.

Reicht diese Funktion um den Counter und ICP zu konfigurieren?
Wie erreiche ich dass der Counter zu zählen beginnt oder habe ich dass 
mit der Prescaler Einstellung schon gemacht?
void ConfigInterruptICP()
{
  TCCR1A = 0x00;
  //Ganz normaler Modus
  
  TCCR1B = (1<<ICNC1) | (1<<CS10) | (1<<ICES1);
  //Reaktion auf positive Flanke
  //Interner Clock Prescaler auf 1
}

>> Es ist auch eine Warnung gekommen, ich habe sie nur ignoriert und dachte
>> das wird schon passen^^.
>
> Dann hast du jetzt eine wichtige Lektion zum Thema Warnungen gelernt,
> hoffe ich. ;-)

Habe ich definitiv =)

Mfg
Christoph

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.