MODDING-FAQ FORUM

Anlehnend an meine damalige Umfrage, aus der STLCD entstand, nun eine neue... Diesmal für das Projekt STGLCD.

Die Anforderungen werden wie bei STLCD sein (in fact hoffe ich, eine Menge Code daraus übernehmen zu können) - nur das man mit STGLCD eben grafische LCD ansteuert.

Die bisherige von mir so beäugte GLCD-Software hat ein gewaltiges Manko: Man darf seine Daten anzeigen (oder auch nicht) - aber wie das passiert, ist vorgegeben. Dat paßt mir nicht, wie sollte es anders sein ;D

Ich habe also zunächst in der Planung:

- Grafiken für das LCD selbst erstellbar
- Systemdaten frei plazierbar
- Zeichensatz ggf. frei definierbar
- Möglichst breitgefächerte Controllerunterstützung

An Systeminfos ist der gleiche Umfang wie bei STLCD angedacht. Natürlich ist das ganze bidirektional - was ich für STGLCD entdecke, baue ich gern in STLCD ein, wenn möglich.

Das ganze steht und fällt mit der Tatsache, das ich n GLCD brauche. Wenn also jemand mein blaues HD44780-LCD haben möchte, das maßgeblich für die Entstehung von STLCD verantwortlich war...

Mein Glcd kannst du für testzwecke haben... vorraussetzung: vernünftige software entsteht dadurch ;)

1. Vorschlag von mir: kleine Filmchen/animationen abspielen können (z.b. animated gif), denn die software die ich bis jetzt gesehen hab konnte das nicht ::) und wenn dann waren zwischen den (hintergrund)bildern mind. 1 sec. pause :-\

Ich glaube nicht, das das wirklich sinnvoll funktioniert... Die Datenmengen, die zum GLCD geschickt werden müssen, sind mindestens um den Faktor 12 größer (bei 128x64 in Monochrom) als bei einem 20x4-Display. Timings usw. berücksichtigt, kann das schon mal ne Sekunde dauern - kommt dir sicher bekannt vor ;D

However, wenn das nicht stört, kann man das versuchen.

eine simulierte analoge anzeige fände ich ganz nett oder das ganze display flashen lassen bei nem bestimmten event... also quasi invertieren und normales anzeigen im wechsel

Vielleicht ansteuerbar mit einer speziellen Meta-Sprache oder sowas wie XML/HTML.
Oder Postscript ;D Währe echt der Hammer.
Muss ja nicht der volle Sprachumfang sein. ;)

Es währe halt schick, wenn es ein paar BASIC-artige Befehle gäbe. So wie damals:
Sowas dann für den jeweiligen Screen in einer Datei.

Im Kopf dann vieleicht die Konfiguration:
Ich habe mir noch nicht angeschaut, wie es die anderen Programme machen. Ist ist so eine Idee, welche ich vor längerem schonmal andachte und wie BASIC für Mikrocontroller grafische Displays ansprechen.

Spunky

Ähm... Postscript kommt definitiv nicht in Frage - hab mal in einen PS-Interpreter-Source reingeschaut. No Thanks ;D

Aber das mit dem Basic-ähnlichen finde ich ne prima Idee.

ja in der tat das ist gut !!


Also waws nicht fehlen darf ist der Spectrum analyzer von winamp..

Wenn du das alles auf die beine kriss, dann hast du wieder nen beta tester ;) hol mir dann nämlich auch nen glcd

PS:lasst doch mal die gewünschten Controller zusammentragen :D
ich fang an: T6963C, KS0108 (könnte ich besorgen), SED 1330, und 1520 (gibts doch oder?)

EDIT: ich würde euch sogar helfen, zB datenblatt suchen, um olaf oder so ein bischen arbeit abzunehmen, wenn es sich wirklich so gut wie stlcd entwickelt, und glaubt mir, dass wird es :D


EDIT²: NUR SO NEBENBEI!!!: gibts eigentlich auch schon farb glcds?? wenn ja sagt mir nur nen controller...

EDIT³*g*: befehle wie oder wären auch praktisch, um schriften zu zentrieren oder so

Der Hammer wäre nätürlich ein Konfigurationstool. Dadrin stellt man dann erst die Größe ein, und dann kann man Pixelweise was aufs Display malen, und per Drag&Drop so Felder ins Bild ziehen (zB <CPU>) und dann werden sie im fertigen Bild durch den WErt ersetzt 8) 8) 8)
Also, wenn du das umsetzen würdest, würd ich mir auch ncoh nen gLCD zulegen ;D

@Klinkerstein: Zum Thema Controller fällt mir noch der HD61830 ein, vor kurzem erst hier erwähnt, kann Character und GLCD. Datenblattbeschaffung ist nicht sooo schwer, das kriegt meine 2MBit-Leitung in Zusammenarbeit mit Google noch hin - Beschaffung der Displays ist das Problem.
Einen Spektralanalyzer für WinAmp 2.8x habe ich bereits gebastelt (512-Band Stereo, 0% CPU). Den aufs Display zu bekommen ist ne andere Sache...

@Tortus: Möchte nur ungern ein Grafikprogramm schreiben... Ich dachte mehr daran, das man seine Bildchen in Paint, Photoshop, Paintshop oder whatsoever erstellt. Dann passend zurechtskalieren, Monochrom draus machen, den Rest erledigt STGLCD. Wäre das akzeptabel ?

Zum Thema UDF (User Defined Fonts) habe ich auch schon ne Idee, das die Leute ihre(n) Traumfont(s) selbst erstellen können. Das gilt aber nur für Fixed Fonts.

Wenn jemand mit Programmieren möchte (let's make the best GLCD-Software on Planet Earth ;D) - ein FontEditor wäre schon mal zu vergeben.

Sach an, welche brauchst du? Ich habe ein paar T6963C, SED1520.
Mein SED1330 muss ich erst noch testen. Es hat einen seltsamen Adapter, von dem ich die Belegung nicht kenne. Ausserdem fehlt mir der Wandler für die CCFL-Beleuchtung. Es ist eine inverse Variante. Ohne Licht kannste nix erkennen.

Spunky

Wo isn mein Post geblieben ??? Wech isser.

Also, ich denke, mit nem T6963 erschlagen wir die große Masse - viele Tester, während wir mit den SED15x kämpfen.

Danach schaun wir mal. Größe und Farbe des LCD ist egal, nur funzen muß es ;D

So... Habe einmal etwas Brainstorming betrieben.

Bei herausgekommen ist Spunkys Basic-Parser, der inzwischen die Kommandos HOME, RECT, CIRCLE, LINE, LINER, MOVE und MOVER kennt, parst, Tokenisiert und ausführt. Folgendes "Script" hab ich mal laufen lassen:

home
liner 10,10
line 5,5,26,39
circle 64,32,20
rect 0,0,127,63
line 0,0,127,63
line 0,63,127,0

Benötigte Zeit vom Beginn des Parsens bis zum fertigen Zeichnen: Mit GetTickCount nicht meßbar.

Noch geplant: HOMELT (Left Top), HOMERT, HOMELB (Left Bottom) und HOMERB, um sich schnell in die Ecken bewegen zu können, sowie PSET zum Punkte setzen. Falls jemandem noch mehr Kommandos einfallen, versuche ich mein bestes. Aber bitte: Denkt daran, das das hier ein Monochromes Display mit sehr begrenzter Fläche ist, also bitte keine DirectX-Geschichten ;D

Ach ja: So sieht es aus, wenn dieses Versuchsprogramm soweit durchgelaufen ist:
(http://stlcd.curz.com/Parsertest.GIF)

Das kleine Rechteck da oben links ist ein simuliertes 128x64-Display. Ich denke, das reicht, um Rosinen aus dem Kopf zu treiben ;)

sieht schon sehr gut aus olaf, also laut der dauer, der berechnung kann man wohl schließen das Porzessorauslastung =0% (wofür auch cpu leistung?? das kriegn ja fast menschen mit ihrem gehiorn in nen paar minuten hin ;D )

8--o :respect: :respect: :respect: :respect: :respect: <:0>
Genial

Spam modifiziert, nach dem ich die Sprache wiedergefunden habe. :D
Nur ein Respect war mir doch zuwenig ;D

Vorschlag:
Interessant währen (für später) verschiedene Linienstile (dicke, gepunktet, dünne Doppellinie) und vielleicht Füllmuster. Ich denke dabei an meinen alten Atari ST und seine GEM-Oberfläche.
Oder Macros für Stile, welche sich öfters wiederholen. Dann braucht man nicht für unterschiedliche Screens jedesmal die Rahmen neu malen.
Es muss auch nicht unbedingt print sein. Für dynamische Texte kann der Befehl auch function oder so lauten.

Spunky

ach, mir fällt grad noch was ein, etwas seeeeehr wichtiges:
wir bräuchten dringed etwas mit tastern, mit denen wir das programm ansteuern können.
ihr wisst scho, winamp steuern und dergleichen,
das wär der hammer.

certhas

ja, das kenn ich auch, aber ich es wär zum beispiel geil wenn man screens vom programm vorspulen könnte,zu speziellen screens springen kann,

oder wenn jemand albumlist (nen progrämmle für winamp) kennt könnte man auch playlisten auf dem display darstellen die man dann durchscrollen kann.
und das muss das lcd programm können.
also ich weiss das man albumlist in programme einbauen kann ich kenn das von lcdc da gibt es das.
ob man die playliste selber auch einbauen kann weiss ich ned.
ausserdem wär ich gegenüber einer usb-serielle-parallele variante von diesen tastern sehr aufgeschlossen, gameport... na ja, irgendwie...
bei mir hats auf jeden fall noch ned funktioniert, hat mir das ganze system so massiv ausgebremst das der winamp lieder nur noch verzerrt abgespielt hat, was komisch ist da er normalerweise sonst einfach aussetzt

certhas

hm stimmt das ist ne idee, ne art OSD einzubauen, mit auswahlmenü für winamp

man könnte die taster unter das display setzten, und im lcd dadrüber schreiben wofür der taster grad gut ist...

PS: @certhas:lass mal unsere "prügelposts" ;D löschen

EDIT: ah ich seh grad der spunky hat seine sprache im spam post wiedergefunden ;D

was meinst du mit stehenn die 20 für die Pixel? kann man eigentlich recht schlecht abschätzen wieviel 20pixel jetz sind, dann müsste mann das immer ausprobieren und so, evtl könnte man nen kleines config programm basteln, was der stglcd software ihre einstellungsdatei schreibt.. und da die maße seinens GLCD eintragen kann, und diese dann virtuell (im maßstsb 1:1) dargestellt wird auf dem monitor

Ein Touchscreen hmmmm, das währe was feines. ;D

hab ich nich gesagt :-P

meinte dass die taster interaktiv mit dem glcd zusammen laufen *g*

Ein Touchscreen oder Touch Panel ist ein Display mit einer berührungsempfindlichen Folie.
Siehe: http://www.electronic-assembly.de/deu/touch/touch.htm

Ja, mit 20,20 ist die Position in Pixeln gemeint. Wenn die Scriptsprache steht, kann vielleicht auch einer eine Drag&Drop-Soft schreiben. Man könnte auch Olaf sein Testprogramm nehmen. Das zeigt einem beim Entwurf das Ergebnis an.

Spunky

@Spunky: Ich verrate nun ein Geheimnis. Sämtliche Befehle der Scriptsprache werden mit WINAPI-Befehlen umgesetzt und in ein HBitmap gezeichnet. Ist der Interpreter durch, wird das Bitmap zum GLCD geschickt.
Das heißt: Was das WinAPI kann, kann auch STLCD. Nur mit den Fonts wird das nix.
[OT] Schade, der Spam hat mir gutgetan ;D[/OT]

@certhas: Das mit den Tastern hatten wir schon mal irgendwo bei STLCD, aber niemand schien das wirklich haben zu wollen.
Den GamePort in einem eigenen Mid-Priority-Thread abzufragen, dürfte das Problem des Stotterns sicher beheben.

Bei aller Euphorie sollte man auch nicht vergessen, das hier ne simple Scriptgeschichte gebaut werden soll. Vergeßt also Schleifen, Unterroutinen, Variablen (außer denen von STLCD) und derlei Krams. Ich darf mit meinem Delphi keine Programmiersprache entwickeln.
Das mit den Makros könnte man aber mit Chance noch hinbekommen.

Hi!

Also OSD mit Tastern - das wär ja echt cool. Weis aba net, ob das möglich ist, hab von programmieren keine Ahnung.

Und HD61830 -Support wäre auch super!!!
Ich hätte auch ein entsprechendes Display zum Testen für dich.

Cu
Peter

in der tat dsa wäre goil aber naja egal

zum HD HD61830
;)

hab grad ma kurz rechherchiert

SED1330 (http://www.eio.com/ks0108b.pdf]KS0108[/url]
[url=http://www.grote.net/bascom/files/writing_software_to_control_t6963c_based_displays.pdf]T6963[/url](beherscht buchstaben)
[url=http://shellyinc.com/conchips/HD61830.pdf]HD61830[/url] (beherscht buchstaben)
[url=http://www.hantronix.com/down/sed1520.pdf]SED1520[/url]
[url=http://ertw.dhis.org/Projects/GraphicLCD/d1330.pdf)(behrscht buchstaben)



[EDIT: man ihc glaub ich war gestern besoffen... ;D]

---

thx 2 spunky

Folgende Controller beherrschen auch Buchstaben:

T6963C
HD61830
SED1330

Die anderen sind nur Grafikfähig. Dort muss man die Buchstaben selber aus Punkten zusammen puzzeln.

Spunky

Was nicht so schlimm wäre, mit UDF muß man das ohnehin Pixelweise hinzeichnen.

also, wollte mal wieder einen anfang machen, habe dafür erstmal eine liste zusammen gesetzt mit den features die das programm schon haben sollte..

---

Internet:
-kb/s up
-kb/s down
-kb/MB/GB downloaded
-kb/MB/GB uploaded
-public IP (auch hinter router, evtl auflösung eines dyndns account)
System:
-Prozessor Geschwindigkeit
-Prozessor Auslastung
-Ram Frei, Belegt
-Festplatten Frei, Belegt
-Temperatur (MBM..)
Winamp:
-Interpret-Titel
-Indikator zum Fortschritt des aktuellen Titel anzuzeigen (bargraph ähnlich)
-Gespielte Zeit , Restspieldauer, Gesamtlänge (von aktuellem titel)
-Samplerate
-Spectral Analyzer
-Indikatoren für Shuffle, Repeat
-Playlist von Winamp (sollte Interaktiv mit Girder irgndwie zusammen laufen (UP/DOWN scrolling))

---

Desweiteren übernehme ich mal spunkys post von der letzen seite

---

Desweiteren noch hier


_{Einen parser hast du ja schon auf die beine gekriegt.... die idee war wirklich gut}

---

olaf könnte ja jetz mal stellung nehmen und sagen was möglich wäre, was schweirig wäre, und was unmöglich wäre, somit haben wir ja schon zumindest ein kleines ziel..

---

PS: brauchst du immernoch nen GLCD olaf??? wenn du in ~1woche immernoch keins hast (was wir mal nicht hoffen ;D) dann frag mich, bekomme ein 128x128(hoff ich ;D) mit t6963c controller, ich hoffe denn es läuft einwandfrei (ich sag dir dann mal bescheid)
_{Ich will dich jetz um gottes willen nicht hetzen, oder bedrängen, nur fände ich es schade wenn dieses Projekt einfach so zerfällt... ;) Weiterhin G00D Luck
Es wäre mir auch eine Ehre dir helfen zu können/dürfen ;) und einen Betatester hast du auch ;)}

Dann nehme ich doch ma Stellung...

Public IP, womöglich mit DynDNS-Auflösung wirds nicht geben. Das wird mit Sicherheit das gesamte Timing der Software total zerlegen. Die eigene IP dagegen stellt nicht das Problem dar.

WinAmp-Sektral-Analyzer würde ich gern machen (Klinki hat meinen Analyzer schon gesehen), wird aber aufgrund der schieren Datenmasse nix werden. Allerdings weiß man ja nie.
An "Shuffle" und "Repeat" sowie Playlist komme ich AFAIK nicht ran. Girder-Plugins sind bei weitem nicht so trivial, wie es aussieht... Aber man weiß ja nie.

Das mit dem Basic hab ich schon gezeigt, no thema. Die Makro-Geschichte dagegen zerfällt in drei Möglichkeiten:
- Compiler: Kein Ding, bekomme ich hin. Dann bieten sich noch ganz andere Sachen...
- JIT-Compiler: das bekomme ich mit Chance hin, starke CPU vorausgesetzt.
- Realtime-Interpreter: muß die CPU noch stärker sein.

@Klinki: Ich laß mich nicht hetzen ;D Aber ich gestehe, die Reaktion auf meine GLCD-Software ist deutlich schwächer als auf STLCD.

Fakt ist, STGLCD wird, wie STLCD auch, Freeware bleiben - auch wenn ich ein paar Oiros gut brauchen könnte. Wie gehabt, bleibt der Source bei mir. Externe Tools sind immer willkommen, Schnittstellen-Specs gebe ich gerne her.

Das dacht ich mir :'(
Nanu, mach doch nicht soviele Kanäle darein, vielleicht 5stck stereo und 5stck mono
Das liegt vielleicht daran, dass GLCD schwerer zu checken sind, man muss tierischa fpassen auf so sachen wie ob der controller drauf ist, und so, das ist halt nichts für Leute die nich soo viel Ahnung haben, die haben dann mal schnell das Geld versemmelt....Trotzdem denke ich dass das Programm schon echt praktisch wär..Mal ne sauber programmierte software für nen glcd...das ists worauf es mir ankommt..
Na. wieso kommstn da nit dran? Winamp läuft doch im shared memory modus, das kann ja nich, daran musst du kommen ;D ;)
Meinst du dass das mit Girder mgölcih wär?? ein plugin für girder machen, dann ein befehl für genau einen meiner Tastencodes, der sendet dann den Befehl an dein Programm? das geht?? cool. müsste man nur an die playlist kommen *heul*

Die Sachen sind echt kein problem, wir werden dir sovel Abnehmen wie wir können, schließlich werden wir ja nachher belohnt ;)

Ich würd vorerst mal sagen, wenn du mal nen GLCD hast (Spunky ;)) dann kannst du erst schonmal den "rohbau" machen, ist ja jetz auch nich schlimm und vora allem nicht notwendig dass alles auf einmal kommt...Erstmal ruhig anfangen, dann optimieren und Features hinzufügen

hmm,
also, ich weiss ned ob das mit der playliste an sich geht.
ich kenn nur etwas mit dem winamp plugin "albumlist" (sucht einfach mal bei sourceforge danach) da gibts bei lcdc son plugin mit dem man durch albumlist scrollen kann.

certhas

WinAmp verfügt nicht über Shared Memory. Hier muß alles per Windows-interner Message-Queue abgefragt werden.
Soweit ich Messages habe, benutze ich sie - für Playlisten gibts aber schlicht keine. Ergo: Nix Playlist. Aber es gibt Messages für Play, Stop, Next, Prev etc... Des könnte man mit Tastern oder so verknuseln.

Das nächste Problem an Winamp und seinen Plugins ist: Man kann nur eines haben. Ich hab ein Plugin für den Spektralanalyzer etc. gefunden - dann ist aber nix mit Playlist-Plugin. Vielleicht hat jemand was in der Schublade, mit dem beides zusammen geht, dann reden wir darüber.

Zum Spektralanalyzer: Der Analyzer belegt eine gewisse Fläche auf dem GLCD. Diese muß ständig und vor allem permanent aktualisiert werden. Es ist also piepsegal, ob ich 5 oder 500 Kanäle anzeige - die Fläche und somit der Zeitfaktor bleibt identisch :o Aber es gibt Hoffnung:
Nachdem ich den sensationellen Self-coded MP3-Player meines Bruder unter der Lupe hatte, ist mir ne Idee zu so einer Art "Double-Buffer-XOR"-Routine gekommen, mit der sich sowas vielleicht umgehen ließe - die Datenmenge wird nämlich auf ein paar Prozente eingedampft, dafür muß der Prozzessor kräftig rechnen und somit ist ein P4 3.2EE mindestens nötig ::)

Nur ein Scherz, natürlich wird auch Klinkis 800er P3 das packen - krieg ich schon hin ;)

Bei anderen Programmen geht das doch aus, dass er die Playlist auslesen kann...

warum kann man nur eins haben? man kann nur ein visualization plugin haben oder?

Das mit dem ständig aktualiseierne einer flächse dürfte doch auch nich das problem sein, mein "langsames" T6963C kommt damit super klar, mit Liquid MP3

Achja nix für ungut. dsa war kein 800er das war en 650er ;)
Und das andere war ein P1 200 Mhz

hab aber jetz nen XP 1700 ;)

Leute, gebt mir doch ne Chance... Ich hab ein GLCD noch nicht mal "live" gesehen, wie soll ich da beurteilen, was geht und was nicht... Schick mir doch dein T6963er zu, dann seh ich ja, was aufmich zukommt - schließlich weiß man ja nie ;D

könnt ich machen, nur müsstest du entweder warten oder die balue Leitung an dem ATX NT Board stecker anzapfen. du hast die qual der wahl

Nenn mir eine Belegung, wie ich das Display verschalten soll, und ich schicke dir ein 240x64 mit T6963C und ein SED1330 240x128. Die beiden haben ein Netzteil-Anschluss und Netzteil liegt bei.

Ein kleines 128x64 mit KS0107/108 habe ich heute bekommen. Muß ich nur noch in ein Gehäuse bauen.

Spunky

So, Leute. Hier war's lange ruhig...

Ich hab mich mal der Zeichendarstellung angenommen. Bei herausgekommen ist ein universaler Character-Zeichner, der für ein 5x7-Zeichen 141us benötigt (4us pro Pixel) - das sind etwa 7000 Zeichen pro Sekunde inklusive löschen des Hintergrundes.

Ihm ist es egal, wie groß die Zeichen tatsächlich sind (5x7 war nur ne Testeinstellung). Je mehr Pixel die Zeichen haben, desto mehr Zeit wird gebraucht und das ganze ist sehr stark von der CPU-Power abhängig.

Beim Studium des T6963c ist mir aufgefallen, das man den Bildschirm "splittet", wenn man den Zeichengenerator benutzen will - da ich LCDHype hier nicht korrekt zum funzen bringe, würde es mich interessieren, ob man dann "obere Hälfte nur Text/untere Hälfte Grafik" hat. Ist dem so, wäre das (für mich) inakzeptabel und ich verzichte auf den eigebauten Zeichengenerator. Da zeichne ich das lieber alles selbst.

Wäre das für alle anderen auch akzeptabel ?

Hey Ho,
Nur so eine kleine Idee :
Die Playlist, mit der Winamp zuletzt beendet wurde, ist immer unter C:\Programme\Winamp\winamp.m3u (natürlich nur Beispiel) zu finden, und ne Text-Datei wirst ja wohl noch auslesen können ;). Wenn du dann noch die ganzen ID3-Tags haben willst, nimm die ID3Lib (http://www.id3lib.org)! Und schon haste ne Playlist. Einziger Nachteil is halt, das dass immer die Playlist ist, die mit Winampzuletzt beendet wurde.
Naja, vielleicht hilfst trotzdem :).

cu

So, erste "wirkliche" Experimente mit GLCD's begonnen... Ich hab mir Spunkys T6963c gegriffen, angeklemmt und losgebastelt.

Es handelt sich dabei um ein 240x64-Display, Fontsize=6. Ein voller Bildschirm hat somit knapp 2KB. Es hat mich ziemlich Nerven gekostet, bis ich herausbekommen habe, wie das da alles zusammenhängt. Eimal kapiert, isses eigentlich lächerlich simpel ;)

Einen kompletten Screen über die Leitung zu jagen dauert rund 20ms (mit vollem Handshake, wohlgemerkt - für jedes gesendete Byte wird eines gelesen), was wiederum heißt, maximal 50 Fullscreen-Updates pro Sekunde :o Keiner war überraschter als ich, nach meinen bisherigen Kenntnissen wären höchsten 3 fps möglich gewesen.

Ein bissel weiter herumgerechnet folgt, das meine PIO-Routinen im Extremfall fast 100KB/s bidirektional übertragen können. Irgendwer hat mal behauptet, bei 8KB/s sei Schluß mit Lustig ;D

Nach diesen Erwartungen gebe ich mal ne Schätzung ab: wir landen am Ende bei etwa 12-15 fps - wenn mein Bitmap-Kompressor sich als Praxistauglich erweist (und notwendig ist), dürfte zudem mehr als 10% CPU-Last die Ausnahme sein.

na siehste und wer ist hier schneller mit seinem prog fertig!:)

gegen dich zu proggen macht keinen spaß, du bist einfach zu gut! ;)

wie lang haste den dran gesessen?

Okay, hast gewonnen ;)


Ach wat - ich hatte einfach Glück, schätze ich mal...


Bis zu meiner ersten Meldung etwa 7 Stunden wildes rumexperimentieren und mit dem Logic-Analyzer herumfingern.

Gerade eben ist folgendes passiert:



(http://stlcd.curz.com/ToshiGLCD.JPG)

Ist übrigens ein vom Parser eingeladenes BMP...

STGLCD unterstützt nun T6963c-kompatible GLCD's - dabei ist es noch nicht einmal richtig angefangen worden ::)

Bereits komplett integriert: Die Steuersignale (WR,RD,CE,C/D) können nach belieben auf den 4 üblichen Pins STROBE,AUTO FEED, INIT, SELECT verteilt werden. In der STGLCD.INI korrekt konfiguriert funktioniert das prima.
Einen Parserfehler im PSET-Befehl hab ich auch behoben.

[smile=0]Olaf ist der grösste!!!!!!11!!!!!!!!11[/smile] <:0> :respect:

bin ja ma gespannt wann das fertig ist

wenn ich dann ma geld hab greif ich entweder auf STLCD oder auf STGLCD zurück

[smile=0]Code King Olafst!![/smile]

[smile=1]wenn ich nur so gut coden könnte[/smile] :D

Ist doch kein Problem. Olaf hat 16 Jahre Vorsprung. Wenn du dich anstrengst, kannst du ihn bestimmt einholen. Ein Computer hast du, Delphi bekommt man als Hobby-Entwickler kostenlos und ein Text-Display für Tests könnte ich dir leihen.

Bei eBay oder auf der HobbyTronic bekommt man preiswerte Bücher für den Einstieg ins Programmieren.

Dann heisst es dir Ärmel hochkrempeln und frisch ans Werk. ;)

Spunky

Fehlt nur noch ein wenig Intelligenz, logisches Denken, Kombinationsgabe, Gedächtnis, abstraktes Denken und - auch wenn's sich blöd an hört - Disziplin...

[smile=2]Carbrögen for Coder[/smile]

@Spunky: Meine Karriere begann 1983 mit einem ZX81 (1K RAM) - es sind also 20 Jahre ;D

@jowblob: Sooo viel Intelligenz ist nicht wirklich erforderlich - erleichtert das ganze aber ungemein. Gilt auch für Kombinationsgabe. Das abstrakte Denken wird sich mehrfach potenzieren, das bringt das ganze mit sich. Am wesentlichsten ist die Logik und das Durchhaltevermögen - denn eigentlich bekommt man nur den Ärger für seine Arbeit und nur äußerst selten einen meßbaren Lohn, gleich welcher Form.

Bis der Screen da erschien habe ich 14 Stunden volles Rohr geackert und glaubt mir, so manches Haar ist ausgerissen worden. Ein Glück, das Spunky die Displays alle so schön und so Failsafe aufgebaut hat. Ich werde echt jammern, wenn die alle wieder zurückgehen müssen :'(

Ich meinte mehr das Alter. Ein bisschen Erfahrung mit Computern hat Carbrögen ja auch schon. Allerdings hatten die alten Homecomputer einen großen Vorteil. Man musste sich gleich tiefer mit den Teilen auseinander setzen. Selten hatte man gleich Zugriff auf eine Flut von fertigen Programmen. Meistens hat man die Programme aus Zeitschriften abgetippt und anschließend modifiziert. Erst mit den Floppies am C64 begann die Zeit des massenhaften Kopierens und dem einfachen Programm laden und starten.

Heute sind viele doch nur noch dumme Mäuseschubser. ;)

Aber, man kann das ändern. Man muss nur wollen, sich hinsetzen und anpacken. Praktisch ist, wenn man ein Ziel hat, was man eigentlich für ein Programm schreiben will. Einfach nur Programmieren können wollen bringt einen nicht unbedingt weiter. ;)

Auch hier gilt: Übung macht den Meister!

Spunky

Full ACK. Ohne eine (wirklich irgendeine) konkrete Aufgabe, die man sich stellt, wird das nix. Und: Anfangs sollte man Butter bei den Fischen lassen. Als bloody beginner sich an eine LCD-Software zu machen dürfte kaum Erfolgsaussichten zu haben.

Auch wenns am Anfang irgendwie lächerlich wirkt, so ein Hundertzeiler... Meister fallen nicht vom Himmel (und wenn, dann sterben sie dran) und solche Monster wie STLCD, TVBILL oder ObjectFinder entstehen in Monaten oder Jahren permanenter Arbeit. Also nicht entmutigen lassen - und nich gleich alles den Freunden zeigen ;D

So, unnu BTT ;)

Neuigkeiten in Sachen STGLCD:

User-Funktionen:

- Parser kann Bitmaps (*.BMP) einladen.

Technisches:

Der T6963c schnell genug, das ich aufs Handshake verzichten kann, was ordentlich Performance bringt. Das wird aber nicht bei allen Controllern so sein.

Weiterhin ist es mir gelungen, eine enorm schnelle Umwandel-Routine zu basteln. Letztlich wird alles, was irgendwie auf das Display kommen soll, zunächst einmal vollständig in ein Bitmap gezeichnet - somit erschieße ich auch gleich die "LCD-Vorschau", die bei LCDHype für die enormen CPU-Lasten mitverantwortlich ist ;D

Wenn alles gezeichnet ist, muß das ganze aufs Display. Das passiert in drei Schritten:
1. Die einzelnen Pixel des Bitmaps auslesen
2. Korrekten Datenblock per Barrelshifter zusammenstellen
3. Datenblock ans Display schicken

Punkt 3) dauert idR 1 ms.
Punkt 2) ist nur per Profiler meßbar (162 us)

Für Punkt 1) muß man an die einzelnen Pixel des Bitmaps rankommen ::) Es gibt da ne einfache Lösung, dann dauert das Auslesen des Bitmaps etwa 100ms (!!!!!!!). Bei nem 150ms-Takt zum Senden fliegt daher die CPU-Last durchs Dach (99.98%).

Eine ganze Woche hab ich #0!, °>|, :0# und 0=<

Nun hab ich ne Routine, die mit GetTickCount praktisch unmeßbar ist (ab und zu blitzt mal ne 16 auf, ganz selten auch ne 32). CPU-Last Null komma Null. Ich lass nun den Profiler drüberlaufen, dann weiß ich genau, wie lange das ganze dauert.

[Edit] 347.2 us für 1) und 2) zusammen, da der Einfachheit halber der Barrelshifter gleich voll integriert wurde. Diese Version ist also 288x schneller als die erste Idee und Papi hat nich eine Zeile Assembler verwendet ;D[/EDIT]

einfach :respect: ! darf ich dir demnächst deinen kaffe bringen und die schuhe putzen? ;D

PS: Du könntest die Suppe auch mal hierrein (http://www.stlcd.de/Forum/index.php?board=11;action=display;threadid=21;start=new;boardseen=1) verfassen

EDIT: ich habs mal für dich gemacht, bärli ;D ;D ;D ;D
http://www.stlcd.de/Forum/index.php?board=11;action=display;threadid=21;start=new;boardseen=1

Ist aus diesem Projekt eigentlich noch irgendwas geworden?
Das hat hier scheinbar so abrupt aufgehört.

Im Zeitalter der 64-Bit-Systeme möchte ich natürlich eine 64-Bit-Anwendung basteln. Doch was nützt diese, wenn es keine Treiber gibt, um GLCD anzusteuern ? (Kommt mir nicht mit der Krücke der unsignierten Treiber).

Ich befasse mich aber schon länger wieder mit diesem Thema...

[Edit]

Prinzipiell würde ich sagen, wir legen uns auf eine Schnittstelle fest: USB. Der Parallelport ist de facto ausgestorben, die SIO wird demnächst folgen. Bleibt nur noch USB.

Forscht man etwas weiter, trifft man unweigerlich auf die FTDI-Chips - und diese haben 64-Bit-Treiber. Mir schwebt daher eine Art Interface vor, bestehend aus USB-Buchse, FTDI und einem kleinen Atmel-µC. Ich hätte kein Problem damit, eine entsprechende Schaltung zu entwickeln - nur kann ich sie nicht ätzen bzw. die Kosten für eine professionelle Fertigung tragen. Darüberhinaus bin ich auch nicht mehr in der Lage, die SMD-Chips von FTDI aufzulöten - die Augen machens nicht mehr, trotz Brille :(

Um alles andere würde ich mich schon kümmern - Software für den µC, PC-Software etcpp.

Hi Olaf,

ich sehe das ähnlich, dass die Sache mit den 64 Bit Treiber im Moment nicht wirklich eine Lösung ist. Sieht man ja auch am gefrickel bis Ast's USB-LCD unter Win7/x64 läuft.

Was ich mal so in den Raum werfen will, sind die USB µCs von Atmel (AT90USB*). Für die gibt es (wie für den FT232) auch signierte 64 bit Treiber. Preislich liegt der AT90USB162 bei 4.50 Euro und etwa im gleichen Preissegment wie FT232 + AVR.

Geschwindigkeitstechnisch fällt V-USB nochmal raus (~20kb/s). Der FT232 schafft 3M Baud mit TTL und 1M Baud mit RS232. Die Atmel USB µCs unterstützen USB 2.0 Full-Speed sprich 12 Mbit/s. Für ein monochromes GLCD mit 240*128 Pixeln also mehr als genug.

Was das Löten angeht, so kommt man wohl um SMD nicht herum. Die AT90USB µCs haben den Vorteil, dass sie eine Single-Chip Lösung wäre. Dazu kommt, dass die AT90USB µCs einen USB-Bootloader besitzen, so braucht man auch kein ISP mehr.

µC-seitig gibt es ein paar Frameworks um das USB-Interface zu benutzen. Allen voran bietet Atmel ein solches an. Aber auch ein offenes Framework steht mit LUFA zur Verfügung.

Die Entwicklung ist natürlich etwas komplexer als die der FT232 Version.

Ich bin da eher per Zufall drauf gestossen und dachte, dass es vielleicht ein Alternative sein könnte. Was mein ihr dazu ?

Hier noch ein paar hilfreiche Links:
- http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4440
- http://www.fourwalledcubicle.com/LUFA.php

Gruß hackspider

Deine Geschwindigkeitsrechnung hat einen Haken  ;)

Ein Monochromes GLCD mit 240x128 (also schon reichlich groß) umfaßt 30720 Pixel. Da es aber monochrom ist, werden immer 8 zugleich angesprochen. Das macht, rein für die Pixeldaten, eine Minimalgeschwindigkeit von 3840 Bytes/s aus - das schafft eine serielle mit 38k4 gerade so eben (38400 Baud bei 8N1 = 3840 Bytes/s).

Mit Protokolloverhead brauchen wir vllt. 4KiB/s, das ist seriell mit 57K6 überhaupt kein Problem, mit 115K2 schon gar nicht.

Interessant wirds erst mit farbigen GLCD, wenn man mehrere Bits je Pixel braucht (16 Farben = 4Bit, Truecolor = 32Bit). Aber derartige GLCD sind für die angepeilte Klientel, die sich kaum den 8€-Atmel leisten kann, völlig indiskutabel vom Preis her  ;)

Den AT90USB schau ich mir mal genauer an, ist eine interessante Maßnahme. danke für den Schubser !

Hi Olaf,

rechnest du mit einem Bild pro Sekunde ? das sieht bei FFT-Graph von Audiosignalen aber nicht unbedingt "geschmeidig" aus.

Mal die Rechnung die ich im Kopf hatte:
240 * 128 = 30720 bits
30720 / 8 = 3840 bytes
3840 * 25 = 96000 bytes/sec
entspricht 96 kbyte/s

der FT232 und die AT90USB µCs sind dafür schnell genug, die reine Softwarevariante mit V-USB eignet sich wohl doch eher für Steuerungsaufgaben als für schnelle Datenübertragung.

Hehe bleiben wir erstmal beim monochromen Displays, aber wenn man mit 256 Farben rechnet bleibt das auch noch unter den 1M Baud vom FT232  :laugh:

So, wollte eigentlich nur kurz meine Rechnung erläutern  :)

Gruß hackspider

Gibts eigentlich irgendwo detaillierte infos über die Schnittstelle zum Display, bzw. der Befehle?
Evtl. gibts auch eine USB-Lösung ohne Extra-Treiber. Da muss ich aber erstmal schauen.

Hi Boldar,

für GLCD gibt es verschiedene Controller die wurden hier (http://www.modding-faq.de/Forum/index.php?board=13;action=display;threadid=4312&start=0]hier[/url] mal zusammengetragen. Angesteuert werden die in der Regel über einen 8 Bit Datenbus und über ein paar Steuerleitungen.

Damit man keinen Extra Treiber braucht, kann man das USB Device mit Hilfe der HID oder CDC Klassen implementieren. Betriebssysteme stellen in der Regel dafür eigene Treiber bereit. Das ganze wurde in einem gewissen Rahmen [url=http://www.modding-faq.de/Forum/index.php?topic=19355.msg158141#msg158141) schon einmal diskutiert. Olaf hatte da Einwände wegen der PC-seitigen Kommunikation zu einem HID.

Gruß hackspider

Gäbe es eine fertige Lösung, wäre sie hier längst aufgetaucht ;D Üblicherweise haben solche Fertiglösungen einen der zwei folgenden Haken:

- Sie existieren nicht
- Sie sind exorbitant teuer

Darum zermartern wir uns ja das Hirn hier  ;)

@hackspider: 25fps sind völlig überzogen. Du darfst nicht vergessen, die FFT muß auch berechnet werden (was kein Zuckerschlecken ist), anschließend passend aufs GLCD zurechtskaliert und dann übertragen werden.
Außerdem ist mit USB kein Präzisionstiming möglich, da Übertragungen nur im 50ms-Takt erfolgen (IIRC gibt es da einen Modus, wo das gehen soll, aber der ist noch komplexer zu programmieren als USB ohnehin schon ist - und ob der AT90USB den beherrscht, muß ich noch rausfinden).

Gibt es eigentlich Sockel für diese Atmels ? Ich hab schon mal bei Reichelt gestöbert, war aber nicht erfolgreich.

Reichelt hat nur sockel für DIL/DIP. SMD gibts nicht - Leider!

so schlimm ist eine FFT dann aber auch nicht! das geht ja sogar im atmel selber http://elm-chan.org/works/akilcd/report_e.html.
ein heutiger pc macht ne 128er fft mal so nebenher. das würde auch locker reichen für n spektrum auf nem lcd. und das skalieren kann auch nicht so aufwändig sein.

hingegen gibts in der tat probleme mit dem timing über usb. aber dennnoch sollten 25fps möglich sein. wenngleich 10fps auch dicke reichen würden für ein lcd.

Hi,

ich weiß nicht ob Olaf wirklich einen Sockel oder vielleicht doch eine Adapterplatine für das TQFP32 Package meinte. Also es gibt schon Sockel dafür aber sind die Dinger horende teuer. Adapterplatinen gibt es bei Reichelt schon: Nr.: RE 471EP. Sind mit >15 Euro aber auch nicht billig. Allerdings kann man sich die Platinen auch für unter 5 Euro inkl. Versand bei Ebay aus China kommen lassen.

Alternative, wäre wenn man sich selber ein Layout entwirft, dass ggf. sogar zu dem DIP Package eines ATMega16 kompatibel wäre, so könnte man bestehende Entwicklerboards verwenden. Dieses Layout könnte man selber ätzen oder ätzen lassen (www.platinenbelichter.de)

Soviel zur Hardware.

Ich geb da Olaf recht 25 FPS sind für LCDs zuviel, ich hab die Zahl einfach aus dem TV Bereich im Kopf gehabt und damit gerechnet um die Datenmenge abschätzen zu können. Aber wir können ja die Rechnung mal anderst rum aufstellen.

V-USB:
Speed: ~20Kbyte/s
Daten für ein Bild: 3840 bytes (240 x 128)
FPS = ~5.2

FT232
Speed: 3M Baud = 3Mbyte/s
Daten für ein Bild: 3840 bytes (240 x 128)
FPS = 781.25

AT90USB
Speed: 12Mbit/s = 1.5 Mbyte/s
Daten für ein Bild: 3840 bytes (240 x 128)
FPS = 390.625

Diese Berechnungen sind alle mit Vorsicht zu genießen, da kein Overhead für Protokolle mit einbezogen wurde. Was die Rechnung aber dennoch zeigt, ist das wir uns über Transfergeschwindigkeit beim FT232 oder bei den AT90USB µCs keine Sorgen machen müssen egal wie nacher die tatsächliche Bildwiederhohlrate aussieht.

Den 50ms (20Hz) Übertragungstakt ist mir bekannt, sehe ich jedoch nicht als Problem. Niemand hat gesagt, dass man pro Übertragung ein vollständiges Bild senden muss. Die GLCD Controller arbeiten, so wie ich das überflogen habe, ähnlich wie die CLCD Controller, sprich mit Datenbus und Enable (?). Somit entscheidet der Mikrocontroller wann Daten an das GLCD gesendet werden. Sprich das ganze wäre nicht timingkritisch da nicht synchron übertragen wird.

Zu letzt die PC-seitige Programmierung:
Man handhabt hier ja keine Zeichenketten mehr sondern (monochrome) Bilder. Dazu kommt, dass man mehrere Werte (FFT, CPU Load, RAM, HDD, ...) auslesen und aufbereiten muss (Ist glaub ich das was Olaf meinte ?), was sich auch auf modernen PCs als ressourcenintensiv herrausstellen kann. Wir wollen ja am liebsten STGLCD immer laufen lassen können, ohne dass es nennenswerte CPU Zeit oder RAM benötig. Da dann ohne Rücksicht auf Ressourcen zu Programmieren nur weil "mans hat" halte ich für keine guten Stil. Hier muss man (wie so oft) einen Kompromiss zwischen FPS und Ressourcenbedarf finden.

@Olaf
Mit welche Programmiersprache entwickelst du STGLCD ? (Delphi, C++, ... ?) und willst (musst) du an einer propritären Lizenz festhalten ?

Ist ein bisschen Text zusammen gekommen, ich hoffe ich hab nicht zuviel Unsinn geschrieben :laugh:

Gruß hackspider

wenn es denn darum geht, ne platine zum probieren zu erstellen und smd zu löten, würde ich mich anbieten ...  die FTDI hab ich schon erfolgreich auf ner selbst geäzten platine verlötet

evtl könnte ich dann auch für die allgemeinheit zum selbskostenpreis platinen ätzen, mal schauen

Wenn es nur um das Austesten der AT90USB-Serie geht, ist der AT90USBKEY (http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879) von Atmel sicher einen Blick wert. Kostet etwas unter 40 Euro, bringt einen AT90USB1287 mit sämtlichen externen Komponenten mit und erlaubt über Lötpads den direkten Zugriff auf alle Port-Pins.

Da sind doch einige sehr interessante Posts zusammengekommen.

Auf jeden Fall interessant ist die Testplatine mit dem AT90USB drauf. Interessanterweise steht die bei praktisch allen Händlern, die ich abgeklappert habe, auf "z.Zt. nicht lieferbar". Der Preis liegt zwischen 30 und 60€, ich konnte einen abgreifen für 30€.

Was die Sprache angeht, mit der STGLCD entwickelt wird: Ideal wäre natürlich Delphi. STLCD ist in Delphi gemacht, ich könnte also Tonnen von Code einfach übernehmen. Das Problem ist, das Codegear einfach nicht in der Lage ist, einen 64-Bit-Compiler zu basteln - ich hätte aber gern eine 64-Bit-Version.

Dann wäre da C#... Eine elegante Sprache, problemlos läßt sich damit sowohl 32- als auch 64-Bit programmieren, man hat immer die neuesten Features von Mirosoft "frei Haus" und bekommt einen kompletten Compiler für lau. Problem: .NET, P-Code und damit weitestgehend ungeschützer Sourcecode verfügbar. Außerdem bin ich noch sehr ungeübt in C#  ;D

Bliebe noch C++... Kann ich, bin nur etwas eingerostet. Umstellung von 32- auf 64-Bit-Code ist nicht ganz so simpel wie mit C#, dürfte aber gehen. Auch hier ist man immer "up to date", was Microsoft und seine Neuerungen angeht. Allerdings kann man mit der freien Version des Visual Studios praktisch unmöglich eine Windows-Anwendung basteln (man muß dann zurück in die Steinzeit und Fenster so basteln, die man es 1988 noch getan hat). Die kleinste Version davon kostet schon 500 Euros, die ich weder habe noch ausgeben will  >:(

Auch an anderer Front habe ich überlegt... z.B. die wahnwitzige Idee, Screens per Scriptsprache frei designbar zu machen. Das ist, im nachhinein überlegt, völlig schwachsinnig. Es würde aus STGLCD ein Monster an Dokumentation machen, uns hier im Forum mit Anfragen der Marke "kann mal einer [xxx] für mich basteln ?" bzw. "Ich habe hier n Script das nicht funzt - wo ist der Fehler ? [20k Spaghetticode folgen]" überschwemmen... Muß nicht sein. Alle akzeptieren bei GLCD-Software fertige Screens - also machen wir das auch so.

Auch die Frage nach den FPS ist irgendwie müßig - wir haben nicht mal n Bild auf nem GLCD produziert und grübeln schon über FPS  ;D Wollen doch erstmal sehen, ob ich Nerv genug habe, mir das ganze überhaupt anzutun ;)

Da wäre ja noch Lazarus, aber Dephi ist tot.
Wäre die wohl zukunftsweisendste Sprache.
Meiner Meinung nach eher ungeeignet. NET ist die Zukunft.
Dann sage ich halt: Ok, für 50€...
Ich würds nicht akzeptieren, und das ist der Grund, warum ich noch kein GLCD habe.
Ich habe mir für das Display in meiner G15 ein eigenes Programm geschrieben, was dieses nach meinen Wünschen ansteuert.

Aber für mich gehört zu einem LCD-Programm nicht, dass es 10k verschiedene Sachen auslesen kann, sondern dass es eine Plugin-Schnittstelle zur verfügung stellt, durch die jeder sich das selbst konfigurieren kann, z.B. über XML-Dateien.

Full ACK.
Und genau das ist der springende Punkt:
Deine Kenntnisse in Ehren, aber ich glaube nicht, dass du das alleine in den nächsten Jahren hinkriegst, zumindest nicht, wenn du sonst noch ein Leben hast ;)
Vielleicht finden sich ja hier ein paar Leute, die das als Gemeinschaftsprojekt mitmachen wollen. Ich wäre wohl dabei, ich habe auch schon einige Erfahrung mit jeder der genannten Sprachen (am meisten mit Delphi, aber das scheidet aus den oben genannten Gründen meines Erachtens aus. Aber bei einer Entwicklung in C# könnte man das sehr gut trennen; ich könnte mich z.B. mit der Entwicklung des "Frontends" befassen, also ne GUI zum konfigurieren, das zusammensetzen des Bildes und das übergeben des bildes ans "Backend", einer Plugin.Schnittstelle usw.
Im Prinzip gilt bis zu einer gewissen Grenze: je mehr Leute, desto besser.
Dort: http://www.c-sharp-forum.de gibt es z.B. ein Forum, welches sich mit C# befasst, da findet man sicherlich noch interessierte. (Ideal wären wohl so max. 5 Leute)

1. Delphi ist nicht tot. Hätten eine Reihe Leute wohl gern, doch die Community ist aktiv wie zuvor.

2. .NET ist ganz sicher nicht die Zukunft. M$ tut alles, um es zu pushen, aber für die wirklich interessanten Dinge, die über simples UI-Basteln hinausgehen, brauchts dann doch wieder das WinAPI.

3. Wenn du fertige Screens nicht akzeptieren willst, dann ist das deine Entscheidung. Du hast ja deine Software schon, wozu also STGLCD.

4. STLCD ist ebenfalls eine One-Man-Show gewesen. Die gesamte Programmierung und auch das Herausfinden der Ansteuerung für die LCDs ist komplett auf meinem Mist gewachsen. Beruflich betreue ich Programme einer Größe, gegen die STLCD ein 5-Zeiler ist, da werden mich die paar zigtausend Zeilen Code eines STGLCD ganz sicher nicht schocken.

Es sind solche Leute wie du, die sich hier hinstellen "Ich hab mir schon eine gebastelt, ich brauch deins nicht und du kriegst es eh nicht hin", die einen demotivieren.

Delphi ist tot, seit die Turbo-Versionen eingestellt wurden.
Zudem wird keine Firma ohne gute Gründe ein größeres Projekt in einer Programmiersprache anfangen, wo man von einem Compiler einer Firma abhängig ist, deren Zukunft eh wackelig ist bzw. wo in letzter zeit zweimal der Besitzer gewechselt hat.
Ich habe nie behauptet, das WinAPI aussterben wird. Allerdings wäre das eine klassische Anwendung für NET: modular aufgebaut, einfach zu debuggen usw.
Da ging es um das integrierte Display der G15, was etwas vollkommen anderes ist, da eine einfache API existiert, wo man nur auf ein Canvas malen muss.
Ok, wenn du beruflich schon so viel machst und dann privat noch zeit und Lust hast, über längere Zeit deine Freizeit dafür zu opfern...
Ich glaube, da hast du was falsch verstanden. Ich habe lediglich aufgezeigt, dass man sowas auch als Teamprojekt machen kann. Es gibt kaum (bzw. immer weniger) große Projekte, die von einem Mann im Alleingang geschrieben werden. Das weisst du als jemand, der da Beruflich mit zu tun hat, bestimmt.
Denn eine Software rein zur GLCD-Ansteuerung ist das eine, aber gerade das ganze drumherumist viel Arbeit. Und zudem denke ich, das man anderen "die Tür offen lassen" sollte, sodass zumindest die, die Ahnung vom Programmieren haben, die Software nach ihren Wünschen anpassen können. Gerade dies würde dein STGLCD dann von anderen solchen schon existierenden Programmen unterscheiden (wie z.B. LCD-Studio). Und da du scheinbar gegen open-source bist, würde ein pluginsystem genau dies ermöglichen. Dann musst du nicht alle Features selbst einbauen, sondern kannst anderen kreativen Usern diese Möglichkeit lassen. Dann kannst du nämlich den Leuten, die nach Feature xy fragen, sagen "machs doch selber und stelle es den anderen zur Verfügung", statt "nö, gibs nicht".
Das wäre einer wachsenden Community enorm förderlich.

Oh wow die Diskussion scheint hier aus dem Ruder zu laufen  :(.

Zu der ganzen Sache mit Delphi will ich mich mal raushalten, da ich mit Delphi nie wirklich programmiert hab.

Ich weiß jetzt gar nicht wo ich anfangen soll um meinen Senf dazuzuegeben. Ich probiers dennoch mal:

Programmiersprache
Ich habe in .net (sprich C#) mehr Erfahrung als mir lieb ist. .net ist bei Anfängern fast so beliebt wie Java, weil die Sprachen einiges an Arbeit abnehmen. Was mich an den beiden Sprachen stört ist der Ressourcenaufwand. Bei Java muss ich immer eine JVM mitschleppen und auch ein einfaches 'Hello World' mit C# braucht fast 10MB an RAM.
Ideologisch kommt dazu, dass Oracle im Moment anfängt andere Java basierende Projekte (Android) zu verklagen. Was ich grad bei Boldars Post grad ein wenig irritierend fand war, dass er Delphi aufgrund der Abhängigkeit zu einem Compiler und zu einem Unternehmen rügt, auf der anderen Seite jedoch .net als "die Zukunft" (sry aber ohne Hochkomma kann ich das nicht schreiben) empfindet, obwohl .net ja auch nur von einem Unternehmen (M$) abhängt.

Ich persöhnlich bevorzuge C++. Der Compiler meines Vertraues ist der g++, allerdings hab ich auch schon Projekte mit dem MSVC umgesetzt. Wenn man mit C++ entwickelt, ist man auch nicht zwangsläufig an eine (kostenpflichtige) IDE gebunden. Man kann da je nach Geschmack Eclipse CDT, Visual Studio oder so wie ich im Moment den Qt Creator verwenden. Sowieso wäre das Qt Framework eine interessante Alternative um so ein Projekt umzusetzen (?). Hier kann man dann auch den Compiler verwenden auf den man steht, sprich MSVC oder den g++. Den MSVC bekommt man kostenlos mit der VS2010 Express Edition und der g++ ist sowieso kostenfrei. Das einzige was man überprüfen müsste, ist ob der g++ Qt mit 64 bit kompilieren kann.

Fertige Screens
Kann mir irgendjemand kurz erklären, was genau damit gemeint ist ? Ich hab zwar eine Vorstellung was das sein soll bin mir in dem Punkt allerdings unsicher was ihr damit gemeit habt.

Das Projekt an sich...
... ist für einen erfahrenen Softwareentwickler ein überschaubares Projekt, was nicht heißt, dass es einfach oder schnell zu entwickeln wäre. Das Olaf SW-Projekte durchziehen kann, hat er schon bewiesen und ich sehe keinen Grund warum er das mit einer GLCD SW nicht auch schaffen sollte. Von mir wirst du nur aufbauende Kommentare erhalten :knuddel:.

Die Frage die Boldar aufwirft kann man allerdings als berechtigt ansehen: Willst du STGLCD wieder als "One-Man-Show" oder mit Unterstützung der Community entwickeln ? (oder weißt du das vielleicht ja noch gar nicht ?)

Dabei will ich es auch erstmal belassen, meine weiteren Gedanken zu der Software behalte ich jetzt erstmal für mich und schau was daraus wird. Die würden jetzt glaub ich zu viel Unruhe stiften. Vielleicht sollten wir die Dinge (Aufbau des Projektes, Programmiersprache, FPS, Plugins, Scripsprachen, ...) einzeln diskutieren dann bleibt alles übersichtlich und die Emotionen gehen nicht so schnell hoch :).

Grüße hackspider

ich verfolge das hier mit interesse. nur mal so zur Info.

@Boldar: sorry, aber fuer mich klingt deine aussage ehrlich gesagt auch eher so nach
'mach DU mal die "leichten" sachen wie treiber/ansteuerung/timing/API etc. - das "komplizierte" grafische clickibunti baue ICH mir dann ganz muehsam mit dem baukasten irgendeiner wysiwyg-programmier-suite... aber denk dran, WIR sind ein Entwickler-TEAM!'

ironie? jehova.

Ich glaube, die Diskussion über die verwendete Programmiersprache ist mindestens ebenso müßig, wie die über die FPS. Alles führt zum Ziel, es ist nur die Frage, welche Mühe man dazu auf sich nehmen will - oder welche Kompromisse man eingehen möchte.

Ich bin auch der Ansicht, das die Windows-Seite das kleinere Problem ist - eine LCD-Software braucht ganz bestimmt keine unglaublich coole, mit Klickibunti angefüllte Bedienoberfläche mit durchlöcherten Fenstern und DirectX-Support  ;).

Das viel größere ist die Atmel-Seite, denn DIE muß mit den GLCDs klarkommen. Da gibt es drei wesentliche Controller-Typen, die es zu unterstützen gilt: T6963c, die SED-Controller und den LC7981 (Ich hoffe, ich hab die Zahlen noch richtig im Kopf).

Mit vorgefertigten Screens ist gemeint: Irgendwer designt sozusagen komplett, was aufs LCD kommen soll. Die Positionen für Balken und Werte sind vorgegeben und unveränderbar. Somit haben wir als Entwickler die Möglichkeit, perfekt auf die Auflösung abgestimmte Bilder zu produzieren. Wir wissen genau, was wohin gehört und wenn wirs getestet haben, wissen wir: Es funktioniert. Das ist wichtig für den Support später.

Wenn wir zuverlässig Bilder aufs LCD kriegen, kann man immer noch übers anpassen reden.

So in der Richtung meinte ich das ja:
Es gibt da ein Plugin, was genau diese Bilder als Bitmaps einer definierten größe erzeugt. Dem Backend kann dann egal sein, was da drin ist. So kann jeder, der lust hat, das an seine Wünsche anpassen. Bloss der Kernteil, also das was die Bilder sendet, ist immer gleich. Und das ist dann halt STGLCD. Die Oberfläche ist ja nun wirklich S****ssegal. Das ist ja das mindeste an Arbeit. Ich glaube, ihr habt mich auch ein wenig falsch verstanden: Ich bot nur an, ein wenig beim ganzen "drumherum" zu helfen, also auslesen der Daten, zusammenfügen zu Bildern usw., damit sich Olaf auf das wesentliche konzentrieren kann. Und glaubt mir, es ist mir S****ssegal, ob mein name da irgendwo auftaucht. Ich werde bestimmt nie zu meinen Freunden gehen und sagen: Boah guckt mal, da steht mein name, ich bin ja soo cool.

Mit dem System könnte man nachher auch noch einen PlugIn-Builder bauen, um das konfigurierbarer zu machen. Das wäre dann nur ein letzter Schritt, aber man hält sich von Anfang an die Möglichkeit dafür offen durch eben diese strikte Trennung von auslesen/zusammenfügen der Daten und dem verschicken. So kann nämlich auch beides seperat getauscht werden, z.B. bei Updates oder Unterstützung neuer Controller.
Für sowas gibt es auch schon fertige, leicht zu implementierende Schnittstellen.

Moin zusammen,

Ich lass jetzt mal absichtlich die Diskussion um vordefinierte Screens und generelle Konfigurierungsideen außen vor und folge dem Vorschlag uns erstmal um die Ansteuerung der LCDs zu kümmern.

Controller
Ich hab mal aus diesem Thread einen USB-Multicontrol (http://www.modding-faq.de/Forum/index.php?topic=4160.msg46063#msg46063]Post[/url] ausgegraben. Da waren folgende Controller gelistet:
- T6963
- HD61830 / LC7981
- SED1330
- SED1520
- KS0108

und irgendwo hier drin hab ich auch gelesen, dass man mit dem T6963 wohl die große Masse erschlagen würde. Mein Vorschlag wäre mit diesem Controller anzufangen, soweit Hardware zum Testen vorhanden ist (?).

Hardware

<lautDenken>
Muss den der AVR alle Controller kennen ? Kann man ihn nicht in diesem Punkt "dumm" halten ? Kann man nicht dem AVR jegliche Ansteuerlogik entziehen und diese auf die performante PC Seite verlagern ?

Warum nicht alle GLCD Routinen in den AVR schreiben ? Nunja Speicher genug müsste dieser ja haben. Einerseits scheint es ja logisch zu sein Komplexität von einem schwachen Gerät (USB device) auf ein starkes Gerät (PC) zu verlagern. Andererseits warum sollte man den AVR nicht komplett ausnutzen ?
</lautDenken>

Meine Idee wäre, dass der AVR wirklich nur Daten entgegennimmt und diese an zwei 8 Bit Ports (1x Steuerport 1x Datenport) ausgibt.

Diese Gedanken sind aber nicht in der Komplextätsverlagerung oder Ressourcenschonung begründet, sondern hängt mit der Erweiterbarkeit zusammen. Man kann so eine nahezu unbegrenzte Anzahl an Controller unterstützen. Wie man diese Controllerunterstützung erweitern kann: virtuelle Klasse / Configdatei / Plugins will ich an dieser Stelle nicht wieder ausgraben.

Im Hinterkopf bei dieser Überlegeung hatte ich die Nachbauer, die das Ding einmal aufbauen und dann nie wieder anfassen wollen (also keine neue Firmware flashen). Ähnlich zu dem [url=http://www.modding-faq.de/Forum/index.php?topic=19355.0) woran ich immer mal wieder ein bisschen rumentwickel, könnte man die Hardware auch für andere Aufgaben verwenden (z.B. CPU-Auslastung, LED-Steuerung, VU-Meter, ...). Aber das nur am Rande, ist ja sicher keine Kernanforderung.

Dieser Ansatz hat auch Nachteile über die man sich Gedanken machen muss. Möchte man ein Byte am Datenbus übertragen und nur am Enable Pin "wackeln", überträgt man statt einem Byte gleich mal vier (2x Steuerport 2x Datenport). Auch wenn die Transfergeschwindigkeit das ohne Probleme zulässt, ist das alles andere als ressourcensparend.

Ein möglicher Workaround ist, dass man die Firmware auf dem AVR, semi-intelligent entwirft. Man teilt dem AVR einfach mit, welches der Enable Pin ist und er "wackelt", nach jedem Datenbyte, automatisch an diesem Pin. Der Overhead an Datenübertragung beschränkt sich dann auf einen einmaligen Steuerbefehl um dem AVR den Enable Pin bekannt zu machen. Beim Übertragen des Payload entsteht dann kein Overhead mehr.

Das kann man jetzt alles wieder kontrovers diskutieren, deshalb: Was haltet ihr von der Idee ?

Gruß hackspider

Ich hab gerade den AT90USBKEY (ein AT90 USB mit 128k Flash und 8K SRAM - massenhaft Platz zum austoben) geliefert bekommen und schon mal erste Gehversuche machen können. Atmel hat es geschafft, die Sache wirklich ernstlich leicht zu gestalten  ;D

Nach dem Auspacken stöpselt man den AT90 mit dem mitgelieferten Kabel an den USB an und Win7 beginnt dann mit einer großen Tirade an "DingDong"s :P Das Ding meldet eine Tastatur, eine Maus, einen Massenspeicher (!) und ein HID-konformes Gerät an. Nun, das HID-konforme Gerät ist das einfachste - wäre es nicht so ein irrer Krampf, PC-seitig HID zu machen  :'(
Atmel hat aber seine Hausaufgaben gemacht und packt einen Satz DLLs mit bei (alles auf dem Massenspeicher), die einem das ganze HID-Geraffel komplett vom Hals halten. Weiterhin gibt es da eine höchst interessante Routine, mit der man die Länge eines HID-Frames abfragen muß... Das hat mich in helle Aufregung versetzt ;D

Ein wichtiger Punkt wäre damit auf jeden Fall geklärt: Es kann und wird eine Windows-7-taugliche Lösung geben, wenn wir das HID-Interface benutzen und wenn Atmel es uns so leicht macht, wären wir schön blöd, würden wir nicht mitziehen, oder ? Darüberhinaus ist auch das Thema "und was ist mit Windows 8,9,A,B,C ?" vom Tisch - HID bleibt HID und wird funktionieren. Einzig die PC-seitige Software muß ggf. angepaßt werden, selbst Linuxer und Macser könnten sich was basteln.

Das geht natürlich nur, wenn wir die Aufgaben teilen: Der PC kümmert sich um das Sammeln der Informationen und bereitet das Image vor, das aufs LCD kommt. Außerdem pustet er die Daten über den USB-Bus raus. Diese Sache wäre also auf jedem System anders zu implementieren, je nachdem ob Win, Linux, Max, Solaris oder good old C-64 ;D, von jedermann zu bewältigen, der ein paar Systeminfos abfragen kann.

Der Atmel wiederum ist geradezu prädestiniert dafür, so ein GLCD anzusteuern. Die USB-Versionen laufen eh mit 16MHz (USB erfordert zwingend einen 48MHz-Takt), wir haben also Power ohne Ende auf dem Atmel. Würde aber auch darin resultieren, das wir pro Controller eine Firmware-Version haben (alle Controller-Chips in eins zu gießen ist IMHO nicht so klug, Erfahrung von STLCD).

Das heißt: Wer es nachbauen will, flasht die passende FW zu seinem GLCD in den Chip und damit ist das ganze vergessen. Das einzige, was sich ab da ändert, ist ggf. die Host-Software auf dem PC. Flashen muß er sowieso, der geneigte Bastler wird also eh gezwungen, seine Murmel anzustrengen und sich zu informieren, was für ein Controller da drauf ist. Änderungen an der Atmel-FW werden m.E. nur äußerst selten aufkommen, so das das sicher kein Problem sein wird.

Der geneigte Bastler, der also frisch sein AmigaOS installiert hat, muß sich nur noch um seine Daten kümmern, die er anzeigen will. Der ganze technische Firlefanz, wie man ein LCD ansteuert, interessiert ihn nicht - braucht ihn so auch nicht zu interessieren.

To be discussed.

Wenn der Atmel eh so viel Power hat, könnte man die ja auch nutzen und bestimmte Sachen direkt daruf ausführen. Z.B. Bilder cachen, die dann nicht jedesmal gesendet werden müssen, oder auch "Tabs" verwalten.
Also ist der Stand jetzt bei 3 Teilen?
Atmel <----> PC-Backend <----> PC-Datensammler

Der preis wäre dann so bei 20€, wenn ichs richtig verstanden habe?


Das würde dann ja schonmal viele Probleme lösen.

Hi,

nett das schon jemand Hardware zum loslegen bei sich zu Hause hat. Was ich da lesen hört sich nach einer Menge Spass an :laugh:.

Das mit dem Power ohne Ende stimmt schon der AT90USBKEY hat afair einen AT90USB1287 drauf, mit dem geht schon einiges. Aber für den Nachbau seh ich da ein paar Nachteile: Der AVR ist für die Aufgabe maßlos überdimensioniert, für die finale Umsetztung würde ich einen kleineren Controller aus der AT90SUB Reihe vorschlagen. Dazu kommt, dass der AT90USB1287 gegenüber dem AT90USB162 um einen Faktor ~3 teurer ist: Von low-cost kann dann nicht mehr die Rede sein. Zum Testen und Spasshaben ist dicke AVR aber optimal ;D.

Alle verschiedene Bibliotheken für die verschiedenen Controller auf eine Firmware zu packen halte ich, so wie Olaf, als nicht praktikabel. Ich hab, einfach so aus Spass mal, eine T6963 library mit einem kleinen Sample zusammen kompiliert, der benötigte Flash dazu war ~9 kbyte groß und da ist noch kein einizges byte für die USB-Ansteuerung verwendet. Wissen tu ich es nicht genau, aber ich kann mir vorstellen, dass es für die anderen GLCD Controller ähnlich aussieht.

Eine Lösung mit verschiedenen Firmware Versionen halte ich aber auch nicht für den richtigen Weg. Jede Faser meines SW Entwickler Körpers schreit da nach einem (ich hoffe die MDSD Entwickler verzeihen mir das jetzt) variabilitäts Punkt. Meiner Meinung nach ist die Entwicklung der Ansteuerungslogik PC seitig einfacher und effektiver. Aus persöhnlicher Erfahrung tun sich Entwickler mit dem Einstieg in die Programmierung auf embedded Geräten schwerer als wenn sie einfach nur eine virtuelle Klasse (oder für die .net und Java Entwickler "Interface") implementieren müssen. Ist jetzt subjektiv und bitte widersprecht mir wenn ich in dem Punkt falsch liege. Erweiterungsstrukturen habe sich schon bei anderen LCD Programmen als praktikabel erwiesen und dienen darüber hinaus auch Langlebigkeit und der Akzeptanz der Anwender.

Ich persöhnlich würde eine single-firmware Lösung präferieren, bei der die Ansteuerlogik in einer Zwischenschicht liegt. Vergleichbar zum USB-LCD von Ast nur das man die Logik in die DLL implementieren würde, wobei es verschiedene DLLs für die jeweiligen Controller gibt.

Mit meiner Einschätzung lass ich euch jetzt mal allein :).

Gruß hackspider

PS: Wenn der Durchsatz mit einem HID device passt, dann steht der Umsetzung mit einem solchen nichts im Wege.

Nun, prinzipiell hast du recht - der USBKEY ist überdimensioniert. Oder doch nicht ? Die einzelnen AT90USB unterscheiden sich im wesentlichen nur noch durch die Größe des Flash und des SRAM. Taktraten sind durch USB vorgegeben - die Rechenpower steht also eh zur Verfügung, alle AT90USB gibts mit 16MHz.

Ach ja... Wer hat was von Low-Cost gesagt ? Wenn es eine gewisse Grenze überschreitet - sagen wir mal 30€ - dann sind die Leute deutlich vorsichtiger, wenn es um den Aufbau geht...

Kommen wir zum interessanten Teil  ;D 9k für ne T6963-Lib ist gigantisch. Was hast du da alles mit einprogrammiert ? Einen Basic-Interpreter samt 2-Pass-Assembler ? ;D ;D ;D

Was den Punkt einzelne Firmwares angeht: Ich mag dir zustimmen, wenn es hunderte von Firmwares geben würde. Oder sich diese alle Nase lang ändern würden. Tatsache ist aber: Es gibt ganze 5 (!) Controllerchips, die uns hier bisher untergekommen sind, von denen sind volle 2 (!) wirklich verbreitet (Ich selbst habe nur 3 GLCD-Controller hier vorliegen). Die Anzahl der Änderungen an den Controllerchips - und damit an der Ansteuerung derselben - in den letzten drei Jahren war genau Null. Wozu dem PC eine Sache auflasten, die ihn kein Stück interessiert - während der Atmel mit seiner Rechenpower primär im Sleepmodus liegt ? Wir implementieren die FW genau einmal und fassen sie dann nie wieder an. Alles andere läßt sich mit anders gelegten Kabeln lösen  ;) Dem PC, was der PC gut kann - dem Atmel, was der Atmel gut kann.

Im übrigen: Eine Abstraktionsschicht habe ich schon für STLCD versucht zu implementieren - und bin gescheitert. Die Controller sind einfach zu unterschiedlich, um sie alle auf einen Nenner bringen zu können. Das wird mit den GLCD kaum anders sein.

Nun: Warum bin ich so ein Verfechter dieser Lösung ? Sehr einfach: Ich habe ein Funktionsprinzip im Kopf, das ich gern umsetzen würde. Im Prinzip senden wir die Grafikdaten en bloc an den Atmel - natürlich in kleine Happen geteilt. Ob nun 4 oder 8 oder 128 Bytes je Happen ist egal. Zusätzlich zur Framegröße stellen wir ein Byte voran, wir senden also 1+n Bytes je Frame. In diesem einen Byte sind Steuerinfos drin - von denen wir allerdings erstmal nur ein Bit brauchen. Ist dieses gesetzt, weiß der Atmel, das das Bild neu beginnt (eine Art VSync also). Wie jagen also ein Steuerbyte plus n Byte Payload über den Bus. Mag sich verschwenderisch anhören, aber die Erfahrung zeigt: Irgendwann wirst du sie brauchen, die anderen Bits  ;)

Da Atmel-seitig USB-Transfers per Interrupt abgewickelt werden, laufen hier quasi zwei Prozesse: Ein Interrupt-Driven Process, der die USB-Daten empfängt und im SRAM ablegt; Die übrige Zeit werden die Daten als LCD gesendet. Wir haben dadurch sehr hohe Frameraten (bei 16MHz sollten 25fps wirklich locker gehen). Einzig könnten wir uns Tearing einhandeln, halte das aber für eher unwahrscheinlich.

Problem: Wir brauchen SRAM. bei 240x128 Pixeln 3840 Bytes, bei 320x240 sind es 9600 Bytes. Erfordert also den Einsatz eines AT90USB64x bzw. ein externes SRAM - und wenn wir uns das trauen, sind der LCD-Größe dann auch beinahe keine Grenzen gesetzt (und der Controller kann dann auch ein AT90USB8xx sein).

Das ganze Prinzip macht die Software-Entwicklung leicht: Wir implementieren einmal die USB-Transfergeschichte samt einschreiben ins SRAM - sie ist bei allen GLCD eh gleich. Anschließend implementieren wir das simpelstmögliche Ansteuern des GLCD: Einfach von Anfang bis Ende Daten reinschreiben. Keine Positionsberechnungen, keine Cursorgeschichten, nada.

Auf PC-Seite können wir uns dann richtig austoben: Denn wie der Screen aussieht, der ans LCD geht, liegt exklusiv in des Script-Kiddies Hand  ;D ;D Wer immer will, kann eine Software basteln und die Daten ans GLCD senden - solange die passende FW drauf ist, wird es funktionieren.
Kein Studium von Datenblättern "wie steuer ich das GLCD an", kein lernen "wie implementier ich denn nu ne Klasse, hab doch nur K&R-C gelernt *weinweinwein*". Nein. DLL benutzen, Bitmap im PC erzeugen, rüberpusten, Stolz sein.

[Edit]
Ich habt recht, das Prinzip ist doof. Macht ihr euer Ding, ich mach das hier und verkauf es dann für nen Zehner pro Stück. Mach ich n Vermögen mit.
[/Edit]

Ich hoffe man nimmt mir das nicht übel, wenn ich den Thread ausgrabe, aber dürfte man fragen, ob sich was getan hat?

Seit Delphi XE2 kann man ja für 64bit kompilieren was das 64bit Problem lösen dürfte. Oder gibts ein anderes Problem?

problem is relativ, man bzw. olaf muss sich die zeit nehmen bzw. zeit finden um so ein projekt anzugehen. dabei stellt sich momentan die frage wie viele nutzer es noch geben wird.

wenn du dir die aktivität hier im forum anschaust und wie sich pc-modding die letzten jahre entwickelt hat, denke ich mal ist dir auch klar warum sich hier seit 2010 nichts mehr getan hat.

natürlich kannst du gerne eine neue software programmieren, wir würden dich dabei mit sicherheit unterstützen.  :bestens: