Integerzahl stellen abschneiden

als BCD zählen?

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

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 :)

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.

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...

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

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

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?

Was is denn so schlimm an einer Division?

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?

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?

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.STD_LOGIC_ARITH.ALL;

4

use IEEE.STD_LOGIC_UNSIGNED.ALL;

5

6

7

8

9

entity counter is

10

    Port ( clk :  in  STD_LOGIC

11

     );

12

end counter;

13

14

15

architecture Behavioral of counter is

16

17

  signal zahl1: integer := 0;

18

  signal zahl2: integer := 0; 

19

  signal zahl3: integer := 0;

20

  signal zahl4: integer := 0;

21

  signal zahl5: integer := 0;

22

  signal zahl6: integer := 0;

23

24

begin

25

26

process(clk)

27

begin

28

29

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

30

31

32

   if zahl1 = 9 then zahl1 <= 0;

33

    if zahl2 = 9 then zahl2 <= 0;

34

      if zahl3 = 9 then zahl3 <= 0;

35

        if zahl4 = 9 then zahl4 <= 0;

36

          if zahl5 = 9 then zahl5 <= 0;

37

            if zahl6 = 9 then zahl6 <= 0; else zahl6 <= zahl6 + 1;

38

            end if;

39

          else zahl5 <= zahl5 + 1;

40

          end if;

41

        else zahl4 <= zahl4 + 1;

42

        end if;

43

      else zahl3 <= zahl3 + 1;

44

      end if;

45

    else zahl2 <= zahl2 + 1;

46

    end if;      

47

  else zahl1 <= zahl1 + 1;

48

  end if;      

49

end if;

50

51

end process;

52

53

end architecture Behavioral;

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

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...

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.

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

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 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".

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 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!

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?

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.

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..

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 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!

@ 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.