Forum: Mikrocontroller und Digitale Elektronik Wie 8-Bit Zähler sicher auslesen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

möchte einen mit ca. 10 kHz getakteten 74HC393 per Controller auslesen 
und dann unmittelbar nach dem Auslesen rücksetzen. M.W. erscheinen bei 
dem Baustein beim Umschalten ganz kurzzeitig ungültige Schaltzustände an 
den Ausgängen. Wie kann man den Baustein nun zuverlässig auslesen?

Man könnte die 8 Bit 256 mal lesen und in ein 16 Bit Register 
aufaddieren und dann das obere Byte verwenden. Damit würde sich ein 
Fehler auf das LSB beschränken. Die Zeit habe ich aber eher nicht. Die 
Zeit zwischen Auslesen und Rücksetzen sollte zudem immer gleich lang 
sein.

Wer hat eine Lösung?

Gustav

: Bearbeitet durch User
von Ingo L. (corrtexx)


Bewertung
3 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Wie kann man den Baustein zuverlässig auslesen?
Synchronisiere dich auf den Clock des Timers und lese ihn nach einem 
Clock aus, z.B. 50us danach

Alternativ unterbrichst du den Takt zur Sicherheit, dass während des 
Auslesens kein Takt kommt.

: Bearbeitet durch User
von B. Pastewka (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da du mit einem Controller ausliest, kannst du nach dem Auslesen zwei 
konstante Minipausen hintereinander einbauen (programmieren) und die 
zweite Minipause zum Rücksetzen verwenden.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Ingo L. schrieb:
> Synchronisiere dich auf den Clock des Timers ...

Muss mich bereits auf einen anderen Takt synchronisieren, der das
Auslesen und Rücksetzen des externen Zählers erzwingt.

: Bearbeitet durch User
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Ingo L. schrieb:
> Alternativ unterbrichst du den Takt zur Sicherheit, dass während des
> Auslesens kein Takt kommt.

Das wäre eine Idee ...

Wie hoch ist eigentlich das Risiko, solch einen ungültigen Schaltzustand 
zu erwischen, bzw. wie lange sind die Ausgänge ungültig?

von Cyblord -. (cyblord)


Bewertung
-2 lesenswert
nicht lesenswert
Gustav K. schrieb:
> M.W. erscheinen bei
> dem Baustein beim Umschalten ganz kurzzeitig ungültige Schaltzustände an
> den Ausgängen.

Ich würde erstmal hinterfragen ob das überhaupt so ist bzw. sein muss.
Hast du das mal mit einem LA verifiziert?

: Bearbeitet durch User
von m.n. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Gustav K. schrieb:
> möchte einen mit ca. 10 kHz getakteten 74HC393

Das ist ein 2 x 4 Bit Zähler.
Nimm einen 74HC590, welcher schon ein Ausgangsregister hat.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt Mikrocontroller, die haben integrierte Zähler, die kann man 
glitch-frei über den internen Prozessorbus auslesen, und über externe 
Trigger-Signale weiter zählen lassen. So braucht man keine 8 
Zählerleitungen+Resetleitung am Controller, sondern nur 1 für den 
Trigger. Ziemlich viele Controller sogar. Eigentlich können das fast 
alle. Sogar mit 16 oder 32 bit.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Beim STM32F103 hat man genau dieses Problem beim Auslesen der Uhr. 
Pragmatische Lösung: Wiederholt auslesen, bis man 2x den selben Wert 
erhält.

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Mit dem Controller innerhalb von ca. 50 us (ca. < T/2) mehrfach (z.B. 
5x) den Zählerwert einlesen. Dann die Ergebnisse anschauen und Ausreiser 
ignorieren.

von Ingo L. (corrtexx)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Ich würde erstmal hinterfragen ob das überhaupt so ist bzw. sein muss.
> Hast du das mal mit einem LA verifiziert?
Datenblatt:
The outputs of the ripple counter do not change
synchronously and should not be used for high-speed
address decoding.

Also Takt unterbrechen oder einen internen Zähler vom Clock triggern 
lassen oder Plausibilitätsprüfungen => such dir was davon aus

von Cyblord -. (cyblord)


Bewertung
-2 lesenswert
nicht lesenswert
Ingo L. schrieb:
> Cyblord -. schrieb:
>> Ich würde erstmal hinterfragen ob das überhaupt so ist bzw. sein muss.
>> Hast du das mal mit einem LA verifiziert?
> Datenblatt:
> The outputs of the ripple counter do not change
> synchronously and should not be used for high-speed
> address decoding.
>
> Also Takt unterbrechen oder einen internen Zähler vom Clock triggern
> lassen oder Plausibilitätsprüfungen => such dir was davon aus

Oder halt ordentlichen Baustein nehmen.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Das ist ein 2 x 4 Bit Zähler.
> Nimm einen 74HC590, welcher schon ein Ausgangsregister hat.

Noch ein guter Tipp !

Stefanus F. schrieb:
> Wiederholt auslesen, bis man 2x den selben Wert erhält.

Die Zeit für das Lesen und anschließende Rücksetzen des Zählers muss 
immer gleich lang sein. Evtl. Wiederholungen fallen deshalb aus.

Ingo L. schrieb:
> Also Takt unterbrechen oder einen internen Zähler vom Clock triggern
> lassen oder Plausibilitätsprüfungen => such dir was davon aus

Oder einen anderen Zähler verwenden, ich suche mir was aus.
Problem gelöst, vielen Dank an alle für die Tipps !

: Bearbeitet durch User
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Nimm einen 74HC590, welcher schon ein Ausgangsregister hat.

Nachtrag: Habe ich hier nicht das gleiche Problem, wenn ich genau 
während einer Taktflanke den internen Zählerstand in das 
Ausgangsregister übernehme?

von Johnny B. (johnnyb)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Beim STM32F103 hat man genau dieses Problem beim Auslesen der Uhr.
> Pragmatische Lösung: Wiederholt auslesen, bis man 2x den selben Wert
> erhält.

Genau dasselbe Verhalten gabs (zumindest früher) auch bei der RTC vom 
MSP430.
Es wurde sogar von TI selbst empfohlen, solange die Register auszulesen, 
bis man zweimal hintereinander denselben Wert hatte.

Ich denke das Problem wird sein, dass die RTC halt asynchron und viel 
langsamer zum Takt der CPU läuft und es auch keinen grossen Sinn macht, 
das Ausleseproblem kompliziert in der Hardware zu lösen, wenn auch der 
pragmatische Weg in Software zufriedenstellend und zuverlässig 
funktioniert.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> Nachtrag: Habe ich hier nicht das gleiche Problem, wenn ich genau
> während einer Taktflanke den internen Zählerstand in das
> Ausgangsregister übernehme?


Ja. Du musst das Auslesen mit dem Takt synchronisieren. Zum Beispiel bei 
der steigenden Flanke takten und bei der fallenden Flanke auslesen.

Beitrag #5481153 wurde vom Autor gelöscht.
von Elias K. (elik)


Bewertung
2 lesenswert
nicht lesenswert
Das ist ein prinzipielles Problem: Entweder du kannst syncron auslesen. 
Oder du musst anderweitig synchronisieren. Zum Beispiel per Software, 
oder mit zusätzlicher Hardware.

Gustav K. schrieb:
> Nachtrag: Habe ich hier nicht das gleiche Problem, wenn ich genau
> während einer Taktflanke den internen Zählerstand in das
> Ausgangsregister übernehme?
Wenn ich mir das Blockschaltbild vom 74HC590 anschaue, dürftest du Recht 
haben: Der Zählerwert wird auf die CPR-Flanke übernommen. Es gibt hier 
auch keinen Schutz, dass das nicht in einem Zählvorgang stattfindet.

Kommst du an den zu zählenden Takt? Wenn ja, baue eine Flankenerkennung 
auf fallende Flanke (wenn du die steigende mit dem Zähler zählst) und 
verundest das Signal mit deinem "read-Now"-Signal. (Oder halt in 
Software.)

Gustav K. schrieb:
> Die Zeit für das Lesen und anschließende Rücksetzen des Zählers muss
> immer gleich lang sein. Evtl. Wiederholungen fallen deshalb aus.
Wie viel Fehler ist denn zulässig? Wenn du Frequenz messen willst: 
Welche Auflösung willst du in welcher Messzeit erreichen?

Es gibt da ein gutes Paper von Cummings zum Thema: "World Class Verilog 
& SystemVerilog Training Clock Domain Crossing (CDC) Design & 
Verification Techniques Using SystemVerilog"
http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf

Andere Variante: Graycode-Counter nehmen. Da ändert sich pro Zählschritt 
nur ein Bit. Im Zweifelsfall hast du einen Fehler von +-1 Bit.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Die Zeit für das Lesen und anschließende Rücksetzen des Zählers muss
> immer gleich lang sein. Evtl. Wiederholungen fallen deshalb aus.

Ach komm, 10kHz sind für einen AVR @16MHz 1600 CPU-Zyklen. Da kannst Du 
ne Menge Code ausführen, ohne einen Signaltakt zu verlieren.

Das Rücksetzen kann aber in der Tat zu Zählfehlern führen, wenn es zum 
unpassenden Zeitpunkt kommt. Die Lösung ist aber einfach. Man setzt den 
Zähler nicht zurück, sondern merkt sich den vorherigen Zählerwert und 
bildet die Differenz.

Ein AVR @16MHZ kann auch ganz ohne zusätzliche Hardware mit seinen 
Timern bis 8MHz zählen.

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Elias K. schrieb:
> Kommst du an den zu zählenden Takt? Wenn ja, baue eine Flankenerkennung
> auf fallende Flanke (wenn du die steigende mit dem Zähler zählst) und
> verundest das Signal mit deinem "read-Now"-Signal. (Oder halt in
> Software.)
Bzw. nutzt du gleich den invertierten 10-KHz-Clock für CPR. Damit ist 
das Problem zwar nicht ganz gebannt, aber um Größenordnungen kleiner. 
(Das Propagation Delay im Zähler entfällt.) Um absolute Sicherheit zu 
bekommen, kannst du im Controller den Clk beobachten. Wenn er sich in 
der Auslesezeit ändert, nochmal auslesen oder anderweitig reagieren. Das 
ist bei einem 10 MHz Controller in 2 us zu schaffen. Das sollte bei 100 
us Periodendauer zu verkraften sein.

von Christoph db1uq K. (christoph_kessler)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch einen synchronen 8-bit-Zähler, 74HC40103. Der HC393 ist ein 
ripple-counter, da ändern sich die Ausgänge nacheinander, aber laut 
Datenblatt soll der 40103 synchron sein. Natürlich gibt es da immer noch 
kleine Laufzeitunterschiede.

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Was auch gut gehen dürfte: Ein Clock-Gate für die 10 kHz verwenden. Dann 
kannst du mit dem Controller sehr genau steuern, wann der Zähler 
arbeitet, und wann du ihn sicher auslesen/zurücksetzen kannst.

Bedingung: Das Clock-Gating muss frei von Glitches sein. Zum Beispiel 
mit so einer Schaltung: 
https://electronics.stackexchange.com/questions/95270/circuit-to-enable-inverted-clock-glitch-free
Das verlinkte Paper gibt es gerade nur über die Wayback-Machine.

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Es gibt auch einen synchronen 8-bit-Zähler, 74HC40103. [...]
Das ist ein 8-Bit Abwärtszähler mit Ladeeingang. Ein Ausgang zeigt an, 
wenn der Zähler null erreicht hat. Ich vermute, dass er TO aber ein 
festes Zeitfenster hat und den Zählerstand wissen möchte. Und nicht, 
dass er einen festen Zählerstand hat, bis zu dem gezählt werden soll? 
Wenn dem so ist, nützt dieser IC zunächst nichts.

Synchron wird der 74HC590 mit invertiertem Clock am Ausgangsregister 
auch. Das winzige Problem mit den gleichzeitigen Taktflanken bleibt aber 
immer bestehen, wenn er nicht zusätzlichen Aufwand zur Synchronisation 
treibt.

von Roland L. (roland2)


Bewertung
0 lesenswert
nicht lesenswert
Elias K. schrieb:
> Andere Variante: Graycode-Counter nehmen. Da ändert sich pro Zählschritt
> nur ein Bit. Im Zweifelsfall hast du einen Fehler von +-1 Bit.

gibt es sowas als fertiges IC?

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Roland L. schrieb:
> Elias K. schrieb:
>> Andere Variante: Graycode-Counter nehmen.
> gibt es sowas als fertiges IC?
Ich kenne leider keinen und finde auf die schnelle auch nix. Ich komme 
halt aus der FPGA/Digital-ASIC Ecke. Das gibt es ein paar andere 
Herangehensweisen.

Zur Not selbst einen Chip "machen". ICE40-FPGA im 36-Pin BGA mit 2,5 x 
2,5 mm2. Dann ist das auf jeden Fall kein Problem mehr. :-) Ich fürchte 
nur, das geht etwas am Ziel vorbei...

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Wie kann man den Baustein nun zuverlässig auslesen?

Ich schätze, du hast dein eigentliches Problem schlichtweg falsch 
angefangen. Mir kommt das so vor, as wenn jemand sagt "ich muß aus dem 
Fenster im 10. Stock springen und bin grad am 2. Stock vorbei, jetzt 
suche ich nach einer zuverlässigen Methode, um noch vor dem Pflaster 
auf Tempo null zu kommen".

Überdenke dein Projekt, dann wirst du sehen, daß es auch anders geht.

W.S.

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Wer hat eine Lösung?

Externen Zähler rausschmeißen, Reset weg lassen und internen 
Timer/Counter vom µC zählen lassen, flankengesteuertes Ablesen des 
Zählerstandes per Capture.

von U. M. (oeletronika)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
> Gustav K. schrieb:
> möchte einen mit ca. 10 kHz getakteten 74HC393 per Controller auslesen
> und dann unmittelbar nach dem Auslesen rücksetzen.
evtl. ist das Rücksetzen gar nicht nötig.

> Wer hat eine Lösung?
Was ist denn, wenn du den Zähler nur ausließt und dann einfach weiter 
laufen läßt. Wenn du den Zählerstand speicherst, kannst du beim nächsten 
mal einfach die Differenz bilden und muß den Zähler nicht zurück setzen.
Gruß Öletronika

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Die perfekte und Performance Lösung würde hier ja schon in 2 Teilen 
gepostet:

Stefanus F. schrieb:
> Wiederholt auslesen, bis man 2x den selben Wert erhält.

Ja, aber in höchster Priorität genau 3 Mal naxheinander lesen und wenn 
erster und zweiter wert ungleich sind, dann den dritten nehmen. (Falls 
auslesen länger als das Update dauert und der Takt langsamer ist als 3 
Mal auslesen)

Peter D. schrieb:
> Die Lösung ist aber einfach. Man setzt den Zähler nicht zurück, sondern
> merkt sich den vorherigen Zählerwert und bildet die Differenz.

Und soi gibt's dann auch kein reset-Problem. Solange man nicht anfängt, 
den Überlauf gesondert zu behandeln (das geht regelmäßig in die Hose)

von Mic R. (microller)


Bewertung
0 lesenswert
nicht lesenswert
Alternative zum externen Counter:
Schau dir mal bei www.Cypress.com die PSoC4 bzw PSoC5 an, die haben 
teilweise programmierbare Logic mit drinnen, u.a. counter, die parallel 
nebenher zur MCU laufen. Nennt sich dort UDB (universal digital block). 
Denke damit könntets Du was realsisieren.

Mic Roller

: Bearbeitet durch User
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Elias K. schrieb:
> Was auch gut gehen dürfte: Ein Clock-Gate für die 10 kHz verwenden.

Wie sähe denn so ein Clock-Gate aus?

Habe sowas eben mal mit einem ODER durchgespielt: Das funktioniert nur, 
wenn der Takt gerade auf H-Potenzial liegt. Liegt der Takt auf 
L-Potenzial, so kann ich eine fallende Flanke zwar verhindern, ich 
erzeuge aber eine fallende Flanke (einen zusätzlichen Taktimpuls), wenn 
ich das "Gate" wieder weg nehme.

Peter D. schrieb:
> Die Lösung ist aber einfach. Man setzt den Zähler nicht zurück, sondern
> merkt sich den vorherigen Zählerwert und bildet die Differenz.

Problem ist, dass der 8-Bit Zähler auch (dauernd) überlaufen kann, denn 
die Anweisung, dass der Zähler auszulesen und rückzusetzen ist, kommt 
von außen. Bei meinen Schaltungsentwurf setzt die fallende Flanke des 
MSB ein D-FlipFlop, welches ich lesen kann. Ist dieses Flag gesetzt, 
wird der eingelesene Zählerstand verworfen und durch FFh ersetzt. Das 
D-FlipFlop wird zusammen mit dem Zähler rückgesetzt.

Achim S. schrieb:
> Ja, aber in höchster Priorität genau 3 Mal naxheinander lesen und wenn
> erster und zweiter wert ungleich sind, dann den dritten nehmen.

Ich denke, dies ist die Beste und auch einfachste Lösung.

von Jacko (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bei unbekanntem Taktablauf kannst du selbst bei einem synchronen
Zähler zufällig den Umschaltmoment erwischen - und liest auch
"Hausnummern" ein.

Der synchrone Zähler bringt also nicht viel.

Man könnte den Zähltakt auswerten: Auslesung bei der Flanke, die
der Zähler nicht nutzt. Klappt aber nur bei halbwegs symmetrischem
Zähltakt. Sind es "Nadelpulse", fällt das auch flach.

Also die SW-Variante: 3 mal kurz hintereinander auslesen, wobei
das innerhalb von weniger, als dem min-Zählerpulsabstand geschehen
muss. Allerdings auch nicht mit kleinerem Zeitabstand, als der
propagation-delay des Zählers.

3 von 3 Werten gleich: OK
2 von 3 Werten gleich: den Ausreißer ignorieren
Alle Werte ungleich:   Letzten Wert nehmen! - Wenn der
falsch sein sollte, hast du ein Problem mit dem Zähler, oder
dem Zähltakt und brauchst eine GANZ andere Schaltung...

von m.n. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Achim S. schrieb:
> Ja, aber in höchster Priorität genau 3 Mal naxheinander lesen und wenn
> erster und zweiter wert ungleich sind, dann den dritten nehmen.

Einfach völlig ungeprüft den 3. Wert nehmen? Niemals!

Bislang ist mir nicht klar, welches Problem gelöst werden soll und 
welche Funktionen Hardware und Software haben. Warum ein Hardware-Zähler 
verwendet werden soll ebensowenig.
Solange das nicht klar ist (Funktionsbeschreibung, ggf. Schaltplan), 
kann man nur spekulieren.
Eine konkrete Lösung für ein virtuelles Problem gibt es nicht.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Das frage ich mich auch, warum Du die internen Timer/Zähler eines MC 
nicht benutzen willst.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
m.n. schrieb:
> Einfach völlig ungeprüft den 3. Wert nehmen? Niemals!

Doch!
WENN ein externer Zähler asynchron geändert wird
UND die Änderungen schneller von statten gehen als ein Lesezyklus (was 
bei Logikgattern anzunehmen ist
UND das 3malige auslesen schneller ist als 2 Zählimpulse (was bei 10kHz 
und höchste Priorität beim Auslesen sichergestellt sein kann)
DANN ist das Verhalten eindeutig und das Auslesen wie beschrieben 
sicher.

Natürlich spricht nichts dagegen, auch direkt einen 4ten Wert zu 
erfassen und ein assert darauf zu setzen, dass 2 Werte nacheinander 
gleich sind. Aber das ist debug und von der reinen Funktion zu 
unterscheiden. Ansonsten liest du auch jedes andere Datum doppelt, weil 
es ja irgendein unbekanntes Problem gegeben haben könnte.

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Achim S. schrieb:
> Doch!
> WENN ...
> UND ...
> UND ...
> DANN ...

Du scheinst ein gläubiger Mensch zu sein ;-) Im Glauben, daß alle 
gedachten Annahmen unter jeder Bedingung zutreffen, schafft man sich 
schnell Programmlösungen, die einmal am Tag hängen bleiben und nicht 
auffindbar sind.

Einfach solange lesen, bis zwei aufeinanderfolgende Werte gleich sind. 
Gleich reicht, gleicher ist nicht notwendig.
Fertig!

von Roland L. (roland2)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Im Glauben, daß alle
> gedachten Annahmen unter jeder Bedingung zutreffen, schafft man sich
> schnell Programmlösungen, die einmal am Tag hängen bleiben und nicht
> auffindbar sind.
>
> Einfach solange lesen, bis zwei aufeinanderfolgende Werte gleich sind.
> Gleich reicht, gleicher ist nicht notwendig.
> Fertig!

dann kommen aus irgendeinem Grund die Impulse mit 10MHz statt 10kHz und 
du bekommst niemals zwei gleiche Werte hintereinander.
auf etwas zu warten, was u.U. nie eintritt, ist ebenfalls eine gute 
Methode, um Programme zu schreiben, die irgendwann hängen bleiben.


Die Annahme, dass an einem externen Eingang immer ein Signal ankommt, 
das den Spezifikationen entspricht, zeugt auch von viel Gottvertrauen.
Die Annahme, dass ein IC sich so verhält, wie es im Datenblatt steht, 
ist realistischer.

: Bearbeitet durch User
von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Roland L. schrieb:
> auf etwas zu warten, was u.U. nie eintritt, ist ebenfalls eine gute
> Methode, um Programme zu schreiben, die irgendwann hängen bleiben.

Bei solchen Abfragen ein Timeout einzubauen, muß nicht explizit erwähnt 
werden. Wie gesagt, sind wir allesamt bei virtuellen Lösungen.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Bei solchen Abfragen ein Timeout einzubauen, muß nicht explizit erwähnt
> werden. Wie gesagt, sind wir allesamt bei virtuellen Lösungen.

Aber man muss es explizit tun, sonst Absturz statt Fehlmessung!

Die straighte Lösung funktioniert hingegen auch so zuverlässig, vor 
allem Kontext des TO (der für Überlauf ein Flag hat). Und Diagnose 
bleibt ja eh jedem unbenommen.

von Jack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> möchte einen mit ca. 10 kHz getakteten 74HC393 per Controller auslesen
> und dann unmittelbar nach dem Auslesen rücksetzen.

Das macht wenig Sinn. Weg mit dem 74HC393. Ein halbwegs normaler 
Mikrocontroller kann wunderbar selber binär zählen.

Daher den jetzigen Takteingang des 74HC393 direkt in den Controller rein 
führen und den Controller zählen lassen. Möglichst mit Hardware zählen 
(async Counter) und z.B. einen internen Interrupt beim Erreichen des 
gewünschten Wertes erzeugen. Wenn man keinen Hardware-Counter im 
Mikrocontroller mehr frei hat, dann gehen 10 kHz auch in Software: Z.B. 
Ein 10μs Timer-Interrupt (10 Samples pro Eingangstakt) und im Interrupt 
pollen.

Wenn an den Ausgängen des 74HC393 momentan irgendwas anderes als 
Eingänge des Mikrocontroller dran hängt, dann die Ausgänge des 74HC393 
durch Ausgänge des Mikrocontroller ersetzen und den Zählerstand des 
Counters im Mikrocontroller kontinuierlich ausgeben.

> Man könnte die 8 Bit 256 mal lesen

Der 74HC393 ist ein dualer 4-Bit Counter, kein 8-Bit Counter.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack schrieb:
> Der 74HC393 ist ein dualer 4-Bit Counter, kein 8-Bit Counter.

Auch wenn das dein Vorstellungsvermögen übersteigt: man kann die 2 
4bit-Counter hintereinanderschalten. Ich glaube, das wird sogar im 
Datenblatt beschrieben, aber man sollte auch ohne das mit einigem 
Nachdenken drauf kommen wie.

Georg

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Jacko schrieb:
> Bei unbekanntem Taktablauf kannst du selbst bei einem synchronen
> Zähler zufällig den Umschaltmoment erwischen - und liest auch
> "Hausnummern" ein.

Gut zu wissen, dass hier ein synchroner Zähler nicht die Lösung wäre. 
Wobei die Wahrscheinlichkeit genau den Umschaltmoment zu erwischen viel 
geringer sein wird. Was aber bei ca. 100 Auslesungen pro Sekunde sicher 
irgendwann passieren wird.

m.n. schrieb:
> Einfach völlig ungeprüft den 3. Wert nehmen? Niemals!

Hier würde ich auch lieber den vorigen Wert nehmen.

Jacko schrieb:
> Man könnte den Zähltakt auswerten: Auslesung bei der Flanke, die
> der Zähler nicht nutzt.

Das wäre natürlich optimal, ich habe aber nicht die Zeit, auf die Flanke 
zu warten (max. 50µs bei 10 kHz) und dann nochmals 25µs, um dann sauber 
in der Mitte des Taktimpulses den Zähler auszulesen. Gleiches gilt für 
einen Timeout.

m.n. schrieb:
> Funktionsbeschreibung  ...

Momentaner Entwurf: Eine Flanke von außen setzt ein D-FlipFlop und 
selbiges löst u.a. einen IRQ aus. In der ISR muss nun sofort der 
Zählerstand ausgelesen werden und gleichzeitig der Zähler rückgesetzt 
werden. Denn die Flanke von außen beendet eine Messung und startet 
gleichzeitig eine neue. Wäre eigentlich auch alles kein Problem, wenn 
ich den Zähler mit einem Zugriff zuverlässig auslesen könnte.

Ich würde also 4x lesen (3x den Zähler und 1x das Überlauf-Flag) und 
beschreibe damit 4 Register. Dann wird der Zähler samt Flag gelöscht. 
Die Prüfung auf Überlauf/Gültigkeit des Zählerstandes erfolgt aus 
Zeitgründen später.

georg schrieb:
> man kann die 2 4bit-Counter hintereinanderschalten ...

So isses. Ich nutze den '393 seit Urzeiten als 8 Bit-Zähler.

: Bearbeitet durch User
von vage (Gast)


Bewertung
0 lesenswert
nicht lesenswert
georg schrieb:
> 4bit-Counter hintereinanderschalten. Ich glaube, das wird sogar im
> Datenblatt beschrieben, aber man sollte auch ohne das mit einigem

Kann mich nicht erinnern, das ich jemandem geglaubt hätte der glaubt.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Gustav K. schrieb:
> Eine Flanke von außen setzt ein D-FlipFlop und
> selbiges löst u.a. einen IRQ aus. In der ISR muss nun sofort der
> Zählerstand ausgelesen werden und gleichzeitig der Zähler rückgesetzt
> werden.

Das hoert sich fuer mich nach "broken by design" an.
Wenn die "Flanke von aussen" zeitlich mit deiner Taktflanke, die der 
Zaehler zaehlen soll, zusammenfallen kann, g'hoerst schon der Katz'.
Dann ist auch der naechste Gimmick: Zaehlerstand lesen und 
"gleichzeitig" zuruecksetzen, der nur mit einem synchronen Design von 
Zaehler und Ausgangsregister ginge - erstmal voellig aussen vor.
Aber lass' dich nicht entmutigen, mit n+1 Monoflops und 
Impulsverzoegerungsschaltungen kann man sicher was "ganz tolles" bauen 
<grusel>.

Gruss
WK

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Eine Flanke von außen setzt ein D-FlipFlop und
> selbiges löst u.a. einen IRQ aus.

Das nennt sich bei den AVRs "Input Capture Unit". Der Zählerstand wird 
bei einer Flanke in das Captureregister übernommen, ganz ohne Fehler.
Will man ohne Reset des Zählers einen Überlauf erkennen, geht auch das 
ganz einfach. Man lädt das Captureregister in ein Compareregister.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
"sofort" und/oder "gleichzeitig" kannst du vergessen, das gibt es nicht.

Ist Dir eigentlich bewusst, das die Zeit vom elektrischen INT-Impuls bis 
zur Sprung in die ISR nicht konstant ist (jedenfalls nicht bei AVR und 
ARM)? Ich denke, damit ist dein Konzept tatsächlich broken by Design, in 
doppelter Hinsicht.

Wenn man die Zeit zwischen zwei Ereignissen mit einem µC messen will, 
erfasst man die Zählerstände zu den Ereignissen OHNE ihn zwischendurch 
zurück zu setzen. Eine Integer-Subtraktion mit gleicher Bitbreite 
liefert dann die Differenz, also die Zeit (auch nach einem Überlauf).

Dieses Rad brauchst du nicht neu erfinden.

Ich verstehe ehrlich gesagt auch nicht so recht, warum du alles so super 
schnell und ohne Verzögerungen haben willst. Du willst ihn mit mit 10kHz 
takten, ergo muss das Auslesen lediglich minimal schneller als 0,1ms 
sein, um keinen Messfehler zu produzieren. 0,1ms sind für den µC eine 
Ewigkeit! Aber das hatten wir ja auch schon.

: Bearbeitet durch User
von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ist Dir eigentlich bewusst, das die Zeit vom elektrischen INT-Impuls bis
> zur Sprung in die ISR nicht konstant ist

Das ist mir klar, mit den Zeiten kann ich bei dem Design leben.

Stefanus F. schrieb:
> "sofort" und/oder "gleichzeitig" kannst du vergessen,

Auch klar. Ein Befehl liest den Zähler, der nächste löscht den Zähler. 
Mal eben gemessen: Ein ld x,y benötigt hier genau 1µs. Also 2µs fürs 
Auslesen und Rücksetzen des Zählers lasse ich hier noch als gleichzeitig 
durch gehen.

Was nicht geht, sind 50µs auf eine Taktflanke warten oder einen Timeout 
einbauen. Werde mal paar Routinen schreiben und schauen, wie rund das 
Ganze läuft. Eine gewisse "Luft" ist vorhanden, mal sehen, ob es reicht.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es sind zwei Signale vorhanden. Zu einen ein Taktsignal, was gezählt 
werden soll, und zum anderen ein Signal, welches den Zählerstand 
speichern und rücksetzen soll. Diese beiden Signale können gleichzeitig 
auftreten und müssen daher ohne Verlust zeitlich nacheinander 
abgearbeitet werden.

Pro Kanal: Die aktive Flanke eines Signals wird per D-FF gespeichert. 
Danach folgt ein weiteres D-FF, was synchron zu einem separaten 
Sync-Takt (meinetwegen 1 MHz) den gesetzten Zustand des 1. D-FFs 
übernimmt, es zurücksetzt und eine aktive Flanke an seinem Ausgang 
erzeugt. Das gelöschte 1. D-FF setzt auch das 2. D-FF zurück, sodaß 
durch die Durchlaufzeiten ein hinreichend langer Ausgangsimpuls ansteht.

Diese Synchronisierung wird für beide Eingangssignale gemacht, wobei der 
Sync-Takt an eine Stufe direkt und an die andere Stufe invertiert 
angelegt wird. Damit wird ein gleichzeitiges Auftreten von Zähl- und 
Ausleseimpuls verhindert. Die Zählimpulse werden an den Takteingang des 
HC590 gelegt und gezählt; der Speicherimpuls liefert den Takt für das 
Ausgangsregister und setzt gleichzeitig den Zähler zurück. Der µC 
bekommt seinen IRQ und kann ihn Ruhe das Ausgangsregister des Zählers 
lesen.

An Bauteilen würde benötigt: 2 x 74HC74 zur Synchronisierung der 
Eingänge und 1 x 74HC14 für den Sync-Takt und Invertierung des Taktes 
und ggf. Verlängerung von Durchlaufzeiten.

So sähe eine Schaltung mit Hardware aus, die dann ihren Vorteil 
ausspielen kann, wenn mit schnellen Logikbausteinen 10 - > 100 MHz 
verarbeitet werden sollen, was ein langsamer µC nicht mehr schaffen 
würde.
Ob das für die hier geplante Anwendung sinnvoll ist, kann ich nicht 
entscheiden.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Ob das für die hier geplante Anwendung sinnvoll ist, kann ich nicht
> entscheiden.

Das kann bisher keiner.
Ein ATtiny24 könnte reichen, der hat die benötigten 2 Eingänge:
T1 = Takt
ICP1 = Capture

: Bearbeitet durch User
von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ein ATtiny24 könnte reichen, der hat die benötigten 2 Eingänge:
> T1 = Takt
> ICP1 = Capture

Die 'speziellen' Eingänge braucht man bei DC-nahen Anwendungen garnicht. 
Einfach PA0 - PA7 als gespeicherte Zählerausgänge nehmen und PB0 - PB3 
für 2 x Signaleingänge und für die Ausleseanforderung.
Im DIL14 ist der tiny24 nicht größer als ein xx393.

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Liegt der Takt auf
> L-Potenzial, so kann ich eine fallende Flanke zwar verhindern, ich
> erzeuge aber eine fallende Flanke (einen zusätzlichen Taktimpuls), wenn
> ich das "Gate" wieder weg nehme.

Na und - wo ist das Problem? Du willst doch den Zähler sowieso nach dem 
Auslesen zurücksetzen. Also:
1. Taktsperre setzen
2. Zähler auslesen
3. Reset aktivieren
4. Taktsperre lösen
5. Reset deaktivieren

Dauert alles zusammen nur wenige µs.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Thomas E. schrieb:
> Na und - wo ist das Problem? Du willst doch den Zähler sowieso nach dem
> Auslesen zurücksetzen. Also:

Da ist das Problem:
> 1. Taktsperre setzen


Gruss
WK

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Nach einigen Routinen und Messungen kommt die Ernüchterung: Wenn ich den 
externen Zähler in 2µs auslesen und rücksetzen könnte, würde das Ganze 
halbwegs hinhauen. Kann ich aber nicht, deshalb haut es nicht hin.

Zudem lese ich im interessanten Messbereich Zählerstände zwischen 2 und 
5, die Auflösung ist also unterirdisch (eine Erhöhung des Taktes beißt 
sich an anderer Stelle). Dann sollte man den Takt ebenfalls rücksetzen 
können, denn es kann ja unmittelbar nach dem Auslesen des Zählers eine 
Taktflanke eintreffen, was bei der unterirdischen Auflösung einen 
gewaltigen Messfehler nach sich ziehen würde. Das Problem lösen kann 
eigentlich nur eine reine Hardwarelösung, der lahme Controller schafft 
das nicht.

m.n. schrieb:
> Die aktive Flanke eines Signals wird per D-FF gespeichert.

Das mache ich bereits, der Controller soll dann selbiges D-FF in 
Abhängigkeit des Zählerstandes rücksetzen. Solange der Zählerstand hoch 
ist, klappt das auch. Ist der Zählerstand klein, wird es eng - zu eng. 
Das D-FF ist im ungünstigsten Fall nur 10µs gesetzt. Dazu käme dann noch 
einiges an Jitter wegen der asynchronen Arbeitsweise des Controllers.

Muss deine Lösung nochmal durchdenken, so ganz blicke das noch nicht.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Ein digitales Monoflop (wenn es ein solches gäbe) würde alle meine 
Problem lösen: Das Teil hätte dann 8 parallele Eingänge (gerne auch 10 
für eine höhere Auflösung) für die Programmierung der Länge des 
Ausgangsimpulses und würde synchron ca. 200x/sec. vom Controller neu 
beschrieben.

von Theor (Gast)


Bewertung
3 lesenswert
nicht lesenswert
@ Gustav

Ich würde Dir ernsthaft raten, mal das eigentliche Vorhaben zu 
beschreiben.

Effektiv stellt die Lösung in Deinem Fall ja schon wieder ein Problem 
dar - an dem basteln wir hier mit Dir nun schon fast zwei Tage. Das ist 
ein schlechtes Zeichen, meine ich.

Ich weiß. Das kratzt evtl. ein wenig am Ego. Ging mir auch schon so. 
Aber es ist zielführender und mutiger den Tatsachen ins Auge zu schauen, 
denke ich.

von Gustav K. (hauwech)


Bewertung
-1 lesenswert
nicht lesenswert
Das würde einen Roman geben, den keiner lesen würde. Gib mir ein 
digitales Monoflop und mein Problem ist vom Tisch. Gut möglich, dass es 
keine mit meinen Möglichkeiten realisierbare Lösung gibt. Dann wird das 
Ganze eben beerdigt.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Ja, sehe ich auch so.

Was ist das Ziel der ganzen Aktion? Beschreibe nicht, was der Zähler 
oder der µC machen soll, sondern die Aufgabe, die du damit zu erledigen 
versuchst.

Und trenne dich von der Idee, den Zähler zurückzusetzen. Damit erzeugst 
du neue Probleme, die vollkommen überflüssig sind.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
m.n. schrieb:
> Im DIL14 ist der tiny24 nicht größer als ein xx393.

Der ATtiny24 soll den 393 ja nicht ersetzen, sondern ganz überflüssig 
machen. D.h. der µC übernimmt die Aufgabe einfach mit, die nötige 
Hardware hat er ja intern. Und wenn der ATtiny nicht reicht, dann eben 
einen größeren AVR oder nen ARM.

Mir ist immer noch nicht klar, warum man die Peripherie im µC brach 
liegen lassen will und sich dafür lieber nen Haufen Probleme mit 
externen Bauteilen aufhalst.
Der µC synchronisiert die Zähl- und Captureeingänge ja mit dem CPU-Takt, 
d.h. die Werte sind immer gültig und jitterfrei.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Der ATtiny24 soll den 393 ja nicht ersetzen, sondern ganz überflüssig
> machen.

parte et divide
Es ist doch nirgends gesagt worden, daß der verwendete µC ein AVR sein 
soll. Das wird hier nur 'bösartig' unterstellt ;-)
"Ein ld x,y benötigt hier genau 1µs." ist doch nicht AVR typisch?
Deshalb mein Vorschlag, die Zählfunktion unabhängig vom Haupt-µC zu 
erledigen. Dann täte es auch ein LPT-Anschluß von einem PC.

Gustav K. schrieb:
> Gib mir ein
> digitales Monoflop und mein Problem ist vom Tisch.

Ich habe doch beschrieben, wie man es mit D-FFs erledigt.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:

> [...]
> Dann wird das
> Ganze eben beerdigt.

Na, wenn es nicht so wichtig ist ...

von Elias K. (elik)


Bewertung
0 lesenswert
nicht lesenswert
Gustav, bitte sage etwas mehr zu dem Vorhaben.

(1) Gibt es einen Grund, nicht die Controller-Hardware (Timer) zu 
nutzen?
(2) Mit welchem Takt wird dein Controller betrieben?
(3) Wie sehr schwanken die 10 kHz (in etwa)?
(4) Wie lang ist deine Messzeit? (Sample-Zeit, bzw. Zeit, in der der 
Zähler zählen soll)
(5) Was möchtest du messen? Frequenz, Periodendauer oder Impulse zählen?
(6) Welche Genauigkeit muss erreicht werden?
(7) Welche Auslösung muss erreicht werden?
(8) Sind zufällig falsche Werte akzeptabel, sofern es nicht mehr als x 
pro Million Werte sind?
(9) Ist es eine Option, einen zweiten, kleinen µC anstelle des 
Logikgatters einzusetzen? Wenn nein, wieso nicht?
(10) Welchen Controller und welche Programmiersprache nutzt du?

Das "digitale Monoflop" hat das gleiche Problem mit dem Sampling. Du 
verschiebst es nur vom Controller weg.

Wenn du nur wenige µs den Zähler laufen lässt, wird der Zähler natürlich 
nur bis 4 oder 5 zählen. Und der Messfehler ist unterirdisch schlecht. 
In dem Fall macht man es ja auch anders herum, das niederfrequente 
Signal hochfrequent abtasten. Aber zuerst beantwortest du bitte die 10 
Fragen da oben.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
m.n. schrieb:
> Es ist doch nirgends gesagt worden, daß der verwendete µC ein AVR sein
> soll.

Ja leider werden die wichtigsten Details hartnäckig verschwiegen, wie 
z.B. der µC-Typ.
Allerdings sollte jeder halbwegs gängige µC in Hardware zählen und 
capturen können.
Sogar der alte AT89C52 von 1993 konnte das schon.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Ein digitales Monoflop (wenn es ein solches gäbe) würde alle meine
> Problem lösen: Das Teil hätte dann 8 parallele Eingänge (gerne auch 10
> für eine höhere Auflösung) für die Programmierung der Länge des
> Ausgangsimpulses und würde synchron ca. 200x/sec. vom Controller neu
> beschrieben.

Wenn es unbedingt in altmodischer Technik gelöst werden soll, dann kann 
man für so etwas einen programmierbaren 8bit-Abwärtszähler nehmen (ja, 
gab es zumindest früher mal) und den Vorgabewert in einem 8bit-Latch 
speichern. Runterzählen lassen bis er auf Null ist, dann Ausgangssignal 
erzeugen und Vorgabewert vom Zähler laden lassen. Beispiele für so ein 
Konstrukt solltest du in der Literatur genug finden.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Ein digitales Monoflop (wenn es ein solches gäbe) würde alle meine
> Problem lösen:

Das klingt so, als würde jemand die tausendste Version eines 
Tachokonverters basteln wollen und vermutlich auch die mit Abstand 
komplizierteste.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ralf D. schrieb:
> Vorgabewert vom Zähler laden lassen.

Wenn Du einkaufen gehst, zahlst Du an der Kasse 74,83 und packst dann 
genau für diesen Betrag die Waren in den Korb?
Nur wie weißt du vorher, daß es genau dieser Betrag werden wird?

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Ralf D. schrieb:
>> Vorgabewert vom Zähler laden lassen.
>
> Wenn Du einkaufen gehst, zahlst Du an der Kasse 74,83 und packst dann
> genau für diesen Betrag die Waren in den Korb?
> Nur wie weißt du vorher, daß es genau dieser Betrag werden wird?

Manchmal gibt man das eben vor.

Wenn er ein "digitales Monoflop" haben will, bei dem er einen bestimmten 
Zählerstand vorgeben will, bis zu dem gezählt werden soll, um dann den 
Ausgang zu deaktivieren (sprich: nach Triggerung ein Ausgangssignal von 
x Takten Länge zu erzeugen), dann ist ein programmierbarer Abwärtszähler 
eine Lösungsmöglichkeit.

Wobei ich auch nicht verstehe, warum man das bei 10kHz Zähltakt nicht 
gleich vom Controller erzeugen lässt, der sollte dafür schnell genug 
sein.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ralf D. schrieb:
> Manchmal gibt man das eben vor.

Mag sein, aber hier geht es wohl darum, als Ergebnis die eintreffenden 
Impulse in einem Intervall zu messen. Und das Ergebnis ist eben 
variabel.

Ralf D. schrieb:
> Wobei ich auch nicht verstehe, warum man das bei 10kHz Zähltakt nicht
> gleich vom Controller erzeugen lässt

Es gibt Leute, die mit Hardware besser klar kommen.
Das muß jeder für sich entscheiden.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Was ist das Ziel der ganzen Aktion? Beschreibe nicht, was der Zähler
> oder der µC machen soll, sondern die Aufgabe, die du damit zu erledigen
> versuchst.

Was sollte das bringen? Eine Menge Empfehlungen für moderne Methoden und 
Systeme, die ich nicht kenne, nicht habe und auch nicht beherrsche.

> Und trenne dich von der Idee, den Zähler zurückzusetzen. Damit erzeugst
> du neue Probleme, die vollkommen überflüssig sind.

Soweit bin ich mittlerweile auch, deshalb auch die Idee mit einem 
externen programmierbaren Monoflop, da erfolgt das Rücksetzen 
automatisch. 10µs würden hier auch kein Problem sein. Dummerweise muss 
die Länge des Ausgangsimpulses variabel sein. Im ungünstigsten Fall 
müsste so ein programmierbares Monoflop 200x/sec. neu beschrieben 
werden. Gemeinerweise sind die 200x/sec. auch variabel (bis hinunter zu 
0x/sec.).

Werde mir mal die Funktion des Rückwärtszählers anschauen, bisher hatte 
ich damit noch nicht zu tun.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Was sollte das bringen? Eine Menge Empfehlungen für moderne Methoden und
> Systeme, die ich nicht kenne, nicht habe und auch nicht beherrsche.

Anscheinend beherrschst du aber deine aktuelle Methode auch nicht so 
richtig....

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
>> Was ist das Ziel der ganzen Aktion? Beschreibe nicht, was der Zähler
>> oder der µC machen soll, sondern die Aufgabe, die du damit zu erledigen
>> versuchst.

> Was sollte das bringen? Eine Menge Empfehlungen für moderne Methoden und
> Systeme, die ich nicht kenne, nicht habe und auch nicht beherrsche.

Dann schreibe doch mal, welche Systeme du beherrschst. Wir sind 
schließlich keine Hellseher.

Deine Logikgatter beherrschst du jedenfalls offensichtlich nicht, sonst 
hättest du es selbst hinbekommen (spätestens nach den obigen Tipss). Die 
Zähler deines (immer noch unbekannten) Mikrocontrollers willst du auch 
nicht verwenden.

Einfacher geht es aber nicht!

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Gustav K. schrieb:
> Werde mir mal die Funktion des Rückwärtszählers anschauen, bisher hatte
> ich damit noch nicht zu tun.

Das ist nur an den Symptomen herumgedoktort. Schau dir lieber an, wie 
man Signale von einer Clockdomaine in die Andere rueberbringt und 
synchron verarbeitet. Das ist bei deiner Problemstellung des Pudels 
Kern.

Gruss
WK

von Gustav K. (hauwech)


Bewertung
-1 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Das ist nur an den Symptomen herumgedoktort.

Nachdem ich nun vor der Version mit Rückwärtszähler sitze, komme ich zum 
gleichen Ergebnis. Das zentrale Problem ist die Zeit, die für die 
Bearbeitung des Interrupts draufgeht. Hier sehe ich schon 20 Taktzyklen 
für den Sprung in die ISR und vorher weitere mögliche 20 Taktzyklen, um 
den aktuellen Befehl noch abzuarbeiten. 40 Taktzyklen und noch nichts 
ist passiert. Entweder der Beginn der Impulses stimmt nicht, oder das 
Ende. Die Impulsdauer lasse ich mal außen vor.

Soll das astrein laufen, kommt wohl nur eine reine Hardwarelösung in 
Frage. Das lege ich aber erst mal mal auf Eis.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Das zentrale Problem ist die Zeit, die für die
> Bearbeitung des Interrupts draufgeht.

Bei einem µC, der intern zählen und capturen kann, entschärft sich das 
total. Dann hast Du für die Interruptbehandlung die gesamte Zeit bis zur 
nächsten Capture-Flanke zur Verfügung.

Gustav K. schrieb:
> Hier sehe ich schon 20 Taktzyklen
> für den Sprung in die ISR und vorher weitere mögliche 20 Taktzyklen, um
> den aktuellen Befehl noch abzuarbeiten.

Wäre schon interessant, welcher µC das ist.

Gustav K. schrieb:
> Soll das astrein laufen, kommt wohl nur eine reine Hardwarelösung in
> Frage.

Einfach nen passenden µC nehmen reicht völlig.

von m.n. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Hier sehe ich schon 20 Taktzyklen
> für den Sprung in die ISR und vorher weitere mögliche 20 Taktzyklen, um
> den aktuellen Befehl noch abzuarbeiten. 40 Taktzyklen und noch nichts
> ist passiert.

Vielleicht solltest Du Deine Probleme doch eher mit Deinem Lehrer 
besprechen.

Peter D. schrieb:
> Wäre schon interessant, welcher µC das ist.

Geht nicht, ist geheim. Und es wäre dann ja sofort klar, wie wir hier 
zum Narren gehalten werden.

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wäre schon interessant, welcher µC das ist.

Vielleicht eine MOS6510 CPU, die scheint keine internen Timer zu haben.

von Gustav K. (hauwech)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Bei einem µC, der intern zählen und capturen kann, entschärft sich das
> total.

Der Controller kann intern zählen, aber das hilft auch nichts. Der 
Controller benötigt genau 12 µs, bis die fallende Flanke als externer 
Interrupt einen Impuls erzeugt (Bild 1, Signal unten). Der entstandene 
Impuls wird mittels internem Timer-Interrupt wieder gelöscht. Der 
interne Timer steht dabei auf Minimum, also Prescaler=1 und 
Timer-Register=1. Der Code ist bereits zeitoptimiert. In Bild 1 ein 
Single-Shot.

Ein weiteres Problem ist ein deutlicher zeitlicher Jitter von 2-3 µs, 
weil der aktuell geladene Befehl bei einem Interrupt noch abgearbeitet 
werden muss (Bild 2 (analoge Darstellung)).

Die Impulsdauer ist dann das zentrale Problem, ich schaffe mit 
Prescaler=1 und Timer-Register=1 als Minimum gerade mal 8 µs. Das würde 
eigentlich reichen. Lade ich aber das Timer-Register mit 07h oder 0Fh, 
ändert das an der Impulslänge sichtbar nichts. Erst bei höheren 
Zählerständen verlängert sich der Impuls deutlich. Gefordert ist aber 
eine Verdoppelung der Impulsdauer bei Verdoppelung des Zählerstandes. 
Und gerade bei Zählerständen unter 10 spielt die Musik.

Möglicherweise gibt es irgendwelche "heiße Maschinen", mit denen man das 
Problem lösen könnte. Das hilft mir aber nicht weiter. Ich werde ab 
jetzt die reine Hardware-Lösung favorisieren.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Ein weiteres Problem ist ein deutlicher zeitlicher Jitter von 2-3 µs,
> weil der aktuell geladene Befehl bei einem Interrupt noch abgearbeitet
> werden muss

Dann stell halt den Controller auf 8MHz um.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich verstehe immer noch nicht, warum Verzögerungen weniger µs bei deinem 
Signal von 10kHz eine Rolle spielen?

Du solltest deinen speziellen Anwendungsfall allerdings mal offen legen, 
da du Hilfe erbittest.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Gefordert ist aber
> eine Verdoppelung der Impulsdauer bei Verdoppelung des Zählerstandes.
> Und gerade bei Zählerständen unter 10 spielt die Musik.

Wo ist das Problem, ein µC kann doch rechnen. Rechne einfach so um, daß 
1 = 8µs und 2 = 16µs sind usw. (Y = aX + b).

Nenne doch endlich mal den µC.

Gustav K. schrieb:
> Möglicherweise gibt es irgendwelche "heiße Maschinen", mit denen man das
> Problem lösen könnte.

Ich würden nen AT89C52 von 1993 oder AT90S8515 von 1998 nicht als "heiße 
Maschinen" bezeichnen.

von Gustav K. (hauwech)


Bewertung
-1 lesenswert
nicht lesenswert
Karl schrieb:
> Dann stell halt den Controller auf 8MHz um.

Der läuft seit Urzeiten mit 12 MHz.

Peter D. schrieb:
> Wo ist das Problem, ein µC kann doch rechnen. Rechne einfach so um, daß
> 1 = 8µs und 2 = 16µs sind usw. (Y = aX + b)

Es ist keine Zeit zum irgendwas rechnen.

Seltsam zudem, dass der Timer bei Werten von 1, 2, 3, 4 und 5 immer die 
gleiche Impulslänge erzeugt. 6 und 7 ergab dann einen geringfügig 
längeren Impuls, bei 8 konnte sich der Controller nicht entscheiden 
(Jitter), weiter habe ich das dann nicht verfolgt, weil unbrauchbar. 
Gerade bei den kleinen Werten spielt die Musik, da hilft auch kein 
Rechnen. Ich vermute, dass der Timer noch innerhalb der ISR abläuft. 
Letztendlich egal, mit Timer funktioniert das hier bei kleinen 
Zählerständen nicht.

von Gustav K. (hauwech)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Mal rein interessehalber den ganzen Timerkram rausgeworfen und durch 
eine 8-Bit Zählschleife ersetzt. Und siehe da, das funktioniert um 
Klassen besser und zudem fehlerfrei. Der zeitliche Versatz reduziert 
sich von 12 auf 8µs, der zeitliche Jitter halbiert sich, da nur noch ein 
einziger Interrupt verwendet wird. Und der kürzeste Impuls reduziert 
sich von 8 auf 2µs. Weicht man die Spezifikationen etwas auf, könnte 
daraus ein Schuh werden.

In den Bildern der Ausgangsimpuls bei Zählerstand  1, 2, 3 und 4.
Unten der zeitoptimierte Code zur Impulserzeugung:
1
irq0:  or p0,r6       ;portbit -> H
2
timer: djnz r4,timer
3
       and p0,r7      ;portbit -> L
4
       iret

von Route_66 H. (route_66)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Nenne doch endlich mal den µC.

von Route_66 H. (route_66)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Nenne doch endlich mal den µC.

Peter D. schrieb:
> Nenne doch endlich mal den µC.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Offensichtlich ein 8051 Derivat, welches auch den Befehl ld x,y 
beherrscht.
Man lernt ja nie aus.

von Route_66 H. (route_66)


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Offensichtlich ein 8051 Derivat, welches auch den Befehl ld x,y
> beherrscht.
> Man lernt ja nie aus.

Falsch!
Beim 8051 heissen ALLE Ladebefehle MOV und der Return vom Interrupt 
RETI.
Das oben gezeigte Quellcodebeispiel ist typisch für den Z8.
Da gibt es LD und IRET.

Der Zilog Z8 hat aber eine Unmenge Varianten.

Also noch einmal:

Peter D. schrieb:
> Nenne doch endlich mal den µC.

Peter D. schrieb:
> Nenne doch endlich mal den µC.

Peter D. schrieb:
> Nenne doch endlich mal den µC.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Route 6. schrieb:
> Das oben gezeigte Quellcodebeispiel ist typisch für den Z8.
> Da gibt es LD und IRET.
> Der Zilog Z8 hat aber eine Unmenge Varianten.

Z8673312VSC - und nu?

von Route_66 H. (route_66)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Z8673312VSC - und nu?

Warum suchtst du dir einen OTP-Typ aus?
Warum nutzt du nicht einen der zwei internen Counter?

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustav K. schrieb:
> Z8673312VSC - und nu?

Nun hat keiner mehr Bock auf weitere, notwendige Informationen eine 
Ewigkeit zu warten.

von Gustav K. (hauwech)


Bewertung
0 lesenswert
nicht lesenswert
Route 6. schrieb:
> Warum suchtst du dir einen OTP-Typ aus?

Den suche ich nicht aus, sondern der liegt hier stangenweise im Keller.

Route 6. schrieb:
> Warum nutzt du nicht einen der zwei internen Counter?

Hatte ich bereits versucht, das hat nicht vernünftig funktioniert, wie 
weiter oben schon von mir beschrieben.

Das Problem hat sich aber mittlerweile erledigt, zwei brauchbare 
Lösungen liegen auf dem Tisch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.