Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #205330 > unrolled thread

maximale Eingangsfrequenz Counter AVR

Back to article view | Back to de.sci.electronics

Contents

  maximale Eingangsfrequenz Counter AVR Stefan <df9bi@arcor.de> - 2016-03-24 10:12 +0100
    Re: maximale Eingangsfrequenz Counter AVR Christian Zietz <newsgroup.1001@chz.xyz> - 2016-03-24 10:39 +0100
      Re: maximale Eingangsfrequenz Counter AVR Stefan <df9bi@arcor.de> - 2016-03-24 12:01 +0100
    Re: maximale Eingangsfrequenz Counter AVR Axel Schwenke <axel.schwenke@gmx.de> - 2016-03-24 12:30 +0100
      Re: maximale Eingangsfrequenz Counter AVR Michael Baeuerle <michael.baeuerle@stz-e.de> - 2016-03-24 13:46 +0000
        Re: maximale Eingangsfrequenz Counter AVR Stefan <df9bi@arcor.de> - 2016-03-24 19:13 +0100
        Re: maximale Eingangsfrequenz Counter AVR Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-03-25 04:14 +0100
          Re: maximale Eingangsfrequenz Counter AVR Michael Baeuerle <michael.baeuerle@gmx.net> - 2016-03-25 10:03 +0000
          Re: maximale Eingangsfrequenz Counter AVR Michael Schwingen <news-1454959088@discworld.dascon.de> - 2016-03-25 16:04 +0000
            Re: maximale Eingangsfrequenz Counter AVR Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-03-26 01:06 +0100
              Re: maximale Eingangsfrequenz Counter AVR Michael Schwingen <news-1454959088@discworld.dascon.de> - 2016-03-26 15:00 +0000
                Re: maximale Eingangsfrequenz Counter AVR Stefan <df9bi@arcor.de> - 2016-03-27 14:10 +0200
                  Re: maximale Eingangsfrequenz Counter AVR Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-03-27 23:20 +0200
                  Re: maximale Eingangsfrequenz Counter AVR Michael Schwingen <news-1454959088@discworld.dascon.de> - 2016-03-28 08:43 +0000

#205330 — maximale Eingangsfrequenz Counter AVR

Hallo,

ich hab hier ein Bastelprojekt mit einem PIC16F628 auf dem Tisch. Das 
ist ein simpler Frequenzzähler, der bis maximal 50 MHz geht (?).

Der PIC kann also offenbar schneller zählen als sein eigener Takt.

Wie ist das beim ATmaga? Ich kenn mich mit AVR Prozessoren ganz gut aus, 
aber irgendwie finde ich nicht die passende Seite im Datenblatt.

Wenn man so einen Zähler nun mit nem AVR bauen wollte, wie schnell geht der?

Gruß
Stefan

[toc] | [next] | [standalone]

#205332

Stefan schrieb:

> Wie ist das beim ATmaga? Ich kenn mich mit AVR Prozessoren ganz gut aus, 
> aber irgendwie finde ich nicht die passende Seite im Datenblatt.
> 
> Wenn man so einen Zähler nun mit nem AVR bauen wollte, wie schnell geht der?

Jetzt gibt es nicht *den* ATmega, aber z.B. für einen ATmega8 kann ich
das beantworten. Die externen Eingänge für Timer0 und 1 werden mit dem
Systemtakt gesamplet/synchronisiert, daher: "Since the edge detector
uses sampling, the maximum frequency of an external clock it can detect
is half the sampling frequency. However, [...] it is recommended that
maximum frequency of an external clock source is less than fclk_IO/2.5."

Bleibt noch Timer2, der zwar asynchron getaktet werden kann, aber
eigentlich für 32,768 kHz ausgelegt ist. Zitat Datenblatt: "Applying an
external clock to the TOSC1 pin may result in incorrect Timer/Counter2
operation. The CPU main clock frequency must be more than four times the
Oscillator frequency."

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#205339

Am 24.03.2016 um 10:39 schrieb Christian Zietz:
> Stefan schrieb:
>
>> Wie ist das beim ATmaga? Ich kenn mich mit AVR Prozessoren ganz gut aus,
>> aber irgendwie finde ich nicht die passende Seite im Datenblatt.
>>
>> Wenn man so einen Zähler nun mit nem AVR bauen wollte, wie schnell geht der?
>
> Jetzt gibt es nicht *den* ATmega, aber z.B. für einen ATmega8 kann ich
> das beantworten. Die externen Eingänge für Timer0 und 1 werden mit dem
> Systemtakt gesamplet/synchronisiert, daher: "Since the edge detector
> uses sampling, the maximum frequency of an external clock it can detect
> is half the sampling frequency. However, [...] it is recommended that
> maximum frequency of an external clock source is less than fclk_IO/2.5."
>
> Bleibt noch Timer2, der zwar asynchron getaktet werden kann, aber
> eigentlich für 32,768 kHz ausgelegt ist. Zitat Datenblatt: "Applying an
> external clock to the TOSC1 pin may result in incorrect Timer/Counter2
> operation. The CPU main clock frequency must be more than four times the
> Oscillator frequency."

Ok, dann ist der PIC doch besser für so ein Frequenzzählerprojekt 
geeignet als der ATmega8 o.ä.

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#205342

Stefan <df9bi@arcor.de> wrote:
> ich hab hier ein Bastelprojekt mit einem PIC16F628 auf dem Tisch. Das
> ist ein simpler Frequenzzähler, der bis maximal 50 MHz geht (?).
> Der PIC kann also offenbar schneller zählen als sein eigener Takt.
>
> Wenn man so einen Zähler nun mit nem AVR bauen wollte, wie schnell geht der?

Wenn man einen Zähler in einem AVR (definitiv alles unter Xmega
und für letztere bin ich mir zu 99% sicher daß da auch) von einem
externen Takt clocken lassen will, dann darf der maximal halb so
groß wie der Systemtakt sein, weil der AVR alles mit dem Systemtakt
synchronisiert. Genauer gesagt müssen der H-Anteil und der L-Anteil
des Signals jeweils mindestens eine Taktperiode lang sein. Das gilt
auch für Flankenerkennung (Capture & Co).

Für höhere Frequenzen kommt man also um einen Vorteiler oder gar
Vorzähler nicht drum herum. Mein AVR-basiertes

www.mikrocontroller.net/articles/Frequenzzählermodul

verwendet dafür einen 74HC590. Das rennt dann so weit wie 74HC geht.
Praktisch haben mehrere Leute damit bis 66MHz gemessen.


XL

[toc] | [prev] | [next] | [standalone]

#205346

Axel Schwenke wrote:
> Stefan <df9bi@arcor.de> wrote:
> > 
> > ich hab hier ein Bastelprojekt mit einem PIC16F628 auf dem Tisch. Das
> > ist ein simpler Frequenzzähler, der bis maximal 50 MHz geht (?).
> > Der PIC kann also offenbar schneller zählen als sein eigener Takt.
> > 
> > Wenn man so einen Zähler nun mit nem AVR bauen wollte, wie schnell geht der?
> 
> Wenn man einen Zähler in einem AVR (definitiv alles unter Xmega
> und für letztere bin ich mir zu 99% sicher daß da auch) von einem
> externen Takt clocken lassen will, dann darf der maximal halb so
> groß wie der Systemtakt sein, weil der AVR alles mit dem Systemtakt
> synchronisiert. Genauer gesagt müssen der H-Anteil und der L-Anteil
> des Signals jeweils mindestens eine Taktperiode lang sein. Das gilt
> auch für Flankenerkennung (Capture & Co).

Das scheint doch bei dem PIC16F628 aber ähnlich zu sein. Zitat aus dem
Datenblatt:
| 
| 6.2.1 EXTERNAL CLOCK SYNCHRONIZATION
| 
| When no prescaler is used, the external clock input is
| the same as the prescaler output. The synchronization
| of T0CKI with the internal phase clocks is
| accomplished by sampling the prescaler output on the
| Q2 and Q4 cycles of the internal phase clocks
| (Figure 6-1). Therefore, it is necessary for T0CKI to be
| high for at least 2TOSC (and a small RC delay of 20 ns)
| and low for at least 2TOSC (and a small RC delay of
| 20 ns). Refer to the electrical specification of the
| desired device.
| When a prescaler is used, the external clock input is
| divided by the asynchronous ripple-counter type
| prescaler so that the prescaler output is symmetrical.
| For the external clock to meet the sampling
| requirement, the ripple-counter must be taken into
| account. Therefore, it is necessary for T0CKI to have a
| period of at least 4TOSC (and a small RC delay of 40 ns)
| divided by the prescaler value. The only requirement
| on T0CKI high and low time is that they do not violate
| the minimum pulse width requirement of 10 ns. Refer to
| parameters 40, 41 and 42 in the electrical specification
| of the desired device. See Table 17-7.

Wirklich asynchron kann also scheinbar nur der Prescaler laufen und
der Timer selbst kommt nicht über fosc/4 hinaus (also den Core-Takt,
bei PIC16 ist ja 1 Core-Cycle == 4 * Tosc).

[toc] | [prev] | [next] | [standalone]

#205349

Am 24.03.2016 um 14:46 schrieb Michael Baeuerle:
> Axel Schwenke wrote:
>> Stefan <df9bi@arcor.de> wrote:
>>>

> Wirklich asynchron kann also scheinbar nur der Prescaler laufen und
> der Timer selbst kommt nicht über fosc/4 hinaus (also den Core-Takt,
> bei PIC16 ist ja 1 Core-Cycle == 4 * Tosc).
>

Ok, ich erinnere mich dunkel. Ich hab diese Woche einen PIC16F628 für 
einen Frequenzzähler nach DL4YHF gebrannt ohne mich da näher mit zu 
beschäftigen, aber mir war aufgefallen, dass da Frequenzen angezeigt 
wurden, die deutlich höher waren als die Quarzfrequenz des PIC. Mit dem 
internen Vorteiler macht das natürlich Sinn.


Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#205361

Michael Baeuerle schrieb:

> Wirklich asynchron kann also scheinbar nur der Prescaler laufen und
> der Timer selbst kommt nicht über fosc/4 hinaus (also den Core-Takt,
> bei PIC16 ist ja 1 Core-Cycle == 4 * Tosc).

Ich war ja einigermaßen überrascht, daß ein externer Takt überhaupt 
synchronisiert werden muß. Kann das jemand erklären?

Liegt das vielleicht daran, daß ein asynchroner Zähler nur ausgelesen 
werden darf, nachdem die Überträge ganz durchgelaufen sind?

DoDi

[toc] | [prev] | [next] | [standalone]

#205381

Hans-Peter Diettrich wrote:
> Michael Baeuerle schrieb:
> > 
> > Wirklich asynchron kann also scheinbar nur der Prescaler laufen und
> > der Timer selbst kommt nicht über fosc/4 hinaus (also den Core-Takt,
> > bei PIC16 ist ja 1 Core-Cycle == 4 * Tosc).
> 
> Ich war ja einigermaßen überrascht, daß ein externer Takt überhaupt 
> synchronisiert werden muß. Kann das jemand erklären?

Muss er ja nicht zwingend, wie man an dem Prescaler sieht.

> Liegt das vielleicht daran, daß ein asynchroner Zähler nur ausgelesen 
> werden darf, nachdem die Überträge ganz durchgelaufen sind?

Ich denke die Timer selbst bestehen aus synchronen Zählern, die dieses
Problem nicht haben. Synchronisiert werden muss hier nicht auf den
Übertrag, sondern auf die Zugriffe der CPU. Deren Takt ist hier ja nicht
aus dem des Zählers (bzw. umgekehrt) abgeleitet und es muss sicherge-
stellt werden, dass der Timer während eines Zugriffs nicht weiterzählt.
-- 
> It works.
Die Beschreibung hört sich aber eher nach "It würgs" an...

                                               Günter Frenz in ger.ct

[toc] | [prev] | [next] | [standalone]

#205421

On 2016-03-25, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
> Ich war ja einigermaßen überrascht, daß ein externer Takt überhaupt 
> synchronisiert werden muß. Kann das jemand erklären?

Am Übergang zwischen Clockdomänen muss synchronisiert werden - siehe
https://en.wikipedia.org/wiki/Metastability_in_electronics

Nun kannst Du entweder den Eingangstakt des Zählers synchronisieren, oder
den Ausgang des Zählers in Richtung CPU.  Bei der 2.  Lösung hast Du bei
normaler Binärdarstellung trotzdem das Problem, ob alle Bits beim Auslesen
einen konsistenten Zustand haben.

Die Lösung, den Zähler synchron mit dem CPU-Takt zu fahren und den Eingang
zu synchronisieren macht also bei einem Zähler, der von der CPU lesbar sein
soll, durchaus Sinn.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#205453

Michael Schwingen schrieb:
> On 2016-03-25, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>> Ich war ja einigermaßen überrascht, daß ein externer Takt überhaupt 
>> synchronisiert werden muß. Kann das jemand erklären?
> 
> Am Übergang zwischen Clockdomänen muss synchronisiert werden - siehe
> https://en.wikipedia.org/wiki/Metastability_in_electronics
> 
> Nun kannst Du entweder den Eingangstakt des Zählers synchronisieren, oder
> den Ausgang des Zählers in Richtung CPU.  Bei der 2.  Lösung hast Du bei
> normaler Binärdarstellung trotzdem das Problem, ob alle Bits beim Auslesen
> einen konsistenten Zustand haben.

Die 2. Variante ließe sich auch mit einem Register erledigen, das 
synchronisiert wird. Wenn ein CPU-Zugriff erfolgt, wird das Register 
kurzzeitig eingefroren, danach übernimmt es wieder die Werte des Zählers 
(synchron mit dem Eingangssignal). Kommt drauf an, ob sich dieser 
Aufwand lohnt.

> Die Lösung, den Zähler synchron mit dem CPU-Takt zu fahren und den Eingang
> zu synchronisieren macht also bei einem Zähler, der von der CPU lesbar sein
> soll, durchaus Sinn.

Ja, das ist mir beim Schreiben meiner Frage bereits eingefallen. 
Typischer Fall von "Nachdenken mit den Fingern" ;-)

Aber nun habe ich auch noch die wissenschaftliche Begründung, danke an 
alle fürs Mitdenken :-)

DoDi

[toc] | [prev] | [next] | [standalone]

#205481

On 2016-03-26, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>> 
>> Nun kannst Du entweder den Eingangstakt des Zählers synchronisieren, oder
>> den Ausgang des Zählers in Richtung CPU.  Bei der 2.  Lösung hast Du bei
>> normaler Binärdarstellung trotzdem das Problem, ob alle Bits beim Auslesen
>> einen konsistenten Zustand haben.
>
> Die 2. Variante ließe sich auch mit einem Register erledigen, das 
> synchronisiert wird. Wenn ein CPU-Zugriff erfolgt, wird das Register 
> kurzzeitig eingefroren, danach übernimmt es wieder die Werte des Zählers 
> (synchron mit dem Eingangssignal). Kommt drauf an, ob sich dieser 
> Aufwand lohnt.

Dann musst Du das Einfrieren des Registers aber mit beiden Takten
synchronisieren, damit die Daten garantiert konsistent sind. Dazu sind
vermutlich auf der CPU-Bus-Seite Waitstates nötig - die CPU-Kern und
Businterface erstmal können müssen, ich vermute mal, daß man auf sowas gerne
verzichtet. Bei der Verifikation ist es auch einfacher, wenn man möglichst
wenige Übergänge zwischen asynchronen Clockdomänen hat.

Ergo: ja, das ginge, lohnt aber den Aufwand nicht, und die Vorteile wären zu
gering dafür.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#205515

Am 26.03.2016 um 16:00 schrieb Michael Schwingen:
> On 2016-03-26, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>>>

> Dann musst Du das Einfrieren des Registers aber mit beiden Takten
> synchronisieren, damit die Daten garantiert konsistent sind. Dazu sind

Das ist bei der Anwendung als Frequenzzähler nicht nötig.
Man programmiert den Portpin für die Zähldauer als Eingang und nach 
Ablauf der voreingestellten Zeit als Ausgang und setzt ihn auf GND. 
Alternativ kann man den Zählereingang disablen.

Anschließend liest man dann den Zähler aus und fertig.

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#205550

Stefan schrieb:
> Am 26.03.2016 um 16:00 schrieb Michael Schwingen:
>> On 2016-03-26, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>>>>
> 
>> Dann musst Du das Einfrieren des Registers aber mit beiden Takten
>> synchronisieren, damit die Daten garantiert konsistent sind. Dazu sind
> 
> Das ist bei der Anwendung als Frequenzzähler nicht nötig.
> Man programmiert den Portpin für die Zähldauer als Eingang und nach 
> Ablauf der voreingestellten Zeit als Ausgang und setzt ihn auf GND. 
> Alternativ kann man den Zählereingang disablen.

Gute Idee :-)
Hilft aber nur weiter, wenn der Eingangspin nicht zwangsweise 
synchronisiert wird, wie beim ATmega.

DoDi

[toc] | [prev] | [next] | [standalone]

#205561

On 2016-03-27, Stefan <df9bi@arcor.de> wrote:
>
>> Dann musst Du das Einfrieren des Registers aber mit beiden Takten
>> synchronisieren, damit die Daten garantiert konsistent sind. Dazu sind
>
> Das ist bei der Anwendung als Frequenzzähler nicht nötig.
> Man programmiert den Portpin für die Zähldauer als Eingang und nach 
> Ablauf der voreingestellten Zeit als Ausgang und setzt ihn auf GND. 
> Alternativ kann man den Zählereingang disablen.
>
> Anschließend liest man dann den Zähler aus und fertig.

Das ist bei der Anwendung OK - der CPU-Hersteller baut die Timer aber so,
dass sie universell einsetzbar sein sollen, nicht nur für Frequenzzähler,
und da wird die Synchronisation auf Registerseite dann aufwändig.

cu
Michael

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web