Doc_Arduino:
Hallo,
okay, ich spiel das Spiel mit.
Ich empfinde es langsam als Trauerspiel!
Stellen wir uns einmal ganz dumm und behandeln den Thread als Alleinigen.
Das wäre schön, wenn das endlich mal jemand machen würde! Statt dessen wird auf Sachen rumgehackt, die nicht zum Frageposting gehören. Auch du bist gemeint. Du hast dir jetzt riesige Mühe für ein großes Posting gemacht. Aber davon sind 75 Prozent OT. Weil sie sich ums Drumherum bewegen, statt konkret die klar definierte Frage zu beantworten
Wo nimmst deine besagten 16 Bits her?
Gehört zwar nicht zum Thema. Die 16 Bit kommen aus der Boardmatrix einer elektronischen Dartscheibe. Die möchte ich parallel auslesen.
Bei mir hat 1 Port 8Bit und 3 Ports zusammenbetrachtet 24Bit.
Komisch - bei mir auch
Ich weiß im Grunde genommen auch nicht welchen Controller du hast. Deswegen könnte die Annahme der 8Bit pro Port auch falsch sein.
Arduino UNO R3
Ich weiß auch nicht was du mit den 16Bits machen möchtest.
Habe ich nun bereits mehrfach erklärt
Verstehste?
/* Spielende *\
Trauerspiel! Viel "off Topic!" bezüglich der Ursprungsfrage!
Du musst dich nicht nach unseren Regeln richten. Du musst dich nach den allgemeinen Forenregeln richten. Niemand kann im Forum deinen Tisch, deinen Bildschirm sehen oder deine Gedanken lesen.
Ich weiß wie man in Foren umzugehen hat. Leider gibt es, und ganz speziell in deutschen, Foren immer wieder Leute, die sich gar nicht die Mühe machen eine Frage zu lesen und zu verstehen. Die antworten dann irgendwas mehr oder weniger Brauchbares drumherum. Aber nicht zum Kern der Frage. So auch in diesem Fall. Ich nenne keine Namen. Aber bei ein paar Leuten ist genau das der Fall. Zum Teil auch bei dir. Das muss ich leider sagen. Du fragst mich hier Sachen, die ich ein paar Posts zuvor erklärt habe. So etwas nervt nur und man fühlt sich nicht ernst genommen.
Da ich und andere aber nicht auf dem Kopf gefallen sind, sehen wir was du eigentlich machen möchtest, nur deshalb bekommste hier überhaupt Antworten.
Oh . wie gütlich. Muss ich jetzt auf die Knie gehen? Soll ich mich bedanken dafür, dass mir viele der unnötigen Antworten meine Zeit stehlen und ich immer wieder das zuvor gesagte nochmal wiederholen muss?
Ich sage danke zu denen, die sich die Mühe gemacht haben wirklich konkret zu helfen. Z.B. mit den Hardwaretips.
Wir müssen von dir nicht wissen wie der Controller arbeitet. Wir benötigen Informationen für das drum herum, dass was außerhalb des Controllers passiert.
Ausserhalb des Controllers ist die Dartmatrix! Habe ich aber schon beschrieben!
Zum Bsp. wäre ein Timingdiagramm der Signale nicht verkehrt, wenn es denn so zeitkritisch ist. Würde deinen Text dazu besser veranschaulichen.
Zu den Zeiten habe ich mich bereits sehr ausführlich geäußert!
Das Interruptsignal muss eine Mindestlänge von paar Takten haben. Ansonsten ist das tatsächlich wieder weg zwischen Interrupterkennung und in die ISR springen um das PINx Register auslesen. Wie lang ist der minimale Impuls? Sind das die 9µs? Das entspricht 144 Takte für High Pegel. Wenn dem so ist, reicht das aus. Sind das pro Bit 9µs High und dann 9µs Low Pegel? Wenn dagegen die Signalperiode nur 9µs lang ist, dann wirds echt knapp. Wieviel davon ist dann der High Pegel lang?
Super – es geht ja auch konkret.. Nur leider nicht konkret zu meiner Anfangsfrage! Es nützt nichts wenn du oder andere mir viel vom Drumherum erklären und ich eine spezielle Einzelfrage gestellt habe
Dann musste wie schon geschrieben PINx auslesen und mittels Bit Operatoren vergleichen.
Dass ich das genau so mache habe ich bereits mehrfach geschrieben. Aber das passt nicht zur Frage!
Mehrfach auslesen hilft dir dabei nicht. Du willst ja nicht wissen obs wieder weg ist, du willst wissen welches Bit oder gar Bits im gesicherten Byte drin stecken. Dafür benötigst du besagte Bit Operationen.
Das Mehrfachauslesen war ein Testfall! Der mir gezeigt hat, dass zwischen den Zeitpunkten des Auslösen des IRQ bis zum Abfragen des Ports, sogar zwischen 2 Folgeabfragen, der Eingangswert sich gelegentlich ändert. Und somit falsche Ergebnisse rauskommen. Aber auch das habe ich bereits gesagt
Desweiteren gibt dein Code nicht viel her.
Wozu auch? – es war nur ein Test zum Erkennen des Problems
Was machst du mit der gewonnen Information aus der ISR, wenn sie denn irgendwann einmal klappt?
Was ich damit mache ist bezüglich meiner Frage egal. Aber ich sage auch das nochmal: Ich möchte die Treffer in einer Dartscheibe protokollieren. Bitte dazu aber keine weiteren OT-Antworten
Dabei gehts mir um bestimmte Dinge die ich nicht sehen kann um sie zu prüfen.
Da gibt es nichts zu sehen und zu prüfen! Ich wollte eigentlich nur eine Antwort auf meine Frage. Und keine Romane drumherum.
Trotz deiner Trotzigkeit helfe ich dir mal weiter.
Auch typisch für deutsche Foren ist das Beleidigen der Fragesteller. Der eine bezeichnet mein Handeln mit dem zweiten Thread als dümmlich. Du betitelst mich als trotzig!
Wir müssen es ja nicht ausarten lassen.
Schön – dann kommen wir mal auf den Punkt
Die angenommenen 144 bzw. vielleicht nur 72 Takte reichen locker zur Pegelerkennung und um in die ISR zu springen und den Zustand zu speichern.
Aber nachweislich bekomme ich für einen Interrupt bei 2 direkten (Test-) Folgeabfragen ab und zu unterschiedliche Werte. Natürlich auch bei nur einer Abfrage. Bloß da war das Erkennen des Fehlers schwer. Es ist mir halt nur dadurch aufgefallen, weil mache Ergebnisse unlogisch waren. Deshalb bin ich auf die Suche gegangen.
Sie reichen aber nicht unbedingt aus um aufwendige Bit Operationen auszuführen. Du müßtest ja pro Port 8 Vergleiche machen.
Zum Glück nicht. Von der Matrix ist immer nur eine Spalte und eine Reihe gleichzeitig aktiv. Nach Erkennen eines Interrupts werden in der Loop dann die Bits und Bytes maskiert und/oder geschoben. Als Ergebnis habe ich 2 Variable. Einmal Spalte, einmal Reihe mit je einem gesetzten Bit. Das funktioniert alles.
Dann kann es durchaus sein das eine nächste Pegelerkennung schief geht. Der nächste Interrupt wird zwar angesprungen, aber bis wirklich PINx ausgelesen wird kann der anliegende Puls schon wieder weg sein. Müßte man wenn man es genau wissen will ausmessen.
Ich habe stundenlang scopiert und unzählige Testsscripte dazu gemacht. Das Auswerten der Bits, wenn ich erst mal so ein Portbyte habe, erfolgt in der Loop. Diese erkennt per entsprechender Flags, dass ein neues Byte da ist. Und solange werden keine Interrupts mehr angenommen bzw. gesperrt. Zwischen Darttreffern habe ich mehr als genug Zeit zum Auswerten. Wichtig ist nur, dass ich exakt den Zustand beim Treffereinschlag in das zu lesende Portbyte bekomme. Sie Ursprungsfrage.
Deswegen, um dem Signalverlust vorzubeugen, darfste von den Ports in der ISR nur PINx jeweils auslesen und erst am Ende, wenn alles vorbei ist, kannste alle 3 gespeicherten Bytes in Ruhe außerhalb jeder ISR auswerten. Wie gesagt mit Bit Operationen.
Genauso mache ich das. Habe ich aber schon geschrieben
Woher du Anfang und Ende der Signalerzeugung nimmst weiß ich nicht. Ich weiß nicht was die Dartscheibe an Signalen bietet.
Es gibt kein Anfang und Ende! Die Matrix wird permanent im "Kreis herum" von der Dartelektronik "gescannt" Habe ich aber schon ausführlich erklärt. Und spielt bezüglich meiner Ursprungsfrage eigentlich keine Rolle.
An Signalen bekomme ich die Matrixspalten und Matrikreihen. Deren Pegel überwache ich. Das sind 2 x 8 Bit. Habe ich aber auch schon erklärt
Für all das brauchste noch volatile Variablen, da bin ich mir sicher. Wenn der Datenaustausch zwischen Hauptprogramm und ISR sich nur auf einzelne Byte bezieht, brauchste dich um atomaren Zugriff nicht kümmern. Ansonsten benötigst du das auch noch.
Für das Problem des Signalverlustes, weil möglicherweise zu kurz, gabs im alten Thread auch schon andere Ideen.
Ich weiß, Hardware extern. Das waren auch damals die wenigen sachlich guten zum Thema passenden Antworten. Nur leider entweder nicht einfach umsetzbar oder mir zunächst zu aufwendig. Ich bin mir sicher, dass es per Software machbar ist.
Jetzt rollt der Ball wieder zu dir.
Ich habe aber keine Lust mehr zu spielen. Ich probiere noch ein paar Varianten in der Abfrageoptimierung meines bisher laufenden Scriptes.
Und notfalls kommen 2 Hardware 8>3 Interruptencoder an die Matrix und einen Latch-Baustein.
Danke für deine ausführliche Bemühung
