OLED128x128 SSD1351 RGB Initialisierung Color Farbe bunt SPI 3.3V AVR ATmega8 ATmega328p Assembler

[Bernhard S. (bernhard)]

Kleine Beispiele, einfach und unkompliziert, schnell zusammengefummelt 
zur Initialisierung eines

1.44 "zoll Serielle SPI 128x128 Farbe TFT LCD Display Moduls in
Assembler mit AVR Studio 4.

Vorsicht, das Display verträgt nur 3.3V und benötigt, wenn alle Pixel 
kräftig leuchten ca. 200mA. Gegebenefalls einen Level-Shifter oder 
gemeine Widerstände zur Pegelanpassung verwenden.

Version-1, mit einem 8MHz getakteten ATmega328p.

Das Display wird grundlegend initialisiert, kurz nach dem Anlegen der 
Betriesspannung sehen wir ein verrauschtes Bild, normalerweise ist das 
nicht so informativ, aber in diesem Fall schon, denn es funktioniert 
grundlegend.

Und nun wartet das Display geduldig auf Pixeldaten.

Zuerst ein Kommando 5Ch senden, DC ist dabei low, dann DC auf high und 
immer 2Bytes Farbwerte senden.

2Bytes Farbcodierung:
__high____|low______
0b00000|000000|00000
__rot__|grün__|blau_
0...31 |0..63 |0...31

Um das Display komplett zu beschreiben, das dauert...

128x128=16.384 Pixel x 2Bytes(Farbwert)=32.768 Bytes + diverse Kommandos

Das Nadelöhr ist die Hardware-SPI, warten, bis ein Byte nun endlich 
übertragen worden ist.

Nochmals ein ganz großes Dankeschön an Steffen, er spendierte mir eine 
herrliche Vorlage.

Siehe TWI/I2C OED128x64 Display:
Beitrag "DEBO OLED2 0.96 0,96" OLED-Display SSD1306 SSD1312 Initialisierung TWI I2C AVR ATmeg8 Assembler ASM"

Den Assembler-Code habe ich versucht gut zu kommentieren,
damit Ihr Ver- und Optimierungen vornehmen könnt.

Für Vorschläge, Tipps und konstruktive Kritik bin ich sehr dankbar.

Bernhard

[Steffen H. (avrsteffen)]

Bernhard S. schrieb:
> Um das Display komplett zu beschreiben, das dauert...

Wenn es optimal läuft sollte das bei 8Mhz Systemtakt und daraus 
resultierender maximalem SPI Takt von 2MHz ein Bild in ca. 17ms 
übertragen lassen. Das ist immerhin noch mehr als 50Hz 
Bildwiederholfrequenz wenn man daraus ein Loop macht.

Also bei 4MHz SPI Takt geht das noch flotter..

Gruß Steffen

[Bernhard S. (bernhard)]

Steffen H. schrieb:
> Wenn es optimal läuft sollte das bei 8Mhz Systemtakt und daraus
> resultierender maximalem SPI Takt von 2MHz ein Bild in ca. 17ms
> übertragen lassen.

Sehr seltsam, real habe ich bei 8MHz µC Takt 101ms
und bei 16MHz 51ms gemessen, warum diese große Abweichung?

Ich erkenne kaum noch Optimierungspotential:

OLED_CLEAR:
  ldi ZL,low (128*32)
  ldi ZH,high(128*32)
OLED_CLEAR_s:
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  SPI_TX_NULL
  sbiw ZL,1
  brne OLED_CLEAR_s  
ret

.macro SPI_TX_NULL
  out SPDR,NULL      ; Start transmission of data 
  in temp,SPSR
  sbrs temp,SPIF
  rjmp PC-2          ; Wait for transmission complete
.endm

[Bernhard S. (bernhard)]

Version-2

ASCII mit vier Fonts durch Bitstretching Bitverdopplung aus einem 8x8 
Zeichensatz, ADC und Timer.

Font-0  8x8
Font-1  8x16
Font-2 16x16
Font-3 32x32

Bild "B3" Zeit für OLED.clear 103ms bei MHz µC Takt,
viel schneller geht vermutlich nicht :(


Im Bild "B4" wird die Zeit für den Bildaufbau angezeigt, ca. 70ms

die Zeit seit Programmstart und die Betriebsspannung.

14% Flash, da passt noch viel rein^^

[Bernhard S. (bernhard)]

Version-2 mit ATmega8

Zusätzlich wird der Registerinhalt von MCUCSR ausgewertet, um den Grund 
des letzten Resets zu erfahren, z.B. wurde die Resettaste betätigt, so 
als Spielerei^^

Momentan ist der ATmega8 schon zu 50% gefüllt, werden diverse 
Testprogramme entfernt, dann sieht's diesbezüglich freundlicher aus.

Strombedarf im Haupmenue: ca.50mA

Display komplett weiß gefüllt: ca.200mA