agmue:
Wenn stimmt, was Du schreibst, könnte hier Dein Gedankenfehler liegen: Interrupt wird ausgelöst → Kontakt prellt → Port wird falsch eingelesen.
Da hast du völlig recht. Bei meinem im ersten Posting beschrieben Testablauf waren es aber zum Teil andere Bits, die gar nicht betätigt waren. Ein Preller müsste ja dasselbe Bit rauf und runter toggeln. In dem Test waren bei den beiden gelesenen Bytes unterschiedliche Bits gesetzt oder nicht. Aber vergessen wir das - es soll nur die erste Auslösung zählen. Danach wird ignoriert. Inzwischen bin ich einige Schritte weiter und tatsächlich näher am Ziel.
Eine Fehlerquelle für sporadische unerklärliche Bitmuster war wohl die LED-Schreibtischlampe neben meinem Protoboard. Also bei Tests ohne Dartmatrix. Da sind natürliche viele Eingänge offen und es werden Treffer nur mit Taster simuliert. Die sehr hochohmigen Pullups haben nicht verhindert, dass da Störungen auf anderen offenen Pins getriggert haben bzw. ausgelesen wurden. Die Lampe steht jetzt 30 cm weiter und dieser Spuk ist vorbei.
Eine weitere Fehlerquelle sitzt im Atmel. Zumindest in meinem.
Eingangs im Setup setze ich alle drei Ports komplett Input-High. Also auch A0 bis A5. Die sind dann auch tatsächlich high.
Da ich bei den aktuellen Tests auch "Phantomtreffer" auf 3 der 6 momentan gar nicht angeschlossenen Analogports hatte, habe ich da mal den Scope dran gehängt. Alle Pins nach Start des Programms sind high. Ok.
Nach der ersten Leseabfrage an PortC verschwinden 3 der 6 Highpegel und die Pins flotaen so bei ca. 1 Volt rum. Prompt habe ich dann falsche Bits in der nächsten Abfrage. Der Atmel schaltet da 3 der 6 Pull-Ups einfach ab. Firmwarebug?
Abhilfe: an jedem Port 10kOhm und der Port bleibt high. Oder per Software (pinMode(A0-A5, INPUT_PULLUP) nach der Abfrage den Port gezielt wieder neu setzen. Natürlich alle bzw. die 3 der 6 wo es passiert.
Wieder ist ein halber Tag vorbei. Aber ich bin deutlich weiter. Wenn ich mir was in den Kopf setze gebe ich nicht so schnell auf. Das muss!
ich hoffe du merkst jetzt das deine letzte Antwort kaum noch etwas mit dem Text im Eingangspost zu tun hat? Alle wollten das du deinen Fokus auf den Signalverlauf lenkst. Jetzt haste das begriffen. Vorher haste alle Nachfragen dazu weggebügelt. Signalprellen war bis jetzt nicht erkennbar.
Entweder benötigst du die angesprochene externe Beschaltung damit Preller nicht verloren gehen. Oder du benötigst einen anderen µC der für jeden Pin (Port Bit) ein eigenes Interrupt Flag im Register hat. Dann geht auch nichts verloren. Eine andere Chance sehe ich aktuell nicht. Dafür sind die Gruppen PCINTs hier nicht geeignet. Den Signalverlauf zu sehen wäre weiterhin von Vorteil. Ein Logic Analyzer dafür wurde ja schon angesprochen.
MicroBahner:
Und ich bin mir ebenso sicher, dass es - zumindest auf einem UNO - nicht rein per Software machbar ist. Du wirst sporadisch immer wieder was verlieren, weil dir andere Interrupts in die Quere kommen.
Du müsstest den 386P von Grund auf selbst programmieren um sicher zu sein, dass dir nichts in die Quere kommt. Oder zumindest den millis() Interrupt abschalten und nichts anderes aktivieren, was Interrupts braucht oder sie - und sei es noch so kurz - unterdrückt.
Ich war mir sehr sicher und bin es jetzt zu 99%. Im Test geht jetzt alles.
"Verlieren" wäre auch kein Problem. Nur Fehler beim Erkennen sollten nicht passieren.
Die vielen sporadischen Fehlsignale habe ich u.a. einer Macke meines Atmel zu verdanken. Der schaltet nach dem Schalten mancher Eingänge gegen Masse an ein paar anderen Ports/Pins die Pullups kurz oder teilweise dauerhaft ab. Somit sind meine dann diversen offenen Eingänge rumgefloatet und haben somit wilde Ereignismuster ausgelöst. In der Loop werden nun nach jedem erkannten Treffer die Ports wieder mit "pinmode" gepulluped
Ein weiteres Problem hat mir die Programmiersprache bereitet. Irgend ein Verständnisproblem bei den Bitoperationen. Und das führte auch zu diversen Fehlern. Ist aber jetzt auch korrigiert.
Damit schließe ich für heute.
Danke an alle die sich bemüht haben mir zu helfen, mich zu belehren oder mit OT-Fragen und OT-Hinweisen die Zeit zu erschlagen.....
lupus1952:
Die vielen sporadischen Fehlsignale habe ich u.a. einer Macke meines Atmel zu verdanken. Der schaltet nach dem Schalten mancher Eingänge gegen Masse an ein paar anderen Ports/Pins die Pullups kurz oder teilweise dauerhaft ab. Somit sind meine dann diversen offenen Eingänge rumgefloatet und haben somit wilde Ereignismuster ausgelöst.
Das sind keine Macken des Controllers. Das sind Programmier- und/oder äußere Beschaltungsfehler.
Doc_Arduino:
Das sind keine Macken des Controllers. Das sind Programmier- und/oder äußere Beschaltungsfehler.
Deine Äußerung betrachte ich schon fast als Beleidigung! Du musst mich nicht in allen für zu blöde halten. Das sind 100%ig Macken des Atmel! bzw. konkret meines Exemplares. Ich will keinen generellen Fehler unterstellen. Glaub' mir doch auch mal was. Fast 50 Jahre als Berufselektroniker waren nicht umsonst Ich habe genug gemessen und getestet und kann den Nachweis notfalls erbringen. Das hat mit Programmierung und oder Beschaltung nichts zu tun. Ein offener Eingang mit Pullup muss einfach oben bleiben, solange er nicht per Softwareintern oder extern runtergezogen wird. Dazu hat der Herr Pullup das ja erfunden um eindeutige Werte zu bekommen. Wenn ein anderer Pin, z.B. D8 per Taster gegen Masse geschaltet wird, darf so ein offener Pin nicht runtergehen. Und das tun bei mir 2 der analogen und 2 der digitalen Pins. A2 und A3 sowie D2 und D3. Mittels echtem 10K Pullup bleiben sie oben. Ansonsten floaten die irgendwo rum nach dem ersten "Treffer". Hat mir natürlich eine Menge Verwirrung gestiftet, weil man mit sowas ja nicht rechnet. Und in der Praxis an der Dartscheibe wird das auch keine Probleme mache. Die ist grundsätzlich an allen nicht aktiven Pins high.
Tommy56:
Dann müsste man doch das Vorhandensein eigener Fehler anerkennen. Da schiebt man das lieber auf die Hardware, die kann sich nicht wehren.
Gruß Tommy
Hast du auch sinnvolle Antworten? Oder bist du so ein typischer Forenbesucher der nur zum Anmeckern anderer was sagt? Dass ich Anfänger bezüglich Arduino bin, habe ich gesagt und dazu stehe ich. Und ich schiebe nichts auf Hardware! Ich habe es per intensiven Untersuchungen gemessen, dass der /mein Atmel diese Macke hat und kann es nachvollziehen. Punkt.
lupus1952:
Das sind 100%ig Macken des Atmel! bzw. konkret meines Exemplares.
Fast 50 Jahre als Berufselektroniker
Ein offener Eingang mit Pullup muss einfach oben bleiben, solange er nicht per Softwareintern oder extern runtergezogen wird.
Du bist nicht lustig.
Und ganz ehrlich, das wird jetzt #31 und ich weiss noch immer nicht, was Du hast!
Wenn Du soviel Erfahrung vorweisen kannst, dann komm doch mal mit Aussagen rum, die einen sinnvollen Charakter haben.
Jetzt auch noch zum Rundumschlag auszuholen, ist vor dem Hintergrund der von Dir bisher gelieferten Infos eine Frechheit.
Wenn Du etwas Arsch in der Hose hättest, wäre Dein Aufbau hier als Foto mit einem LA-Bildausschnitt gelandet und kein Schwein hätte sich über richtig oder falsch echauffiert.
Mach weiter - Du wirst Deine Lösung finden. Aber hör auf, gut gemeinte und von Wissen geprägte Ratschläge als persönlichen Angriff zu sehen.
Ist mein letzter Vermittlungsversuch - dann ist aber auch Schluß bei mir.
my_xy_projekt:
Du hast nach #16 sogar noch die Chuzpe nachzutreten, nachdem klar ist das seit DEINEM ersten Post DEINE falsche Angabe schuld an dem Dilemma ist.
Kann man bringen.
Was für eine falsche Angabe ist schuld an welchem Dilemma? Ich habe keine Probleme (mehr). Ich habe auch nirgends ein Dilemma gesehen. Nur eine Menge Leute erlebt die nicht lesen oder verstehen können. Aber das ist in Foren so üblich. Dann gab es ein paar Leute mit guten Ideen. Allerdings eher im vorigen Thread und bezüglich Hardwarelösungen. Hier in diesem Thread eher nur viel Gerede und Unterstellungen ohne echte Hilfe, Vorschläge, die nicht zum Problem passten u.s.w. Aber das ist egal. Da wollte doch glatt jemand Timingdiagramme wo ich wissen wollte ...(siehe erstes Posting). Da hat das eine mit dem anderen nichts zu tun. Leider verstehen viele Leute einfache Fragestellungen nicht. Oder lesen nicht mal die Frage. Und so werden die Antworten schnell OT und so ein Thread verläuft sich bis hin zu Streitereien.
Nebenbei: Inzwischen läuft der nackte Arduino ohne extra Hardware an der Dartelektronik. Er ist also schnell genug das alles ohne extra Hardware zu meistern. Jetzt muss ich nur noch die Sprachdateien sprechen und das MP3-Modul reinhängen. Dann redet mein Dartboard auch deutsch.
Das Thema ist also beendet und ich steige aus. Auf die ganze Nachtretereien habe ich keine Lust.
Schönes Wochenende allerseits.
