Autor
|
Thema: Was bräuchte eine ordentliche GLCD-Software ? (Gelesen 126289 mal)
|
OlafSt
Global Moderator
Karma: +13/-0
 Offline
Geschlecht: 
Beiträge: 2138
Master of STLCD and LISA III
|
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. 
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 
So, unnu BTT
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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
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 [/EDIT]
|
|
|
|
« Letzte Änderung: Januar 25, 2004, 14:54:24 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Klinkerstein
Gast
|
einfach :respect: ! darf ich dir demnächst deinen kaffe bringen und die schuhe putzen?
PS: Du könntest die Suppe auch mal hierrein verfassen
EDIT: ich habs mal für dich gemacht, bärli
http://www.stlcd.de/Forum/inde...new;boardseen=1
|
|
|
|
« Letzte Änderung: Januar 25, 2004, 15:45:29 von Klinkerstein »
|
Gespeichert
|
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
Ist aus diesem Projekt eigentlich noch irgendwas geworden?
Das hat hier scheinbar so abrupt aufgehört.
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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.
|
|
|
|
« Letzte Änderung: August 16, 2010, 11:57:11 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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/produ...sp?tool_id=4440
- http://www.fourwalledcubicle.com/LUFA.php
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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 !
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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Â 
So, wollte eigentlich nur kurz meine Rechnung erläutern 
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
Boldar
LCD-Checker
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 238
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi Boldar,
für GLCD gibt es verschiedene Controller die wurden hier 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 hier schon einmal diskutiert. Olaf hatte da Einwände wegen der PC-seitigen Kommunikation zu einem HID.
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
BrainHunter
Kathodenjünger
Karma: +0/-0
Offline
Geschlecht:
Beiträge: 96
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
|
|
|
