Integerzahl stellen abschneiden

[Fellap (Gast)]

Hallo,

gibt es einen Trick bei VHDL bei Integerzahlen bestimmte Anzahl von 0ern 
abzuschneiden ohne zu dividieren?

Beispiel...

Ich habe einen Counter der bis in den 100tausender bereich zaehlt, 
moechte aber nicht mit der grossen Zahl fortfahren sondern nur die 
ersten drei Ziffern verwenden...

Bsp.:
Counter zaehlt bis 130000, moechte aber nur die 130 davon verwenden... 
die restlichen drei 0er sollen abgeschnitten werden...

Komme ich da an einer Division vorbei oder ist die Division unabdingbar?

Vielen Dank im voraus.

Mfg

Fellap

[.... (Gast)]

als BCD zählen?

[Schlumpf (Gast)]

Willst du immer die gleichen Stellen aus deiner Zahl rausschneiden?
Müssen die Grenzen Dezimal sein, oder dürfen es auch Hexadezimale 
Grenzen sein?

[Fellap (Gast)]

Schlumpf schrieb:
> Willst du immer die gleichen Stellen aus deiner Zahl
> rausschneiden?
> Müssen die Grenzen Dezimal sein, oder dürfen es auch Hexadezimale
> Grenzen sein?

jepp immer die gleichen Stellen...

solange ich die Hexadezimale wieder in Dezimal casten kann.. ist das 
egal :)

[Jonas K. (jonas_k)]

.... schrieb:
> als BCD zählen?

genau.
jede einzelne stelle der zahl als bcd-Zähler, dann kann man einfach die 
hinteren stellen weglassen

EDIT: oder zwei getrennte Zähler: abschneidbare stellen und nicht 
abschneidbare. Das dürfte besser sein, wenn die schnittgrenze konstant 
ist

[Schlumpf (Gast)]

Fellap schrieb:
> solange ich die Hexadezimale wieder in Dezimal casten kann.. ist das
> egal :)

Ich meinte eher, ob diese Stellen, an denen du abschneidest, 10er sein 
müssen, oder ob es auch 16er sein dürfen.

[Fellap (Gast)]

Jonas K. schrieb:
> .... schrieb:
>> als BCD zählen?
>
> genau.
> jede einzelne stelle der zahl als bcd-Zähler, dann kann man einfach die
> hinteren stellen weglassen
>
> EDIT: oder zwei getrennte Zähler: abschneidbare stellen und nicht
> abschneidbare. Das dürfte besser sein, wenn die schnittgrenze konstant
> ist

BCD-Zaehler ist aber recht kompliziert oder?

Wie meinst du das mit zwei Zaehlern? das hoert sich interessant an...

Kannst du mir mal bitte ein Bsp. geben.. (muss jetzt kein code sein..) 
verstehe noch nicht ganz was du damit meinst...

[Schlumpf (Gast)]

Ein BCD-Zähler zählt einfach jede Stelle für sich Binär, erzeut aber den 
Übertrag, wenn er von 9 nach 0 springt..

z.B.
Dezimal: 123 = BCD 0001 0010 0011
                     1    2    3

[Fellap (Gast)]

Schlumpf schrieb:
> Ich meinte eher, ob diese Stellen, an denen du abschneidest, 10er sein
> müssen, oder ob es auch 16er sein dürfen.

nee muss schon 10er sein

[Fellap (Gast)]

Schlumpf schrieb:
> Ein BCD-Zähler zählt einfach jede Stelle für sich Binär, erzeut aber den
> Übertrag, wenn er von 9 nach 0 springt..
>
> z.B.
> Dezimal: 123 = BCD 0001 0010 0011
>                      1    2    3

ja aber dann habe ich ja drei Variablen oder Signale, richtig?

Ich moechte von der Zahl aber dann jedoch was abziehen .. dann muss ich 
die andere zahl, die abgezogen wird auch in BCD umrechnen oder?

bzw BCD wieder in einen Bitvector, Integer oder sonstwas umwandeln... 
und das ist recht kompliziert oder?

[Jonas K. (jonas_k)]

Fellap schrieb:
> Kannst du mir mal bitte ein Bsp. geben.. (muss jetzt kein code sein..)
> verstehe noch nicht ganz was du damit meinst...

Angenommen, du weißt schon, du willst immer durch eine bestimmte Zahl 
teilen (kann z. B. 100 sein). Dann machst du einen ersten Zähler, der 
bis 99 zählt, und einen zweiten, der mit dem Überlauf (99 -> 0) des 
ersten Zählers hochgezählt wird.

Das Ergebis der Division ist damit jederzeit der Wert des zweiten 
Zählers.


Zähler 1              Zähler 2      Gesamtzahl
0                     0             0
1                     0             1
2                     0             2
...                   0             ...
98                    0             98
99                    0             99
0                  -> 1             100
...                   1             1..
99                    1             199
0                  -> 2             200

[Ingo (Gast)]

Was is denn so schlimm an einer Division?

[Jonas K. (jonas_k)]

das dürfen natürlich auch zwei Integer-zähler, oder unsigned, oder was 
auch immer du magst, sein...

[Jonas K. (jonas_k)]

Ingo schrieb:
> Was is denn so schlimm an einer Division?

die Implementierung in Logik?

[Fellap (Gast)]

Jonas K. schrieb:
> Angenommen, du weißt schon, du willst immer durch eine bestimmte Zahl
> teilen (kann z. B. 100 sein). Dann machst du einen ersten Zähler, der
> bis 99 zählt, und einen zweiten, der mit dem Überlauf (99 -> 0) des
> ersten Zählers hochgezählt wird.
>
> Das Ergebis der Division ist damit jederzeit der Wert des zweiten
> Zählers.
>
> Zähler 1              Zähler 2      Gesamtzahl
> 0                     0             0
> 1                     0             1
> 2                     0             2
> ...                   0             ...
> 98                    0             98
> 99                    0             99
> 0                  -> 1             100
> ...                   1             1..
> 99                    1             199
> 0                  -> 2             200


ah.. ja verstehe.. aber wie bekomme ich die zusammenfuerhung von zaehler 
eins und zwei hin?

[Jonas K. (jonas_k)]

du machst ein signal, das im ersten Process (1. zähler) den overflow 
anzeigt, und verwendest es als enable-signal für den zweiten process.

Such mal nach enable-signal...

[Jonas K. (jonas_k)]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

ENTITY twoCounters IS
    GENERIC (
        range1 : INTEGER := 999;
        bits1  : INTEGER := 10;
        
        range2 : INTEGER := 99;
        bits2  : INTEGER := 7;
    )
    PORT ( 
        clk    : in  STD_LOGIC;
        -- counter 2 = output signal
        c2     : out INTEGER range 0 to range1
    );
END twoCounters;

ARCHITECTURE rtl OF twoCounters IS
    -- overflow of counter 1
    signal overflow : STD_LOGIC;    
    signal c1       : INTEGER range 0 to range1;
BEGIN

    first : PROCESS
    BEGIN
        IF(rising_edge(clk)) THEN
            IF(c1=range1) THEN
                c1       <= 0;
            ELSE
                c1       <= c1 + 1;
            END IF;
        END IF;
    END PROCESS;  

    overflow : PROCESS
    BEGIN
        IF(rising_edge(clk)) THEN
            IF(c1=range1-1) THEN
                overflow <= '1';
            ELSE
                overflow <= '0';
            END IF;
        END IF;
    END PROCESS;
    
    
    second : PROCESS
    BEGIN
        IF(rising_edge(clk) and (overflow = '1')) THEN
            IF(c2=range2) THEN
                c2       <= 0;
            ELSE
                c2       <= c2 + 1;
            END IF;
        END IF;
    END PROCESS; 
    
END rtl;

[Fellap (Gast)]

Ware das hier nicht einfacher?

Aber wie bekomme ich nun die einzelnen zahlen zusammen?

Also z.B. zahl 6 bis zahl 4 als einen vektor?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;




entity counter is
    Port ( clk :  in  STD_LOGIC
     );
end counter;


architecture Behavioral of counter is

  signal zahl1: integer := 0;
  signal zahl2: integer := 0; 
  signal zahl3: integer := 0;
  signal zahl4: integer := 0;
  signal zahl5: integer := 0;
  signal zahl6: integer := 0;
  
begin

process(clk)
begin

if clk'event and clk = '1' then     -- rising clock edge

   
   if zahl1 = 9 then zahl1 <= 0;
    if zahl2 = 9 then zahl2 <= 0;
      if zahl3 = 9 then zahl3 <= 0;
        if zahl4 = 9 then zahl4 <= 0;
          if zahl5 = 9 then zahl5 <= 0;
            if zahl6 = 9 then zahl6 <= 0; else zahl6 <= zahl6 + 1;
            end if;
          else zahl5 <= zahl5 + 1;
          end if;
        else zahl4 <= zahl4 + 1;
        end if;
      else zahl3 <= zahl3 + 1;
      end if;
    else zahl2 <= zahl2 + 1;
    end if;      
  else zahl1 <= zahl1 + 1;
  end if;      
end if;

end process;

end architecture Behavioral;

[Jonas K. (jonas_k)]

Fellap schrieb:
> Also z.B. zahl 6 bis zahl 4 als einen vektor?

schaut schon recht gut aus!

du musst also die integer-Werte zusammenzählen und mit 10 
multiplizieren.

Besser wäre schon die Version mit nur zwei Zählern, weil du dann die 
obere Zahl direkt abgreifen kannst.

Konvertierung und Casts siehe hier: 
http://www.lothar-miller.de/s9y/categories/16-Numeric_Std


Ich hab mal deinen Code modifiziert.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;




entity counter is
    Port ( clk :  in  STD_LOGIC;
           q   :  out STD_LOGIC_VECTOR(6 downto 0)
     );
end counter;


architecture Behavioral of counter is

  signal zahl1: integer := 0;
  signal zahl4: integer := 0; 
  
begin

process(clk)
begin

if clk'event and clk = '1' then     -- rising clock edge
   -- ausgang synchron treiben
   q <= std_logic_vector(to_unsigned(zahl4,7)); -- 7 Bits bei 99
   -- zählen   
   if zahl1 = 999 then -- diesen Wert anpassen für beliebige andere "Division"
       zahl1 <= 0;
       if zahl4 = 99 then -- dieser Wert legt das gesamtmaximum fest
           zahl4 <= 0;
       else
           zahl4 <= zahl4 + 1;
       end if;
   else 
       else zahl1 <= zahl1 + 1;
  end if;      
end if;

end process;

end architecture Behavioral;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fellap schrieb:
> Counter zaehlt bis 130000, moechte aber nur die 130 davon verwenden...
> die restlichen drei 0er sollen abgeschnitten werden...
Was ist denn das eigentliche Problem, die eigentliche Aufgabenstellung 
hier? Wofür braucht man sowas?

Ich würde wie Jonas den Counter einfach um den Faktor 100 langsamer 
zählen lassen. In einem uC macht man das mit einem Vorteiler. Nur sähe 
mein Code ein klein wenig anders aus...   ;-)

Jonas K. schrieb:
> signal zahl1: integer := 0;
Ich würde hier z.B. immer eingeschränkte Integer nehmen.

Ingo schrieb:
> Was is denn so schlimm an einer Division?
Sie ist entweder unglaublich langsam oder unglaublich aufwendig. Oder 
beides...
Nur vorzeichenlose Divisionen durch Zweierpotenzen sind trivial.

[PittyJ (Gast)]

Ich verstehe den Sinn nicht so ganz.
Falls der Computer rechnet, ist es doch wesentlich einfacher hinten 
binär etwas abzuschneiden.
Dezimalsystem ist doch nur für Ausgabe an Menschen. Denn nur die Rechnen 
im 10er System. Und für Menchen kann man doch mal 1000 Takte für eine 
Division bereitstellen. Bei 50 MHz wäre das eine Update-Rate von 50 KHz. 
Immer noch zu schnell für einen Menschen.
Und bei einem FPGA kann ja die Rechnung parallel laufen, stört also die 
anderen Algorithmen gar nicht.

Ich habe das Gefühl, dass dir eine Division zu kompliziert ist, und du 
sie deshalb umgehen möchtest. Dabei gibt schon bei Lothar eine fertige 
Lösung:

http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html

[Fellap (Gast)]

Lothar Miller schrieb:
> Ich würde wie Jonas den Counter einfach um den Faktor 100 langsamer
> zählen lassen. In einem uC macht man das mit einem Vorteiler. Nur sähe
> mein Code ein klein wenig anders aus...   ;-)

Ich moechte die Periode von einem Takt bestimmen... damit die Bestimmung 
genauer wird, wollte ich anstatt einer Periode, 100 Perioden zaehlen...
Deswegen moechte ich durch 100 teilen... bzw. die nullen abschneiden...

[Gustl B. (-gb-)]

Und warum durch 100 und nicht durch 64 oder 128?

[Michael (Gast)]

Fellap schrieb:
> Deswegen moechte ich durch 100 teilen... bzw. die nullen abschneiden...

Auch in VHDL muss es doch eine Möglichkeit geben, einen Zähler zu 
implementieren, der als Vorteiler arbeitet.

[Gustl B. (-gb-)]

Na klar gibt es die. Aber warum noch einen Zähler wenn man auch im 
Binärsystem zählen und teilen kann?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fellap schrieb:
> Ich moechte die Periode von einem Takt bestimmen... damit die Bestimmung
> genauer wird, wollte ich anstatt einer Periode, 100 Perioden zaehlen...
Du hast damit immer noch nicht meine Fragen beantwortet. Du siehst das 
Problem zu fokussiert und nimmst das Drumrum nicht wahr...

WARUM machst du das Ganze? WAS für ein Gerät soll das geben? Einen 
Frequenzmesser, der die Frequenz dann anzeigt? ODer wird dieser Wert 
nicht für irgendeine Anzeige verwendet? Falls das so ist: WER braucht 
diesen Wert und wie kommt er dort hin?

[Schlumpf (Gast)]

Fellap schrieb:
> 100 Perioden zaehlen...
> Deswegen moechte ich durch 100 teilen... bzw. die nullen abschneiden...

Du bist gut beraten, wenn du in einem digitalen System bei sowas deine 
Grenzen auf 2er Potenzen legst.
Ob du nun 100 oder 128 Perioden zählst, sollte vom Prinzip ja egal sein.
Mit dem kleinen Unterschied, dass eine Division mit 128 viel einfacher 
ist.

Du willst also messen, wie lange 100 Taktperioden dauern. Sprich, du 
zählst lässt einen schnellen Zähler x laufen und mit einem anderen 
Zähler zählst du 100 Perioden von deinem zu messenden Signal. Nach 100 
Perioden dividierst du dann den Zählerstand von x mit 100 und hast deine 
gemittelte Periodendauer der letzten 100 Takte. Richtig?

Wenn das so ist, dann zähle doch einfach nicht 100 sondern 128 Perioden 
lang.
Dann musst x nicht durch 100, sondern durch 128 teilen und das ist 
trivial

[Achim S. (Gast)]

Fellap schrieb:
> Ich moechte die Periode von einem Takt bestimmen... damit die Bestimmung
> genauer wird, wollte ich anstatt einer Periode, 100 Perioden zaehlen...
> Deswegen moechte ich durch 100 teilen... bzw. die nullen abschneiden...

Wieso erwartest du, dass beim Auszählen der Dauer von 100 Perioden das 
Zählergebnis hinten lauter Nullen hat? Gerade die Information in diesen 
hinteren Stellen erhöht deine Genauigkeit. Wenn du diese Stellen 
abschneidest (Integer-Division durch 100), kannst du auch gleich nur 
eine einzelne Periode zählen.

[Gustl B. (-gb-)]

Wenn 100 Perioden lang gezählt wird und die (eine) Periodendauer in 
Zählerschritten gesucht ist, dann kann man doch die Gesamtzahl durch die 
Zahl der Perioden teilen und erhält wie viele Zählerschritte eine 
Periode im durchschnitt dauert. Oder verstehe ich da was nicht?! Der 
Zähler sollte natürlich deutlich schneller wie die zu bestimmende 
Frequenz sein.

[Achim S. (Gast)]

Gustl Buheitel schrieb:
> Wenn 100 Perioden lang gezählt wird und die (eine) Periodendauer in
> Zählerschritten gesucht ist, dann kann man doch die Gesamtzahl durch die
> Zahl der Perioden teilen und erhält wie viele Zählerschritte eine
> Periode im durchschnitt dauert.

Stimmt schon: wenn man die Dauer einer Periode in Zählerschritten wissen 
will, dann kann man hundert Perioden ausmessen und dann den Zählerstand 
durch 100 dividieren. Aber das wird nur dann genauer als die Messung 
einer einzelnen Periode, wenn man nach der Division auch die 
Nachkommastellen betrachtet. Wenn man die ignoriert ("die restlichen 
Stellen abschneidet") dann wird die Messgenauigkeit nicht höher als bei 
der Messung einer einzelnen Periode.

Einen Vorteil hätte dieser Ansatz nur dann, wenn die einzelnen 
Periodendauern variieren und er den Mittelwert der Periodendauer 
bestimmen will. Das ist aber etwas anderes als "die Genauigkeit der 
Periodenmessung erhöhen".

[Gustl B. (-gb-)]

Und genau das nehme ich an, dass die Perioden leicht in ihrer Länge 
variieren und er eben einen Durchschnitt bilden will.

Für etwas anderes macht was tatsächlich keinen Sinn.

[Fellap (Gast)]

Lothar Miller schrieb:
> Fellap schrieb:
>> Ich moechte die Periode von einem Takt bestimmen... damit die Bestimmung
>> genauer wird, wollte ich anstatt einer Periode, 100 Perioden zaehlen...
> Du hast damit immer noch nicht meine Fragen beantwortet. Du siehst das
> Problem zu fokussiert und nimmst das Drumrum nicht wahr...
>
> WARUM machst du das Ganze? WAS für ein Gerät soll das geben? Einen
> Frequenzmesser, der die Frequenz dann anzeigt? ODer wird dieser Wert
> nicht für irgendeine Anzeige verwendet? Falls das so ist: WER braucht
> diesen Wert und wie kommt er dort hin?


Genau so ist es.. Ich habe Eingangssignal, das anfangs paar Sekunden 
eine konstante Frequenz hat. Und von diesem Eingangssignal moechte ich 
gerne die Periodendauer bestimmen. Und wenn man anstatt eine Periode, 
mehrere Perioden misst, dann wird es ja genauer.. - klar. Und dann würde 
ich gerne die Periodendauer in us auf 4x 7Segmentanzeigen anzeigen 
lassen... Dazu verwende, ich das von Dir bereitgestellten Bitvektor -> 
BCD Wandler...
Aber dein BCD Wandler gibt "nur" die Moeglichkeit 16 Bit einzulesen und 
diese als BCD auszugeben.. und mir fehlen die Skills um zu erweitern... 
Drum moechte ich gerne die Vektor kuerzen.

Schlumpf schrieb:
> Fellap schrieb:
>> 100 Perioden zaehlen...
>> Deswegen moechte ich durch 100 teilen... bzw. die nullen abschneiden...
>
> Du bist gut beraten, wenn du in einem digitalen System bei sowas deine
> Grenzen auf 2er Potenzen legst.
> Ob du nun 100 oder 128 Perioden zählst, sollte vom Prinzip ja egal sein.
> Mit dem kleinen Unterschied, dass eine Division mit 128 viel einfacher
> ist.
>
> Du willst also messen, wie lange 100 Taktperioden dauern. Sprich, du
> zählst lässt einen schnellen Zähler x laufen und mit einem anderen
> Zähler zählst du 100 Perioden von deinem zu messenden Signal. Nach 100
> Perioden dividierst du dann den Zählerstand von x mit 100 und hast deine
> gemittelte Periodendauer der letzten 100 Takte. Richtig?
>
> Wenn das so ist, dann zähle doch einfach nicht 100 sondern 128 Perioden
> lang.
> Dann musst x nicht durch 100, sondern durch 128 teilen und das ist
> trivial

Ganz genau so ist es.
Ja klar, wenn das so einfach ist kann ich den Zaehler 128 Perioden 
zaehlen lassen.. Aber wie funktioniert dann ein solcher trivialer 128er 
Teiler?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fellap schrieb:
> Aber wie funktioniert dann ein solcher trivialer 128er Teiler?
So: ergebnis <= wert/128;
Und was passiert da in der Hardware?
Es werden nur die untersten 7 Bit des Zählers nicht verwendet. Fertig.

[Fellap (Gast)]

Lothar Miller schrieb:
> Fellap schrieb:
>> Aber wie funktioniert dann ein solcher trivialer 128er Teiler?
> So: ergebnis <= wert/128;
> Und was passiert da in der Hardware?
> Es werden nur die untersten 7 Bit des Zählers nicht verwendet. Fertig.

Das ist tatsaechlich trivial. Super - vielen Dank!

[Fellap (Gast)]

Lothar Miller schrieb:
> Fellap schrieb:
>> Aber wie funktioniert dann ein solcher trivialer 128er Teiler?
> So: ergebnis <= wert/128;
> Und was passiert da in der Hardware?
> Es werden nur die untersten 7 Bit des Zählers nicht verwendet. Fertig.

Aber eine doofe Frage habe ich noch:
Muss ich dann den Zaehler bis 128 oder bis 127 zaehlen lassen?

[Achim S. (Gast)]

Fellap schrieb:
> Ich habe Eingangssignal, das anfangs paar Sekunden
> eine konstante Frequenz hat. Und von diesem Eingangssignal moechte ich
> gerne die Periodendauer bestimmen. Und wenn man anstatt eine Periode,
> mehrere Perioden misst, dann wird es ja genauer.. - klar.

Machen wir mal ein einfaches Zahlenbeispiel: dein Referenztakt hat 10ns 
Periode, das Eingangssignal hat genau 1300ns Periode. Wenn du nur eine 
Periode ausmisst ist dein Zählerstand danach 130 +1/-1 (also entweder 
131 oder 130 oder 129). Dein Fehlerbereich wird +1/-1 betragen.

Wenn du 100 Perioden des Eingangssignals misst, dann ist dein 
Zählerstand danach 13000 +1/-1. (13001, 13000 oder 12999). Wenn du davon 
die letzten beiden Stellen abschneidest bleibt als Ergebnis 130 oder 
129. Der Fehlerbereich beträgt +0/-1. Ist das die Genauigkeitserhöhung, 
die erwartest?

Betrachten wir jetzt mal ein Eingangssignal von 1305ns Periode. Misst du 
eine Periode aus, dann ist der Zahlerstand danach 131 oder 130. Misst du 
stattdessen 100 Perioden aus, dann ist der Zählerstand danach 13051, 
13050 oder 13049. Schneide die letzten beiden Stellen ab und das 
Ergebnis ist immer 130. Da war die Messung einer einzelnen Periode mit 
ihrem zufälligen Springen zwischen 130 und 131 näher am richtigen Wert 
dran.

Wenn du nur x Stellen zur Anzeige nutzen kannst, dann bringt es dir 
keine höhere Genauigkeit, x+2 Stellen auszuzählen und danach die letzten 
beiden Stellen zu ignorieren.

[Fellap (Gast)]

Lothar Miller schrieb:
> Fellap schrieb:
>> Aber wie funktioniert dann ein solcher trivialer 128er Teiler?
> So: ergebnis <= wert/128;
> Und was passiert da in der Hardware?
> Es werden nur die untersten 7 Bit des Zählers nicht verwendet. Fertig.

Aber eine doofe Frage habe ich noch:
Muss ich dann den Zaehler bis 128 oder bis 127 zaehlen lassen?

Achim S. schrieb:
> Fellap schrieb:
>> Ich habe Eingangssignal, das anfangs paar Sekunden
>> eine konstante Frequenz hat. Und von diesem Eingangssignal moechte ich
>> gerne die Periodendauer bestimmen. Und wenn man anstatt eine Periode,
>> mehrere Perioden misst, dann wird es ja genauer.. - klar.
>
> Machen wir mal ein einfaches Zahlenbeispiel: dein Referenztakt hat 10ns
> Periode, das Eingangssignal hat genau 1300ns Periode. Wenn du nur eine
> Periode ausmisst ist dein Zählerstand danach 130 +1/-1 (also entweder
> 131 oder 130 oder 129). Dein Fehlerbereich wird +1/-1 betragen.
>
> Wenn du 100 Perioden des Eingangssignals misst, dann ist dein
> Zählerstand danach 13000 +1/-1. (13001, 13000 oder 12999). Wenn du davon
> die letzten beiden Stellen abschneidest bleibt als Ergebnis 130 oder
> 129. Der Fehlerbereich beträgt +0/-1. Ist das die Genauigkeitserhöhung,
> die erwartest?
>
> Betrachten wir jetzt mal ein Eingangssignal von 1305ns Periode. Misst du
> eine Periode aus, dann ist der Zahlerstand danach 131 oder 130. Misst du
> stattdessen 100 Perioden aus, dann ist der Zählerstand danach 13051,
> 13050 oder 13049. Schneide die letzten beiden Stellen ab und das
> Ergebnis ist immer 130. Da war die Messung einer einzelnen Periode mit
> ihrem zufälligen Springen zwischen 130 und 131 näher am richtigen Wert
> dran.
>
> Wenn du nur x Stellen zur Anzeige nutzen kannst, dann bringt es dir
> keine höhere Genauigkeit, x+2 Stellen auszuzählen und danach die letzten
> beiden Stellen zu ignorieren.

Oh.. ja ok.. verstehe... Danke Dir... Dann mache ich das nun doch 
anders..

[Fpgakuechle K. (Gast)]

Gustl Buheitel schrieb:
> Wenn 100 Perioden lang gezählt wird und die (eine) Periodendauer in
> Zählerschritten gesucht ist, dann kann man doch die Gesamtzahl durch die
> Zahl der Perioden teilen und erhält wie viele Zählerschritte eine
> Periode im durchschnitt dauert. Oder verstehe ich da was nicht?! Der
> Zähler sollte natürlich deutlich schneller wie die zu bestimmende
> Frequenz sein.

Ich bezweifle, das das genauer wird als eine Periode des Referenztaktes, 
da man das zu messende Signal mit dem Referenztakt einsynchronisiert. 
Dadurch entsteht ein Fehler von höchstens einer Referenz-Periode 
(setup/Hold verletzung), sehr unwahrscheinlich zwei Perioden. Dieser 
Fehler ist weniger von der tatsächlichen Frequenz des Messsignlas 
abhängig, als von dem Setup/Hold Fenster und statistischen 
Wahrscheinlichkeiten was bei einer Setup/Holdverletzung eintritt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fellap schrieb:
> Muss ich dann den Zaehler bis 128 oder bis 127 zaehlen lassen?
Du musst 128 Zyklen zählen. Im Normalfall wird das erreicht, indem ein 
Zähler von 0..127 zählt.
Nimm mal zum Nachdenken einfach eine kleinere Zahl: Wenn ein Zähler 
von 0 bis 3 zählt (also 0, 1, 2, 3) wieviele Schritte sind das dann?

[Fellap (Gast)]

Lothar Miller schrieb:
> Fellap schrieb:
>> Muss ich dann den Zaehler bis 128 oder bis 127 zaehlen lassen?
> Du musst 128 Zyklen zählen. Im Normalfall wird das erreicht, indem ein
> Zähler von 0..127 zählt.
> Nimm mal zum Nachdenken einfach eine kleinere Zahl: Wenn ein Zähler
> von 0 bis 3 zählt (also 0, 1, 2, 3) wieviele Schritte sind das dann?

4.. Haha... verstehe.. :) danke!

[Gustl Buheitel (Gast)]

@ Fpga Kuechle:
Ja, klar stimmt das es wird nicht genauer, aber ich vermute er will die 
Periode von irgendeinem Signal bestimmen das von aussen reinkommt und 
nicht immer die gleiche Periodendauer hat. Also so wie wenn ich da Audio 
habe das ich ueber das Micro aufnehme, auch wenn der Lautsprecher vorher 
einen schoenen 1kHz Sinus bekommen hat, ist das hinter dem Micro eben 
ziemlich unsauber. Ich vermute daher, dass es um eine Mittelwertbildung 
geht, etwas anderes hat wirklich keinen Sinn, da soll er lieber 
schneller zaehlen.