Hallo, ich möchte mir einen Frequenzstandard aufbauen, bei dem ein OCXO über das GPS Signal diszipliniert wird. Dafür suche ich nach einem 32-Bit Counter IC mit SPI-Interface, der schnell genug für 10 MHz ist und genug Stufen besitz ca. 10 bis 20 Sekunden lang zu zählen(20 sec *10 Mhz ~ 28 Bit). Mit dem µC möchte ich das Zählen nicht machen, da mir die 20 MHz Takt der Atmegas zu gering für eine sichere Erfassung sind und ich auch gern bei den ATMegas bleiben will. Die Google-Suche hat bis jetzt noch nichts mit SPI zu Tage gefördert daher meine Frage ob jemand einen solchen externen binären Zähler kennt? Danke und Gruß
Stefan D. schrieb: > Dafür suche ich nach einem 32-Bit Counter IC mit SPI-Interface, der > schnell genug für 10 MHz ist und genug Stufen besitz ca. 10 bis 20 > Sekunden lang zu zählen(20 sec *10 Mhz ~ 28 Bit). > > Mit dem µC möchte ich das Zählen nicht machen, da mir die 20 MHz Takt > der Atmegas zu gering für eine sichere Erfassung sind und ich auch gern > bei den ATMegas bleiben will. Dafür brauchst du keinen 32-Bit Zähler. Es reicht ein Vorteiler, so dass der µC nur einen Bruchteiler deiner Frequenz per Timer/Counter zählen muss.
Stefan D. schrieb: > Dafür suche ich nach einem 32-Bit Counter IC mit SPI-Interface, der > schnell genug für 10 MHz ist und genug Stufen besitz ca. 10 bis 20 > Sekunden lang zu zählen(20 sec *10 Mhz ~ 28 Bit). > > Mit dem µC möchte ich das Zählen nicht machen, da mir die 20 MHz Takt > der Atmegas zu gering für eine sichere Erfassung sind Mein Gott, dann schaltet man halt eine einzige Binärteilerstufe dazwischen und gut isses. Keine Suche nach exotischen Bauteilen mehr nötig, alles geht im AVR. Bit 0 des Zählers ist zwar dann nicht mehr zugreifbar, wäre ja aber sowieso nicht wirklich zu gebrauchen. Höchstens statistisch. Man kann sich das Leben auch unnötig schwer machen...
Ja, nur mit der Binärteilerstufe auf 5 MHz verdoppelt sich dann meine Messzeit. Bei 1 Sekunde Messzeit mit 10 MHz kann ich auf +/-1 Hz genau messen - bei 5 MHz nach Vorteiler brauche ich schon 2 Sekunden um 10 Mhz +/- 1Hz zu haben. Würde gern in den Bereich +/- 0,05 Hz -> 20 Sekunden. Da macht es schon einen Unterschied ob ich 20 oder 40 Sekunden warte.
c-hater schrieb: > Mein Gott, dann schaltet man halt eine einzige Binärteilerstufe > dazwischen und gut isses. Da irrst du aber gewaltig, mei Liaber. Natürlich kann man das so machen wie du beschrieben hast, aber der TO wollte sich ein frequenznormal aufbauen und so etwas sollte wenigstens einigermaßen jitterarm sein und die tatsächliche Einschwingzeit auf.. na sagen wir mal 10E-10 sollte auch nicht eine Ewigkeit dauern. Und nun bedenke bitte, daß alle (ja, ALLE) Vorgänge in einem µC taktsynchron zu dessen Systemtakt laufen. Auch das Signal aus dem OCXO wird auf diesen µC Takt synchronisiert, d.h. gesamplet (gesampelt? geprobennehmt..?) und genau DESHALB geht jeglicher Phasenunterschied zum Systemtakt des µC verloren - und auch für ein GPS-Signal gilt dieses. Man kann damit trotzdem etwas basteln, aber muß dann solche Zeitkonstanten in Kauf nehmen, daß die o.g. Phasenunterschiede klein gegen das Gesamt-Differenzsignal werden. Und bei angezielten 10E-10 ist das schon ne ganze Menge. Fazit: für solche Vorhaben würde ich allemal eine wirklich spezielle Lösung aus Analogtechnik und CPLD benutzen und einen µC nur zum Steuern des ganzen sonstigen Zeugs (Anzeigen, Berechnungen usw.) benutzen. Einen ATMega würde ich für sowas aber auf keinen Fall nehmen, für die gibt's ja nicht einmal double - und was will man mit single bei so einem Projekt, wo es um richtig große Auflösungen geht. W.S.
Stefan D. schrieb: > Würde gern in den Bereich +/- 0,05 Hz -> 20 Sekunden. Da macht es schon > einen Unterschied ob ich 20 oder 40 Sekunden warte. Wieso? Mußt du daneben stehen und irgendeine Kurbel drehen oder sowas? Mich würde nichtmal interessieren, wenn das eine halbe Stunde dauert, solange ich, außer ggf. den Anstoß des Vorgangs, nichts weiter dazu beitragen muß, sondern nur irgendwann nur die LED zu Kenntnis nehme, die "habe fertig" anzeigt.
W.S. schrieb: > Da irrst du aber gewaltig, mei Liaber. Natürlich kann man das so > machen wie du beschrieben hast, aber der TO wollte sich ein > frequenznormal aufbauen und so etwas sollte wenigstens einigermaßen > jitterarm sein und die tatsächliche Einschwingzeit auf.. na sagen wir > mal 10E-10 sollte auch nicht eine Ewigkeit dauern. Was hat die Einschwingzeit des Normals mit dem Thread-Thema zu schaffen? Garnix. > Und nun bedenke bitte, daß alle (ja, ALLE) Vorgänge in einem µC > taktsynchron zu dessen Systemtakt laufen. Das stimmt nicht mal. Aber selbst wenn es stimmen würde, spielt es beim konkreten Thema überhaupt keine Rolle. > Auch das Signal aus dem OCXO > wird auf diesen µC Takt synchronisiert, d.h. gesamplet (gesampelt? Natürlich. Genau deswegen braucht er ja auch die zusätzliche Teilerstufe, weil sonst der edge detector am Takteingang des Timers nicht schnell genug für das Signal wäre. > und genau DESHALB geht jeglicher Phasenunterschied zum > Systemtakt des µC verloren Was in dieser Anwendung, die darauf abzielt, recht lange zu zählen, exakt KEIN SCHWEIN interessiert. Du hast offensichtlich einfach nicht begriffen, was der TO eigentlich machen will...
Stefan D. schrieb: > Ja, nur mit der Binärteilerstufe auf 5 MHz verdoppelt sich dann meine > Messzeit. Als ob es kein Zwischending zwischen Bit-ignorieren und 32-Bit-Zähler-mit-SPI gibt. Vielleicht ist irgendwo noch irgendein Nachfolger vom 74192 als 4-Bit Vorteiler aufzutreiben,
Stefan D. schrieb: > Mit dem µC möchte ich das Zählen nicht machen, da mir die 20 MHz Takt > der Atmegas zu gering für eine sichere Erfassung sind und ich auch gern > bei den ATMegas bleiben will. Hmm, Du willst nicht den OCXO nehmen um den Controller zu takten? Das ist doch die einfachste und beste Moeglichkeit. Ansonsten muss Deine Taktquelle fuer den Controller ja noch genauer als der OCXO sein. 73
Hi Sven, ich will das GPS Signal als Torheit für die Messung nutzen und nach 20 Sekunden die Pulse des Ocxo auswerten. Will die Messzeit möglichst kurz halten um nicht Probleme mit der Kurzzeitstabilität des Ocxo zu bekommen.
Stefan D. schrieb: > ich will das GPS Signal als Torheit für die Messung nutzen Eine Torheit zu begehen, bringt aber noch keine genaue Torzeit. ;-) MfG Paul
Stefan D. schrieb: > Hi Sven, ich will das GPS Signal als Torheit für die Messung nutzen "Torheit" trifft den Nagel auf den Kopf ;-) Ein Beispiel auf die Schnelle: Beitrag "reziproker Frequenzzähler, GPS-stabilisiert, ATmega162" Und wenn Du Dich vom AVR verabschieden möchtest, etwas Feines: http://www.mino-elektronik.de/FM_407/fmeter_407.htm
Stefan D. schrieb: > Hi Sven, ich will das GPS Signal als Torheit für die Messung nutzen und > nach 20 Sekunden die Pulse des Ocxo auswerten. Will die Messzeit > möglichst kurz halten um nicht Probleme mit der Kurzzeitstabilität des > Ocxo zu > bekommen. Hmm, schau Dir mal das Konzept von dl4jal an http://www.dl4jal.eu/fnormal/fnormal.html Bitte lies auch das Paper von Ulrich Bangert zum Thema http://ulrich-bangert.de/AMSAT-Journal.pdf das sollte Pflichtlektuere fuer OCXO Bauer sein. Eventuell ueberdenkst Du Dien Konzept dann nochmal. 73 und viel Erfolg
Der Inhalt des Teilers ist ja nicht verloren. Wenn das Tor zu gemacht hat, wackelt der µC so oft am Teiler-Eingang, bis sich dessen Ausgang ändert. Und schon hat man wieder die volle Auflösung.
Komisch andere schaffen 1ns Auflösung mit dem Arduino. https://www.febo.com/pipermail/time-nuts/2014-February/082820.html Gruß Anja
Wie wär's mit einem Mikrocontroller, der ausreichend schnelle Timer hat? Ein STM32F103RBT6 zB (gibts handliche Eval-Boards für) hat Timer die mit 36MHz externem Takt zählen können. So brauchts 0 externe Komponenten...
Hallo Stefan, um auf deine Ausgangsfrage zurück zu kommen, kennst Du schon den SN74LV8154-EP ? DUAL 16 BIT BINARY COUNTER WITH 3 STATE OUTPUT REGISTERS # http://www.ti.com/product/SN74LV8154-EP
:
Bearbeitet durch User
Hi Uwe, den hab ich gerade eben auch gefunden, sieht gut aus, muss nur noch schauen, wo ich den beschaffen kann. Habs bisher nur bei Mouser gefunden. Sven: Genau so etwas soll es werden, nur das der Atmega diese spezielle Capturefunktion nicht hat. KinderGärtner: Ich will - aus Mangel an Pic Ahnung - für das Projekt nicht die Plattform wechseln. Anja: Ist mir noch nicht so ganz klar, wie er auf 1 ns kommt... Der reziproke Frequenzzähler sieht auch sehr interessant aus. Danke schonmal an Alle
Hallo Stefan, ich habe noch DIL-16 und TSSOP Typen da. Gegen Porto Erstattung, erhälst Du gerne einen von mir. Noch etwas zur Beschaltung könntest Du hier erfahren: # http://www.swharden.com/blog/2011-01-28-home-brew-transceiver-taking-shape/
Stefan D. schrieb: > Anja: Ist mir noch nicht so ganz klar, wie er auf 1 ns kommt... Durch einen externen Phasenkomparator der mit dem ADC auf 10 Bit aufgelöst wird. Gruß Anja
Hallo Uwe, das ist wirklich klasse von Dir. Ich schreib Dir eine PN.
Anja schrieb: > Komisch > > andere schaffen 1ns Auflösung mit dem Arduino. > > https://www.febo.com/pipermail/time-nuts/2014-February/082820.html > > Gruß Anja Hallo, das ist ja sehr interessant. Was meint er mit "TIC"? Ich finde nichts sinnvolles, wofuer er die Abkuerzung verwendet. 73
wie wäre es mit time interval counter ? http://tf.nist.gov/general/pdf/1950.pdf Es scheint bei den time nuts keine ungebräuchliche Abkürzung zu sein. Ist wohl so etwas wie eine "blinkende LED" oder ein "hello world" https://www.febo.com/pipermail/time-nuts/2014-February/082682.html Gruß Anja
Mike schrieb: > Als ob es kein Zwischending zwischen Bit-ignorieren und > 32-Bit-Zähler-mit-SPI gibt. Vielleicht ist irgendwo noch irgendein > Nachfolger vom 74192 als 4-Bit Vorteiler aufzutreiben, Also wenn schon, dann *193. Und auch der wäre Scheiße, weil er kein Latch für die Ausgänge besitzt. Und ohne so ein Latch wird es dir nicht gelingen, die vier Bit des externen Counters synchron mit den Bits des internen Counters einzulesen. Generell ist es so, daß die Zahl der Stufen des externen Vorteilers bezüglich der Geschwindigkeit irrelevant ist, weil bereits eine genügen würde, um sie ausreichend herabzusetzen. Bezüglich der Bits ist aber ohne Latch alles verloren, was außerhalb der Taktdomäne des µC passiert, weswegen natürlich anzustreben ist, daß die kleinstmögliche Bitzahl außerhalb des µC gezählt wird, also genau eins. Mit Latch hingegen werden wieder alle Bits nutzbar, aber auch dann ist anzustreben, sowenig Bits wie möglich außerhalb zu zählen, weil dadurch die Pinzahl zum Datenaustausch zwischen µC und Latch minimiert wird. Das Minimum wären hier drei Pins (Tx,ICPx,Bit0) und dieses Minimum wird genau dann erreicht, wenn man eine einzelne externe Teilerstufe mit Latch verwendet. Beim Ansatz der TO würde man zwar mit zwei Pins auskommen (SCK und MISO), hätte aber statt des leicht realisierbaren und spottbilligen 1-Bit-Counters mit Latch (z.B. *13) einen Spezial-IC zu suchen, zu besorgen und zu bezahlen. Und genau deswegen ist er ja hier aufgeschlagen...
Warum man allerdings solch einen TIC braucht, verstehe ich nicht so richtig. Ein ATmega macht die Zählerei nebenbei - schnell genug und taktgenau per Input-Capture. Ferner hat man ohne Verdrahtung die Werte schon im µC. Aber mach so, wie Du es kannst. W.S. schrieb: > Einen > ATMega würde ich für sowas aber auf keinen Fall nehmen, für die gibt's > ja nicht einmal double - und was will man mit single bei so einem > Projekt, wo es um richtig große Auflösungen geht. 'double' geht mit AVR und ist nicht einmal langsam.
m.n. schrieb: > Warum man allerdings solch einen TIC braucht, verstehe ich nicht so > richtig. Der TO will 28 Bit Auflösung in weniger als 20 Sekunden. Mit der Methode der time-nuts erhält man 1ns Auflösung in 1 Sekunde = 30 Bit. m.n. schrieb: > Ein ATmega macht die Zählerei nebenbei - schnell genug und > taktgenau per Input-Capture. aber nicht mit 1000 Mhz (1ns) Auflösung. -> der Phasenjitter des Oszillators erhöht sich entsprechend. Wenn man schon unbedingt einen externen 32 Bit Zähler mit SPI haben will kann man auch einen pic24fv32ka304 nehmen und zwei der 16-Bit Zähler samt Capture/Compare kaskadieren. (Ich würde in dem Fall allerdings den ATMega weglassen). Gruß Anja
Nachtrag: ich sehe gerade beim PIC24FV32KA304 kann man mit der CTMU Unit Auflösungen bis 200ps erreichen. -> man könnte mit etwas Hirnschmalz die Lösung der time-nuts noch um Faktor 5 toppen. Gruß Anja
Anja schrieb: > Der TO will 28 Bit Auflösung in weniger als 20 Sekunden. Die hat er doch, wenn er die 10 MHz 20 Sekunden lang zählt. Beim AVR betreibt man diesen mit den 10 MHz und 'fängt' 20 Flanken des 1pps GPS-Signal mit Timer1 ein. Man hat damit einen Startzeitpunkt und einen Endzeitpunkt und die Zeit als Differenzwert. Anja schrieb: > aber nicht mit 1000 Mhz (1ns) Auflösung. Ich kann Dir leider nicht folgen. 1 GHz, wo kommen die denn jetzt her? 1 ns hattest Du ins Spiel gebracht. Die rechnerische Auflösung kann meinetwegen 1 ps betragen, mich interessiert eher die Genauigkeit. Ist die irgendwo verifiziert? Ich bleibe lieber auf einem Teppich, der nicht fliegt, laß mich aber auch gerne überraschen ;-)
sven schrieb: > Was meint er mit "TIC"? Ich finde nichts > sinnvolles, wofuer er die Abkuerzung verwendet. Hast du es mal mit "time interval counter" versucht? vy 73
c-hater schrieb: > Mike schrieb: > >> Als ob es kein Zwischending zwischen Bit-ignorieren und >> 32-Bit-Zähler-mit-SPI gibt. Vielleicht ist irgendwo noch irgendein >> Nachfolger vom 74192 als 4-Bit Vorteiler aufzutreiben, > > Also wenn schon, dann *193. Und auch der wäre Scheiße, weil er kein > Latch für die Ausgänge besitzt. Und ohne so ein Latch wird es dir nicht > gelingen, die vier Bit des externen Counters synchron mit den Bits des > internen Counters einzulesen. Das braucht man doch garnicht. Die richtige Flanke vom 1PPS (ich gehe mal davon aus das sowas benutzt werden soll) startet/stoppt die ganze Zaehlmechanik. Dazu braucht man richtige Hardware ausserhalb des µC, kontrolliert vom µC, der Stand des externen Vorteilers muss natürlich auch vom µC gelesen/zurückgesetzt werden können. Und viola, man hat etliche 100mS Zeit die Zähler auszulesen und zusammenzurechnen. Dadurch hat man natürlich immer 1 Sekunde Totzeit zwischen den Messungen, aber wen stört das wenn eine Messung Dutzende Sekunden dauert?
Jasch schrieb: > Dazu braucht man richtige Hardware ausserhalb des µC, kontrolliert > vom µC, der Stand des externen Vorteilers muss natürlich auch vom > µC gelesen/zurückgesetzt werden können. Und natürlich muss der exernen Vorteiler vom µC nicht direkt gelesen werden können. Die Methode hatte Lukas bereits beschrieben. Das Rücksetzen ist damit auch gleich erledigt. Lukas K. schrieb: > Wenn das Tor zu gemacht hat, wackelt der µC so oft am Teiler-Eingang, > bis sich dessen Ausgang ändert.
Jasch schrieb: > Und viola, Gruß an Viola ;-) > Dadurch hat man natürlich immer 1 Sekunde Totzeit zwischen den > Messungen, aber wen stört das wenn eine Messung Dutzende Sekunden > dauert? Mich stört das, weil es überhaupt nicht notwendig ist; ebensowenig wie ein ext. Zähler. Anders wäre die Situation, wenn man passende Zähler verwendet, die meinetwegen 500 MHz mitmachen und sich bei der Messung ohne Berücksichtigung der Phasenlage gleich ein Faktor 50 zu der 10 MHz Referenz ergäbe. Dann landet man wohl beim obigen Vorschlag von W.S., gleich ein CPLD zu verwenden und kann die Phasenlage des Referenzsignals gleich digital mit auswerten. Nur zu ;-)
m.n. schrieb: > Jasch schrieb: >> Und viola, > > Gruß an Viola ;-) Ich behaupte einfach mal das sollte so... ;-) >> Dadurch hat man natürlich immer 1 Sekunde Totzeit zwischen den >> Messungen, aber wen stört das wenn eine Messung Dutzende Sekunden >> dauert? > > Mich stört das, weil es überhaupt nicht notwendig ist; ebensowenig wie > ein ext. Zähler. Bist Du da sicher? Die Counter im ATMega können meines Wissens maximal bis zur halben Taktfrequenz betrieben werden, im Sinne zuverlässigen Funktionierens wäre ein Sicherheitsabstand gut. Und selbst der 16-Bit-Counter würde dann noch über 150 Interrupts pro Sekunde machen, von denen man keinen verpassen darf. Wenn Du bloss einen 8-Bit-Counter zur Verfügung hast, hmm. Ich würde es mir da einfach leichter machen wollen, damit die Software nicht so schwierig wird. > Anders wäre die Situation, wenn man passende Zähler verwendet, die > meinetwegen 500 MHz mitmachen und sich bei der Messung ohne > Berücksichtigung der Phasenlage gleich ein Faktor 50 zu der 10 MHz > Referenz ergäbe. > Dann landet man wohl beim obigen Vorschlag von W.S., gleich ein CPLD zu > verwenden und kann die Phasenlage des Referenzsignals gleich digital mit > auswerten. Nur zu ;-) Kommt drauf an was man bauen will. Ein Frequenznormal für stinknormale Sachen oder ein Time-Nuts-Style Timing-Grade Dingens. Für letzteres landet man dann z.B. bei schon genanntem TIC und anderem ziemlich komplexem Zeug, mit Auflösungen für die Phasendifferenz von Sub-Nanosekunden, direkt die 10MHz zählen tut da keiner mehr. Ist ein ganz eigenes, nicht direkt billiges, Hobby. =8^)
Jasch schrieb: > Die Counter im ATMega können meines Wissens maximal bis zur halben > Taktfrequenz betrieben werden, im Sinne zuverlässigen Funktionierens > wäre ein Sicherheitsabstand gut. Das ist schon richtig, aber ich meine es etwas anders. Der µC (und damit der passende interne Timer1 beim AVR) wird mit Fref betrieben; diese liegt ja permanent an. Synchron zum 1 pps-Signal wird der Timer ausgelesen und man erhält damit das genaue Verhältnis von 1 Hz (GPS) und Fref. Die paar Interrupts, die dabei auftreten, sind kein Problem, da man einige Millisekunden Zeit hat, darauf zu reagieren. Wichtig ist nur, daß das Capture-Register den genauen Zeitpunkt festhält. Jasch schrieb: > Kommt drauf an was man bauen will. Ja, stimmt! Bei schönenm Wetter fange ich immer an zu spinnen; und gestern war schönes Wetter ;-)
Stefan D. schrieb: > Dafür suche ich nach einem 32-Bit Counter IC mit SPI-Interface, der > schnell genug für 10 MHz ist und genug Stufen besitz ca. 10 bis 20 > Sekunden lang zu zählen(20 sec *10 Mhz ~ 28 Bit). Nimm einen ATtiny25 und programmiere ihn entsprechend. Die 10MHz an CLKI (PB3), SPI an PB0,1,2 und falls Du noch ein jitterfreies Torsignal brauchst, von OC1B (PB4) abgreifen.
Stefan D. schrieb: > Mit dem µC möchte ich das Zählen nicht machen, da mir die 20 MHz Takt > der Atmegas zu gering für eine sichere Erfassung sind und ich auch gern > bei den ATMegas bleiben will. Jaja, immer diese AVR-Bastler. Du könntest das ganze mit einem kleinen CPLD oder FPGA erschlagen. Damit würdest Du auch noch problemlos ein bis eineinhalb Zehnerpotenzen höher von der Geschwindigkeit kommen. fchk
@Jasch (Gast): 150 Interrupts/Sekunde sind für einen ATmega eine lockere Nebenbeschäftigung, bei 20 MHz sind das ein Interrupt alle 133333,333... Taktzyklen, da ist man von 'knapp' und Interrupts verpassen noch weit weg. Wenn man, wie schon, von anderen hier, vorgeschlagen, den ATmega mit dem zu zählenden Signal taktet, kann man den Zähler mit vollem Takt laufen lassen, und so jeden Impuls erfassen. Mit freundlichem Gruß - Martin
Vielen Dank für die guten Antworten und Ideen! Das TIC Thema finde ich recht interessant, aber vermutlich vorerst etwas zu hoch für mich. Die Sache mit dem ATTiny25 will mir auch nicht so recht einleuchten, da ATTiny mit 20 MHz vermutlich nicht jede Flanke des 10MHz Signals mitbekommen würde. Ich werde jetzt erstmal mit dem externen Zähler SN74LV8154 von Uwe beginnen und mit 20 Sekunden Torzeit hoffentlich auf meine 0,05Hz Genauigkeit kommen(So wie im Link von Sven beschrieben). Parallel zu meiner Schaltung werde ich mich dann mal in die TIC Geschichte genauer einlesen und das evtl. mit auf der Platine für erste Tests vorsehen. Hab mich für einen ATMega324 entschieden - damit soll dann noch ein Display angesteuert, die GPS-Daten ausgewertet(Zeit, Anz. der Satelliten) und die VCO-Spannung mittels PWM für den OCXO erzeugt werden. Hat jemand von Euch schonmal eine solche TIC-Schaltung aufgebaut? Und verstehe ich es richtig, dass man damit dann quasi den Phasenwinkel als Spannung zur Auswertung bekommt? Also bspw. in meiner Torzeit habe ich 23 volle Perioden + 0,37 Perioden gemessen?
Stefan D. schrieb: > Die Sache mit dem ATTiny25 will mir auch nicht so recht einleuchten, da > ATTiny mit 20 MHz vermutlich nicht jede Flanke des 10MHz Signals > mitbekommen würde. Wenn ein AVR mit 10 MHz getaktet wird, bekommt er auch jede Flanke mit. Ich dachte, das wäre klar gewesen :-(
Die TIC Schaltung gibt eine analoge Interpolation für die hohe Zeitauflösung. Das Beispiel mit den 23,37 Periode kommt schon so hin. In dem Beispiel wird halt der 1 MHz Takt noch einmal auf rund 1000 Stufen interpoliert. Die angegebenen 1 ns sind aber etwas übertrieben, weil der ADC und der 4046 nicht perfekt sind. Das sollte aber ausreichen um unter 10 ns zu kommen, und damit besser als der Jitter des 1pps Signals vom GPS Empfänger. Statt hc4046 ließe sich ggf. auch ein CPLD oder ein paar 74AC74 und 74AC00 nutzen um noch etwas genauer zu werden, indem weniger als 1 µs (z.B. 100 ns) interpoliert werden.
Martin Schlüter schrieb: > @Jasch (Gast): > > 150 Interrupts/Sekunde sind für einen ATmega eine lockere > Nebenbeschäftigung, bei 20 MHz sind das ein Interrupt alle 133333,333... Das ist klar. Ist nicht mehr so locker wenn man z.B. den 16-Bit-Counter für den PWM-DAC zur Nachsteuerung des Oszillators verplant hat. > Taktzyklen, da ist man von 'knapp' und Interrupts verpassen noch weit > weg. In meinem Hinterkopf war da dass der ATmega ja sicher noch mehr tun soll als bloss zu zählen. Und je nachdem was das alles ist und wieviele andere Interrupts und sonstige Gemeinheiten das involviert (mmmhhhh, verschachtelte Interrupts, Kopfschmerzen) ist es eben nicht mehr ganz so einfach. [...]
Jasch schrieb: > Und selbst der 16-Bit-Counter würde dann noch über 150 Interrupts pro > Sekunde machen, von denen man keinen verpassen darf. Ooh, my god ... Wer natürlich lange delay() in die ISR packt, kann damít echte Probleme bekommen.
Jasch schrieb: > In meinem Hinterkopf war da dass der ATmega ja sicher noch mehr tun soll > als bloss zu zählen. Das ist kein Problem; die Timer laufen völlig ohne Software-Unterstützung. > Und je nachdem was das alles ist und wieviele andere Interrupts und > sonstige Gemeinheiten das involviert (mmmhhhh, verschachtelte > Interrupts, Kopfschmerzen) ist es eben nicht mehr ganz so einfach. Diese Probleme existieren nur in Deinem Kopf. Ein ATmega wird sich richtig langweilen ;-) Ulrich H. schrieb: > Die angegebenen 1 ns sind aber etwas übertrieben, > weil der ADC und der 4046 nicht perfekt sind. Das sollte aber ausreichen > um unter 10 ns zu kommen, und damit besser als der Jitter des 1pps > Signals vom GPS Empfänger. Ich teile Deine Einschätzung, daß die erhoffte Auflösung/Genauigkeit zu optimistisch gesehen wird. Weiter oben hatte ich auf eine GPS-stabilisierte Messung mit einem STM32F4xx verwiesen, die von Hause aus schon 6 ns Auflösung/Genauigkeit bietet. Meines Erachtens ist die Wahl eines geeigneten µC effektiver, als mit diverser Hardware schnelle Timer nachzubilden.
also ich kann da nur m.n. (Gast) zustimmen, ein Rechenzeit-Problem sehe ich da echt nicht, und wenn man den Timer tatsächlich für eine PWM braucht, lässt man ihn halt dauernd laufen, ersetzt das starten/stoppen des Timers durch das auslesen des Zählerstands, hier ließe sich vielleicht die Capture-Einheit nutzen, und kann mit dem Timer sowohl messen, als auch die PWM-Erzeugung machen. Selbst wenn man doch auf einen der 8-Bit Timer ausweicht, die ISR für das erfassen der Ueberläufe sollte in 25-35 Taktzyklen (Inclusive Aufruf) machbar sein, das sind dann auch nur 13,7% der Rechenleistung. Geschickt programmiert stemmen die ATmegas Einiges. Etwas Hirnschmalz, und die Bereitschaft ein Bisschen zu knobeln sollte halt schon vorhanden sein. Ich bastele gerade an einem LED-Cube, da wird jede LED mit ihrer 10-Bit Software-PWM versorgt, da generiert ein ATmega644 25 PWM-Signale mit einer PWM-Frequenz von 2400 Hz und einer Auflösung von 10 Bit. Getaktet ist er mit 10 MHz. Dabei müssen die Ausgaben auf die Ports auf einen Taktzyklus genau sein, die Schrittweite der Impulslänge ist gerade mal 4 Taktzyklen. Mit freundlichen Grüßen - Martin
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.