Nachdem Ihr mir bei der Frage nach der Kommunikation mit dem OLED I2C über eine längere Verbindung schon so gut helfen konntet hier nun die Nächste:
OLED-Bibliotheken brauchen relativ viel Speicherplatz.
Die von Greimann braucht wenig Speicherplatz, ist aber rein auf Text ausgelegt?
Die ug8 von Olli Kraus braucht wenig Speicherplatz, aber ich finde keine Möglichkeit Bereiche invers anzuzeigen (zum auswählen)
Die ug82 könnte das (vielleicht) leisten, braucht aber viel zu viel Speicherplatz.
Das gleiche gilt für die Adafruit Library mit GFX.
Was ich will: Display mit Anzeige von ausgelesenen Werten und Menüpunkte zur Änderung/Einstellung von weiteren Werten bei möglichtst geringem Speicherbedarf.
schneeloch:
Nachdem Ihr mir bei der Frage nach der Kommunikation mit dem OLED I2C über eine längere Verbindung schon so gut helfen konntet ...
Um was für ein Display geht es? Ich habe mir eine sehr kleine Bibliothek für meine SSD3306-Displays gestrickt. Die kann zwar nur eine „Schriftart“, sonst aber eigentlich alles, was man so braucht. Es gibt halt keine Schrifteffekte (nur ganzzahlige Skalierung, also etwa „dreimal so groß“), Hokuspokus und Firlefanz.
schneeloch:
OLED-Bibliotheken brauchen relativ viel Speicherplatz.
Nein, nicht wirklich, auch wenn es Unterschiede geben mag.
Speicherplatz benötigen überwiegend die Fonts.
Die Bibliotheken gehen unterschiedlich mit Fonts um. Bei einem Test von mir durchgeführten, sicherlich nicht wissenschaftlichen Test hat die Bibliothek von Oli Kraus für meine Bedürfnisse gewonnen.
Speicher sparen kann man durch die Art der Datenaufbereitung und die Wahl des richtigen Fonts.
Datenaufbereitung U8g2: "full_buffer" braucht viel, "page_buffer" weniger Speicher
Datenaufbereitung U8x8: wenig Speicher, aber nur Text
Font U8g2: Die U8g2 Font names geben Auskunft über den Speicherbedarf.
Font U8g2: Hier kommt es wohl nur auf die Größe an.
Oli hat U8x8 als Teil von U8g2 konzipiert, aber aus Anwendersicht sind U8g2 und U8x8 unterschiedliche Bibliotheken.
Zu dem "page_buffer" sollte noch erwähnt werden, daß hier das Bild des Display mehrfach komplett vom Arduino gezeichnet werden muß, die Lib jeweils aber nur einen Teil davon 'mitschneidet' - eben den Bereich, Der gerade jetzt dran ist.
Wenn Alles gezeichnet ist, wird dieser Bereich zum Display geschickt.
Man erkauft Speicher mit zusätzlicher Rechenzeit.
Man könnte - wenn man denn könnte - auch in den einzelnen Pages nur die Bereiche zeichnen, Die eben in diesen Pages auch landen - nur weiß man Das eher nicht, auch backt jedes Display Sein eigenes Süppchen, wie die Daten letztendlich zum Display übertragen werden.
So sind bei meinen kleinen OLED-Displays, wenn ich mich recht entsinne, 8 untereinander stehende Pixel ein zu übertragendes Byte.
Somit kann man das Display NICHT pixelweise ansteuern, weil man ja die 7 anderen Pixel vorher gar nicht kennt - man muß Seinen Pixel ja dort 'rein ver-odern'.
(oder zum Löschen den Kehrwert verunden)
Da die I²C-Schnittstelle ein Auslesen nicht unterstützt (nur gelesen, weder das Datenblatt dazu sondiert noch eigene Versuche unternommen), geht Das auch nicht pixelweise.
Somit ist man darauf angewiesen, jedes Mal den kompletten Inhalt des Display zu zeichnen, damit die Bytes im Buffer stimmen.
postmaster-ino:
Man erkauft Speicher mit zusätzlicher Rechenzeit.
Guter Hinweis, fehlt bei mir.
postmaster-ino:
Da die I²C-Schnittstelle ein Auslesen nicht unterstützt ...
Nicht die I²C-Schnittstelle, sondern das Display. Die I²C-Schnittstelle geht bidirektional, was man bei anderen Bausteinen wie Sensoren, MCP23017 und Speicher sieht.
Mir fiel der Hinweis, daß man das Display nicht zurück lesen könne, nur bei I²C-Interface auf - vll. etwas vorschnell Verknüpfungen erstellt, Die so nicht wirklich zutreffen.
So, ich habe habe jetzt eine Lösung für die u8glib gefunden:
u8g.drawBox(70,50,55,13); //Hintergrund weiß
u8g.setColorIndex(0); // invertiert die Darstellung
u8g.drawStr(76,52,("AP EDIT"));
u8g.setColorIndex(1); //hebt die Invertierung wieder auf
Was sollen wir mit den hingeworfenen Schnipseln anfangen?
Was für ein Typ ist Kompasskurs, warum machst Du da klammern drum und was funktioniert nicht?
Tommy56:
Was sollen wir mit den hingeworfenen Schnipseln anfangen?
Was für ein Typ ist Kompasskurs, warum machst Du da klammern drum und was funktioniert nicht?
Gruß Tommy
Hallo Tommy,
ich will Euch nicht mit dem kompletten Code quälen.
int Kompasskurs
liefert eine Ganzzahl vom Magnetkompasssensor.
Funktioniert auch ohne Klammern nicht / meckert schonbei der Überprüfung des scetch
Dann ist der Code zwar nicht mehr ISO-konform, aber er sollte funktionieren. Die Funktion erwartet an dieser Stelle anscheinend einen C-String, Du gibst ihm einen nummerischen Typ.
@TO: Klar tut er das (meckern). Das Str im Funktionsnamen deutet auf eine Zeichenkette hin.
Damit Du nicht in 5 Minuten darüber stolperst, dass die Zahlen unterschiedlich lang sind, schau Dir mal sprintf bzw. snprintf an.