Hallo,
ich beabsichtige auf einem Mini Pro 16MHz ein kleines OLED zu bereiten. Parallel soll eine (Software) Serielle Schnittstelle betrieben werden. Das Display hängt an I2C. Mit Beispielprogrammen läuft das Display ohne Probleme auch das Hauptprogram läuft ohne Display Treiber. (Auf eine Teensy mit HardwareSerial läuft alles ohne Probleme.)
Sobald ich die SoftwareSerial (oder AltSoftSerial) einbinde wird das Display nicht mehr initialisiert und der Code bleibt in der Initialisierungsroutine des Dispays stecken. (Das DISPLAY wird an erster Stelle in Setup() vor allem anderen initialisiert -> Seltsamer hängt das ganze vom Programmcodeumfang ab (Memoryauslastung ist <60%) Wenn ich code reduziere funktioniert die Initialisierung (aber natürlich das Prog nicht mehr so wie es soll
).
Ist dieses "Problem" jemandem bekannt ? Hab nichst darüber gefunden ?
Danke
Klaus
Die SoftwareSerial verwendet Pins die auch von anderen Bibliotheken verwendet werden. Versuche mal, die Pins umzustellen.
In dem Zusammenhang (I2C und SoftwareSerial) sind mir keine Probleme aufgefallen, auch die Standard Libraries arbeiten zusammen. Evtl. solltest du mal Links deiner verwendeten Libraries posten.
Ich vermute aber ein Speicherproblem, wie du auch schon geschrieben hast.
Setze mal deine reinen Textausgaben mit dem F-Makro
display.print(F("dein Text"));
in den Sketch. Vermutlich lässt sich dein Problem damit lösen.
@HotSystems: ich muss nicht mal eine
display.print(F("dein Text"));
Befehl im code haben um den Fehler zu haben
@DrDiettrich: leider fest verdrahtet - im Moment nicht so einfach zu ändern (RX=8, TX=9) und A4/5 für I2C als nix ungewöhliches ...
Hab nun eine ander Lib gefunden:
#include "SSD1306Ascii.h"
#include "SSD1306AsciiWire.h"
Mit der gehts ohne Probleme ... aber halt schade da ich sonst die Adafruit benutze
klaus313:
@HotSystems: ich muss nicht mal einedisplay.print(F("dein Text"));Befehl im code haben um den Fehler zu haben
Du hast ungefähr das genaue Gegenteil von dem verstanden, was gemeint war!
klaus313:
@HotSystems: ich muss nicht mal einedisplay.print(F("dein Text"));Befehl im code haben um den Fehler zu haben
Ich verstehe leider nicht, was du mir sagen willst.
Geht es evtl. auch deutlicher ?
mmh.... also zur Klarstellung: Es muss kein einziger Befehl: z.B. display.print(...) im code sein, um zu sehen dass das Display sich nicht in der Setup routine initialisiert ! Warum Gegenteil verstanden ??
egal ob ich die Textausgabe mit Macro oder ohne mache geschweige denn, ob ich alle Ausgabebefehle rausschmeiße, das display bleibt bei:
if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) { // Address 0x3D for 128x64
Serial.println(F("SSD1306 allocation failed"));
for(;;); // Don't proceed, loop forever
}
hängen...
Nun steht im Aufruf 0x3C, im Kommentar 0x3D.
Welches ist die richtige Adresse des Displays?
Ich befürchte, du hast es nicht verstanden.
Weist du schon, was das "F-Makro" macht ?
befürchte ich leider auch ... F-Macro spart RAM und legt die Daten im PROGMEM ab
Was hat das aber mit meinem Probelm zu tun, das versteh ich (auch) nicht
BTW: 0x3c ist richtig -!
klaus313:
BTW: 0x3c ist richtig -!
Schade. Aber dann ist es das jedenfalls nicht.
Vielleicht braucht das Display in einem anderen Modus weniger Speicher?
klaus313:
befürchte ich leider auch ... F-Macro spart RAM und legt die Daten im PROGMEM ab
Was hat das aber mit meinem Probelm zu tun, das versteh ich (auch) nicht
Wenn dein Sketch beim Starten zu wenig Ram-Speicher zur Verfügung stellt, dann wird ein Start erst garnicht ausgeführt. Daher sollte man dann die Texte im Flash ablegen, das passiert mit dem F-Makro.
Der andere Treiber belegt den Speicher anders und damit funktioniert es bei dir.
Danke das wars - hab nun all meine Debug Messages an die serielle Schnittstelle auch in Macro verpackt.
Der Compiler zeigt zwar jetzt einen deutlichen Mehrverbrauch an Variablen im RAM (von 1234Bytes -> 1390Bytes) und einen geringfügig geringeren Programmspeicher 20296->20280) !aber es geht.
Ich verstehe ich es trotzem nicht
Danke Euch
klaus313:
Ich verstehe ich es trotzem nicht
War meine Erklärung nicht deutlich, oder was verstehst du nicht ?
Der Compiler zeigt zwar jetzt einen deutlichen Mehrverbrauch an Variablen im RAM (von 1234Bytes -> 1390Bytes)
Nur durch Verwendung des F() Makro? Das verstehe ich auch nicht.
Sehe ich auch so!
Der Compiler zeigt zwar jetzt einen deutlichen Mehrverbrauch an Variablen im RAM
Durch Verwendung des F() Makro sollte genau das Gegenteil der Fall sein.
Leider zeigt der TO uns seinen fehlerhaften Sketch nicht.
Da könnte man sich etwas erkennen.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.