Abend allerseits, mein ATmega 8 arbeitet mir ein wenig zu langsam (sollte µSekunden aufnehmen können) udn nun habe ich in einigen viedeos und aanderen Quellen gesehen, dass manch einer seinen ATm8 übertaktet hat. Beispielsweise mit 24MHz. Ich würd mal sagen 20 reichen mir mal fürs erste. 1. Aber überlebt der des? 2. Und packt der Compiler des? also passen die Zeiten und so dann auch noch? 3. Muss ich dann einfach einen anderen Quarz anschließen? und was mach ich mit den fuses? Die folgenden Teile vom ATm8 werden benötigt: UART Interrupt Timer vll EEPROM Vll ne schwachstelle an dem Plan: die ganze Sache läuft mit 3,3V. Zurzeit unter 16MHz. Danke schonmal für eure hoffentlich zahlreichen antworten MfG Pat711
Gast
#1868317
>1. Aber überlebt der des? Probiers aus? >2. Und packt der Compiler des? Das interessiert den Compiler nicht die Bohne. > also passen die Zeiten und so dann auch >noch? Wenn F_CPU definiert ist vieleicht. >3. Muss ich dann einfach einen anderen Quarz anschließen? Kannst den Takt auch von Hand machen. 20MHz wird dich aber überfordern. >und was mach ich mit den fuses? In den Kühlschrank legen. Da bleiben sie lange frisch;)
nimm gleich einen Mega 88, der kann 20Mhz von Hause aus. Axel
Gast
#1868435
Axel Düsendieb schrieb: > nimm gleich einen Mega 88, der kann 20Mhz von Hause aus. Aber streng genommen erst ab 4,5V ;-) frank
Ich selbst habe für einen DDS-Generator bei 5V mit 35 MHz übertaktet. Da liefen das einfache DDS Programm und die I2C-Schnittstelle noch, wenn der Takt aus einem externen Oszillator kam. Allerdings ist es zweifelhaft, ob andere Peripheriefunktionen (RS232, Timer, Int's, Oszillator für Quarz)auch noch arbeiten. 24 MHz bei 3,3V dürften ein Zufall sein, jedenfalls kann man es nur durch Probieren feststellen.
Patrick R. schrieb: > Vll ne schwachstelle an dem Plan: die ganze Sache läuft mit 3,3V. > Zurzeit unter 16MHz. Damit übertaktest du den AVR schon jetzt ... Und um vernünftig solche kurze Zeiten messen zu können brauchst du wahrscheinlich einen um Größenordnungen schnelleren Takt - Oder eine andere Herangehensweise an dein Problem. Wie wäre es wenn du Mal dein Problem beschreibst statt die von dir auserkorene Lösung? mfG Markus
Was genau meinst du mit "sollte µSekunden aufnehmen können"? Was soll aufgenommen werden? Normalerweise sollte man es gar nicht nötig haben, zu übertakten. Wer das braucht, hat offensichtlich den falschen Prozessor ausgesucht oder das Problem ineffizient gelöst. Natürlich spricht nichts dagegen, dass man das aus reinem Interesse und Spaß mal ausprobiert, aber als Problemlösung darf man einen Betrieb außerhalb der Spezifikation nicht ansehen und sollte das nach Möglichkeit immer vermeiden. Wenn sich die Problemlösung nicht vereinfachen lässt, kommen dann keine schnelleren Prozessoren in Frage? z.B. ATXmega MSP430F5xxx AT91SAM7 LPC21xx ... Grüße, Peter
Eine duemmliche Idee. Dann wuerd ich doch gleich einen AVR32UC3 (32bit) nehmen und den mit 90MHz laufen lassen...
Gast
#1868544
Morgen zusammen, die µsec brauche ich, da ich eine am Interrupt eingehende Taktfrequenz möglichst genau messen muss. Einen anderen Controller zu wählen wäre eine Möglichkeit allerdings ist die bisherige Firmware eben auf dem ATm8 ausgelegt. Mit 32-Bit Controllern habe ich absolut keine Erfahrung. Ist der Weg da der selbe? Library usw.? MfG Pat711
Gast
#1868547
Guck dir mal die Möglichkeit des Inputcaptures beim AVR an, damit geht so was auch. Damit werden Zeitmarken für Events an einem Pin (ICP) genommen und die kann man dann vergleichen.
Pat711 schrieb: > die µsec brauche ich, da ich eine am Interrupt eingehende Taktfrequenz > möglichst genau messen muss. Laberlaberlaber! Definiere "möglichst genau" möglichst genauer... :-/
> Definiere "möglichst genau" möglichst genauer... :-/
Umso genauer der Wert wird um so besser wird im Endeffekt auch mein
messergebnis. Also am besten auf 1-2µsec genau
Gast
#1869346
1MHz -> T = 1µs 16MHz -> T = 1/16µs Wieso kannst du damit nicht auf 2µs Auflösung messen?
letztes mal ist es daran gescheitert, dass das Programm zu groß war und der Interrupt zu oft kam. Vermutlich waren eben auch zu viele Befehle in der Interruptschleife (dürfen ja dann nicht mehr als 16 bzw. 15 Takte sein)
Hallo Patrick, wie sieht das Eingangssignal aus? Welche Taktfrequenz hat es? Ohne eine exakte Problembeschreibung wird das hier nix ... mfG Markus PS: Eine mögliche Lösung wäre (nach momentanem Wissensstand) die Verwendung der Input-Capture-Funktion in Kombination mit einem vorgeschalteten Zählerbaustein ...
Gast
#1869470
Für eine genaue Messung sollte man besser die ICP Funktion nutzen. MIt der ICP Funktion kreigt man die Zeiten in der Regel auf 1-2 Zyklen genau, d.h. bei 10 MHz Takt ist man bei +-100-200 ns. Die Länge der Interruptroutine ist dann für die minimal messbare Zeit, nicht die Auflösung verantwortlich. Wenn dann der Takt nicht ganz reicht, dann besser einen Mega88 - da ändert sich sehr wenig am Programm und in der Regel nichts am Layout.
die eingangsfrequenz resultiert aus einem RC Glied. Das letzte Test lag Sie zwischen 2 und 3 kHz. Außerdem sind es 3 eingangsfrequenzen, welche über einen Multiblexer (SMDHC4051) ausgewählt werden. das mit dem ICP hab ich mir nun auch überlegt, gibt es denn dazu ein Tutorial?
Patrick R. schrieb: > die eingangsfrequenz resultiert aus einem RC Glied. Das letzte Test lag > Sie zwischen 2 und 3 kHz. Dazu muss man keinen AVR übertakten, das macht der locker innerhalb der Spezifikation. > Außerdem sind es 3 eingangsfrequenzen, welche über einen Multiblexer > (SMDHC4051) ausgewählt werden. > > das mit dem ICP hab ich mir nun auch überlegt, gibt es denn dazu ein > Tutorial? Was willst Du mit einem Tutorial? Im Datenblatt (Kapitel Timer1) steht alles drin, was Du dazu wissen musst. MfG
Patrick R. schrieb: > Das letzte Test lag Sie zwischen 2 und 3 kHz. Und da machst du so einen riesigen Aufstand? Für 3kHz brauchst du noch nicht Mal nen Input-Capture, da kannst du auch ganz bequem mit einer Zählervariable, einem flankengetriggerten Interrupt und einem Counter als Zeitreferenz machen. Messablauf: Zähler zurücksetzen Counter zurücksetzen und starten Eingehende Flanke: Zähler inkrementieren Counter-Überlauf oder CTC -> Ende der Messung Ergebnis: f = Anzahl der Flanken / Messzeitraum mfG Markus
Markus J. schrieb: > > Messablauf: > Zähler zurücksetzen > Counter zurücksetzen und starten > > Eingehende Flanke: Zähler inkrementieren > Counter-Überlauf oder CTC -> Ende der Messung > > Ergebnis: f = Anzahl der Flanken / Messzeitraum > > mfG > Markus so gehts natürlich auch. Bei mir war das folgendermaßen: zähler bei eingehender steigender Flanke auf 0 setzen, bei nächster eingehender Steigender Flanke Wert ind andere Variable speichern, nächsten Kanal abfragen
Patrick R. schrieb: > Bei mir war das folgendermaßen: [...] Was nahe an der ICP-Methode ist, hat aber folgenden Nachteil: Die Messgenauigkeit wird durch internes und externes Timing relativ stark beeinflusst (f = 1/T bei kleinem T bewirkt starke Schwankungen). Wenn du den Messzeitraum dagegen in die Länge ziehst bekommst du mehr Stützstellen und somit ein genaueres/stabileres Ergebnis. mfG Markus
Gast
#1869804
Wenn man den ICP Modus nutzt, kann man sich unter Umständen sogar den externen Multiplexer sparen, denn ICP geht auch über den Komperator und den Multiplexer des AD wandlers. Bei 2-3 kHz ist die Taktfrequenz ziehmlich unkritisch. Kritisch wird das ab etwa 200-300 kHz. Bei 2-3 kHz muß man sich nichtmal groß um Überläufe kümmern. Die Auswertung von Hand, aber auch mit einem Durchlaufenden Timer wäre eventuell eine Reizvolle aufgabe, wenn man die 3 Kanäle Simultan auswerten will, z.B. per Pin Change Interrupt. Auch da sollte eine Takt von run 8 MHz schon recht weit reichen, wenn man die ISR in ASM schreibt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.