- LiFePO4 Speicher Test         
Ergebnis 1 bis 10 von 96

Thema: C++ fstream GPIO Trigger/Interrupt

Baum-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #11
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    10.04.2005
    Ort
    Bad Aibling
    Beiträge
    212
    Jetzt läuft es mit inotify. Es macht auch einen Unterschied ob man rising, falling oder both benutzt. Nur Merkwürdig ist das falling und rising invertiert erscheinen. Kann das an den internen Pullup oder Pulldown Widerständen liegen? Ein aktiver Pullup würde doch wie ein Inverter wirken. Nur weiß ich nicht wie man die konfigurieren kann ...

    [Edit]
    Ich habe jetzt gelesen das die internen Pull Up/Down nach dem booten ausgeschaltet sind. Dann lag es daran das der Port bei mir dann offen war. So kleine Mosfet wie in den Prozessoren wird das bisschen Energie das an einer offenen Leitung einstrahlt schon reichen das er einschaltet. Mit einem externen Pull Down Widerstand funktioniert es dann einwandfrei. Wenn man immer einen gesicherten Zustand haben will wird man so externe Widerstände nehmen müssen. Weil der interne beim booten oder Reset ja nicht vorhanden ist und erst beim Start der Steuerungssoftware konfiguriert wird.

    Nach einigen Tests mit der inotify Lösung sieht man schon das das nicht die schnellste ist. Wenn man in einer Endlos Schleife einen Port ein/ausschaltet und den anderen als Eingang für der Trigger benutzt. Verliert er sehr viele Impulse die der Trigger nicht mitbekommt. Bisher habe ich als kleinsten Wert mit einer Verzögerung von einer Millisekunde getestet. Damit funktioniert es problemlos. Ob noch kleinere Werte möglich sind habe ich bisher nicht getestet. Für die Lösung von Mechanischen Steuerungsaufgaben sollte es aber ausreichend sein.
    Code:
      for (;;)
      {
        std::cout << "Port 2: 1" << std::endl;
        ioPort2 << 1;
        milliSleep (1); // benutzt intern nanosleep
    
        std::cout << "Port 2: 0" << std::endl;
        ioPort2 << 0;
      }
    Vermutlich wäre die Lösung mit epoll schneller und auch recht gut Hardware unabhängig. Bei epoll spart man sich ja einmal die Zugriffe über das Filesystem die schon sehr viel Zeit kosten. Alles Memory Mapped ist zwar schnell aber leider dann auch 100% Hardware abhängig.
    [/Edit]

    [Edit]
    Falls es jemanden interessiert habe ich den aktuellen Stand in mein git Repo kopiert. Das ist noch nicht fertig aber man kann sehen wie es geht. Fehlerhandling usw. muss man noch anständig machen. https://git.hts-software.de/index.ht.../Gpio/Gpio.hpp
    [/Edit]
    Geändert von alexander_ro (24.01.2018 um 09:59 Uhr)

Ähnliche Themen

  1. Benötige Hilfe zu AT32U3C und GPIO
    Von xrzr im Forum AVR Hardwarethemen
    Antworten: 1
    Letzter Beitrag: 10.11.2015, 18:54
  2. Respberry Pi GPIO mit C++ und QT
    Von Basti1204 im Forum Raspberry Pi
    Antworten: 0
    Letzter Beitrag: 05.03.2013, 23:01
  3. [ERLEDIGT] Raspberry Pi GPIO
    Von Kampi im Forum Raspberry Pi
    Antworten: 4
    Letzter Beitrag: 04.11.2012, 22:45
  4. GPIO-Register Ansprechen
    Von kmrish im Forum Microcontroller allgemeine Fragen/Andere Microcontroller
    Antworten: 7
    Letzter Beitrag: 14.07.2011, 09:45
  5. schmitt-trigger an interrupt
    Von Bluesmash im Forum Sensoren / Sensorik
    Antworten: 2
    Letzter Beitrag: 19.06.2005, 22:46

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test