Forum: Projekte & Code [ASM] SSD1306 text library für oled displays + AVR 0- und 1-Series


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Steffen H. (avrsteffen)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Da ich immer noch sehr viel in Assembler programmiere und auch mal diese 
kleinen OLed Displays ausprobieren wollte ist mir aufgefallen, dass es 
nur Treiber in C, C++ oder Bascom gibt. Deswegen hab ich mich dran 
gesetzt und versucht das ganze einmal in AVR Assembler umzusetzen.

Raugekommen ist dabei eine kleine Library für den Oled-Displaytreiber 
SSD1306 zum Darstellen von Text im 8x8 Font. Das benutzte Interface ist 
hierbei I2C (TWI).

Das ganze ist allerdings auf die neuen AVR Controller der 0-Serie oder 
1-Serie ausgelegt. Dabei sind noch viel mehr kleine Include Datein 
entstanden die bei den neuen Serien sehr vorteilhaft sind. So zum 
Beispiel die der Interruptvectoren.

Ich habe dazu auch mal ein Beispiel wie man die Library benutzt mit 
angehangen.

Bis jetzt stehen Funktionen wie:
- oled_init
- oled_clr_screen
- oled_home
- oled_gotoxy(x,y)
- oled_write_char(c)
- oled_write_string(x,y,*Y)
- oled_write_fstring(x,y,*Z)
zur Verfügung.

Die Beschreibung der Funktionen stehen in der SSD1306_driver.inc mit 
drin.

An alle ASM Fans der AVR Familie, über Rückmeldung würde ich mich 
freuen.

MfG Steffen

von Steffen H. (avrsteffen)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Leute,

Ich hab das ganze mal noch ein bisschen aufgebohrt. Jetzt können 
verschiedene Fonts in verschiedenen Größen benutzt werden. Durch 
Bit-Schubserei kann dieser sogar an beliebiger Stelle im Display 
positioniert werden, keine Pageweise Adressierung sondern Pixelgenaue. 
Noch wird kein Abbild (virtueller Displayspeicher) im SRAM benötigt.

Die Fontdaten stammen vom GLCDCreator2.1 und mussten noch zur Benutzung 
in Assembler modifiziert werden. Diese Daten sind allerdings so eine Art 
"packed". Das heißt, dass jedes Zeichen so seine eigene 
Zeichen-Pixel-Breite hat und so auch mal mehr oder weniger Speicher 
benötigt. Denn ein "!" ist schmaler als ein "W". Und genau das wird hier 
genutzt.

Was mich hier gerade noch stört ist, dass der Assembler in jeder 
Datenzeile noch ein "padding Zero" anhängt wenn die Summe der Datenbytes 
ungerade ist.

Desweiteren ärgert mich die Möglichkeit den Inhalt der aktuelle 
Speicherstelle vom DRAM des SSD1306 auslesen zu können. Zumindest 
mittels I2C geht es nicht.


Mfg Steffen

*die 1. "SSD1306_APEdriver.inc" Datei ist leider eine noch im Test 
befindliche Include Datei um Fonts in ein serielles SPI EEPROM 
auszulagern..

von Erwin E. (kuehlschrankheizer)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Steffen H. schrieb:
> Durch
> Bit-Schubserei kann dieser sogar an beliebiger Stelle im Display
> positioniert werden, keine Pageweise Adressierung sondern Pixelgenaue.
> Noch wird kein Abbild (virtueller Displayspeicher) im SRAM benötigt.

Die Pixelgenaue Ausgabe finde ich sehr interessant. Wie schaffst du es 
aber, ein Zeichen mit 10 Pixeln beispielsweise an der y-Pos 10 
auszugeben und anschließend ein weiteres Zeichen an der gleichen x-Pos 
mit z.B. y-pos 24? Da du den Inhalt des GRAM nicht lesen kannst (und 
auch keinen Buffer verwendest), sollte eigentlich das zuerst ausgegebene 
Zeichen teilweise überschrieben werden. Zur Verdeutlichung: In der 
Skizze der grüne Bereich ist gemeint.

Ich habe einen SSD1306-Treiber in C geschrieben, der ebenfalls 
verschiedene Fontgrößen erlaubt und ohne Buffer auskommt, aber für 
dieses Problem habe ich keine Lösung gefunden. Eigentlich war ich bisher 
der Meinung, das ist schlicht nicht möglich, wenn man nicht lesend auf 
das GRAM zugreifen kann und auch keinen Buffer verwendet.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Erwin E. schrieb:
> Eigentlich war ich bisher
> der Meinung, das ist schlicht nicht möglich, wenn man nicht lesend auf
> das GRAM zugreifen kann und auch keinen Buffer verwendet.

Ja, genau so ist es auch. Weil normalerweise löst man dies über eine 
Maske. Man muss den von dir gemeinten (Page) grünen Bereich einlesen und 
dann mit den neuen Daten "ODER" verknüpfen.
Das kann man nur über ein Abbild (Buffer im SRAM) schaffen. Somit wird 
es auch schwieriger eine Grafik-Library zu schreiben.

Deswegen mag ich diese Displaytreiber auch nicht so.

Mir geht es hier viel mehr um die Fonts. Hier auf einem EPSON Controller 
(S1D13700)

MfG Steffen

von Erwin E. (kuehlschrankheizer)


Bewertung
0 lesenswert
nicht lesenswert
Steffen H. schrieb:
> Noch wird kein Abbild (virtueller Displayspeicher) im SRAM benötigt.

Tippfehler? Du verwendest also doch einen Puffer?

von Steffen H. (avrsteffen)


Bewertung
0 lesenswert
nicht lesenswert
Nein, noch verwende ich keinen Displayspeicher. Also wenn man da nicht 
Obacht gibt, dann überschreibt man ganz schnell eine andere Zeile.

Deswegen werde ich versuchen einen Displayspeicher im SRAM zu 
integrieren. Mal schauen, wie hoch da dann noch die Performance ist.

Jetzt gerade arbeite ich an der Anbindung eines seriellen SPI EEPROMs um 
die Fonts darin unterzubringen. So bleibt der Flash der MCU frei..

MfG Steffen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.