Suche gutes LCD/LED Display-System mit leicht verwendbarem Framework für meine Bachelor-Arbeit.

> Kombination bei der die einz. Pixel "Matrixähnlich" ansteuern kann
> (Auflösung grob so um die 50x100).

> Und zu dem ein anständiges Framework existiert, das die Display

Das ist weitestgehend quatsch. :-)

Displays mit 128x64 werden ueblicherweise mit SPI oder I2C angesteuert. 
DA muss man nichts gross frameworken.
Wenn du unbedingt willst kannst du dies hier nutzen:

https://github.com/lvgl/lvgl

Aber bei so einem kleinen Display ist man gerade an der Grenze wo das 
anfaengt sinnvoll zu werden.

Olaf

Du suchst ein Graphikfähiges terminal, kein stupides Display. Schau dir 
mal die STM Discovery boards an

Beitrag "stm32 display"
https://www.mikrocontroller.net/articles/STM32F4-Discovery
https://www.mikrocontroller.net/attachment/431734/UserManual_STM32H747_DISCO.pdf

Das ist kein Hexenwerk, ein SetPixel ist die primitivste aller 
Zeichenprimitiven und das können alle Grafiklibs.
Die einfachen TFT mit den integrierten Controllern brauchen eine Init 
Sequenz und dann schickt man Kommandos um zB die Schreibposition zu 
setzen und schiebt dann die Pixeldaten in den Controller.
Da reichen die billigen Kombinationen aus Mega256 + Aufsteckdisplay oder 
auch verschiedene Cortex-M 32 Bitter. Bekannte Libs sind ug8 oder 
AdafruitGFX. Auch die schon genannte lvgl ist super, die setzt aber auch 
auf setPixel Funktionen auf.

> Das ist kein Hexenwerk, ein SetPixel ist die primitivste aller
> Zeichenprimitiven und das können alle Grafiklibs.

Nicht ganz. Ein Framework nimmt dir ja schon etwas arbeit ab was die 
Grafikelemente angeht. Sobald man also komplexere Dinge macht kann das 
schon nett sein. Aber man muss sich da halt auch erstmal reinarbeiten 
und bei kleinen Anwendungen wie man sie auf einem 128x64er Display 
verwirklicht wird sich der Aufwand meist nicht lohnen. Haengt ein 
bisschen davon ab was man damit macht.

> Auch die schon genannte lvgl ist super, die setzt aber auch
> auf setPixel Funktionen auf.

Jein. Die schreibt, jedenfalls wenn du es fuer dein Display so 
implementiert, schon blockweise in den Speicher. Allerdings wird man das 
auch so machen wenn man selber ein Display anspricht. Ich z.B hab immer 
einen Buffer fuer 128x64pixel im Ram, setze da einzelne Pixel und eine 
Interruptroutine im Hintergrund prueft ob sich etwas in einem 
32Byte-Block geaendert hat und uebergibt denn dann ans Display. Damit 
wird dann in der Regel beim setzen von 8Pixel nur einmal auf das Display 
zugegriffen und printf Aufrufe in der Anwendung sind sehr schnell, 
koennen also ueberrall im Source gemacht werden.

Oh..und auch bei lvgl muss man die Lowlevelsachen natuerlich erstmal 
selber implementieren. .-) Ausserdem braucht lvgl einiges an Resourcen. 
Das sollte der Microcontroller mindestens 10k Ram haben.

Olaf

Jupiter Q. schrieb:
> There are only 10 types of people in this world.
> Those who understand binary and those who don't.

I really love my Apple computer,
but my girlfriend has the best software!

Olaf schrieb:
> Nicht ganz.

doch, ganz und gar. Zeichenprimitive sind Punkt, Linien, Rechteck, 
Kreis. Und evtl. noch Zeichenausgabe und Bitmap darstellen. Und alle 
können mit einem setPixel() realisiert werden. Alle Zeichenprimitive 
sind ein bisschen Mathematik die die Pixel zwischen Punkten berechnet 
und dann per setPixel() set. Controllerabhängig kann man evtl. noch 
optimieren, das beherrschen u8glib und AdafruitGFX auch.

Olaf schrieb:
> Ich z.B hab immer
> einen Buffer fuer 128x64pixel im Ram, setze da einzelne Pixel und eine
> Interruptroutine im Hintergrund prueft ob sich etwas in einem
> 32Byte-Block geaendert

unnötig, dann hast du die Doku zu lvgl bzw. der Treiberimplementierung 
nicht gelesen oder nicht verstanden.
Die Optimierung macht lvgl nämlich selber schon. Die Zeichenfunktionen 
rendern auf eine virtuelle Tapete die sogar grösser sein kann als der 
Darstellungsbereich auf deinem Display. lvgl erkennt dann welche 
Bereiche geändert wurden und ruft für diese die low level Darstellung 
auf. Das ist im einfachen Fall das Setzen der Pixel für einen 
rechteckigen Bereich mit setPixel. Weil viele Controller wie ILI und Co. 
rechteckige Zeichenbereiche mit autoinkrekment unterstützen, kann man 
die Ausgabe optimieren indem man einmalig den Ausgabebreich setzt und 
dann in einer Schleife die Pixel für X,Y rausfeuert. Oder als 
Optimierung alternativ GPU / DMA benutzt wenn es die Hardware hergibt. 
Es muss ein Framebuffer (einfach oder doppelt) angelegt werden, der muss 
aber nur min. 10 Zeilen hoch sein. Da ist lvgl sehr clever was das 
Display aktualisieren angeht.

Und lvgl kann kann auch transparente Bitmaps malen. Damit könnte man die 
Dronen auch als kleine Symbole über das Display fliegen lassen.

Johannes S. schrieb:
> Damit könnte man die
> Dronen auch als kleine Symbole über das Display fliegen lassen.

Auf 128 Pixeln Breite, ja das macht Spass.
Bitte mehr solche Vorschläge.

128 Pixel kam nicht vom TO. Der wollte nur 50 x 100 :)
Es gibt aber auch bezahlbare Displays mit mehr Pixeln.

JupiterQ schrieb:
> Am schönsten wäre sowas in der Art wie:
>
>    // PseudoCode:
>    //(MC über Ports mit LCD-Modul/Controller verbunden):
>    import ValhallaTec.LcdController;
>    // innerhalb irgendeiner Objekt-Methode
>    LcdController controller = new LcdController("LcdModulXYZ");
>    controller.Initialize();
>    controller.ActivatePixel(15,59);

Jaja, Schwarm-Intelligenz im Drohnenschwarm als Bachelor-Arbeit ... und 
dann sowas hier wie "ActivatePixel(x,y)". Was hast du in den vergangenen 
Semestern denn bloß gemacht?

Ich geb dir mal nen Abriss in dürren Worten:

Also, als allerunterste Stufe braucht man für ein GUI die 
Lowlevel-Hardware-Treiber, die das Display physisch in Gang setzen - und 
das sind keine Objekte, die man per new(Tsowieso) kreiert, sondern es 
sind Hardware-treiber!!!. Das sollte dir klar sein.

Da obendrauf werkelt ein GDI, also eine Schicht, die Kringel malen kann, 
also Linien, Kreise, Flächen, Schrift - und das in verschiedenen 
Farben/Graustufen und verschiedenen Fonts. Sowas ist auch KEIN Objekt!

Da obendrauf sollte dann ein Menüsystem sitzen - und dort kommt dann die 
objektorientierte Programmierung und ereignisgesteuerte Programmierung 
dazu. Die Objekte sind die grafischen Elemente, also die diversen 
Kringel, die sich auf der Bildfläche tummeln sollen.

Aber da das Ganze ja in einem µC stattfinden soll und nicht im PC, 
sollte das Menüsystem im Flash angeordnet sein, so daß man dafür nicht 
noch extra den ganzen Kram im RAM aufbauen muß. Was Objekte sind, was 
Methoden von Objekten sind und was Properties von Objekten sind, 
solltest du selber wissen. Und wie man bei Objekten, bei denen nicht nur 
die jeweiligen VMT im Flash liegen sondern das ganze Objekt, die den 
Properties zugrundeliegenden internen Variablen realisiert, das solltest 
du dir selber ausdenken können. Sowas kann man zu Fuß auch in C machen. 
Ich hatte vor Jahren eben dieses in der Lernbetty demonstriert.

Wenn du also derartiges noch garnicht beherrschst, dann lies dir dort 
an, wie man sowas machen kann. Von dem, was du im Eröffnungspost 
geschrieben hast, habe ich jedoch den Eindruck erhalten, daß du noch 
nicht reif für den Informatik-Bachelor bist.

W.S.

> die Ausgabe optimieren indem man einmalig den Ausgabebreich setzt und
> dann in einer Schleife die Pixel für X,Y rausfeuert. Oder als

Bei den einfachen Display uebergibst du aber immer ein Byte mit 8Pixel.
Da ist es schon sinnvoll wenigsten diese 8Pixel am Stueck zu setzen.

> 128 Pixel kam nicht vom TO. Der wollte nur 50 x 100 :)

Ich hab das mal grosszuegig aufgerundet weil diese Anfaenger ja garnicht 
wissen mit welchen Zahlensystemen Hardwareentwickler denken. :-)

Mittlerweile sind die Display aber so preiswert geworden das ich auch 
eher empfehlen wuerde etwas mit 240x128 oder 320x240 zu nehmen. Aber 
dann darauf achten dieses Display immer noch mit spi angesprochen werden 
kann.

Olaf

inglischman schrieb:
> Auf 128 Pixeln Breite, ja das macht Spass.

Olaf schrieb:
> ich hab das mal grosszuegig aufgerundet

soso, noch so Chameleon das die Forenuser mit wechselnden Namen 
verarscht.

Olaf schrieb:
> Bei den einfachen Display uebergibst du aber immer ein Byte mit 8Pixel.

und weil die Displaycontroller Autoinkrement können muss man nicht jede 
Adresse vor der Pixelausgabe wieder neu setzen, das war gemeint.

W.S. schrieb:
> Jaja, Schwarm-Intelligenz im Drohnenschwarm als Bachelor-Arbeit ... und
> dann sowas hier wie "ActivatePixel(x,y)". Was hast du in den vergangenen
> Semestern denn bloß gemacht?

Wieder völlig am Thema vorbei.
Wieweit soll die Fertigungstiefe bei der Bachelorarbeit gehen? Chips 
selber designen und fertigen?
Und deine Lernbettys haben dafür auch alle K.I. und sind schwarmfähig?

Auch der Rest der Antwort ist purer Anachronismus. Grafiktreiber können 
sehr gut als Objekt modelliert werden und die Mittel von C++ 
(Mehrfachvererbung) unterstützen das wie in den genannten Beispielen. 
Der 'Treiber' bzw. das Displayobjekt setzt sich aus Schnittstellenklasse 
und Klasse für Zeichenfunktionen zusammen. Damit lässt sich beides 
unabhängig voneinander implementieren und die gleichen Zeichenfunktionen 
können mit SPI, Parallel oder µC spezifischem wie FSMC arbeiten.
Der Vorteil schon auf diesem Level mit Objekten zu arbeiten ist, das es 
mehrere Instanzen von Displays geben kann. Fest vernagelte Treiber sind 
einfach nur Mist.
Und von Menusystemen war hier nie die Rede in der Anforderung.

Johannes S. schrieb:
> soso, noch so Chameleon das die Forenuser mit wechselnden Namen
> verarscht.

Nö, ich  !=  Olaf.

Das wird jeder Moderator bestätigen können.

Was lernt man im Studiengang Informatik überhaupt? Mit logischen Denken 
kann man sich doch das ein/ausschalte einzelner Pixel herleiten. Auch 
die Wahl der Displayauflösung ist doch nicht auf denken in Binärzahlen 
zurück zu führen. Aber ich erkenne das der TO wenigstens den Begriff 
Schwarmwissen versteht, denn etwas anderes will er hier nicht anzapfen - 
wann sind wir an dem Punkt wo die Bachelorarbeit als Multiple 
Choice-Test geschrieben wird?

Johannes S. schrieb:
> Auch der Rest der Antwort ist purer Anachronismus. Grafiktreiber können
> sehr gut als Objekt modelliert werden und die Mittel von C++
> (Mehrfachvererbung) unterstützen das wie in den genannten Beispielen.

Witzbold. Wer soll denn da was vererben - bei Hardware? Und hier geht es 
wohl nicht um's Modellieren, sondern um's reale Machen. Ist ein 
ziemlicher Unterschied. Und die Lernbetty konnte zwar nicht schwärmen, 
aber sie konnte Grafik und Sound (jedenfalls soweit, wie die HW reicht).

Aber wenn du so gut drauf bist mit dem Modellieren von Displays und der 
dazu passenden Software auf einem µC und in allen Schichten, dann zeig 
doch mal, was du tatsächlich kannst mit einem geposteten Projekt hier in 
diesem Forum.

W.S.

Nimm das Nokia Display ;) Das kann sogar ein Arduino prima ansteuern.

Der Unwissende schrieb:
> wann sind wir an dem Punkt wo die Bachelorarbeit als Multiple
> Choice-Test geschrieben wird?

Ich denke mal, der Herr v.Guttenberg hat uns schon vor Jahren den 
aktuellen Weg aufgezeigt.

Aber das soll hier nicht das Thema sein. Es war zu meiner Studienzeit so 
und wird vermutlichst auch heute noch so sein, daß die akademische 
Hierarchie so angelegt ist, daß wohl fast jede Arbeit immer nur eine 
Zuarbeit für die nächst höhere Liga und ein Sub-Themen-Geber für die 
darunter liegende Liga ist. Deshalb sind Bachelor-Arbeiten nicht so 
aufzufassen, daß dabei jedesmal etwas wie e=m*c^2 herauskommt.

Kurzum: Es ist normal, daß bei Bachelor- und Master-Arbeiten eben etwas 
kleinere Brötchen gebacken werden. Eben Teilbereiche. Das ist völlig 
normal.

Nun soll der TO eine Arbeit zu "KI in verteilten Systemen" schreiben, 
was (soweit zu erkennen) trotz des sehr hochgestochenen Titels darauf 
hinausläuft, ein paar echte ferngesteuerte Drohnen durch einen 
"Leit"-Mikrocontroller steuern zu lassen, so daß sie irgendwo 
hinfliegen, ohne sich gegenseitig anzurempeln. Und für diesen Steuer-µC 
sucht er nun die Komponenten, die er für's Display braucht. Kann man ja 
verstehen, ist auch nur Mittel zum Zweck, weil sein Thema das 
gegenseitige Nichtanrempeln sein dürfte. Aber er hat von den 
Software-Schichten, die zwischen den Kringeln, die er auf der Glotze 
sehen will und der Glotze selbst liegen, noch keinen Überblick, weswegen 
er auf den gezeigten hanebüchenen Ansatz kam. Da ist noch ne Menge 
Arbeit drin, wenn er das alles selber entwickeln will. Aber dazu braucht 
er erstmal ein Konzept und ein Aufteilen in einzelne abarbeitbare Teile.

W.S.

>  Dann kann man alle 16 RGB-Bits mit nur einem Clock
> raushauen. Das geht deutlich schneller als SPI.

Das ist voll cool wenn man Videos darstellen will. Wenn man aber nur 
etwas
Text und eine Messkurve darstellen will ist das viel zuviel Aufwand,
EMV, kabel zum Display, einfach kacke. Erst recht fuer einen Anfaenger 
der nur Informatiker ist. .-)

Olaf

W.S. schrieb:
> dann zeig
> doch mal, was du tatsächlich kannst mit einem geposteten Projekt hier in
> diesem Forum.

Code in diesem Forum zu posten (bis auf kurze snippets) ist auch 
Anachronismus, dafür gibt es github & Co.

Test mit AdafruitGFX und Portierung auf Mbed für ein STM32F407VE 
Chinaboard oder LPC1347:
https://github.com/JojoS62/mbed-os-example-
blinky_STM32F407VE/tree/master/lib/Adafruit_TFTLCD_16bit_STM32-master/sr 
c
Für den LPC mit dem anderen Display wird die Zeile

1

Adafruit_TFTLCD_16bit_STM32 tft(NC);

ausgetauscht, alles andere bleibt.

das zeigt sowas an:
https://www.youtube.com/watch?v=cM-VeylqiPc

Unter mbed2 hatte ich die Lib auch schon benutzt:
https://os.mbed.com/users/JojoS/code/Adafruit_GFX/
für das Display UC1601S, das dir vielleicht bekannt vorkommt. Nur bei 
mir funktioniert das mit 128x32.

Auch die bekannten OLED funktionieren mit Adafruit, hier mit einem 
LPC824. Der hat genug Speicher für einen Framebuffer.
https://www.youtube.com/watch?v=2aIS2tJxsAA

lvgl Treiber für einige STM32 Boards sind noch hier:
https://github.com/JojoS62/Test-lvgl/tree/master/libs/Display/lvglDriver

noch für lvgl v6, da gibt es mittlerweile auch eine v7 die ich noch 
nicht angesehen habe. Es funktioniert auch auf dem F407 rasend schnell 
ohne DMA, damit könnte die CPU nochmal entlastet werden. Für F746 oder 
F469 habe ich die DMA aus dem BSP für diese Boards benutzt. Kann man 
rauswerfen und direkt in die nötigen Klassen einbauen, aber bei 1-2 
MByte Flash sind solche Optimierungen zweitranging.

Und im Netz gibt es reichlich Beispiele für einfache Anwendungen für 
AdafruitGFX oder u8glib. In den Repos sind auch Beispiele drin die 
genauso arbeiten wie der TO sich das vorstellt. Der gemeine Arduino User 
(und das dürften viele tausend oder gar zigtausend sein) weiss sicher 
nicht was da alles hintersteckt, aber die Anwendung ist sehr simpel und 
mit ein paar Zeilen Code hat man Punkte gesetzt oder einfache Objekte 
gezeichnet.

Warum hat hier noch keiner Nextion in die Runde gerufen?

Aaaah, Brille ist fleckig,  bin mal putzen.

Philipp S. schrieb:
> Wurde gleich in der ersten Antwort genannt. :-)

Ein Nextion ist schon sehr unterfordert mit einem simplen 
'setPixel(color)'. Dazu der Overhead den ganzen Befehl erstmal in einen 
String zu verpacken und im Display zu dekodieren und auszuführen. Oder 
gibt es auch einen Binärmode für die Ansteuerung?
Wenn das Update der Pixel langsam ist und es nicht zuviele sind, dann 
geht das sicher. Vor allem wenn der Skynet Master ein PC ist kann er 
einfach per USB angeschlossen werden. Aber über diesen Part hatte der TO 
ja nichts geschrieben. Und so Drohnen bewegen sich ja im 3D Raum, da ist 
die Pixelmap doch nur wenig aussagekräftig?

Mw E. schrieb:
> Wir wissen, dass du nichts kannst, das musst du nicht immer aufs Neue
> bestätigen!

Na vielleicht solltet ihr euch auch mal auf ein Bier zusammensetzen, die 
Fehde ist doch wohl schon alt genug...

Und Informatiker sind auch Leute die Datenbankgedöns, 
Warenwirtschaftssysteme, ERP CRM und so ein Zeug programmieren. Die 
haben sicher auch keinen Spaß an Bitschieberei und Compileroptionen 
einstellen, und trotzdem sind das keine schlechten Menschen.

Und wer Software schreiben kann um sowas zu koordinieren der muss für 
ein popeliges Display wohl auch erstmal umdenken:
https://www.youtube.com/watch?v=ggs1XRrCnlE
https://www.youtube.com/watch?v=7mISNNEARkA

Icke ®. schrieb:
> Laß den Informatik-Bachelor sausen und bewirb dich für den RTL-Bachelor.
> Die intellektuellen Anforderungen entsprechen dort deinem Level und der
> Softwarewelt entsteht kein Verlust. Win/Win.

Gibt es einen Grund, so beleidigend zu sein?

inglischman schrieb:
> I really love my Apple computer,
> but my girlfriend has the best software!

got