- Akku Tests und Balkonkraftwerk Speicher         
Ergebnis 1 bis 10 von 15

Thema: [gelöst] Einfache IR-Kommunikation für den RP6

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Neuer Benutzer
    Registriert seit
    01.04.2012
    Ort
    Mülheim an der Ruhr
    Beiträge
    3
    Hallo,

    ist das eigentlich hier der aktuellste Thread zum Thema "IR Kommunikation? In anderen Threads wird oft auf diesen hier verlinkt ...

    Ich versuche gerade herauszufinden, wie der Code funktioniert. Wenn ich das richtig sehe, wird beim Lesen das Timing durch aktives Warten mit "sleep(4);" erledigt. Dazu 2 Fragen:

    (1) Wenn man mit anderen Baudraten arbeiten will, muss man hier den Wert ändern (z.B. "sleep(;" für 1200 Baud), richtig?

    (2) Mich wundert, das hier die Interrupts nicht ausgeschaltet werden. "sleep(4);" könnte doch von einem Interrupt unterbrochen werden, und dann stimmt das Timing nicht mehr oder?!? Andererseits lassen ja die folgenden Antworten darauf schließen, dass die Methode funktioniert.

    Kann mich hier wer mal schlau machen?

    mfg
    TigerWolf

  2. #2
    Erfahrener Benutzer Roboter-Spezialist Avatar von RolfD
    Registriert seit
    07.02.2011
    Beiträge
    414
    Hallo Tigerwolf,
    guck dir mal das hier an : http://www.rn-wissen.de/index.php/RP6_-_Morse-Code
    da ist wohl einiges an Wissen um die IR Kommunikation mit eingeflossen.
    Gruß Rolf
    Sind Sie auch ambivalent?

  3. #3
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    62
    Beiträge
    5.799
    Blog-Einträge
    8
    Hallo

    Es ist der aktuellste Thread, weil es der einzige ist.

    Vielleicht die Antwort auf die zweite Frage zuerst: Wenn man die Interrupts ausschaltet, wird die ISR für sleep() nicht mehr aufgerufen.

    In der Lib für die Base findet man folgende ISR: Externer INT0 und INT1 für die Encoder, INT2 fürs ACS, Timer1_comp als Zeitgeber für sleep() und die Stopwatches, Power-on-Warnung und die Motorregelung. Letztlich noch die Timer2_comp für die ACS-Impulse. Da die IR-Kommunikation blockierend ist, können wir das ACS als Störquelle ausschließen. Wenn dann noch die Antrieb stören sollten, könnte man die auch kurz anhalten. Eine kleine Verzögerung bei den sleep()s stört aber nicht wirklich:

    Zu 1: Die Bitdauer bei 2400 Baud ist 417µs, sleep(1) dauert 100ms. Ähnlich wie bei Himmel und Hölle haben wir zehn Felder hintereinander (Start-, 8 Daten und Stopbit) mit je 417 Länge und wir müssen so durchspringen, dass wir jedes Feld genau einmal treffen. Einzige Einschränkung: Wir haben nur 100er als Sprungweite. Beim ersten Sprung mit 300 trifft man das dritte Viertel (im Abstand von 300 von der Vorderkante) des Startbits und alle weiteren mit 400 treffen dann die einzelnen Datenbits. Da die Feldlänge aber nicht unseren Sprungweiten entspricht, landen wir mit jedem Sprung um den Unterschied (hier 17) kürzer. Das summiert sich dann auf 11*17 und ist weniger als die 300 die wir zu Beginn noch Abstand zum Feldanfang hatten. Verwirrt? Ich auch.

    Bei 1200 Baud beträgt die Bitdauer 834µs. Durch einfaches Verdoppeln der Werte würde sich dann sleep(6) als Startverzögerung anbieten und sleep(8) zum Weiterspringen. Da man mit sleep(8) aber auch noch mit 34µs reserve auf das Startbit treffen würde, wäre sleep(7) als Startverzögerung wohl optimal.

    Um nun nochmals auf die Interrupts zurückzukommen: Da die sleep()s eh nicht genau in die Feldlänge passen, stört eine kurze Verlängerung der Verzögerung durch die Ausführung einer ISR nicht.

    Gruß

    mic

    Der Trick mit Sleep() ist schon alt:
    https://www.roboternetz.de/community...597#post444597
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

Berechtigungen

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

Labornetzteil AliExpress