Taster mit Kondensator entprellen

HaWe · 15.05.2019, 15:18

Ich kann Taster bzw. digital Pins mit ca 400-500ns lesen und toggeln (je nach µC auch etwas schneller oder etwas langsamer), aber vor allem: ich möchte einfach vermeiden, dass rechenintensive Funktionen sowie UART, I2C und SPI - R/W durch delays bei Buttonabfragen ausgebremst werden. 1ms ist da schon 1ms zuviel.

Da wir hier im Arduino-Unterforum sind: C++11.

**Holomino** · 15.05.2019, 15:22

Ich hab's jetzt nachgeschlagen, wie ich das mal gelöst habe.

Code:

//Timer keys polling
ISR(TIMER0_COMPA_vect)
{
    static uint8_t keyPrescaler = 0;
    static uint8_t oldKeys = 0;
    keyPrescaler++;
    if (keyPrescaler >= 20)
    {
        keyPrescaler = 0;
        uint8_t newKeys = (PINC & 0xF0); //Keys port
    
        uint8_t keysChanged = newKeys ^ oldKeys;
        uint8_t newKeysSet = keysChanged & newKeys;
        keysSet |= newKeysSet;
        oldKeys = newKeys;
    }
}

Ich polle da wohl alle 20ms im 1ms-Timer-Interrupt die entsprechenden vier Port-Pins in die "keysSet"-Variable...

Code:

// called from Main loop
void MaskProcessFromForeground()
{
    //SET KEYPRESSED, MASKTIMER ELAPSED AND CHECK READ BUFFER CALLS FROM MAIN ROUTINE

    CheckReadBufferTelegrams((FIFO_t*) ReadBuffer, Admin.TelegramReceived);


    if(TimerPrescalerCounter == 0)
    {
        TimerPrescalerCounter = Admin.TimerPrescaler;
        if (Admin.TimerElapsed != 0)
            Admin.TimerElapsed();
    }

    if (Admin.KeyPressed != 0)
    {
        uint8_t keysSetCopy = keysSet;
        for (int i = 0; i < 4; i++)
        {
            if (keysSetCopy & (0x80 >> i))
                Admin.KeyPressed(i);
        } 
        cli();
        keysSet &= ~keysSetCopy; // reset handled keys
        sei();
    }
}

...und spreche die keyPressed-callbacks (können dann schon mal etwas länger dauern) aus der main-loop an.

Nicht verwirren lassen: "Admin" ist eine Struktur mit Funktionszeigern, die auf die Funktionen der aktuell geladenen Bildschirmmaske zeigen (die werden beim Umladen der Maske in die Admin-Struktur geschrieben).

HaWe · 15.05.2019, 15:35

Interrupts kann ich leider nicht verwenden, ich verwende digitalRead für beliebig viele Buttons in Instanzen eines Button-Objekts:
https://github.com/dsyleixa/Arduino/...er/ButtonClass

Abgefragt werden alle Button-Zustände mindestens 1x pro loop(), und wie lange eine Loop dauert, lässt sich nicht allgemein vorhersagen (u.U. nur 1ms oder sogar weniger, evtl aber auch länger).
In der Button Class sind derzeit auch noch delay(1) drin, aber auch die sollen noch raus.
10 oder 20ms warten bis entprellt ist, ist absolut nicht möglich.

Leider gibt es auch kein preemptives Multithreading für die ARMs (POSIX pthread oder std::thread), sonst könnte ich das in einen eigenen langsameren Thread "outsourcen".

Daher suchte ich eine simple Entprellung per Kondensator.

**Moppi** · 15.05.2019, 15:47

Naja, man kann auch Schleifen ohne delay()-Funktion bauen, einfach mit Zählern.

Der Taster wird gegen Masse geschaltet. Ein Kondensator kann keine 0V ausgeben. Er kann nur positive Ladung abgeben.
Musst Du die Logik der Taster umkehren, dann kannst Du Kondensatoren in der Größe 4700µF oder mehr nehmen, evtl etwas weniger, musst Du dann ausprobieren.

MfG

HaWe · 15.05.2019, 15:59

Zitat von Moppi

Naja, man kann auch Schleifen ohne delay()-Funktion bauen, einfach mit Zählern.

Der Taster wird gegen Masse geschaltet. Ein Kondensator kann keine 0V ausgeben. Er kann nur positive Ladung abgeben.
Musst Du die Logik der Taster umkehren, dann kannst Du Kondensatoren in der Größe 4700µF oder mehr nehmen, evtl etwas weniger, musst Du dann ausprobieren.
MfG

4700µF Elkos würden aber bei weitem den verfügbaren Platz überschreiten

die Kerkos sollten dicht neben die Tasterbuttons gesteckt werden, quasi daneben "verschwinden".

Schleifen ohne delay nutze ich ja bereits, denn es sollen ja auch Doppelklicks und lange Drücke erfasst werden.
Guck dir mal dazu bitte den ButtonClass-Code genau an.

Trotzdem kommt es zum unerwünschten Erfassen von Prellen im Bereich z.B. von 1ms bis (geschätzt) 10ms, die dann unerwünschterweise wie Doppelclicks wirken.

**Holomino** · 15.05.2019, 16:38

Wenn Du kein delay() verwendet wissen möchtest, warum verwendest Du dann den oben angegebenen Code?

https://github.com/dsyleixa/Arduino/.../ButtonClass.h
Zeile 146
Zeile 175

HaWe · 15.05.2019, 16:51

Zitat von Holomino

Wenn Du kein delay() verwendet wissen möchtest, warum verwendest Du dann den oben angegebenen Code?
https://github.com/dsyleixa/Arduino/.../ButtonClass.h
Zeile 146
Zeile 175

ich schrieb doch oben: die sollen auch noch weg.

In der Button Class sind derzeit auch noch delay(1) drin, aber auch die sollen noch raus.

Momentan verbessern sie das Prellen zwar schon (bei Prellen innerhalb der ersten 1ms), aber dennoch nicht gut genug für die ersten 20ms, und daher wollte ich alles rausschmeißen und per Kondensatoren entprellen (siehe TO Post).

Wenn du aber den ButtonClass Code derart verbessern kannst, dass er SOWOHL perfekt bis 20ms entprellt ALS AUCH gar keine delays mehr verwendet:
HER DAMIT!

**White_Fox** · 15.05.2019, 20:40

Zitat von HaWe

Ich kann Taster bzw. digital Pins mit ca 400-500ns lesen und toggeln (je nach µC auch etwas schneller oder etwas langsamer), aber vor allem: ich möchte einfach vermeiden, dass rechenintensive Funktionen sowie UART, I2C und SPI - R/W durch delays bei Buttonabfragen ausgebremst werden. 1ms ist da schon 1ms zuviel.

Da wir hier im Arduino-Unterforum sind: C++11.

Busse wie UART, I²C und SPI sind vieles, aber ganz sicher nicht rechenintensiv. Das sind normalerweise weitgehend eigenständige Hardwareeinheiten, die von der ALU weitgehend unabhängig laufen. In deren Datenregister wird ein Byte reingeschoben-und je nach Konfiguration war es das entweder, oder die UART/SPI/... meldet sich mit einem Interrupt zurück, daß sie fertig ist. Die CPU-Last beschränkt sich auf das gelegentliche Schreiben/Lesen in ein Register. Manche Controller verfügen auch über eine Funktion, daß die Peripherie selbständig Teile des Speichers auslesen kann, da hat die CPU kaum noch etwas mit zu tun.

Mit dem Warten sieht es übrigens ähnlich aus: Du kannst stur Zeit vertrödeln, (z.B. einfach nur ein Register inkrementieren), aber du kannst auch einen Timer verwenden. Das ist ein simpler Zähler, der ebenso weitgehend unabhängig von der CPU inkrementiert wird. Je nach Funktion kann das Inkrementieren mit einem Vorteiler noch verlangsamt werden. Der Timer kann, je nach Ausstattung und Konfiguration, u.A. einen Interrupt geben wenn er einen bestimmten Wert erreicht hat oder überläuft. Wenn der Timer einfach nur läuft, kann die CPU während dessen irgendwas anderes machen. Und damit kannst du sehr wohl einen Taster 20ms sperren, ohne den Controller 20ms zu blockieren.

Das hat übrigens nichts mit Threads oder so zu tun. Sondern einfach nur damit, wie so ein Mikrocontroller funktioniert. Ich weiß natürlich nicht, wie speziell dein Code genau funktioniert und welchen der vielen Wege nach Rom dein Programm letztendlich geht. Es sind schließlich recht viele Wege...

HaWe · 15.05.2019, 21:02

mit UART lese ich laufend eingehende Bytes ein und kopiere sie in verschiedene Zwischenpuffer zur Weiterverarbeitung (strtok etc.), über I2C werden laufend verschiedenste Sensoren nacheinander ausgelesen und die Werte dann verrechnet, dann werden neue Werte gesammelt und über UART arrays wieder zurückgeschickt, über SPI wird das 480x320 TFT angesteuert, was schon recht lang dauert, dann seine touchscreen und touchbutton events erfasst und Hardwarepuffer beschrieben/gelöscht.
Das alles dauert schon seine Zeit.
Damit dann das Bild nicht ruckelt, weil zwischendurch ein paarmal auf ein ButtonUp oder ein Debounce gewartetet werden muss, muss man zumindest hier auf delays verzichten.
Außerdem sind nicht alle Pins, an denen ein Button angeschlossen sein kann, Interrupt-fähig, dann beträfen Interrupts ja auch nur einzelne Instanzen, solange sie aktuell existieren, und sie müssten auf nur 1 Zustand der Statemachine begrenzt werden (z.B. Level 3) und bei anderen Zuständen (1,2,4,5,6,...) zwingend inaktiv bleiben - aus meiner Sicht also nicht machbar.

Mit pthread auf dem Pi mache ich das anders:
1 langsamer low priority Thread für HDMI TFT Ausgabe, die nach und nach mit 20Hz alles ausgibt, bis es vollständig ist, dann auf 50ms (nonblocking) delay, und dann sofort wieder von vorn aktualisiert,
1 superschneller super-high-priority-Thread für Encoderpins alle 100µs auslesen,
1 schneller high-proiority für 115200 baud UART für Dashboard und remote control im handshake ohne delay,
1 mittelschneller medium priority für 400kHz I2C mit ein paar delays zwischen einzelnen Device r/w
1 sehr langsamer low priority zum Keyboard auslesen
1 medium priority für SD r/w
usw.
Delays in irgend einem Thread werden dabei automatisch als Rechenzeit den anderen Threads zur Verfügung gestellt.
Die Zeitscheiben verwaltet pthread optimal, und das klappt wunderbar, kein Thread behindert einen anderen oder bremst irgend etwas aus, auch nicht auf einem Single-Core Zero: GPIO-toggle ist fast genau so schnell wie wenn es ganz alleine läuft.

Hier beim Arduino aber muss ich alles in 1 Thread-Loop reinpressen, und viele langsame Vorgänge bremsen die schnellen unerträglich herunter.

Dennoch, ich bin schon weitergekommen mit meiner statemachine, auch wenn es langsam unübersichtlich wird

PS,
Allerdings wäre auch für künftige andere Entprell-Probleme ein simpler Kondensator am Button einfacher gewesen - wenn es funktioniert hätte...