HB-RC-3-ENC, Encoderauflösung?

[Matsch]

Bevor ich mich in die Tiefe grabe:
Weiß jemand auf Anhieb, ob man die Encoderauswertung in Button.h hinsichtlich der Auflösung modifizieren kann (encoderISR?) ?

Hintergrund ist der Einsatz eines ALPS-Encoders, der halbe Schritte macht (15 Impulse pro Drehung, aber 30 Raststellungen).

Üblicherweise ist die Auswertesoftware von ingrementalen Drehgebern ja so ausgelegt, dass man entweder Vollschritte (also hier 15) oder Halbschritte (30, also an jeder Flanke des Data-Kanals) oder Viertelschritte (60, an jeder Flanke von Data und Clk) festlegen kann. Das sehe ich hier auf den ersten Blick nicht. FALLING in CHANGE ändern?
Und für den Encoder wären Halbschritte notwendig.

[papa]

FALLING in CHANGE ändern - müsste klappen.

[Matsch]

So, jetzt klappt alles. Allerdings war dazu noch viel mehr erforderlich als nur die Flankentriggerung.
Ich mußte die Initialisierung encoderISR() erweitern um einen Parameter für die Impulsauswertung (1x oder 2x), das dann in BaseEncoder einbauen. Zudem mußte auch die Impulsauswertung (encirq() ) noch angepaßt werden.

[papa]

Kannst ja mal zeigen, was rausgekommen ist. Dann können wir das auch gerne einbauen.

[Matsch]

Ich habe Button.h so geändert, dass dem Encoder jetzt bei Initialisierung auch noch die Auflösung gesagt werden muß, momentan neben dem bisherigen 1x auch noch 2x.

Beispiel: encoderISR(enc,CLK_PIN,DATA_PIN,2);

Die vierfache Auflösung (Triggerung an jeder Flanke von beiden Kanälen) ist noch etwas aufwändiger und wurde (noch) nicht umgesetzt.
Ich zeige dir hier die Differenzprotokolle. Ich erhebe keinerlei Anspruch darauf, dass das alles wirklich elegant und sauber umgesetzt wurde, da setze ich auf deine Kompetenz. Hier also die Programmdifferenzen, linke Spalte die bisherige Variante, rechts meine geänderte.

Besser wäre es, dass der neue Parameter optional wäre, habe ich aber noch nicht hinbekommen, weil die Methode ja als Makro definiert ist.

[papa]

Besser wäre es, dass der neue Parameter optional wäre, habe ich aber noch nicht hinbekommen, weil die Methode ja als Makro definiert ist.

Hab jetzt nur mal kurz draufgesehen. Kannst Du den Auflösungsparameter nicht schon im Konstruktor machen. Dann würde auch das Makro wieder wie vorher gehen.

[Matsch]

Deswegen bist du hier genau richtig. Ich kenne C++ ausschließlich aus Lehrgängen, habe nie wirklich beruflich damit gearbeitet und mit 71 ist das nicht mehr so einfach. Ich schau mal. Du meinst den Konstruktor von RemoteEncoder?

[Matsch]

Hallo @papa, solltest du irgendwann tatsächlich in Erwägung ziehen, eine solche Auflösungsanpassung noch zu implementieren, da muß ich noch über eine Begleiterscheinung berichten.

Mit der Halbschrittauswertung trat manchmal ein neuer Effekt auf, der in deinem Originalsketch und Vollschrittencoder nicht passiert. Immer mal wieder beobachtete ich, dass bei erneuter Spannungszufuhr des Stellers dieser sofort beim Hochfahren einen Drehimpuls sendete. Unschön, wenn dann nur durch Spannungszufuhr des Stellers die gesteuerte Lampe zu glimmen beginnt. Nach längerer Suche habe ich dann folgendes Problem gefunden:

Bei einem Vollschrittencoder liegt in eingerasteter Position der Pegel beider Signale CLK und DATA immer auf Low (Kontakte geschlossen), bei einem Halbschrittencoder aber in den Zwischenstellungen auch mal auf HIGH (offen). Bei der Initialisierung werden die Ports auf Input Pullup geschaltet und sofort danach der Interrupt von CLK freigegeben. Wenn man nun die Signale hardwaremäßig entprellt hat (RC-Glied), dann liegen die Eingangspegel bei Interruptfreigabe in solchem Fall durch die entladenen Cs noch auf Low, sie laden sich aber über die Pullup auf und erzeugen so eine CHANGE-Flanke, der Impuls wird ausgegeben.
In diesem Fall braucht man also zwischen dem Setzen der Pin-Betriebsart und der Interruptfreigabe eine Verzögerung, die der Auslegung des RC-Gliedes entspricht.

Wie man das im Sketch löst, weiß ich nicht. Es sollte eigentlich keine feste Größe sein, um an die Hardware angepaßt werden zu können.
Entweder ein weiterer Parameter oder aber die init-Routine schaltet die Interrupts noch nicht frei und der Nutzer muß das selbst mit einer neuen Methode anschließend tun - nach einer von ihm realisierten Verzögerungszeit.

[Matsch]

Kannst Du den Auflösungsparameter nicht schon im Konstruktor machen. Dann würde auch das Makro wieder wie vorher gehen.

Ich hab's mal so umgesetzt. Der Parameter wird schon im Konstruktor festgelegt und ist nun auch optional. Wenn er fehlt, gilt halt wie bisher einfache Auswertung.

[papa]

Kannst Du dafür einen PullRequest machen ?