Autor
|
Thema: Was bräuchte eine ordentliche GLCD-Software ? (Gelesen 126306 mal)
|
OlafSt
Global Moderator
Karma: +13/-0
 Offline
Geschlecht: 
Beiträge: 2138
Master of STLCD and LISA III
|
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# 
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 Wollen doch erstmal sehen, ob ich Nerv genug habe, mir das ganze überhaupt anzutun 
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
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.
Da wäre ja noch Lazarus, aber Dephi ist tot.
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#Â
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 ?"
Dann sage ich halt: Ok, für 50€...
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.
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.
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Â
Wollen doch erstmal sehen, ob ich Nerv genug habe, mir das ganze überhaupt anzutun
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)
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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.
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
1. Delphi ist nicht tot. Hätten eine Reihe Leute wohl gern, doch die Community ist aktiv wie zuvor.
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.
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.
Ich habe nie behauptet, das WinAPI aussterben wird. Allerdings wäre das eine klassische Anwendung für NET: modular aufgebaut, einfach zu debuggen usw.
3. Wenn du fertige Screens nicht akzeptieren willst, dann ist das deine Entscheidung. Du hast ja deine Software schon, wozu also STGLCD.
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.
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.
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...
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.
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.
|
|
|
|
« Letzte Änderung: August 18, 2010, 18:33:07 von Boldar »
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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  .
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
|
|
|
|
|
Gespeichert
|
|
|
|
Falzo
Diktator vom Dienst
Administrator
Karma: +15/-0
Offline
Geschlecht:
Beiträge: 5088
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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.
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
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.
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.
|
|
|
|
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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 Post 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 USB-Multicontrol 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
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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Â
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  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
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 , 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.
|
|
|
|
« Letzte Änderung: August 20, 2010, 17:58:16 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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  .
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 .
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.
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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 9k für ne T6963-Lib ist gigantisch. Was hast du da alles mit einprogrammiert ? Einen Basic-Interpreter samt 2-Pass-Assembler ?
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 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]
|
|
|
|
« Letzte Änderung: August 21, 2010, 10:35:55 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
|
|
xonom
Modding MacGyver
Karma: +5/-0
Offline
Geschlecht:
Beiträge: 779
|
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. 
|
|
|
|
|
Gespeichert
|
|
|
|
|
