ZitierenMomentan wohl noch nicht. Ich hab soeben erfolglos versucht, ein 2,1" Display mit der Bascom-Library zum Laufen zu bringen.
Momentan wohl noch nicht. Ich hab soeben erfolglos versucht, ein 2,1" Display mit der Bascom-Library zum Laufen zu bringen
Gruß: - Reinhard -
Hast du das Display allein gekauft oder das ganze Modul?
Beim Modul ist der Code zum Ansteuern schon dabei, hald nicht als .lib sondern als Code.
Hast du es schon mal zum laufen gebracht?
Wenn ja, hast du ein Demobild zum ansehen?
Ich hab im Laufe der Zeit bereits mehrere Module (1,5" und 2,1") gekauft und mit den kleinen Modulen schon einiges gemacht. Der Code ist bei den Modulen, wie Du schon bemerkt hast, jeweils dabei und funktioniert auch gut.
Ich wusste aber bis gestern nicht, das beim Bascom schon eine Library dabei ist (hatte ich zufällig im Bascom-Forum gelesen) und das aufgrund Deiner Anfrage mal beim großen Display ausprobiert. Das funktioniert aber nicht, weil die Library z.Zt. nur für die kleinen Displays verfügbar ist, wie mir der Autor heute per Mail mitteilte.
Demobilder gibt es auf www.display3000.com ...
Gruß: - Reinhard -
Also sobald es eine eigene Bibliothek für das 2,1"DisplayModul gibt, dann wäre ich auch daran sehrinteressiert. Die Routinen von Display3000 sind ja nur die absolute Grundversorgung. Manche Sachen gehen damit nicht. Ganz ärgerlich finde ich die Tatsache, daß es keine transparente Farbe gibt. Also einen Button als Grafik laden und dann etwas drauf schreiben sieht einfach mal nach gewollt, aber nicht gekonnt aus.
Besser ist da schon die Bibliothek von Christian Kranz.
http://www.superkranz.de/christian/S...ySoftware.html
Leide rist die aber komplett in Assembler und C geschrieben und ich bin noch nicht so lange mit Bascom dabei, daß ich mir zutrauen würde die in eine BAscom-lib umzusetzen.
Hier mal die Feature-Liste
The graphic library is for WinAVR C compiler, but use only GCC assembler source, handmade.
What supports the library ?
- colors
- pixel setting
- lines
- rectangles with border and filling, transparent and full color
- ellipses and circles with border and filling, transparent and full color
- proportional and fixed fonts with multiple colors
- fonts are highly compressed with an table based RLE coding, like a mini Huffmann
- fontroutines use an separate window for display texts (glcd_Window)
- a full featured font creator for MS Window is included
- with fonts it is easy possible to design own bitmaps and icons with transparency
- all font routines such as glcdPrint() can work on nullterminated strings stored in Flash or RAM
- the font data access can be controlled trough own callbacks to support external I2C EEPROMs or other external memories,
thus there is no need to store large fonts in flash
- all display operation can be truncated with a clipping rect
- all display operation supports transparency
- 65536 color modes
- own bitmap data can be used
- with some hopefully small changes on the base display functions in glcd00.S it should be easily possible to support
other controllers, mainly all highlevel routines such as glcdLine(), glcdEllipse() are hardware independend.
- display resolution can be upto 254x254 without any changes
- inculded are a LFSR-SG (linear feedback shift register shrinking generator) as random generator with period 2**63-2
- this RNG is faster, stronger and far more resource fiendly as the GCC inbuild LCG rand() function
- i have included 2x 1000 random and certified irreducible polynomials for the LFSR
Whats not supported ?
- the library don't use double buffering of display RAM, otherwise we need 46 KByte SRAM
- the S65-Display don't support reading of internal display RAM, thus any operation, such as pixel XOR'ing,
that need reading of display can't be supported
- the adressspace for the font routines is assumed to 16bit and don't support 24bits directly. But with installing an own font read callback there
exists the possibility to access any memory space in chunks of 64Kb. Thus take care on useing fonts on MCU's with 128 Kb flash.
- one font can't and must not excide 64Kb.
- i can't give expensive support, thus use the lib as is without any warrenties
IMPORTANT!
please remember the library use hardware SPI and you have to ensure that ~SS Pin is configured as output or is driven high to ensure SPI
Master. Best choice, with single Master SPI, is to use ~SS Pin as ~CS for the Nokia LCD. But sometimes on ATmega8 as example the ~SS Pin is
equal to OCR1B and we want to use this Pin as PWM Output. So far as this Pin is an output there exists no problems.
Naja - von wegen Grundversorgung bei Display3000. Da muss ich widersprechen: Da finde ich eher die Bascom Routinen für das 1.5" Display Grundversorgung - mit dem eigenen Code von Display3000 ist wesentlich mehr möglich als mit Bascom direkt; selbst beim kleinen Display habe ich die Bascom eigenen Routinen nicht benutzt.
Und beim 2.1" Display: Ich finde, da ist alles bei, was man braucht:
2 Fonts, frei skalierbar (leicht erweiterbar durch eigene Fonts), einzelne Pixel setzen, Linien dick und dünn, Rechtecke gefüllt und ungefüllt (also transparent), Kreise gefüllt und ungefüllt (also transparent)
Bitmaproutinen inkl. Dekomprimierung und Nutzung von Farbtabellen bei Bitmaps zur Speicherreduzierung
Windows-Programm zur Konvertierung der Grafiken in die verschiedenen Formate (mit optionaler Komprimierung).
Nicht zu vergessen liefert display3000 eine hervorragend dokumentierte Software (und Manual), die man auch kapiert und ändern oder anpassen kann. Was nutzen mir Assemblerprogramme, die nur auf dem Atmel laufen und die ich nie im Leben an einen anderen Controller anpassen kann. Ich lese überall nur von Problemen die die Leute mit dem Superkranz-Display und der Superkranz-Software haben. Wenn ich mir die völlig konfuse Dokumentation ansehe, wundert mich das auch nicht.
Transparenz geht eigentlich nur unter 2 Voraussetzungen
a) entweder erlaubt das Display das Auslesen der aktuellen Pixel und der dementsprechenden Behandlung (das geht bei diesem Display nicht)
b) ich habe einen riesiegen Overhead an Datenverkehr, denn ich muss statt nur einmal für ein Zeichen nun für einzelne Pixel ein Ausgabefenster öffnen (oder wenn es ein transparentes Pixel ist eben auch nicht) - d.h. jedes Pixel braucht dann statt 2 Byte nun 14 Byte - d.h. die Ausgabe wird 7x langsamer. Toll, da verzichte ich gerne auf Transparenz - außerdem: wenn ich es bräuchte, könnte ich es in weniger als 5 Minuten hinzuprogrammieren:
1) einfach in LCD_Print (in GLCD21_Display3000.bas) das Ausgabefenster im Display pro Pixel und nicht mehr pro komplettem Zeichen Öffnen (dann halt immer nur 1 Pixel gross)
2) eine If - Then Abfrage zufügen - dort, wo sonst die Hintergrundfarbe gesetzt wurde, mache ich dann einfach nichts (kein Pixel gesetzt = Transparenz).
Das ist schon alles.
Aber wie schon gesagt: Transparenz brauche ich nie und wenn, programmiere ich es mir Ruckzuck hinzu. Vielleicht mache ich es einfach mal am Wochenende, wenn ich Langeweile habe. Mal sehen, wie lange ich brauche.
Also die Transparenzfrage bezog sich eher auf die Fonts. Dort wird erst mal der Hintergrundbereich des Zeichens mit der Hintergrundfarbe überpinselt. Verwendet man hier Transparenz, so bedeutet das einfach, daß eben genau diese Hintergrundpixel nicht beschrieben werden. Damit steigt nicht der Datendurchsatz sondern er sinkt weil nur die Vordergrundpixel, also das eigentliche Zeichen übertragen wird. Man kann dann zwar nicht die selbe Stelle mehrfach überschreiben, weil dann das alte Zeichen noch sichtbar ist. Man kann aber damit schicke Button machen, die eine strukturierte Oberfläche haben und zunächst als Bild gezeichnet werden. Dann kommt da die Beschriftung tansparent drauf.Rechtecke gefüllt und ungefüllt (also transparent), Kreise gefüllt und ungefüllt (also transparent)
Jetzt könnte man ja sagen, daß man sich einfach für jede Funktion einen eigenen Button mit entsprechender Beschriftung macht und diesen speichert. Das dürfte aber reine Speicherverschwendung sein.
Außerdem könnte man das Bitmap des Buttons gleich in ein entsprechend dimensioniertes Array packen und dann mehrere dieser Button sehr schnell auf dem Bildschirm positionieren. Einmal array füllen, window definieren, array in einem stück senden, nächtes window definieren und array wieder schrieben. Bisher wird bei jedem Button den man erzeugt die Bilddaten decodiert und gesendet. Will man das selbe nochmal tun, so muss wieder decodiert werden. Das kann nicht schnell gehen. Klar geht das bei Vollbildern nicht, weil da der SRAM zu klein ist, aber man zeichnet ja auch nicht mehrere Vollbilder kurz nacheinander.
Da stimme ich dir zu. Das war aber nicht das was ich meinte. Die Routinen von Display3000 sind recht ineffizient. Ein wenig mehr Assembler und effektives Datenmanagement hätte dem durchaus Beine gemacht. Hinzu kommt noch, daß Bascom ja eh schon langsamen Code erzeugt.Da finde ich eher die Bascom Routinen für das 1.5" Display Grundversorgung
Naja es gibt sicher Probleme, aber Herr krantz verdient ja auch kein Geld mit seiner Software. Bei Display3000 zahle ich aber für ein fertiges Produkt und da möchte ich doch auch erwarten, daß die Software und Hardware gut dokumentiert ist.Ich lese überall nur von Problemen die die Leute mit dem Superkranz-Display und der Superkranz-Software haben. Wenn ich mir die völlig konfuse Dokumentation ansehe, wundert mich das auch nicht.
Außerdem ist die Software von Display3000 auch nicht fehlerfrei wie ich inzwischen feststellen musste. Ich habe mal etwas herumgespielt und in irgendeinem Grafikmodus werden die die linken 8 Pixel des Bitmaps rechts ans Bild gehängt. Ich glaube es war der 4096 Farben Modus, bin mir aber jetzt nicht ganz sicher. Die Grafik wurde mit dem beiliegenden Grafikkonverter konvertiert. Ich muss mal prüfen, ob das am Grafikkonverter liegt oder ob irgendwo in den Routinen ein Index falsch läuft.
Ich habe zudem mal ein paar Performancetest gemacht und versucht die Software etwas zu optimieren. Da steht zum Beispiel in der LCD_CLS Rountine drin, daß dort immer 8 Byte am Stück übertragen werden, damit es schneller geht. Man könne die ZAhl der BYtes erhöhen um die geschwindigkeit zu erhöhen. Ruft man die Originalroutine 100 mal auf, so dauert das 19 Sekunden, also 0,19sek/CLS. Dann habe ich versucht die Arraygröße auf 128byte zu erhöhen, was die Zeit auf 16Sekunden verkürzte. Kein wirklich gravierender Geschwindigkeitsgewinn. Das kann aber auch an Bascom liefern, da Bascom hier vermutlich zwar prinzipiell HardwareSPI kann, abe rnicht hinterher kommt die Daten zu liefern. Das liegt wohl daran, daß Bascom die Variablen immer im SRAM hält und von dort auch lädt. So braucht das zuweisen eine Variablen 3 Takte während es bei Assembler mit Verwendung von registern in einem Takt geht. Zudem verwendet die Display3000 Software ziemlich viele LOCAL- variablen, was noch langsamer geht.
Meine ersten Versuche die kritischen Routinen in Assembler umzuarbeiten reduzierten die Zeit für 100x CLS auf 9 Sekunden.
Meine Absicht war es nicht das Display irgendwie schlecht zu machen, für einfache Aufgaben reicht es vollkommen, aber ich finde trotzdem, daß es durchaus bei der Software deutlichen Optimierungsbedarf gibt. Im Handbuch steht drin, daß extra nicht alles ausgeschöft wurde um die Software verständlich zu gestalten. Das mag sicher OK sein, für den, der diese gern selbst umschreiben will. Wer aber ein Display kauft um damit effektiv zu arbeiten, der will auch schnelle und effektive Software dafür haben. Man sollte sich auf die Programmierung der Anwendung konzentrieren können und nicht darauf, wie man die Grafikausgabe schneller bekommt.
Man stelle sich mal vor man kauft ein Auto und da ist als Motor eine Dampfmaschine drin: Argument des Verkäufers: die ist halt einfacher zu verstehen ist als ein moderner Einspritzmotor mit seiner ganzen Elektronik. Wenn Sie Power haben wollen,d ann abuen sie sich einen Motor oder Tunen ihre Dampfmaschine.
Wie wäre es wenn Display3000 zwei Versionen seiner Software beilegt. Eine für den, den es interessiert, wie es intern funktioniert und eine optimierte Bibliothek für den, der das Display einfach nur effektiv und S
schnell einsetzen will. Damit wäre jedem geholfen.
Berechtigungen
Lesezeichen