- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: pulseIn Klappt nicht

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    242

    pulseIn Klappt nicht

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hallo,

    ich experimentiere gerade mit einem Ultraschallsensor.

    Wenn der Befehl pulseIn in diesem Hauptprogramm ist, funktioniert alles gut.

    Code:
    double Ent;
    
    
    void setup() {
    
      Serial.begin(250000);
      while (!Serial);
    
      pinMode (13, OUTPUT);  // Ausgang für das US-Triggersignal
    }
    
    void loop() {
     
      delay (20);
      digitalWrite (13, LOW);      //negative Flanke für Triggersignal
    
      Ent = pulseIn(4, HIGH);
    
      Serial.print ("Ent   =  ");
      Serial.println(Ent);
    
    
      delay (20);
    
      digitalWrite (13, HIGH);       // Triggersignal zurück auf High setzen
    
    
    }

    Versuche ich die US Bearbeitung aber in einem eigenen TAB laufen zu lassen, klappt das nicht:

    Code:
    double Entfernung ()
    {
    
    static double Ent;
    
      Serial.println ("ich bin im UP");
    
      delay (20);
      digitalWrite (13, LOW);      //negative Flanke für Triggersignal
    
      Ent = pulseIn(4, HIGH);
    
      Serial.print ("Ent   =  ");
      Serial.println(Ent);
    
      return Ent;  // gibt die Pulslänge in Mikrosekunden zurück
                   // während der Messung geht der Programmlauf **** nicht ***** weiter
                   // sondern wird real für 15, theoretisch für 20 ms angehalten
    
      delay (20);
    
      digitalWrite (13, HIGH);       // Triggersignal zurück auf High setzen
    
    
    
    }       //   >>>>>   ENDE    int Entfernung
    Das Unterprogramm wird durchlaufen, aber die Variable Ent ist immer nur 0.00

    Kann es sein, dass der pulseIn in einem Tab nicht funktioniert?

    Gruß
    fredyxx

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865
    Dein "digitalWrite (13, HIGH);" am Ende der Funktion wird nie ausgeführt. "Return" springt aus der Funktion. Mag es daran liegen (Triggersignal) oder ist das nur zu Dekozwecken?
    Abhilfe: schiebe die entsprechende Return -Zeile ans Ende der Funktion.

    Frage noch (bin kein Arduino-Progger): Was ist ein TAB?

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.197
    Ausserdem ist pulseIn() blockierend...
    Das wird oft übersehen, wenn die Entfernung grösser ist als die Reichweite des Sensors, tut sich ne volle Sekunde- gar nichts, während der Rechner nur wartet ob da noch was kommt. Da nix kommt, ist das Ergebnis 0.0.
    Daher kann (und sollte man, wenns einigermassen zügig laufen soll) ein sinnvolles Timeout festgelegt werden.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  4. #4
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    242
    Zitat Zitat von Holomino Beitrag anzeigen
    Dein "digitalWrite (13, HIGH);" am Ende der Funktion wird nie ausgeführt. "Return" springt aus der Funktion. Mag es daran liegen (Triggersignal) oder ist das nur zu Dekozwecken?
    Abhilfe: schiebe die entsprechende Return -Zeile ans Ende der Funktion.

    Frage noch (bin kein Arduino-Progger): Was ist ein TAB?
    Danke, das war's. Manchmal ist man eben etwas blind.

    Ein TAB ist ein neues Register in der IDE in dem man ein Unterprogramm unterbringen kann. Evtl. auch noch anderes.

    Gruß

    fredyxx

    - - - Aktualisiert - - -

    Zitat Zitat von Rabenauge Beitrag anzeigen
    Ausserdem ist pulseIn() blockierend...
    Das wird oft übersehen, wenn die Entfernung grösser ist als die Reichweite des Sensors, tut sich ne volle Sekunde- gar nichts, während der Rechner nur wartet ob da noch was kommt. Da nix kommt, ist das Ergebnis 0.0.
    Daher kann (und sollte man, wenns einigermassen zügig laufen soll) ein sinnvolles Timeout festgelegt werden.
    Auch für diesen Tipp ein Dankeschön. Das hätte mich vielleicht auch noch mal überrascht.

    Gruß
    fredyxx

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.197
    Tabs sind das nur in der IDE.
    In Wirklichkeit sind das komplette, eigene Dateien.
    Sehr praktisch, da man dort z.B. Geschichten rein packen kann, die man öfter benötigt (z.B. eine RTC auslesen, samt allem zugehörigen Sermon, wie stellen, Zeitzone anpassen usw.).
    Diese separate Datei kann man dann einfach im nächsten Projekt wieder mit in den Ordner kopieren, und hat die dann da auch wieder als "Tab".
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865
    OK, also Codefiles.
    Sind das dann die berüchtigten Sketches oder ist das wieder was Anderes im Arduino-Slang?

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.197
    Die berüctigten "Sketche" (ich frag mich auch immer mal, wer auf den blöden Namen gekommen ist) sind das gesamte Programm.
    Im einfachsten Fall halt eine Datei namens meinProgramm.ino.
    Da sind dann auch Include-Anweisungen für evtl. verwendete Bibliotheken enthalten (einige werden sowieso standardmässig eingebunden).

    Aber nun kommts: durch diese Tabs kann man den "Sketch" jetzt eben auch in mehrere Dateien aufteilen. Die heissen dann meinProgramm.ino, meineRTC.ino, meineDisplayroutinen.ino....und so weiter.

    Wenn ich nun mal ein neues Projekt aufmachen will, in dem ich die Display-Routinen weiter benutzen will, dann erstelle ich meinProgramm2.ino, die wird automatisch in nen eigenen Ordner gepackt. Dort rein kopiere ich von vorher einfach noch die meineDisplayroutinen.ino und-hab die anschliessend in nem neuen Tab.
    Besser als ne Bibliothek, weil ich die Quelle direkt editieren kann, während dem schreiben.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  8. #8
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    242
    Zitat Zitat von Rabenauge Beitrag anzeigen
    Ausserdem ist pulseIn() blockierend...
    Das wird oft übersehen, wenn die Entfernung grösser ist als die Reichweite des Sensors, tut sich ne volle Sekunde- gar nichts, während der Rechner nur wartet ob da noch was kommt. Da nix kommt, ist das Ergebnis 0.0.
    Daher kann (und sollte man, wenns einigermassen zügig laufen soll) ein sinnvolles Timeout festgelegt werden.
    Hallo,
    es ist schon so weit, dass mich diese Blockierung stört.
    Kann man da was anderes machen, dass das Programm weiterläuft, während der US-Sensor auf den Antwortimpuls wartet?

    Gruß

    fredyxx

  9. #9
    HaWe
    Gast
    Zitat Zitat von fredyxx Beitrag anzeigen
    Hallo,
    es ist schon so weit, dass mich diese Blockierung stört.
    Kann man da was anderes machen, dass das Programm weiterläuft, während der US-Sensor auf den Antwortimpuls wartet?

    Gruß

    fredyxx
    ja, mit Multithreading.
    Es gibt dazu z.B. die Scheduler Lib von M. Patel, mit der man mehrere loops() parallel, unabhängig voneinander laufen lassen kann, und die sogar auch auf AVRs funktioniert.
    Da sie nicht pre-emptives, sondern kooperatives MT bieten und die loops dauerhaft parallel laufen, können z.B. Semaphoren zur Thread-Steuerung benutzt werden: Diese werden vom Haupt-loop() aus gesetzt und beginnen zu messen, sobald ein Semaphor einen bestimmten Wert besitzt, ansonsten können sie auch "leer" laufen. Erfordert nt ein wenig Übung und ERfahrung, zugegebenermaßen.
    Mit pulsin habe ich es noch nicht getestet, wäre aber einen Versuch wert:

    https://github.com/mikaelpatel/Arduino-Scheduler

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.197
    Was du tun kannst ist, ein timeout für pulseIn festzulegen.
    Dazu rechnest du anhand der Schallgeschwindigkeit die nötige Laufzeit für deine maximal nötige Entfernung aus (bei den billigen hc-sr04 sind das maximal 4m, aber nimm das doppelt, da das Echo auch zurückmuss, wenn du nur kürzere Entfernungen zu nutzen gedenkst, umso besser), und hast dein Timeout. Länger wartet der Prozessor dann nicht!
    Lies dazu mal die Doku zu Pulsein, da steht dann auch, ob man es in Millisekunden (ich glaub schon, habs aber nicht im Kopf) angeben muss, und auch, wie man das macht- müsste der dritte, optionale Parameter bei pulseIn() sein...
    In der Regel kommst du dann auf Wartezeiten, mit denen man gut leben kann (8m dauern bei Schallgeschwindigkeit ja nicht so wirklich lange).
    Oder du nimmst eben was schnelleres als Ultraschall-prinzipbedingt ist das ein bissel lahmarschig.

    Alternativ guckst du dir mal die NewPing- (oder ähnlich...) Bibliothek an, die arbeitet angeblich nicht-blockierend.

    So ganz theoretisch _könnte es sogar gehen, als Eingang einen der Hardware-Interrupt-Pins zu benutzen.
    Dann ist da definitiv nix blockierend, wenn man es ungefähr so macht:

    -Ping senden (wie das beim HC nötig ist, über einen normalen Digitalpin)- den Eingang (Echo) aber auf einen der Interrupt-Pins legen. Der müsste dann so konfiguriert werden, dass er bei High den Interrupt auslöst.
    Beim Senden die aktuellen Millisekunden (oder auch die Microsekunden, geht auch) merken, und in der ISR wiederum die aktuellen merken.
    Wenn dann "das andere"- was nebenbei laufen soll, abgearbeitet ist kann man MillisSenden von MillisEmpfangen abziehen und hat- die Laufzeit (aus der man wiederum die Entfernung errechnen kann). Da dank dem Interrupt sofort reagiert wird, können in der Zwischenzeit durchaus andere Dinge erledigt werden....
    Kann man dann noch verfeinern, indem man z.B. den Interrupt nur aktiviert, wenn auch gemessen werden soll usw.
    Müsste eigentlich funktionieren-probiert hab ich es aber noch nicht!
    Wenn du es probieren willst (nicht besonders schwierig, aber aus unverständlichen Gründen haben viele Angst vor Interrupts), halt mich mal auf dem Laufenden, die Idee kam mir grade beim schreiben erst.

    *notiz an mich selber: das ^^ mal im Hinterkopf behalten, hat was...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. RP6 (M32) -- ISP klappt nicht ?!?
    Von AsuroPhilip im Forum Robby RP6
    Antworten: 3
    Letzter Beitrag: 24.03.2012, 06:53
  2. Warum klappt das nicht!
    Von Philsuro im Forum Robby RP6
    Antworten: 10
    Letzter Beitrag: 29.12.2010, 02:56
  3. SPI klappt nicht
    Von p_mork im Forum Assembler-Programmierung
    Antworten: 0
    Letzter Beitrag: 22.04.2007, 14:10
  4. C Motorsteuern klappt!?!?!pwm nicht!!!
    Von patti16 im Forum C - Programmierung (GCC u.a.)
    Antworten: 15
    Letzter Beitrag: 25.01.2006, 22:36
  5. I2C klappt bei mir nicht
    Von Matthias Mikysek im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 14
    Letzter Beitrag: 16.02.2005, 07:27

Berechtigungen

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

LiFePO4 Speicher Test