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

[Moppi]

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

[Rabenauge]

In der FAQ der Lib steht, dass es durchaus Probleme geben könnte: https://github.com/Arduino-IRremote/Arduino-IRremote

[Moppi]

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.

[Rabenauge]

Erzähl doch mal, was du vorhast (wenns nicht allzu geheim ist).
Wir sitzen auch mal wieder an IR-Übertragung im Moment.

[Moppi]

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

[021aet04]

Könnte es an der Versorgung oder dem watchdog liegen?

Eventuell die Fusebits kontrollieren.

MFG Hannes

[Moppi]

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.

[Moppi]

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.

[Rabenauge]

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/34497758/what-is-the-secret-of-the-arduino-yieldfunction

[Moppi]

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

[Moppi]

Noch mal kurz zu IRremote:

belegt bei mir ~380 Byte RAM, also fast 20% des verfügbaren RAM auf einem 328P. Und muss in kurzen Abständen immer wieder auf einen neue erkannten Code abgefragt werden. Am besten nimmt man dafür einen extra µC, nur für diese Aufgabe.

MfG

[Rabenauge]

Das sollte doch funktionieren, wenn man den Code möglichst eindampft (keine Variablen grösser deklarieren als nötig, und immer schön lokale Variablen benutzen, wo das geht)...

[Moppi]

Ich wollte die IRremote nicht umstricken. Belegt original so viel Platz. Aber sonst funktioniert IRremote. Scheint sich nicht aufzuhängen. Damit wäre das dann geklärt. Na ja, diese Mini-Fernbedienungen dazu taugen nicht wirklich was, zum Ausprobieren reicht es aber gerade.


MfG