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
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
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.
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
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?
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
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.
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.
Beim STM32F103 hat man genau dieses Problem beim Auslesen der Uhr. Pragmatische Lösung: Wiederholt auslesen, bis man 2x den selben Wert erhält.
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.
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
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.
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
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?
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
> 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.
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.
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.
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.
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.
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.
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.
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?
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...
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.
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.
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
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)
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
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.
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...
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.
Das frage ich mich auch, warum Du die internen Timer/Zähler eines MC nicht benutzen willst.
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.
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!
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.
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.
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.
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.
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
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
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.
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
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.
"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.
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.
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.
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
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.
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.
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
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.
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.
@ 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.
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.
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.
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.
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.
Gustav K. schrieb: > [...] > Dann wird das > Ganze eben beerdigt. Na, wenn es nicht so wichtig ist ...
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.
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.
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.
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.
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?
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.
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.
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.
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....
>> 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!
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
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
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.
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.
Peter D. schrieb: > Wäre schon interessant, welcher µC das ist. Vielleicht eine MOS6510 CPU, die scheint keine internen Timer zu haben.
Angehängte Dateien:
-
12usec.jpg
28 KB -
Jitter.jpg
26 KB
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.
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.
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.
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.
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.
Angehängte Dateien:
-
Timer_1.jpg
31 KB -
Timer_2.jpg
31 KB -
Timer_3.jpg
31 KB -
Timer_4.jpg
31 KB
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 |
Peter D. schrieb: > Nenne doch endlich mal den µC. Peter D. schrieb: > Nenne doch endlich mal den µC.
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.
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?
Gustav K. schrieb: > Z8673312VSC - und nu? Warum suchtst du dir einen OTP-Typ aus? Warum nutzt du nicht einen der zwei internen Counter?
Gustav K. schrieb: > Z8673312VSC - und nu? Nun hat keiner mehr Bock auf weitere, notwendige Informationen eine Ewigkeit zu warten.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.