Hallo zusammen,
für ein Projekt muss ich mich mit Interrupts beschäftigen und habe daher
einen Drehgeber an meinen Arduino nano angeschloßen.
Die ISR wird jedoch doppelt ausgeführt.
mein Plan ist es das clk Signal mit einem Interrupt zu erkennen und eine
flag im programm zu setzen.
wegen den Prellen schalte ich den externen interrupt anschließend aus.
1
voidinit_INT0()
2
{
3
EICRA|=1<<ISC01;//ISC01 -> set int0
4
EIMSK|=1<<INT0;//enable INT0
5
6
}
7
8
ISR(INT0_vect)
9
{
10
int0_detected=1;//set
11
EIMSK=0;//disable INT0
12
}
Im loop wird anschließend die Richtung bestimmt und es wird vorerst 2
sekunden gewartet damit das clk Signal auf jeden Fall nicht mehr prellt.
Wegen dem Prellen setze ich am Ende noch das Interrupt Flag register
zurück um den besagten merfachaufruf zu verhindern und aktiviere den
externen Interrupt wieder.
1
voidloop()
2
{
3
if(int0_detected)
4
{
5
if(PIND&DIR_mask)Serial.println("<- left");
6
elseSerial.println("right ->");
7
8
delay(2000);
9
Serial.println("\n\n\n\n\n\n\n\n\n\n\n");
10
11
int0_detected=0;
12
PCIFR|=(1<<PCIF0);//clear interrupt flag
13
EIMSK|=1<<INT0;//enable INT0
14
15
}
16
}
Das Prooblem bleibt weiterhin bestehen und davon abgesehen stellen sich
mir weitere Fragen:
1. nach dem Reset von PCIFR sollte doch ein Wiederaufruf bis zum
nächsten clk verhindert werden?
2. PCIFR wird laut datenblatt von haus aus mit nullen initialisiert,
kann aber mit einsen resetet werden. müsste bei Programmstart dann nicht
automatisch die ISR aufgerufen werden?
vieleicht weiß ja jemand Rat, ich komme jedenfalls nicht weiter
Grüße
Enrico
Enrico I. schrieb:> Im loop wird anschließend die Richtung bestimmt und es wird vorerst 2> sekunden gewartet damit das clk Signal auf jeden Fall nicht mehr prellt.
Hast du eine ganz grobe Vorstellung davon, wie Prellen und wie
Drehgebersignale auf der Zeitskala aussehen?
Und was soll das für ein clk Signal sein, von dem du sprichst?
nun ja, es gibt 2 zeitlich versetze signale.
von signal a kann man sich die drehrichtung herleiten und signal b kann
man zum einlesen verwenden daher habe ich es clk genannt
was wäre den die korrekte bezeichnung?
Enrico I. schrieb:> von signal a kann man sich die drehrichtung herleiten und signal b kann> man zum einlesen verwenden daher habe ich es clk genannt> was wäre den die korrekte bezeichnung?
Die Signale werden gewöhnlich A/B-Signale genannt und sind völlig
gleichberechtigt. Am Dekodereingang kannst du sie einfach vertauschen,
ohne dass sich an der Funktion irgendetwas grundlegendes ändert.
Enrico I. schrieb:> Die ISR wird jedoch doppelt ausgeführt.
Ja nun, wenn man den falschen Ansatz verfolgt, funktioniert's halt
nicht.
https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29https://www.mikrocontroller.net/articles/Drehgeber
Suche dir für deine Interruptübungen halt eine andere Anwendung, in der
es zu keinem Prellen kommen kann, nicht zu einem Interupt während der
vorherige noch bearbeitet wird, dann hagelt es dir nicht auch gleich
beim Verlassen der Interrupt-Routine den nächsten, gespeicherten rein.
MaWin schrieb:> Ja nun, wenn man den falschen Ansatz verfolgt, funktioniert's halt> nicht.
Da erfindet halt wieder mal einer das Rad, allerdings ein viereckiges,
und dann wundert er sich wenn es holpert. Wahrscheinlich könnte man
alles löschen, was hier jemals über Quadratursignale geschrieben wurde,
es würde nichts ändern.
Georg
Georg schrieb:> Da erfindet halt wieder mal einer das Rad, allerdings ein viereckiges
ehrlich gesagt verstehe ich die aufregung nicht, ich versuche nicht eine
perfekte auswertung zu erreichen.
Ich arbeite das erste mal mit Interrupts und den dazugehörigen Registern
und habe Fragen zu dem verhalten gestellt welches bei mir aufgetreten
ist
ob mein ansatz zur auswertung der signale sinn macht oder nicht ist doch
wohl nebensächlich
MaWin schrieb:> Enrico I. schrieb:>> Die ISR wird jedoch doppelt ausgeführt.>> Ja nun, wenn man den falschen Ansatz verfolgt, funktioniert's halt> nicht.
ob mein ansatz komplett "Falsch" ist kann ich noch nicht beurteilen da
ich noch zu wenig code verglichen habe.
Auf jeden Fall danke für die Links
Enrico I. schrieb:> habe daher> einen Drehgeber
Ist das ein optischer, magnetischer oder mechanischer Drehgeber?
Enrico I. schrieb:> ich versuche nicht eine> perfekte auswertung zu erreichen.
Das hast Du ja schon geschafft ;-)
Georg schrieb:> Wahrscheinlich könnte man> alles löschen, was hier jemals über Quadratursignale geschrieben wurde,> es würde nichts ändern.
Ja - Lesen ist heute nicht mehr "in", man nutzt die
"Schwarmintelligenz". Ob das auf eigene Defizite hindeutet muss sich
jeder selbst beantworten.
Hugo H. schrieb:> Georg schrieb:>> Wahrscheinlich könnte man>> alles löschen, was hier jemals über Quadratursignale geschrieben wurde,>> es würde nichts ändern.>> Ja - Lesen ist heute nicht mehr "in", man nutzt die> "Schwarmintelligenz". Ob das auf eigene Defizite hindeutet muss sich> jeder selbst beantworten.
typisch forum
man stellt eine frage, kriegt erstmal nur hinweise dass das was man vor
hat falsch ist und wird hinterher beleidigt weil man das forum scheinbar
nur dafür nutzen soll um sich mit seinem wissen zu profilieren anstatt
um hilfe zu bitten wenn man mal nicht weiter weiß.
Das eine konstruktive antwort einen akt der selbstlosigkeit darstellt
und ich über jeden ansatz froh sein kann ist klar aber das hier ist doch
lächerlich
ich will doch nur wissen ob ich das datenblatt richtig interpretiere und
das PCIFR Register einfach zurücksetzen kann um ein erneuten interrupt
zu verhindern bzw warum das bei mir nicht funktioniert hat...
Enrico I. schrieb:> Das eine konstruktive antwort einen akt der selbstlosigkeit darstellt> und ich über jeden ansatz froh sein kann ist klar aber das hier ist doch> lächerlich
Lächerlich ist, dass Du nicht mal ansatzweise versuchst, Dich selbst zu
informieren, wie man allgemein damit umgeht. Man kann im großen weiten
Internet und gezielt hier auf viele Hinweise stoßen, wie es gelöst
werden kann. Aber man kann auch einfach irgendetwas ausprobieren und
dann herumfragen, warum es nicht funktioniert.
Enrico I. schrieb:> ich will doch nur wissen ob ich das datenblatt richtig interpretiere und> das PCIFR Register einfach zurücksetzen kann um ein erneuten interrupt> zu verhindern bzw warum das bei mir nicht funktioniert hat...
Auch zum Thema Interrupts gibt es hier informative Artikel, welche man
sich ansehen und deren Code man nachvollziehen kann um die Grundlagen zu
erlernen.
Enrico I. schrieb im Beitrag #6808360:
> es hätte auch ein einfacher schalter sein können.
Selbst das Auslesen eines "einfachen Schalters" muss entprellt erfolgen.
Das ist übrigens ein interessantes Stichwort.
Hugo H. schrieb:> Enrico I. schrieb im Beitrag #6808360:>> es hätte auch ein einfacher schalter sein können.>> Selbst das Auslesen eines "einfachen Schalters" muss entprellt erfolgen.> Das ist übrigens ein interessantes Stichwort.
ist ja scheinbar so als ging es hier mitlerweile um die signal
verarbeitung
also danke
Enrico I. schrieb:> Georg schrieb:>> Da erfindet halt wieder mal einer das Rad, allerdings ein viereckiges>> ehrlich gesagt verstehe ich die aufregung nicht, ich versuche nicht eine> perfekte auswertung zu erreichen.> Ich arbeite das erste mal mit Interrupts und den dazugehörigen Registern> und habe Fragen zu dem verhalten gestellt welches bei mir aufgetreten> ist>> ob mein ansatz zur auswertung der signale sinn macht oder nicht ist doch> wohl nebensächlich
Nein, das ist nicht "nebensächlich".
Denn dein Weg ist ein Irrweg.
Und auf diesem Irrweg muss man keinen bestärken, zudem gibts auch keine
"elegante" oder einfache Lösung.
Wenn es doch unbedingt Interrupts sein müssen, dann werte den Drehgeber
in einem Timer Interrupt aus. Das ist die angemessene Methode für
händisch bediente Encoder.
Tipp:
> Wer in die falsche Richtung läuft,> muss sich nicht beeilen.
Wer die verrückte Idee mit dem Flankeninterrupt in die Welt gebracht
hat, wollte die Menschheit nur ärgern. Milliarden von Benutzern kämpfen
daher täglich mit prellenden Drehgebern.
Hier in der Firma sind alle Kaffeemaschinen, der Generator 33220A und
das Oszi HMO2024 davon betroffen.
Die von mir entwickelten Geräte haben keine Probleme mit Drehgebern
(Abtastung im Timerinterrupt). Sie sind seit 1995 im Einsatz.
c-hater schrieb im Beitrag #6808330:
> das geht auch mit Interrupts, aber nur unter bestimmten Voraussetzungen.> Nämlich: Es müssen für die beiden Kanäle VERSCHIEDENE Interrupts> verwendet werden.> Und natürlich müssen die ISRs für die beiden verwendeten Interrupts> richtig implementiert sein, klar...
Klar. Man kann sich natürlich von hinten durch die Brust ins Auge
schießen. Aber ob man es auch sollte?
Peter D. schrieb:> Wer die verrückte Idee mit dem Flankeninterrupt in die Welt gebracht> hat, wollte die Menschheit nur ärgern
Filter und Entprellschaltungen sind schon erfunden und lassen eine
zuverlässige Auswertung zu. Wer Kontakte, ohne Beschaltung, an MC
Eingänge anschaltet, ist selber Schuld.
Gerald K. schrieb:> Wer Kontakte, ohne Beschaltung, an MC Eingänge anschaltet, ist selber> Schuld.
Im Gegenteil: Er ist kostenbewusst und verlagert Hardware in Software.
Dafür muss man Softwareerstellung aber auch beherrschen und nicht
falschen Grundprinzipien dogmatisch verhaftet bleiben.
Gerald K. schrieb:> Filter und Entprellschaltungen sind schon erfunden und lassen eine> zuverlässige Auswertung zu.
Die Auswertung von Gray-Code BRAUCHT keine Entprellung. Aber das scheint
bei vielen noch nicht angekommen zu sein, obwohl diese Art der Kodierung
inzwischen fast 70 Jahre alt wird.
Wolfgang schrieb:> Die Auswertung von Gray-Code BRAUCHT keine Entprellung. Aber das scheint> bei vielen noch nicht angekommen zu sein, obwohl diese Art der Kodierung> inzwischen fast 70 Jahre alt wird.
Wer halt die korrekte Methode nicht verstanden hat und auf Grund
ideologischer Blockiertheit auch nicht verstehen will, der bleibt auf
ewig doof.
MaWin schrieb:> Wer halt die korrekte Methode nicht verstanden hat
Gottseidank ist das Verständnis von Graycode für den Fortbestand der
Menschheit nicht so entscheidend wie manches andere, sonst sähe es
zappenduster aus. Also entspannt euch, ob der TO sein Problem jemals
begreift ist ziemlich irrelevant.
Georg
Georg schrieb:> Gottseidank ist das Verständnis von Graycode für den Fortbestand der> Menschheit nicht so entscheidend ...
Stimmt, ein Großteil der Menschheit kauft einfach die Geräte, in denen
er verwendet wird und der Rest wird von einigen mehr oder weniger
fähigen Ingenieuren erledigt.
Frank schrieb:> Klar. Man kann sich natürlich von hinten durch die Brust ins Auge> schießen. Aber ob man es auch sollte?
Aber klar, unter den entsprechenden Umständen:
Eindeutige Pro-Indikationen für eine interrupbasierte Lösung sind:
1) Es müssen schnelle Encoder abgefragt werden, ohne dabei dauerhaft
eine hohe Grundlast an Rechenzeit zu erzeugen.
2) Es handelt sich um ein Design, bei dem der minimale Energieverbrauch
eine Rolle spielt.
Eindeutige Contra-Indikationen sind:
1) Es müssen viele (langsame) Encoder abgefragt werden.
c-hater schrieb im Beitrag #6809966:
> Man kann sie nämlich auch situationsabhängig DEAKTVIEREN
Das nützt nichts, wenn man nicht noch einen Timer zusätzlich benutzt.
Denn ohne Timer kann nur ein Interrupt sich selbst sperren und auf den
jeweils anderen warten, einer muss immer aktiv sein, also auf von sussen
eintreffende events reagieren können. Auch damit besteht also die
Möglichkeit, dass der uC zu nichts anderem kommt, als der Abarbeitung
der nicht entprellten Interrupts, und stillsteht.
Und wenn man einen Timer verwendet, nun, dann kann man den ganzen
Scheiss mit den Flankeninterrupts gleich ganz lassen, denn ein Timer
reicht zur Auswertung eines Drehgebers schon alleine ganz aus.
Das verstehst DU jedoch erkennbar überhaupt nicht.
c-hater schrieb:> Eindeutige Pro-Indikationen für eine interrupbasierte Lösung sind:>> Es müssen schnelle Encoder abgefragt werden, ohne dabei dauerhaft eine> hohe Grundlast an Rechenzeit zu erzeugen.>> Es handelt sich um ein Design, bei dem der minimale Energieverbrauch> eine Rolle spielt.
Es gibt kein 'pro' für flankenbasierte Interrupt aus nicht entprellten
Quellen.
Es macht auch keinen Sinn, irgendwelche CPU Last einzusparen, denn wenn
jemand dreht, und das kann ja wohl zu jedem beliebigen Zeitpunkt
erfolgen, muss der uC die ganze Rechenleistung übrig haben, sonst
verpasst er die Drehgeberauswertung.
Zur Energieeinsparung reicht ein Interrupt auf Flankenwechsel beider
Kanäle, der dann nur die stinknormale timerbasierte Graykanalauswertung
anschmeisst bzw. wieder stoppt. Dank Graykanalauswertung muss man dabei
nicht mal beachten, ob ein Prellen auftritt, ob also der dann
eingelesene Portpinzustand mit der Flanke die den Interrupt auslöste
übereinstimmt, sie zählt automatisch richtig.
MaWin schrieb:> c-hater schrieb im Beitrag #6809966:>> Man kann sie nämlich auch situationsabhängig DEAKTVIEREN>> Das nützt nichts, wenn man nicht noch einen Timer zusätzlich benutzt.
Doch, genau das braucht man eben bei einem Quadratur-Encoder nicht zu
tun. Die Sperrung erledigt "timeless" die ISR des eigenen Kanals, die
Freigabe erfolgt genauso "timeless" einzig über die ISR des anderen
Kanals. Das ist der ganze Trick. Und dass der funktioniert, liegt halt
an der grundsätzlichen Funktionsweise so eines Encoders.
Absolut trivial, aber Leute wie du kapieren das nach zwei Jahrzehnten,
entsprechendem Beispielcode und hinreichend Erklärungen dazu immer noch
nicht...
c-hater schrieb:> Eindeutige Pro-Indikationen für eine interrupbasierte Lösung sind:>> 1) Es müssen schnelle Encoder abgefragt werden, ohne dabei dauerhaft> eine hohe Grundlast an Rechenzeit zu erzeugen.
Quatsch. Wenn schnelle Encoder per Software abgefragt werden müssen,
muss die Rechenleistung dafür vorhanden sein. Oder willst du bei schnell
drehenden Encoder alle anderen Aufgaben so lange zurück stellen, bis die
Mimik wieder langsam dreht?
Wolfgang schrieb:> Quatsch. Wenn schnelle Encoder per Software abgefragt werden müssen,> muss die Rechenleistung dafür vorhanden sein.
Das ist völlig unbezweifelbar richtig.
Der Punkt ist hier vor allem: auch wenn sie vorhanden ist (vorhanden
sein muss), ist es extrem SCHWACHSINNIG, sie dauerhaft abzurufen, auch
wenn es in 99% oder mehr der Zeit des Betriebs der Anwendung überhaupt
nicht nötig wäre. Das führt uns im Minimum wieder ein Stück in Richtung
des Entropietods des Unversums. Bei Betrieb aus irgendwas anderem als
dem Stromnetz führt es aber auch unter einem enger gefassten
Betrachtungswinkel dazu, dass die Sache MERKLICH mehr Kosten und
Aufwand verursacht, als nötig wäre. Weil halt Primärzellen dann häufiger
neu gekauft werden müssen und Akkus häufiger geladen werden müssen.
> Oder willst du bei schnell> drehenden Encoder alle anderen Aufgaben so lange zurück stellen, bis die> Mimik wieder langsam dreht?
Das könnte eventuell sogar tatsächlich eine Notlösung für Grenzfälle
sein. Hängt von der Anwendung ab. Strebt man aber natürlich
normalerweise nicht an. Der normalerweise interessante Arbeitsbereich
ist alles darunter. In diesem Bereich wird der Rest nur
seltener/langsamer verarbeitet (worst case berechenbar). Aber dieser
worst case tritt nur dann ein, wenn der Encoder wirklich volle
Schrittrate liefert. Von allem darunter profitiert der Rest unmittelbar,
so er denn Rechenzeit braucht. Er kann dann einfach mehr davon
verwenden.
Ich verstehe überhaupt nicht, wo dein Problem ist. Genau dieser Ansatz,
immer nur das an Rechenzeit zu verbrauchen, was man auch wirklich
benötigt, ist ja z.B. das Grundkonzept aller modernen Betriebssysteme.
Wer das für sinnlos hält, ist definitiv allein deswegen mit einiger
Wahrscheinlichkeit ein VOLLIDIOT, weil alle, die was von der Sache
verstehen, halt dieses Konzept gewählt haben...
c-hater schrieb:> Der Punkt ist hier vor allem: auch wenn sie vorhanden ist (vorhanden> sein muss), ist es extrem SCHWACHSINNIG, sie dauerhaft abzurufen
Bei MCs hängt der Stromverbracuh nicht von der Rechenleistung ab. Dem MC
macht es also überhaupt nichts aus, wenn er permanent rechnet oder nur
ne Endlosschleife dreht.
Ich hab z.B. mit einem AT89C51CC03 2 Positionsgeber (X,Y) im
Timerinterrupt 50kHz abgefragt. Es gingen keine Schritte verloren und
der MC wurde auch nicht heiß. Die anderen Tasks (CAN-Kommunikation usw.)
liefen auch einwandfrei.
Peter D. schrieb:> Bei MCs hängt der Stromverbracuh nicht von der Rechenleistung ab.
Ich finde diese Sichtweise ziemlich eingeschränkt.
Die STM32 nehmen zum Beispiel alle deutlich weniger Strom im WFI (Wait
for Interrupt) Zustand auf, als wenn sie Befehle ausführen.
Stefan ⛄ F. schrieb:> Die STM32 nehmen zum Beispiel alle deutlich weniger Strom im WFI (Wait> for Interrupt) Zustand auf, als wenn sie Befehle ausführen.
Dürfte dem Idle beim AVR entsprechen, da sinkt der Strom natürlich
etwas. Ich benutze bei netzbetriebenen Schaltungen in der Regel aber
keine Stromsparmodi. Ob der MC nun 5mA oder 2mA zieht, fällt gegenüber
den anderen Lasten kaum ins Gewicht. Selbst der Spannnungsregler 7805
verbraucht ja schon 5mA. Am 230V Eingang wird man den Unterschied daher
nicht mehr messen können.
Stromsparmodi zu implementieren und zu testen, kostet weitere
Entwicklungszeit, die der Kunde nicht bezahlen will.
Stefan ⛄ F. schrieb:> Die STM32 nehmen zum Beispiel alle deutlich weniger Strom im WFI (Wait> for Interrupt) Zustand auf, als wenn sie Befehle ausführen.
Spielt nur im Batteriebetrieb eine Rolle. Bei Netzversorgung geht der
Unterschied in der Stromaufnahme im Rauschen unter.
Bei Batteriebetrieb braucht man aber meistens ein Display, möglichst LCD
Glas und schon hast du wieder einen 2ms Takt. Also nix gespart.
c-hater versucht jeden Strohhalm um seine desolate Lösung irgendwie
aufrechtzuerhalten, aber es ist alles vergeblich. Selbst wenn man die
Drehgeberauswertung erst startet wenn ein PinChange vom Drehgeber oder
Tastatur kommt (und dann zeitig wieder schlafen legt), wertet man sie
doch klüger per state machine im Timertick aus. Dann stimmt wenigstens
das Ergebnis.
Auch dass eine interrupt-gesteuerte Version schneller sein soll, wurde
schon längst widerlegt, 1 Mio Striche/Sekunde an 4 Drehgebern
gleichzeitig sind an einem 16 MHz AVR möglich per polling, no chance das
per Interrupt zu schaffen, da ist schon der Interrupt-overhead höher.
MaWin schrieb:> Auch dass eine interrupt-gesteuerte Version schneller sein soll, wurde> schon längst widerlegt, 1 Mio Striche/Sekunde an 4 Drehgebern> gleichzeitig sind an einem 16 MHz AVR möglich per polling, no chance das> per Interrupt zu schaffen, da ist schon der Interrupt-overhead höher.
Jetzt kommt dieser Blödsinn wieder! Aber manche begreifen es eben nie
;-)
Enrico I. schrieb:> typisch forum>> man stellt eine frage, kriegt erstmal nur hinweise dass das was man vor> hat falsch ist und wird hinterher beleidigt weil man das forum scheinbar> nur dafür nutzen soll um sich mit seinem wissen zu profilieren anstatt> um hilfe zu bitten wenn man mal nicht weiter weiß.
Ähem...
Also zum einen: Du stellst dich hier ausgesprochen 'wittfleudig' an und
zu anderen verrätst du mit keinem Wort, was du da treibst. Und dann
wirst du obendrein auch noch ungehalten, wenn die anderen auf deine
Einlassungen irgendwann mal genervt reagieren.
Also: So ein typischer Drehgeber für die Frontplatte eines Radios o.ä.
hat 3 Dinge: 2 Kontakte, die man durch Drehen am Stiel öffnen und
schließen kann und obendrein auch noch eine Rastung, die ist nur etwas
Mechanisches.
Die beiden Kontakte öffnen und schließen versetzt ( idealerweise um die
Hälfte versetzt, das kann aber konstruktiv und/oder verschleißbedingt
anders sein ) und damit erhält man bei jedem Zustandswechsel des einen
Signals durch Betrachten des anderen Signals die Richtungsinformation.
Rein elektrisch ist es schnurz, welches Signal man für den o.g.
Zustandswechsel benutzt. Aber diese Rechnung ist ohne die mechanische
Rastung gemacht. In der Realität tut man besser, sich das Signal als
Zustandswechsel-Signal auszusuchen, was möglichst fern der Rastung
seinen Zustand wechselt.
Wenn du nun Signale hast, die bereits prellfrei sind, dann ist die
Auswertung kein Problem: das 'Zustandaswechsel'-Signal triggert mit
jeder Flanke einen Interrupt und dieser liest beide Signale und
verknüpft sie per XOR. Das Ergebnis ist die Richtungsinformation. Das
Auslesen beider Signale möglichst zeitnah an der triggernden Flanke ist
esseziell, denn je länger man wartet, desto wahrscheinlicher ist es, daß
das andere (nacheilende) Signal bereits beim Umschalten ist.
So. Was dir bleibt, ist die Arbeit, deine beiden Signale ausreichend
prellfrei zu kriegen und die Arbeit, dir einen Interrupt zu
programmieren, der auf beide Flanken gleichermaßen reagiert.
Und jetzt mache es und jammere nicht.
W.S.
Peter D. schrieb:> Bei MCs hängt der Stromverbracuh nicht von der Rechenleistung ab.
Natürlich tut er das. Man muß die nur richtig programmieren. Also:
pennen schicken, wann immer es nicht wirklich etwas zu tun gibt.
MaWin schrieb:> Spielt nur im Batteriebetrieb eine Rolle. Bei Netzversorgung geht der> Unterschied in der Stromaufnahme im Rauschen unter.
Ja klar, solche fähigen Programmierer wie du kommen natürlich zu solchen
Ergebnissen. Aber betrachte das mal bei Anwendungen, die konsequent
nicht pollen und die MCU immer schlafen legen, wann immer es möglich
ist. Dann sieht das gleich GANZ anders aus. Für 99.999999% aller
existierenden µC Anwendungen. Naja, es könnte zumindest so aussehen,
wenn sie halt nicht von Programmierern stammen würden, wie du es einer
bist...
> Bei Batteriebetrieb braucht man aber meistens ein Display, möglichst LCD> Glas und schon hast du wieder einen 2ms Takt. Also nix gespart.
Häh? 2ms? Und in diesem Intervall müssen ein paar Ports togglen? Das
kann man typisch in n µs (u.U. sogar ns) tun. Und dann den µC 2000-n µs
(wenn sonst nix anliegt) pennen schicken. Typisch also >>99% der Zeit.
Also ich jedenfalls kann das tun (und mache es in etlichen Anwendungen
genau so), du nicht?
> c-hater versucht jeden Strohhalm um seine desolate Lösung irgendwie> aufrechtzuerhalten
Das ist deine, ganz offensichtlich heftig beschränkte, Sicht der Dinge.
Du musstest nun schon zugeben, dass es (also interruptbasierte Abfrage
von Quadraturencodern) prinzipiell funktioniert. Hast du nur nicht offen
und ehrlich zugegeben, dazu fehlen dir wohl die cojones.
Aber indirekt hast du es DOCH getan, indem du nämlich jetzt anfängst,
die daraus erwachsenden Vorteile nieder zu diskutieren. Wenn du
weiterhin der Meinung währst, das es grundsätzlich nicht geht und nicht
gehen kann, wäre das doch völlig überflüssig, das sagen die Gesetze der
Logik...
W.S. schrieb:> Also: So ein typischer Drehgeber für die Frontplatte eines Radios o.ä.> hat 3 Dinge: 2 Kontakte, die man durch Drehen am Stiel öffnen und> schließen kann und obendrein auch noch eine Rastung, die ist nur etwas> Mechanisches.
Die prellen und kratzen....
Wie der Zufall es will, trotz allem Unken "Das brauchts dank Gray nicht"
spuckt mir der Drehencoder meines Korad LNTs, einige Dutzend gültige
Sequenzen raus, so das die Spannung nicht wie gewollt um 0,1V steigt,
sondern gleich mal um einige Volt nach oben springt....
Meine billigen Restposten ALPS, tun auch erst zuverlässig ab ~1mA. Also
nix für Batterie und Interrupt.
Mein unprofessionelles Fazit, als Anwender und Hobbybastler: Ich mach
nich mehr ohne 1mA und SW-Entprellung.
Da taugt der Interrupt höchstens noch zum aufwecken aber was will man
bei 1-2mA "Grundlast" schon noch aufwecken. Wie viel Strom zum Schalten,
gönnt Ihr den eurem Drehgebern?! :)
Ach so ja, die putzen sich ja alleinig schon durchs Schleifen der
Kontakte. Das müssen also alles SW Fehler sein.....
c-hater schrieb:> Wenn du weiterhin der Meinung währst, das es grundsätzlich nicht geht> und nicht gehen kann, wäre das doch völlig überflüssig, das sagen die> Gesetze der Logik...
Niemand hat gesagt das es nicht geht. Nur das es nicht sinnvoll ist.
c-hater schrieb:> Du musstest nun schon zugeben, dass es (also interruptbasierte Abfrage> von Quadraturencodern) prinzipiell funktioniert. Hast du nur nicht offen> und ehrlich zugegeben, dazu fehlen dir wohl die cojones.
Hast Du zufällig mal etwas für ELV entwickelt? FHT80b oder PPS 5330?
c-hater schrieb:> Du musstest nun schon zugeben, dass es (also interruptbasierte Abfrage> von Quadraturencodern) prinzipiell funktioniert
Falsch.
c-hater schrieb:> Aber indirekt hast du es DOCH getan, indem du nämlich jetzt anfängst,> die daraus erwachsenden Vorteile nieder zu diskutieren
Falsch.
c-hater schrieb:> Wenn du weiterhin der Meinung währst, das es grundsätzlich nicht geht> und nicht gehen kann, wäre das doch völlig überflüssig, das sagen die> Gesetze der Logik...
Falsch.
Deine interruptbasierte Variante hat mehrere Defizite und zählt dann
falsch.
Was bei einem sauberen nicht prellenden Drehencoder im Test auf dem
Schreibtisch noch funktioniert, wird dann in der Praxis nach Jahren der
Benutzung mit schlechter werdenden Kontakten zu den Kunden störenden
Fehlfunktionen neigen.
Es sei allerdings nicht verschwiegen, dass auch die richtige Methode der
pollenden Drehgeberauswertung ihre Probleme hat, wenn Kontakte nicht nur
mehr an Übergängen prellen, sondern die ganze Zeit beim rutschen über
die Kontaktfläche (und Staub bzw. Oxidstellen) zu kurzen Aussetzern
neigen. Da ist ein Kondensator am Kontakt, der über den pull up
aufgeladen wird, notwendig. Software alleine hilft da nicht mehr. Die
korrekte Art der Drehgeberauswertung weist aber immerhin auf das Problem
hin in dem die state machine einen ungultigen Zustandswechsel erkennt.
c-hater schrieb:> Du musstest nun schon zugeben, dass es (also interruptbasierte Abfrage> von Quadraturencodern) prinzipiell funktioniert
Falsch.
c-hater schrieb:> Aber indirekt hast du es DOCH getan, indem du nämlich jetzt anfängst,> die daraus erwachsenden Vorteile nieder zu diskutieren
Falsch.
c-hater schrieb:> Wenn du weiterhin der Meinung währst, das es grundsätzlich nicht geht> und nicht gehen kann, wäre das doch völlig überflüssig, das sagen die> Gesetze der Logik...
Falsch.
Deine interruptbasierte Variante hat mehrere Defizite und zählt dann
falsch.
Was bei einem sauberen nicht prellenden Drehencoder im Test auf dem
Schreibtisch noch funktioniert, wird dann in der Praxis nach Jahren der
Benutzung mit schlechter werdenden Kontakten zu den Kunden störenden
Fehlfunktionen neigen.
Es gibt keine Vorteile in deiner Methode. Sie wertet im Gegensatz zu
deiner Behauptung langsamer aus, sie lässt sich leichter stören und
zählt dann falsch, sie bremst den uC stärker aus wenn pinChanges durch
Prellen viel öfter vorkommen als reale Zustandswechsel und kostet
dadurch auch noch mehr Strom als ein timerinterruptbasiertes pollen. Und
der einzige Vorteil, sie lässt den uC schlafen wenn keiner am Knopf
dreht, funktioniert genau so mit der polling Methode wenn man sie bei
pinChange startet.
Es sei allerdings nicht verschwiegen, dass auch die richtige Methode der
pollenden Drehgeberauswertung ihre Probleme hat, wenn Kontakte nicht nur
mehr an Übergängen prellen, sondern die ganze Zeit beim rutschen über
die Kontaktfläche (und Staub bzw. Oxidstellen) zu kurzen Aussetzern
neigen. Da ist ein Kondensator am Kontakt, der über den pull up
aufgeladen wird, notwendig. Software alleine hilft da nicht mehr. Die
korrekte Art der Drehgeberauswertung weist aber immerhin auf das Problem
hin in dem die state machine einen ungultigen Zustandswechsel erkennt.
MaWin schrieb:> Es gibt keine Vorteile in deiner Methode. Sie wertet im Gegensatz zu> deiner Behauptung langsamer aus, sie lässt sich leichter stören und> zählt dann falsch, sie bremst den uC stärker aus wenn pinChanges durch> Prellen viel öfter vorkommen als reale Zustandswechsel und kostet> dadurch auch noch mehr Strom als ein timerinterruptbasiertes pollen.
c-hater hat leider in keinem einzigen Beitrag "sein Verfahren"
zusammenhängend dargestellt, sondern immer nur Brotkrümel hingeworfen.
Um ihn zu verstehen, musste ich mir das Verständnis aus mehreren seiner
Beiträge erst zusammenklauben.
Wenn ich ihn richtig verstehe, meint er folgendes:
1
1. PCINT Enable auf Pin A
2
2. Wenn INT auf Pin A, dann:
3
3. PCINT Disable auf Pin A
4
4. Hole Zustand von Pin B
5
5. PCINT Enable auf Pin B
6
6. Wenn INT auf Pin B, dann:
7
7. PCINT Disable auf Pin B
8
8. Hole Zustand von Pin A
9
9. Weiter bei 1.
Dadurch, dass er zwei Interrupts abwechselnd benutzt (Pin/Kanal A und
B) und immer dann, wenn ein Interrupt erfolgt, diesen anschließend
sofort sperrt, lässt den µC ein Prellen kalt: Es erfolgt ja kein
Interrupt mehr auf demselben Pin, nur im folgenden auf dem anderen.
Von daher ist die Kritik im Artikel Drehgeber bezüglich
Interrupt-Lösungen für c-haters Verfahren nicht zutreffend. Ein
"Pendeln" sollte hier kein Problem darstellen. Ebenso halbiert sich
nicht die Auflösung, da A und B vollkommen symmetrisch ausgewertet
werden.
Es kann auch sein, dass ich ihn komplett falsch verstanden habe. Leider
hat er sein Verfahren selbst überhaupt nicht im Zusammenhang erklärt.
Ich selbst habe auch mit Drehencodern noch nicht rumgespielt, habe daher
keine Erfahrung damit.
Hallo Enrico I.
ich habe gerade mal den ganzen Verlauf schnell mal überflogen.
Also nicht alles gelesen...
Ich benutze auch einen solchen Encoder für meine CNC.
Bei mir funtkioniert es sauber.
Meine Frage ist, wie hast du deinen Interrupt eingestellt??
Steigende Flanke, fallende Flanke oder wie ich vermute
Beide Flanken ???
Deshalb der doppelte Auslöser...
Gruß Thomas
Thomas schrieb:> ich habe gerade mal den ganzen Verlauf schnell mal überflogen.
Merkt man.
> Deshalb der doppelte Auslöser...
Das Thema "Prellen" hast Du hier leider komplett ignoriert.
Frank M. schrieb:> Dadurch, dass er zwei Interrupts abwechselnd benutzt (Pin/Kanal A und> B) und immer dann, wenn ein Interrupt erfolgt, diesen anschließend> sofort sperrt, lässt den µC ein Prellen kalt: Es erfolgt ja kein> Interrupt mehr auf demselben Pin, nur im folgenden auf dem anderen.
Ja schon aber so zählt er trotzdem ins Nirwana, wenn die Kontakte
kratzen.
Da jetzt noch SW zum Endprellen/Fehlererkennung dran dröseln lohnt doch
nich, da polle ich doch lieber gleich.
Wie MaWin schon erwähnte, selbst meine hingefrickelte SW-Entprellung,
dämpft das Problem nur, beseitigt es aber nicht. Das nur per SW zu
machen wird sicher nich ohne, da löt ich mir dann doch lieber noch ein
paar Bauteile extra dran. :)
Also, nich das ich das für meine Privaten Projekt, für nötig erachte!
Teo schrieb:> Ja schon aber so zählt er trotzdem ins Nirwana, wenn die Kontakte> kratzen.
Kannst Du das bitte näher erläutern? Wenn ein Kontakt "kratzt" passiert
doch exakt gar nichts, da der Interrupt bereits nach der ersten Flanke
deaktiviert worden ist?
Frank M. schrieb:> Wenn ich ihn richtig verstehe, meint er folgendes:> 1. PCINT Enable auf Pin A> 2. Wenn INT auf Pin A, dann:> 3. PCINT Disable auf Pin A> 4. Hole Zustand von Pin B> 5. PCINT Enable auf Pin B> 6. Wenn INT auf Pin B, dann:> 7. PCINT Disable auf Pin B> 8. Hole Zustand von Pin A> 9. Weiter bei 1.
Nun dreht man vorwärts und dann rückwärts:
1
R: vorwärts | rückwarts
2
A: 001111000|000111100
3
B: 111100000|000001111
4
zahlt er
5
D: 00+0+0+00|00000-0-0
also in der Summe +3 -2 um 1 falsch.
[Mod: Formatierung angepasst für Ansicht mit Proportionalschrift]
Frank M. schrieb:> Kannst Du das bitte näher erläutern? Wenn ein Kontakt "kratzt" passiert> doch exakt gar nichts, da der Interrupt bereits nach der ersten Flanke> deaktiviert worden ist?
Und wann wird der andere aktiviert?!
Prellen und Kratzen treten immer auf beiden Kanälen gleichzeitig auf!
Das is dann wie Lotto spielen. Nur mit Interrupt(s) zählst du da jeden
Treffer, beim pollen nur jeden x-ten.
Bei mir geht das sofort ins die Tonne (wird verworfen), wenn da ein
anderes Muster als erwartet auftaucht. Funst scheinbar ganz gut. ;)
MaWin schrieb:> also in der Summe +3 -2 um 1 falsch.
Ja, das kann ich nachvollziehen. Dann muss das c-hater mal erklären, wie
das funktionieren kann.
Teo D. schrieb:> Prellen und Kratzen treten immer auf beiden Kanälen gleichzeitig auf!
Okay, ich dachte, dass bei Drehgebern immer nur ein Kanal prellen kann,
nämlich der, wo gerade ein gewollter Pegelwechsel auftritt. Das war wohl
ein Fehlschluss. "Kratzen" an sich hatte ich ausgeschlossen, da ich mal
irgendwo gelesen hatte, dass hier jeweils 2 Kontakspuren verwendet
werden, also eine Art "Doppelfinger" pro Schleifer. Kann auch sein, dass
ich mich hier irre.
Nicht, dass man mich falsch versteht: Ich selbst bin bei mechanischen
Kontakten auch kein Freund von Interrupts und benutze daher stehts
Polling. Ich wollte nur verstehen, ob und was hinter dem "Verfahren von
c-hater" wirklich steckt.
Frank M. schrieb:> aber wie wahrscheinlich ist das dann noch?
Die Wahrscheinlichkeit ist gruselig hoch.
Mit zunehmendem Alter immer gruseliger.
Was sich die Hardware an Schwäche leistet, muss man irgendwie ausbügeln.
Denn:
Jede Fehlfunktion nervt.
Der Benutzer erwartet eine korrekte reproduzierbare Funktionalität, und
keine willkürlichen Hüpfer.
Frank M. schrieb:> Klar, ganz ausgeschlossen wird ein "Kratzen" damit nicht, aber wie> wahrscheinlich ist das dann noch?
Wahrscheinlicher als ich ursprünglich dachte, nur wie bereits erwähnt,
hat mich dann der Spannungssprung von 5V auf ~16V (0,1V Schritt), dann
doch etwas stutzig gemacht. #-/ Als dann mein viel bekurbelter
Test-Drehencoder fürs Breadboard zu spinnen begann, hab ich erst mal mit
dem Frittstrom experimentiert. Weil das hatte nur 0,5mA und da ich mir
hierüber noch nie wirklich Gedanken gemacht hatte.... Also 3mA gegönnt
und sie da, es bringt wirklich was. 8-O
Aber das alleine wars dann doch nich (was mich nicht erstaunt), also per
SW noch entprellt. Juhu, nu tut er's wieder.
Haja, alle Drehencoder für die Finger, die ich bisher zerlegt gesehen
habe hatten min. zwei Zungen pro Kontakt. Halbiert aber das Problem nur.
Frank M. schrieb:> Kannst Du das bitte näher erläutern? Wenn ein Kontakt "kratzt" passiert> doch exakt gar nichts, da der Interrupt bereits nach der ersten Flanke> deaktiviert worden ist?
Bei den gebräuchlichsten billigen Drehgebern stecken keine
Schleifkontakte drin, sondern ein gedelltes Plastikrad, was auf zwei
Büchsenblech-Streifen drückt und damit sowohl die Kontaktgaben als auch
die mechanische Rastung erledigt. Sparsam eben. Die Dinger sollen in der
Herstellung möglichst garnix kosten.
Zwei sich gegenseitig verriegelnde Interrupts halte ich für nicht
wirklich betriebssicher, denn das kommt irgendwann außer Tritt.
Obendrein hätte man bei dem Kanal, der im oder ganz nahe dem Rastpunkt
schaltet, ein Problem mit einem sinnlosen Gewitter von Interrupts. Also
besser nur ein Interrupt und zwar auf dem "zuverlässigeren" Kanal, dafür
aber auf beide Flanken.
Nochwas: Wenn man schon voraussetzt, daß die Kontakte dank fehlender
Entprellung prellen, dann ist das Pollen unzuverlässiger als das
Benutzen der Interrupts, denn der Zustand des zweiten Signals sollte
möglichst zeitnah zum Umschalten des ersten Signals erfaßt werden, sonst
ist die Richtungsfindung nicht mehr zuverlässig möglich. Also wenn
pollen, dann in sehr kurzen Zeitabständen, was Rechenzeit und ggf. Strom
kostet. Soviel zu den vollmundigen Äußerungen von Mawin.
W.S.
W.S. schrieb:> denn der Zustand des zweiten Signals sollte> möglichst zeitnah zum Umschalten des ersten Signals erfaßt werden
Was??? Vollverpeilt?! Jeder sollte wissen, dass dies entweder
gleichzeitig (ein Port) geschieht oder mit 2-4 Maschinenzyklen abgetan
ist! 8-O
Teo D. schrieb:> Was??? Vollverpeilt?!
Nö, sondern bei Polling durchaus drin, wenn das Lesen der beiden Kanäle
mal zu spät kommt (von der tatsächlichen Flanke aus gesehen).
W.S.
W.S. schrieb:> denn der Zustand des zweiten Signals sollte> möglichst zeitnah zum Umschalten des ersten Signals erfaßt werden
Ha jetzt versteh ich dich. Nur ist das völliger Blödsinn. Der exakte
Augenblick, wann der Mechanische-Kontakt erfolgt, ist sowas von
unwichtig, ja kontraproduktiv, da zu diesem Zeitpunkt das blöde Ding ja
nicht nur Kratzt sonder eben gerade dann auch prellt..... OK, 'ich'
umgeh das zwar nur rein zufällig, aber immer hin. :)
Frank M. schrieb:> Ja, das kann ich nachvollziehen. Dann muss das c-hater mal erklären, wie> das funktionieren kann.
Das ist nur ein Scheinproblem: bei Wiederholung kann sich das nicht
summieren.
Wer sich daran stört kann zusätzlich zum Zahlstand auch den aktuellen
Wert des prellenden Bits auswerten. Notwendig ist das nicht.
Der erste hier, der auf Gray hinwies und das dafür keine Entprellung
notwendig ist, war m.E.
Wolfgang schrieb:> Die Auswertung von Gray-Code BRAUCHT keine Entprellung.
C-hater hat es eher nur das wie erklärt.
Edit: sorry, war wohl doch c-hater eher. Gelöscht?
c-hater schrieb:> Ja klar, solche fähigen Programmierer wie du kommen natürlich zu solchen> Ergebnissen. Aber betrachte das mal bei Anwendungen, die konsequent> nicht pollen und die MCU immer schlafen legen, wann immer es möglich> ist. Dann sieht das gleich GANZ anders aus. Für 99.999999% aller> existierenden µC Anwendungen. Naja, es könnte zumindest so aussehen,> wenn sie halt nicht von Programmierern stammen würden, wie du es einer> bist...
Absolut hirnloser Kommentar. Bei einem STM32F103 z.B. ist der
Unterschied im Stromverbrauch vom Run zum Sleep-Modus nicht mal Faktor
2. Spätestens wenn das Gerät noch was anderes ausser den µC enthält,
wird das auch mehr oder weniger Strom verbrauchen. Damit verringert sich
die Wirksamkeit des Sleep-Modus noch weiter wenn man die
Gesamtenergiebilanz betrachtet.
Das weiteren wird ja wohl kaum ein Gerät nur aus einen oder zwei
Drehgebern bestehen. Und wenn ja haben sie oft auch noch einen Kontakt
beim Drücken. Spätestens wenn da die Interruptjongleure ala c-hater zur
Hochform auflaufen wird das Chaos perfekt.
In meinen Augen gibt es absolut keinen einzigen Grund der bei der
Auswertung mechanisch betätigter Schalter/Drehgeber u.s.w. für
Flankeninterrupts spricht. Dafür ist Polling das Mittel der Wahl und
solange das nur ein paar wenige Eingänge sind, wird sich die CPU auch
weiter 99% im Sleep-Modus befinden, selbst bei Polling-Raten von 1ms.
temp schrieb:> In meinen Augen gibt es absolut keinen einzigen Grund der bei der> Auswertung mechanisch betätigter Schalter/Drehgeber u.s.w. für> Flankeninterrupts spricht.
Doch: Geplante Obsoleszenz. Wenn die Drehgeber nach ein paar Jahren
labbrig werden und der Stellwert dank falscher Flankenauswertung nur
noch wild in der Gegend herumspringt fliegt das Gerät auf den Schrott
(dem Entwickler um die Ohren hauen geht ja leider meist nicht) und ein
Neues wird gekauft.
EAF schrieb:> Der hat solche Decoder in der Timer Hardware.> Da wird man das nicht in Software abhandeln.
Das ist auch Schwachsinn in Bezug auf mechanische Drehgeber. Und wenn es
ein paar mehr werden ist sowieso Multiplexing angesagt, schon allein um
Verdrahtungsaufwand zu sparen. Den Code dafür hat man einmal in der
Schublade und ist auf allen denkbaren Controllern lauffähig (bis auf die
Initialisierung der Pins).
Frank M. schrieb:> Um ihn zu verstehen, musste ich mir das Verständnis aus mehreren seiner> Beiträge erst zusammenklauben.
Naja, dann hast du das richtige Posting nicht auf Anhieb gefunden. Ich
habe es allerdings auch nicht gefunden. Es gibt so unzählige voluminöse
Threads zu dem Thema, dass das keine leichte Aufgabe ist. Zumal mit der
lausigen Suchfunktionalität der Board-Software.
> Wenn ich ihn richtig verstehe, meint er folgendes:>
1
> 1. PCINT Enable auf Pin A
2
> 2. Wenn INT auf Pin A, dann:
3
> 3. PCINT Disable auf Pin A
4
> 4. Hole Zustand von Pin B
5
> 5. PCINT Enable auf Pin B
6
> 6. Wenn INT auf Pin B, dann:
7
> 7. PCINT Disable auf Pin B
8
> 8. Hole Zustand von Pin A
9
> 9. Weiter bei 1.
10
>
Ja, genau das ist es. Es fehlt eigentlich nur die "start condition". Das
ist der einzige Zeitpunkt, zu dem beide Interrupts "scharf" sind. Sobald
einer davon erstmals ausgelöst wurde, ergibt sich dann die von dir
beschriebene "Schleife" des Zustandsautomaten, der keiner zusätzlichen
(rechenzeitkostenden) Verwaltung bedarf, sondern mit dem
Enable/Disable-Gedöhns für die Interrupts bereits vollständig
abgehandelt ist.
Und wenn man Pedas Code genau analysiert, stellt man fest, dass er im
Prinzip exakt dasselbe tut, was ich in der Interruptvariante mit der
gegenseitigen Entriegelung der Interrupts tue (was kein Wunder ist, da
er ja natürlich sinnvollerweise genauso die grundlegende Eigenschaft so
eines Quadraturencoders benutzt, statt idiotisch irgendwelche Kontakte
zeitabhängig zu entprellen).
Das ist, was all diese Programmiererluschen mit MaWin an der Spitze
scheinbar einfach nicht zu begreifen in der Lage sind...
c-hater schrieb:> Ja, genau das ist es. Es fehlt eigentlich nur die "start condition". Das> ist der einzige Zeitpunkt, zu dem beide Interrupts "scharf" sind. Sobald> einer davon erstmals ausgelöst wurde, ergibt sich dann die von dir> beschriebene "Schleife" des Zustandsautomaten, der keiner zusätzlichen> (rechenzeitkostenden) Verwaltung bedarf, sondern mit dem> Enable/Disable-Gedöhns für die Interrupts bereits vollständig> abgehandelt ist.
Kannst Du das an dieser Stelle vielleicht mal allgemeinverständlich - in
Pseudo-Code oder irgendwelchem Code - darstellen? Generationen von
Code-Erzeugern werden es Dir ggf. danken.
In keinem der von mir verlinkten Threads wird irgendetwas konkretes
sichtbar - ob Du es so willst oder es schlicht nicht kannst bleibt
offen.
Du gehörst ja sicher nicht zu den
c-hater schrieb:> Programmiererluschen mit MaWin an der Spitze
Hugo H. schrieb:> Kannst Du das an dieser Stelle vielleicht mal allgemeinverständlich - in> Pseudo-Code oder irgendwelchem Code - darstellen?
Nun ich könnte den Asm-Quelltext raussuchen, den ich irgendwann schonmal
geposted habe (welchselbiges Posting ich aber leider nicht finden kann,
sonst würde ich einfach einen Link darauf posten) und den erneut posten.
Würde dir das weiter helfen? Oder kannst du kein Assembler? Dann kann
ich mir die Mühe sparen.
c-hater schrieb:> Nun ich könnte den Asm-Quelltext raussuchen, den ich irgendwann schonmal> geposted habe
Ja, das wäre durchaus hilfreich ...
Hugo H. schrieb:> Kannst Du das an dieser Stelle vielleicht mal allgemeinverständlich - in> Pseudo-Code oder irgendwelchem Code - darstellen?
Hugo H. schrieb:> Generationen von> Code-Erzeugern werden es Dir ggf. danken.
Aber nicht hier im Forum, da erntet er höchstens grenzenloses Mobbing -
es gilt je richtiger desto mob.
Georg
Georg schrieb:> Hugo H. schrieb:>> Generationen von>> Code-Erzeugern werden es Dir ggf. danken.>> Aber nicht hier im Forum, da erntet er höchstens grenzenloses Mobbing -> es gilt je richtiger desto mob.>> Georg
Störe Dich bitte nicht an solchen "Gästen" ... uninteressant.
Hugo H. schrieb:> c-hater schrieb:>> Nun ich könnte den Asm-Quelltext raussuchen, den ich irgendwann schonmal>> geposted habe>> Ja, das wäre durchaus hilfreich ...
Nun, ich habe ihn nicht finden können, auch nicht in meiner eigenen
Ablage. Aber da ich bei dem Projekt, mit dem ich aktuell zugange bin,
sowieso mal wegen einer gewissen geistigen Verknotung eine kleine
Aus-Zeit benötigt habe und obendrein richtig Lust dazu hatte, mal wieder
was für AVR8 zu schreiben, habe ich die Sache einfach mal from scratch
neu programmiert. Das Ergebnis dürfte mit einiger Wahrscheinlichkeit
etwas schöner und universeller einsetzbar sein als der damaligen Code.
Sicher weiss ich es nicht, weil der ja leider nicht auffindbar ist.
Der aktuelle Code ist jedenfalls nahezu gnadenlos auf Speed optimiert.
Die einige Ausnahme ist die Benutzung eines Common-Teils für die beiden
ISRs. Das spart 22 Bytes Codespace, führt aber dafür für eine
Zählrichtung 2 Straftakte ein. Wenn das stört, kann man es leicht
ändern.
c-hater schrieb:> Der aktuelle Code ist jedenfalls nahezu gnadenlos auf Speed optimiert.
Mist, aber die Sachen mit den konfigurierbaren Pullups war nur zur
Hälfte eingebaut.
Hier also die korrigierte Fassung...
m.n. schrieb:> Das ist optimaler Code, um Leute von Assembler fernzuhalten.
Egal, es gibt in diesem Forum genau eine Person, die noch freiwillig
(mehr als unbedingt nötig) in Assembler programmiert. Und die findet den
Code super.
Also ist die gesamte Zielgruppe hoch zufrieden gestellt.
Stefan ⛄ F. schrieb:> Egal, es gibt in diesem Forum genau eine Person, die noch freiwillig> (mehr als unbedingt nötig) in Assembler programmiert.
Nein, sicher nicht. Mindestens gibt es da noch einen, der recht
regelmäßig entprechende Ambitionen verkündet.
Und es gibt offensichtlich noch eine große, mittlerweile einfachn ur
noch genervt schweigende Menge von Leuten, die es leid sind, sich für
die Verwendung von Asm vor den Nicht-Asm-fähigen Vollidioten
rechtfertigen zu müssen, aber weiterhin Asm verwenden.
Außerdem: wenn dich die Asm-Umsetzung stört: Niemand hindert dich daran,
das in fluffiges Idioten-C oder meinetwegen sogar Arduidioten-C++ zu
verwandeln. Das Ergebnis wird NATÜRLICH sehr viel schlechtere
Laufzeiteigenschaften haben, als der Assemblercode. Aber er wird auch
dann funktionieren. Mit den entsprechenden Abstrichen bei der möglichen
Performance...
Es ging im Kern nur darum, zu zeigen, dass es prinzipiell geht.
c-hater schrieb:> wenn dich die Asm-Umsetzung stört
Tut sie nicht, mach nur weiter. Ich wollte nur andeuten, dass du dazu
nur wenig Feedback erwarten kannst.
c-hater schrieb:> Was genau gefällt dir daran denn nicht?
Viel zu viele Bäume und kein Wald zu sehen.
Anstatt einer universellen Version wäre ein Version mit festem Port und
festen IO-Pins für das Verständnis hilfreicher. Es fehlen die
notwendigen Kommentare zum Code.
So wirst Du keine "Oberpoller" bekehren können - Programmierneulinge
schon garnicht.
Wer diese Routinen in seinen C-Quellcode einbetten will, wird daran
scheitern, daß die verwendeten Register nicht reserviert sind. IAR
könnte das zwar, ist hier aber nicht beliebt. In diesem Punkt ist es
dann doch keine universelle Programmierung, sondern zwangsläufig daran
gebunden, alles in Assembler zu machen.
Eine langsamere, abgekapselte Version mit PUSHs und POPs könnte besser
in C-Programme eingebunden und dann direkt mit anderen Auswerteverfahren
verglichen werden.
m.n. schrieb:> Viel zu viele Bäume und kein Wald zu sehen.
Der Code ist aber doch SEHR überschaubar. Wer das nicht lesen kann,
der ist kein Programmierer.
> Anstatt einer universellen Version wäre ein Version mit festem Port und> festen IO-Pins für das Verständnis hilfreicher.
Kann sich doch jeder leicht soweit runterbrechen?!
> Es fehlen die> notwendigen Kommentare zum Code.
Höchstens in den ISRs und nur außerhalb dessen, was das Grundkonzept
ausmacht, um das es ging, von dem halt einige Idioten behauptet haben,
dass es nicht funktionieren kann. Das Grundkonzept wurde unzählige Male
kommentiert, zuletzt recht ordentlich hier:
Beitrag "Re: Drehgeber an Arduino, external interrupt ISR wird doppelt ausgeführt"
Also, nichtmal von mir selber. Das zeigt im Minimum: es gibt da
tatsächlich durchaus Programmierer, die in der Lage sind, es zu
verstehen...
> So wirst Du keine "Oberpoller" bekehren können
Naja. Will ich eigentlich auch nicht. Die sind eh' verloren. Haben nie
gelernt, wie man "ereignisorientiert" programmiert. Sind in
Kontrollstrukturen in main() gefangen. Armes, bemitleidenswertes Pack.
> Wer diese Routinen in seinen C-Quellcode einbetten will, wird daran> scheitern, daß die verwendeten Register nicht reserviert sind.
Was interessiert mich das Elend von C-Only-Programierern? Und: natürlich
ist es kein Problem, die reservierten Register los zu werden. Mit den
entsprechenden Einbußen bei der möglichen Performance natürlich...
c-hater schrieb:> Hier also die korrigierte Fassung...
Herzlichen Dank - werde ich in Ruhe anschauen und überdenken. Dauert
vermutlich etwas ... :-), da ich noch berufstätig bin.
Hugo H. schrieb:> Herzlichen Dank - werde ich in Ruhe anschauen und überdenken. Dauert> vermutlich etwas ... :-), da ich noch berufstätig bin.
Wie ich auch. Deswegen hat auch die Lieferung etwas gedauert...
c-hater schrieb:> Was interessiert mich das Elend von C-Only-Programierern?
Auch mich überhaupt nicht :-) abgesehen davon, dass der pure Kumpel eh
keinen A-Code in sein Progrämmchen hineinbasteln kann!
Gruß Rainer
c-hater schrieb:> Das Grundkonzept wurde unzählige Male> kommentiert, zuletzt recht ordentlich hier:>> Beitrag "Re: Drehgeber an Arduino, external interrupt ISR wird doppelt> ausgeführt">> Also, nichtmal von mir selber. Das zeigt im Minimum: es gibt da> tatsächlich durchaus Programmierer, die in der Lage sind, es zu> verstehen...
OK, dann ist dies ja bestätigt. Jetzt fehlt nur noch jemand, der das an
nem ollen 08/15 Drehgeber ausprobiert. Dieser "Speed optimierte" Code,
muss da unweigerlich Amok laufen!
Teo schrieb:> OK, dann ist dies ja bestätigt. Jetzt fehlt nur noch jemand, der das an> nem ollen 08/15 Drehgeber ausprobiert. Dieser "Speed optimierte" Code,> muss da unweigerlich Amok laufen!
Das kann nur jemand sagen, der IMMER NOCH NICHT DAS KONZEPT VERSTANDEN
HAT. Was, wie schon erwähnt, im Prinzip exakt dasselbe ist wie in PeDas
bewährtem Code. Nix Entprellung. Braucht ein Quadrature-Encoder auf
Grund seines Funktionsprinzips einfach nicht.
Manche Leute begreifen es halt einfach nicht. Hoffnunglos von der Natur
mit unterdurchschnittlichen geistigen Fähigkeiten benachteiligt.
c-hater schrieb:> Manche Leute begreifen es halt einfach nicht. Hoffnunglos von der Natur> mit unterdurchschnittlichen geistigen Fähigkeiten benachteiligt.
Wow, wer beleidigt hat Recht oder was? WTF!
c-hater schrieb:> Das kann nur jemand sagen, der IMMER NOCH NICHT DAS KONZEPT VERSTANDEN> HAT.
OK, du hast das ja. Also sollte dir folgendes, doch nicht schwerfallen:
Also nur so mal zum Spass. Sagen wir es gäbe tatsächlich Drehgeber, die
nicht nur Prellen, sondern währenddessen, auf dem anderen Kanal Kratzen.
Wie würde dein Ultra-Speed Code darauf reagieren?!
"
1. PCINT Enable auf Pin A
2. Wenn INT auf Pin A, dann:
3. PCINT Disable auf Pin A
4. Hole Zustand von Pin B
5. PCINT Enable auf Pin B
6. Wenn INT auf Pin B, dann:
7. PCINT Disable auf Pin B
8. Hole Zustand von Pin A
9. Weiter bei 1.
"
(C-hater schrieb:> Beitrag "Re: Drehgeber an Arduino, external interrupt ISR wird doppelt> ausgeführt">> Also, nichtmal von mir selber. Das zeigt im Minimum: es gibt da> tatsächlich durchaus Programmierer, die in der Lage sind, es zu> verstehen...)
Teo D. schrieb:> auf dem anderen Kanal Kratzen.
Wenn der andere Kanal in der Mitte seines Signals "kratzt", wie soll man
den dann auswerten?
Entweder du definierst das Kratzen, dann ist es eine sportliche
Herausforderung, oder es Kratzt beliebig, dann ist die Auswertung
sinnlos.
Teo schrieb:> Jetzt fehlt nur noch jemand, der das an nem ollen 08/15 Drehgeber> ausprobiert.
Ein gut funktionierender reicht.
Da drehste am Knopf rechts 5 Rasten, und dann wieder links 5 Rasten, und
die Anzeige steht um 1 daneben
Da fragste dich dann als Bediener (vom Radio, Labornetzteil,
wasauchimmer) ob du blöd bist und nicht zählen kannst, die Hardware
nichts taugt, oder alles unter einem Zauber liegt.
Dabei war's der Programmierer der zu dumm ist, korrekten code zu
schreiben. c-hater halt.
MaWin schrieb:> Ein gut funktionierender reicht.
Tun sie aber irgend wann nich mehr. Da muss man doch nich gleich Amok
laufen.
Das dem C-Hasser hier bei jeder Richtungsumkehr, die erste
Rastung(Schritt) verloren geht, wollte ich ncht ansprechen. Ich wollts
halt erstmal einfach halten... ;P
A. S. schrieb:> Entweder du definierst das Kratzen, dann ist es eine sportliche> Herausforderung, oder es Kratzt beliebig, dann ist die Auswertung> sinnlos.
Ja irgendwann hilft nicht mal mehr ein HW Tiefpass.... Die Dinger halten
halt nich ewig.
Aber warum nich den Frust, wenn in der Zwischenzeit doch immer wieder
mal der Zufall zuschlägt, für den Anwender soweit reduzieren wie möglich
und letztendlich auch noch 50-100% an Lebenszeit für den Drehgeber raus
holen?!
MaWin schrieb:> Da drehste am Knopf rechts 5 Rasten, und dann wieder links 5 Rasten, und> die Anzeige steht um 1 daneben
Das ist für mich kein Argument. Es ist doch Sch..ß-egal ob ich einen
Rastpunkt mehr oder weniger in eine Richtung drehen muss - Hauptsache es
ist im Drehvorgang ein zuverlässiger Zähler und wackelt nicht sinnlos
durch die Gegend ohne zu (meinem) Ziel zu kommen. Außerdem könnte man
das ja wohl in der Auswerte-SW kompensieren.
@PeDa: Erkennt Deine Routine die Richtungsumkehr ohne Schrittverlust?
Weiß ich jetzt nicht, da es mich nie interessiert hat ...
MaWin schrieb:> Da drehste am Knopf rechts 5 Rasten, und dann wieder links 5 Rasten, und> die Anzeige steht um 1 daneben
Diese 1 ist aber das Maximum. Es summiert sich nichts auf. D.h. Du
kannst 1000x links und rechts drehen und am Ende liegst Du maximal 1
daneben. Und dieses 1 kannst Du jederzeit korrigieren, wenn Du möchtest.
Hugo H. schrieb:> Es ist doch Sch..ß-egal ob ich einen> Rastpunkt mehr oder weniger in eine Richtung drehen muss
Wenn es sich aufsummieren würde (also bei jeder Kehre die Chance auf
eine Abweichung), wäre es unbrauchbar. Zwar nicht für eine Bedienung,
aber z.B. für einen Weggeber.
MaWin schrieb:> Dabei war's der Programmierer der zu dumm ist, korrekten code zu> schreiben.
Da wird schon wieder gemeckert und geblökt, daß die Wände wackeln.
Warum probiert es nicht jemand aus?
Teo D. schrieb:> Sagen wir es gäbe tatsächlich Drehgeber, die> nicht nur Prellen, sondern währenddessen, auf dem anderen Kanal Kratzen.
Kratzen ist ja jetzt neu. Bislang haben Drehgeber immer nur gezittert.
A. S. schrieb:> Diese 1 ist aber das Maximum. Es summiert sich nichts auf. D.h. Du> kannst 1000x links und rechts drehen und am Ende liegst Du maximal 1> daneben.
Ganz genau. Und ganz genau so ist es auch in PeDas Code (zumindest
wahlweise). Die Alternative ist, halt Wackler ständig zu melden und es
dem "Client" zu überlassen, damit sinnvoll umzugehen. Was der dann (wenn
er Ahnung hat) auch wieder bloß (mit vergleichsweise viel Aufwand) mit
einer Umkehr-Hysterese von 1 löst, weil eine echte Information steckt ja
typisch nicht in dieser Wackelei...
Auch wieder eine Sache, die MaWin AKA HeinBlöd nicht kapiert. Und
überhaupt hat er auch die Sache mit den Rastpunkten nicht kapiert. Da
kommt's nämlich darauf an, alle wieviel Schritte (Schritt=minimale
Zustandsänderung des Systems) die liegen. Sein "Problem" existiert
überhaupt nur, wenn es für jeden Schritt wirklich einen gibt und wenn es
überhaupt Rastpunkte gibt...
Und wenn das so ist, dann sollte der Encoder auch gut genug sein, hier
nicht sinnlos zu wackeln, sondern nur, wenn sich tatsächlich was bewegt
hat. Und dann kommt das in's Spiel, was du hier schreibst:
> Und dieses 1 kannst Du jederzeit korrigieren, wenn Du möchtest.
So ist das. Für jemanden, der das PRINZIP verstanden hat, ist es kein
Problem, zu jedem beliebigen Zeitpunkt einer Abfrage des Zahlerstands
auf den intern gespeicherten Zählerwert eine +-1-Korrektur anzuwenden.
Alle dazu nötigen Daten liegen im Freigabestatus der Interrupts, dem
Status-Byte und dem (dann aktuell einzulesenden) Zustand der Leitung,
dessen Interrupt inaktiv ist.
Teo D. schrieb:> Das dem C-Hasser hier bei jeder Richtungsumkehr, die erste> Rastung(Schritt) verloren geht, wollte ich ncht ansprechen.
Geht er nicht. Du kannst definitiv schonmal kein Assembler und/oder hast
das PRINZIP immer noch nicht begriffen...
Was maximal "verloren" geht, ist der zuletzt gemachte Schritt. Das wird
dann aber (wenn es geschehen ist) beim nächsten Schritt sofort
kompensiert. Sprich: der maximale Fehler des internen Zählers ist zu
jeder Zeit +-1 Schritt.
Und wenn sich der Client sicher ist, dass der Encoder nicht nur sinnlos
wackelt (was eher die Ausnahme sein dürfte), kann er auch diesen Schritt
noch ermitteln. Kostet nur vier oder fünf weitere Zeilen Assembler.
Teo D. schrieb:> Sagen wir es gäbe tatsächlich Drehgeber, die> nicht nur Prellen, sondern währenddessen, auf dem anderen Kanal Kratzen.
Das sind dann keine tauglichen Drehgeber mehr. So einfach ist das.
Kein Software der Welt kann die dann wirklich sinnvoll auswerten.
Naturgesetz. Capisce?
c-hater schrieb:> Naturgesetz. Capisce?
Aber naja, warten wir mal auf MaWins Statement. Der kann das bestimmt.
Ganz sicher. Man muß nur entprellen und das geht...
Ich bin zumindest diesbezüglich hochgespannt auf Lösungen von
Fachleuten, die die Naturgesetze erfolgreich ignorieren...
c-hater schrieb:> c-hater schrieb:>>> Naturgesetz. Capisce?>> Aber naja, warten wir mal auf MaWins Statement.
Aber warum eigentlich auf MaWin warten (der wird sich nicht darauf
einlassen, so clever ist er dann doch).
Sehen wir uns doch statt dessen einfach DEINE wohldurchdachte Lösung
für den Fall des "kratzenden" anderen Kanals an...
Das wird genausp lustig, soviel kann man wohl vorab versprechen. Und das
ganz ohne Hellseher zu sein...
Der Ersteller des Theads, Enrico I. hat eigentlich nur einen Fehler
gemacht:
Er hat das Wort Encoder in der Raum geworfen. Dann wirds hier immer
fundamentalistisch.
Klar, es gibt einwandfreie technische Lösungen um kratzende, prellende
oder sonstwie gestörte Signale vernünftig einzulesen.
ABER: Enrico I. wollte ein anderes Problem behandelt sehen:
Seine Interrupt-Routine wird mehrfach (zweifach ist auch mehrfach)
ausgelöst, und er weiß nicht warum.
Klar zwei Sekunden Delay spricht nicht für überlegtes Handeln, trotzdem
ist das Problem unabhängig vom Reizwort Encoder.
Leider kenn ich mich bei diesen Prozessoren nicht aus und kann nicht
helfen, aber irgendwer, der nicht auf Encoder-Macho macht weiß sicher
die Lösung.
m.n. schrieb:> Kratzen ist ja jetzt neu.
Sehe ich auch so. Habe bislang zwar wackelnde und prellende DG gehabt,
aber keinen einzigen, der gekratzt hätte. Ist wahrscheinlich eher ein
Theoretikum.
W.S.
mehrfach schrieb:> Seine Interrupt-Routine wird mehrfach (zweifach ist auch mehrfach)> ausgelöst, und er weiß nicht warum.
Wird sie überhaupt 2x ausgelöst? Oder besteht das Problem nur darin, daß
die ISR nur int0_detected auf 1 setzt und dieses eine relativ lausige
Kommunikation mit der Auswertefunktion ist?
Kurzum, es ist zuviel an Unwägbarkeiten dabei - bis hin zu womöglichen
Einstellfehlern oder falsch verstandenen Einstellungen bei den AVR (um
die ich mich seit Jahren schlichtweg nicht kümmere).
W.S.
mehrfach schrieb:> Der Ersteller des Theads, Enrico I. hat eigentlich nur einen Fehler> gemacht:>> Er hat das Wort Encoder in der Raum geworfen. Dann wirds hier immer> fundamentalistisch.
Das war eben KEIN Fehler, sondern ein notwendiges Grundlagenwissen
über das Problem. Das ist nämlich schlicht und einfach bei einem rotary
encoder anders lösbar als bei einfachen Kontakten.
Genau das ist der Punkt, den du nicht begriffen hast, etliche andere
Leute auch nicht und vermutlich der TO in hundert Jahren auch noch
nicht...
Der Thread könnte das zum Guten ändern...
...und ich kann kein "void" und sehe daher auch nicht, ob was in dem
Progrämmchen schief läuft...der TO sollte aber mittlerweile so viele
Infos bekommen haben, dass er jetzt seine eigene Implementierung locker
prüfen kann :-)
Gruß Rainer
c-hater schrieb:> Kein Software der Welt kann die dann wirklich sinnvoll auswerten.
Doch, aber dazu muss man überabtasten, also z.B. mit 20-facher
Geschwindigkeit als sonst notwendig, oder auch 100-facher.
Hardware funktioniert auch, da Kratzen nur auf dem Kontakt stattfindet
der gerade geschlossen ist, so lange die Aussetzer zeitlich viel kürzer
sind als die geschlossenen reicht ein Tiefpass, am besten ein
Kondensator über dem Kontakt der bei geschlossenem Kontakt schnell
entladen wird und bei offenem nur über den pull up aufgeladen wird.
Ein Encoderinterface im uC als Hardware hat auch oft deglitching in dem
mit hoher Abtastfrequenz einzelne Aussetzer ignoriert werden.
Solche Drehgeber sind also nicht gleich Müll, sondern passende
Auswertung lässt sich nicht stören.
Erst wenn die Aussetzer statistisch häufiger als die Kontaktgabe werden,
sind die Müll
Nehmen wir c-haters code und solche Drehgeber
1
A: 000011111111111111000000011
2
B: 000000001111111111111100000
3
X: 000011112222222222333344455
4
a: 000011111011110111000000011
5
b: 000000001111011111111100000
6
Y: 000011112322123222333344455
7
Z: aaaabbbbabbbaabbbbbbbbaaabb
8
C: 000011112222112222222233344
A wäre der gute Encoder Kanal A
B der gute Encoderkanal B
X die richtige Zählung
a ist der kratzende Kanal A
b der kratzende Kanal B
Y ist das was polling dabei zahlt
Z auf welchern Flankeninterrupt c-hater wartet
C sollte das sein was c-haters code zählt,
obwohl, sicher bin ich mir nicht,
ich hab sein Programm nicht ablaufen lassen
sonder nur per Hand versucht nachzuvollziehen.
Vielleicht guckt da noch mal jemand drüber.
MaWin schrieb:> überabtasten
kann man mit Software
MaWin schrieb:> ein Tiefpass, am besten ein> Kondensator
geht auch, ABER viel hilft nicht immer viel, irgendwann ist der
Kondensator so groß falsch gewählt das der Umladestrom alle Kontakte
verbrutzelt.
c-hater schrieb:> Mist, aber die Sachen mit den konfigurierbaren Pullups war nur zur> Hälfte eingebaut.>> Hier also die korrigierte Fassung...
Bug in Zeile 258 (UOUT ENC_B_IFLGREG,R17)
ardap schrieb:> c-hater schrieb:>> Mist, aber die Sachen mit den konfigurierbaren Pullups war nur zur>> Hälfte eingebaut.>>>> Hier also die korrigierte Fassung...>> Bug in Zeile 258 (UOUT ENC_B_IFLGREG,R17)
Stimmt, ganz klarer (und ziemlich peinlicher) Bug. Da müsste statt "R17"
natürlich "TMP" stehen. Mist, wie ist das denn passiert? Keine Ahnung.
Blöd, dass dieser Bug im RL nahezu niemals Folgen hat, deswegen habe ich
ihn auch nicht bemerkt.
Da kann man mal sehen, wozu unabhängige code reviews gut sind. Vier
Augen sehen halt doch mehr als zwei.
Also nochmal eine korrigierte Fassung des Codes als Anhang.
c-hater schrieb:> Mist, wie ist das denn passiert? Keine Ahnung.
Aber ich, kannst du dich nicht mehr an deine eigenen Worte erinnern?
c-hater schrieb:> Hoffnunglos von der Natur> mit unterdurchschnittlichen geistigen Fähigkeiten benachteiligt.
temp schrieb:> Aber ich
bravo, dem hast du es mal so richtig gegeben! Du bist so toll! Komm,
lass und freunde werden! Ich brauche noch mehr so geile Typen um mich
herum. Dann können wir durch die Stadt ziehen und alle mal so richtig
fett beleidigen. Das wird ein Hit bei Youtube, deine Mutter wird dich
lieben.
Allerdings musst du bis dahin deine Feigheit ablegen, dich hinter einem
anonymen Zugang zu verbergen.
Stefan ⛄ F. schrieb:> Komm,> lass und freunde werden
Sorry, mein Bedarf an solchen Freunden ist gedeckt.
Stefan ⛄ F. schrieb:> Allerdings musst du bis dahin deine Feigheit ablegen, dich hinter einem> anonymen Zugang zu verbergen.
Und wozu soll das gut sein? Entweder alle oder keiner. Ich wäre sogar
für alle mit Identitätsnachweis. Meinetwegen auch in einem anderen
Forum. Aber hier? Hatte ich mal. Nie wieder.
temp schrieb:> Hatte ich mal. Nie wieder.
Wird seinen Grund haben. Fachlicher Unsinn, Lügengeschichten,
rüpelhaftes Auftreten. Dann ist dein Name verbrannt.
Nun ist wohl bereits alles gesagt und alle Leute haben Gelegenheit
gehabt, ihre Version zum besten zu geben und der TO kann sich da
inzwischen heraussuchen, was er am liebsten kopieren mag, von Polling
bis zu mehreren abwechselnden Interrupts.
Was jetzt noch bleibt, sind nachfolgende und gegenseitige Anfeindungen,
weil eine jede Sparte auf ihrer Methode als einzig seligmachende Version
beharrt.
Ob das nun dem TO noch von Nutzen sein wird? Wohl eher nicht, denn er
befaßt sich nur gezwungenermaßen damit:
Enrico I. schrieb:> für ein Projekt muss ich mich mit Interrupts beschäftigen...
Tja, da muß du eben durch und auch ich werde dich bei passender
Gelegenheit gebührend bedauern.
W.S.
MaWin schrieb:> Wird seinen Grund haben. Fachlicher Unsinn, Lügengeschichten,> rüpelhaftes Auftreten. Dann ist dein Name verbrannt.
Das mach ich dann lieber unter "temp". Gerne auch mal so provokativ dass
mir die Admins einen Thread sperren, wenn er von Leuten gekapert wird
die z.B. C hassen.
Thread beobachten
Seitenaufteilung abschalten