-         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: IRremote auf einem 328P-PU @ 16MHz, 5V

  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29

    IRremote auf einem 328P-PU @ 16MHz, 5V

    Anzeige

    Hallo,

    ich versuche es einfach mal, vielleicht habe ich Glück:

    hatte jemand schon mal bemerkt, dass/ob sich IRremote aufhängt bzw. keine Codes mehr liefert?

    Ich sitze gerade an einem Problem und denke, dass es mit IRremote zu tun haben könnte. Ich nutze dabei millis() und sehr stark I2C. Ich glaube nicht so recht, dass es damit irgend etwas zu tun hat, aber vorsorglich frage ich mal danach.

    Ich bekomme ein paar Mal einen Code per IRremote, dann nicht mehr. Kann aber noch nicht genau sagen, woran es liegt.

    Gruß
    Moppi
    Geändert von Moppi (22.12.2020 um 17:44 Uhr) Grund: zerhaut den Text mit "suche" zu "Suche" als Link , deshalb "suche" rausgenommen

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    52
    Beiträge
    1.840
    In der FAQ der Lib steht, dass es durchaus Probleme geben könnte: https://github.com/Arduino-IRremote/Arduino-IRremote
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29
    Ich lese mir das mal durch, danke!

    Inzwischen habe ich das ausprobiert, ohne viel Code drum herum. Und tatsächlich kann ich es reproduzieren, dass manchmal Codes verloren gehen. Zum probieren habe ich Delays eingefügt.

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    52
    Beiträge
    1.840
    Erzähl doch mal, was du vorhast (wenns nicht allzu geheim ist).
    Wir sitzen auch mal wieder an IR-Übertragung im Moment.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29
    Ich benutze einfach IRremote, um die Software mit Input von außen zu versorgen. Das scheint auch zu funktionieren. Jetzt habe ich was am Code generell geändert, was eigentlich eine Verbesserung sein sollte. Irgendwann habe ich festgestellt, dass die Codes nicht im Programm ankommen. Das ist so alles ineinander übergegangen. Jetzt Suche ich, warum Codes nicht ankommen. Jetzt habe ich IRremote ausgespart und verschiedene andere Dinge eingebunden, um zu überprüfen, ob das Programm funktioniert. Jetzt stelle ich fest, dass zurzeit der 328P ständig rebootet. Ich weiß aber nicht warum. Das mit den Delays hatte ich nun ausprobiert. Jetzt hatte ich im Code geschaut, ob ich Delays verbaut habe, ich habe aber gar keine drinnen. Außer ständigen I2C-Aufrufen, mache ich nichts besonderes. Ich Suche da aber noch. IRremote habe ich komplett raus genommen, das ist offenbar nicht für diese Reboots zuständig.

    MfG

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    33
    Beiträge
    4.995
    Könnte es an der Versorgung oder dem watchdog liegen?

    Eventuell die Fusebits kontrollieren.

    MFG Hannes

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29
    Watchdog habe ich nicht aktiviert. Ist original Bootloader für einen UNO, nichts manipuliert. Die Motortreiber habe ich entfernt. Läuft alles auf Akku. Habe im Programm gerade noch einen Zähler eingebaut. Nun sehe ich am Zähler, dass der AVR immer nach dem dritten Schleifendurchlauf weg ist. Ein Schleifendurchlauf geht immer so in etwa, über I2C: ein Byte aus einem Array von dem AVR lesen, um einen Status zu erfahren, dann noch ein Byte daraus lesen, dann ein Byte ins Array auf dem AVR schreiben (das, was zu Anfang gelesen wurde). Diese Prozedur funktioniert ein Mal. Dann noch Mal und dann noch ein Mal, dann startet der AVR neu. Wenn ich jetzt die Prozedur neu anschubse, funktioniert das ein Mal und noch ein Mal, dann ist der AVR wieder weg.

    Das wird noch etwas dauern, bis ich das Problem gefunden habe.

    MfG

    - - - Aktualisiert - - -

    Den verfügbaren freien Variablen-Speicher habe ich auf 895 Bytes erhöht (keine Meldung - Warnung - von der Arduin-IDE). Vorher war der etwa bei 400 Bytes, da hat der AVR sich genau so verhalten.
    IR-Diode entfernt und Reset-Pin nochmals auf HIGH-Pegel gelegt - keine Änderung.

    - - - Aktualisiert - - -

    Habe jetzt einen neuen AVR genommen, Problem ist dasselbe. Also weiter suchen...

    - - - Aktualisiert - - -

    Fuses habe ich noch mal kontrolliert, da ist nichts eingeschaltet, was einen Reset hervorrufen könnte. BOD war auf 2.7V eingestellt (üblich). Ein 2936 versorgt nur diesen einen AVR. Max. Strom sind hier 50mA über den Regler. Kann mir aber nicht vorstellen, dass die 50mA überschritten werden. Ich hatte mal eine LED zum Testen an genau diesen AVR angeschlossen, wo schon mal 15mA extra für die LED verbraten wurden, das lief (die LED blinkte) über Stunden in einer Testsschleife. Auch jetzt läuft der AVR problemlos in einer Programmschleife, solange keine Kommunikation hinzukommt (hier i2c). Als ich das Programm aufgebaut habe, habe ich das nodeMCU 1.0 und den AVR im fliegenden Aufbau mit Steckern verbunden (AVR auf einem UNO-Board) damit ich serielle Ausgaben zum Testen benutzen konnte, ob die Kommunikation einwandfrei ist. Da ist das dann auch sehr lange Zeit gelaufen, ohne dass es zu Fehlern kam. Wenn ich jetzt den freien RAM-Speicher erhöhe, auf über 1400 Byte, schafft der AVR ein paar Zyklen mehr (wenn es vorher 2 oder 3 waren, sind es jetzt bis zu 9). Macht den Eindruck, als ob da Daten ein Stapel überläuft oder was anderes, durch sich ansammelnde Daten. Aber auch das kann eigentlich nicht möglich sein. Ich mache da nichts extravagantes im Programm, wie extra Speicher reservieren. Alles wird durch den Compiler erledigt. Arrays lege ich nicht zur Laufzeit an, sondern deklariere die im Quellcode (das Erstellen macht dann der Compiler) und die müssen auch nicht entfernt werden, die bleiben immer erhalten. Manchmal habe ich lokale Variablen in Funktionen, die natürlich dann Speicher benötigen und anschließend wird der Platz wieder freigegeben. Aber auch das erledigt der Compiler. Ich habe keine Ahnung , was da los ist. Leider finde ich keine List-Files, wo ich sehen könnte, was da compiliert wird. So kann ich das Ergebnis des Compilers nicht kontrollieren. Was ich jetzt wieder tun kann, dass ich das nodeMCU und den AVR wieder mal fliegend verknüddele und mit Serial.print dann die Vorgänge überprüfe, um genauer herauszufinden, an welcher Stelle der AVR dann rebootet.
    Geändert von Moppi (24.12.2020 um 08:41 Uhr)

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29
    Ich konnte einige Ungereimtheiten finden, die der Verschachtelung von Programmcode geschuldet sind. Zumindest habe ich eine Erklärung für den Reboot. Der kann z.B. auftreten, wenn der Bytecodeinterpreter eine nicht existierende Funktion aufrufen soll. Normalerweise hat jedes Gerät (AVR) seine eigenen Funktionen und damit unterschiedlich viele. Wenn es nun, durch Kuddelmuddel der Sende-/Empfangspuffer bei der Verschachtelung von Programmcodes, der unterschiedlichen Kommunikationskanäle, zur falschen Adressierung von Codeblöcken kommt, kann das darin enden, dass ein AVR eine Funktion der Firmware aufruft, die nicht existiert (der Zeiger auf die Funktion ist dann mit Nullbytes belegt) und damit der AVR neu startet (allerdings nicht durch einen Hardware-Reset). So wie es aussieht, konnte ich das beheben. Allerdings habe ich div. Verbesserungen auch gleich auf den ESP8266 übertragen, jetzt macht der mal wieder Probleme, indem der einfriert, zumindest ist der Webserver per WLAN dann nicht erreichbar. Hier muss ich noch weitersuchen. Ich denke, dass IRremote noch funktionieren wird, aber das kann ich derzeit wegen der andern Probleme nicht genau sagen. Das werde ich später nochmals versuchen.

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    52
    Beiträge
    1.840
    Was das ESP-Problem angeht: du weisst, dass man den ab und zu "warten" lassen muss (ich glaube, alle 20 ms), damit der einwandfrei läuft?
    Das brauchen die für die Kommunikation.
    https://stackoverflow.com/questions/...-yieldfunction
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.518
    Blog-Einträge
    29
    Danke für den Hinweis! Aber, wegen der Frage: ja, ich weiß das. Deswegen baue überall yield() ein. Allerdings sind mir die 20ms neu. Da werde ich mal nach schauen.

    MfG

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. atmega 328P - Servomotor Steuerung
    Von ArduUser im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 11.04.2016, 07:11
  2. Antworten: 0
    Letzter Beitrag: 15.01.2016, 17:16
  3. Baby Orangutan B-328p
    Von hunikuni im Forum AVR Hardwarethemen
    Antworten: 7
    Letzter Beitrag: 25.05.2012, 20:58
  4. Immer diese Fuses ... Atmega 328p
    Von Sebas im Forum AVR Hardwarethemen
    Antworten: 6
    Letzter Beitrag: 16.05.2012, 18:18
  5. 16Mhz Quarz schwingt von einem Tag auf anderen nicht korrekt
    Von Frank im Forum AVR Hardwarethemen
    Antworten: 7
    Letzter Beitrag: 03.06.2004, 21:04

Berechtigungen

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