u8glib langsam?

[Udo (Gast)]

Moin,

ich nutze die u8glib mit einem ATMega328 und einem DogM128. Klappt 
soweit ganz gut. Allerdings komme ich trotz 8 MHz (interner Oszillator) 
bei sw_spi nur auf eine Bildwiederholrate von knapp 2. Gemäß Wiki 
sollten bis zu 20 mit einem ATMega möglich sein. Trotz sw_spi hatte ich 
mir dann doch mehr versprochen.

Das Programm besteht derzeit nur aus einfachen, schnellen Routinen zum 
erzeugen zweier Strings und deren Ausgabe über die Picture loop.
Initiierung:

u8g_InitSPI(&u8g, &u8g_dev_st7565_dogm128_sw_spi, PN(1,5), PN(1,3), PN(1,4), PN(1,1), PN(1,2));

Picture loop:

u8g_FirstPage(&u8g);
do
{
  lcd_Draw();
}  while (u8g_NextPage(&u8g));

lcd_Draw:

{
  u8g_SetFont(&u8g, u8g_font_9x15);
  u8g_DrawStr(&u8g, 80, 48, Titel);
  u8g_DrawStr(&u8g, 80, 63, Buffer);
}

Bevor ich hier alles zerlege:
- Ist die u8glib tatsächlich so langsam?
- Ist der Hw-Modus nennenswert schneller?

Danke und Gruß, Udo

[u8glib (Gast)]

Hallo

Die Textausgabe ist langsam. Je größer der Font, desto langsamer.

Der HW SPI Mode ist auf jeden Fall schneller.

Um die lib weiter zu beschleunigen, könnte in diesem Beispiel auch 
"u8g_SetFont(&u8g, u8g_font_9x15);" vor die Picture Loop gesetzt werden.

Es gäbe noch die Möglichkeit, dass ich den "double buffer" mode 
implementiere. Das hatte ich auch schon bei anderen Displays gemacht: 
Doppelter RAM ergibt dann auch bessere Perforemance. Am besten dazu 
einen Issue of der Projectpage stellen oder mir eine e-mail schicken.

Ausserdem sollte v1.08 verwendet werden. Da hatte ich unter anderem die 
Geschwindgkeit optimiert.

Wichtig ist auch, dass der 16 bit mode deaktiviert ist (siehe u8g.h ca. 
Zeile 40)

Grüße,
Oliver

[Udo (Gast)]

Moin Oliver,

vielen Dank für die schnelle Antwort. Und bei der Gelegenheit auch 
vielen Dank für die u8glib. Gefällt mir ob der Möglichkeiten sehr gut 
und funktioniert soweit auch einwandfrei.
Mein Problem ist halt die Geschwindigkeit, weil das Display über ein 
paar Tasten u.a. für Konfigurationsaufgaben genutzt werden soll. Da sind 
nur ca. 2 fps nicht wirklich prickelnd.

Ich nutze hier die Version 1.09 und der 16 bit-Modus ist deaktiviert. 
Dürfte also maximal schnell sein.

Wenn der hw-Modus nennenswert schneller ist, dann könnte es für meinen 
Verwendungszweck reichen. Allerdings habe ich es bislang nicht geschafft 
das LCD per hw-Modus anzusprechen. Es tut sich gar nichts.

Gemäß Wiki habe ich lediglich

u8g_InitSPI(&u8g, &u8g_dev_st7565_dogm128_sw_spi, PN(1,5), PN(1,3), PN(1,4), PN(1,1), PN(1,2));

durch

u8g_InitSPI(&u8g, &u8g_dev_st7565_dogm128_hw_spi, PN(1,5), PN(1,3), PN(1,4), PN(1,1), PN(1,2));

ersetzt.

Dabei sind ATMega328 und LCD wie folgt mit einander verbunden:
PB5 (SCK) -> SCL
PB3 (MOSI) -> SI
PB1 -> A0
PB4 (MISO) -> CS1B
PB2 (SS) -> RST
Die letzten beiden könnten das Problem sein? Werde ich noch tauschen und 
dann erneut testen.


Danke und Gruß,
Udo

[Chris (Gast)]

Nur mal am rande gefragt. Du hast die Fuse eingestellt am Atmega?
Vom Werk aus läuft der zwar mit den internen 8 Mhz aber sind auf  1Mhz 
runter geteilt.

[Udo (Gast)]

Moin,

danke für den Hinweis. Aber:

Chris schrieb:
> Du hast die Fuse eingestellt am Atmega?
Ja.

Gruß,
Udo

[Karl H. (kbuchegg)]

Udo schrieb:

> Mein Problem ist halt die Geschwindigkeit, weil das Display über ein
> paar Tasten u.a. für Konfigurationsaufgaben genutzt werden soll. Da sind
> nur ca. 2 fps nicht wirklich prickelnd.

Den größten Speedup erzielst du, indem du auch nur die Dinge tatsächlich 
ausgibst, die sich auch wirklich ändern. D.h. die Ausgabe zb aufteilen 
in fixe Texte und die, die sich ändern. Die fixen Texte werden nur 
einmal ausgegeben und bleiben dann in weiterer Folge unangetastet. Von 
den variablen Texten werden auch nur die hingemalt, die sich auch 
wirklich verändert haben. Gerade bei Konfigurationssachen ist das ja 
alles noch überschaubar, da ein Benutzer nicht 25 Einstellungen 
gleichzeitig verändert, sondern immer nur eine nach der anderen. Und nur 
diesen einen Text neu an das DIsplay zu übergeben, sollte da jetzt nicht 
das große Problem sein.

[Udo (Gast)]

Moin,

Udo schrieb:
> Allerdings habe ich es bislang nicht geschafft
> das LCD per hw-Modus anzusprechen. Es tut sich gar nichts.
[...]
> PB4 (MISO) -> CS1B
> PB2 (SS) -> RST
> Die letzten beiden könnten das Problem sein? Werde ich noch tauschen und
> dann erneut testen.
Ja, das war das Problem. Nach Tausch läuft der hw-Modus einwandfrei und 
ist um mehr als den Faktor 10 schneller als der sw-Modus.

Um damit die Frage im Betreff zu beantworten: nein, sie ist nicht 
langsam, wenn man den hw-Modus nutzt. Die 20 fps schafft sie bei o.a. 
Beispiel locker.


Karl Heinz Buchegger schrieb:
> Den größten Speedup erzielst du, indem du auch nur die Dinge tatsächlich
> ausgibst, die sich auch wirklich ändern. D.h. die Ausgabe zb aufteilen
> in fixe Texte und die, die sich ändern.
Ja, wird auch im weiteren Programm berücksichtigt. Nur, wenn ich das 
richtig verstanden habe, funktioniert das eben bei der u8glib nicht, 
weil nach Änderungen und dem folgenden Aufruf der picture loop immer der 
komplette LCD-Inhalt geschrieben wird.
Das ist aber (für mich) kein Problem mehr, weil sie für meine Zwecke 
jetzt schnell genug ist.

Gruß, Udo

[u8glib (Gast)]

Udo schrieb:
>> Den größten Speedup erzielst du, indem du auch nur die Dinge tatsächlich
>> ausgibst, die sich auch wirklich ändern. D.h. die Ausgabe zb aufteilen
>> in fixe Texte und die, die sich ändern.
> Ja, wird auch im weiteren Programm berücksichtigt. Nur, wenn ich das
> richtig verstanden habe, funktioniert das eben bei der u8glib nicht,
> weil nach Änderungen und dem folgenden Aufruf der picture loop immer der
> komplette LCD-Inhalt geschrieben wird.
> Das ist aber (für mich) kein Problem mehr, weil sie für meine Zwecke
> jetzt schnell genug ist.

Genau richtig verstanden: Es muss (leider) immer alles ausgegeben 
werden. Man wird jedoch damit belohnt, dass nur ein kleiner Teil des 
RAMs benötigt wird und nicht der ganze Frame-Buffer im Speicher des 
ATMEGA gehalten wird.

Auf diese Weise läuft u8glib auch auf einem ATTINY oder unterstützt ein 
320x64 Display (beides in der nächsten Release).

Freut mich dass alles soweit läuft. Im HW Modus muss man natürlich die 
Daten und Clock Leitungen an die entsprechenden Ausgänge des SPI 
Subsystems des Controllers legen.

Für Konfigurationsaufgaben mit Tastern könnte ich noch das passende 
Schwesterprojekt empfehlen: M2tk (http://code.google.com/p/m2tklib/)

Grüße,
Oliver