|
46
|
Alles rund ums Modden / Elektronik, Elektrik / Re: Spannung invertieren
|
am: September 30, 2010, 21:57:56
|
Hallo,
wie wäre es mit einem 5V DC - 5V DV Wandler (reichelt: SIM1-0505 SIL4) ?
Die Dinger sind galvanisch getrennt, sodas man den positiven Ausgang auf Masse legen kann und am negativen Ausgang liegen dann gewünschte -5V an.
Vielleicht ein kleiner Denkanstoss.
Gruß hackspider |
|
|
|
|
47
|
Alles rund ums Modden / Tutorials / Re: USB-LCD Lowcost Edition
|
am: September 2, 2010, 20:31:38
|
Hi Overclocked,
Scheint mir als hättest du Schritt 4 und 5 nicht durchgeführt, jedenfalls deinen beschrieben Symptomen nach.
Einfach nochmal diese Schritte abarbeiten und die richtige DLL ins STLCD Verzeichnis kopieren und schon sollte das Ganze funktionieren.
Gruß hackspider |
|
|
|
|
48
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 20, 2010, 19:52:36
|
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. |
|
|
|
|
49
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 20, 2010, 10:01:47
|
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 |
|
|
|
|
50
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 18, 2010, 18:04:26
|
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 |
|
|
|
|
51
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 17, 2010, 18:12:57
|
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 |
|
|
|
|
52
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 17, 2010, 06:47:21
|
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 |
|
|
|
|
53
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 16, 2010, 17:24:16
|
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 |
|
|
|
|
54
|
LCDs und -Software / LCDs Allgemein / Re: Was bräuchte eine ordentliche GLCD-Software ?
|
am: August 16, 2010, 12:11:31
|
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 |
|
|
|
|
56
|
Alles rund ums Modden / Elektronik, Elektrik / Re: [Tutorial] kapazitiver Sensor - Teil 1 (Taster)
|
am: Juli 27, 2010, 08:47:17
|
Hi TT_Kreischwurst,
ein sehr schönes Tutorial und ich denke die kapazitiven Taster/Schalter kann man in Mods gut plazieren. Man braucht halt nicht für alles extra Schalter, sondern man kann die Kontakte ganz dezent hinter ein lackiertes Stück Plexiglas verstecken.
Ich schlag einfach mal den Eintrag in die Tutorialliste der Haupseite vor ?
Ganz kurze technische Frage: Ich hatte mal die Layout-Designs der QTouch library von Atmel angeschaut, die schlagen vor, nahe an der Sensorfläche eine Massefläche zu plazieren, damit sicherer ausgelöst wird, sollte man das für diese Lösung hier auch machen ?
Also dann weiter so und 
Gruß hackspider |
|
|
|
|
57
|
Alles rund ums Modden / Tutorials / Re: USB-LCD Lowcost Edition
|
am: Juli 21, 2010, 18:10:49
|
Hi Davemoon,
da STLCD keine Angaben über eine mögliche Lizenz macht, bin ich vorsichtig mit dem Hochladen von fremden Content. Bei der DLL von Ast ist das kein Problem, die steht unter GPL da geht sowas bedenkenlos.
Für deinen konkreten Fall ist das allerdings egal, wie du schon sagtest, die Beleuchtung zu steuern funktioniert ja. Also ist das eher ein Hardwareproblem und hat eigentlich nichts mit der Software zu tun.
Hast du vielleicht noch einen Windows XP System, bei dem du die Hardware testen kannst ? Das wäre eine Möglichkeit herauszufinden, ob es an der Hard- oder Software liegt.
Mit LCD auf aktiv setzen, meinte ich das Häckchen "LCD aktiv" in STLCD zu setzten.
Gruß hackspider |
|
|
|
|
58
|
Alles rund ums Modden / Tutorials / Re: USB-LCD Lowcost Edition
|
am: Juli 21, 2010, 17:26:11
|
Hi Davemoon,
Wenn du die Beleuchtung an und auschalten kannst, ist das erstmal ein sehr gutes Zeichen. Das bedeutet nämlich, dass der Treiber, die DLL und STLCD funktionieren. Das Problem könnte dann bei den Verbindungen zwischen µC und LCD liegen.
Wird denn das LCD initialisiert ? (verschwinden die schwarzen Balken ?)
Ich geh mal davon aus, das LCD auf aktiv gesetzt wurde (?)
Gruß hackspider |
|
|
|
|
59
|
Alles rund ums Modden / Tutorials / Re: USB-LCD Lowcost Edition
|
am: Juli 21, 2010, 12:13:37
|
Hallo zusammen,
ich habe meine letzte Prüfungsleistung für dieses Semester abgegeben und hatte mal wieder ein bisschen Zeit mich mit dem Windows 7 x64 Problem auseinanderzusetzen.
Also mal wieder ein
Update:
Ich habe mir Ast's USB-LCD Hardware mal auf dem Steckbrett aufgebaut, um nicht nur softwareseitig das Ganze testen zu können. Als nächsten Schritt habe ich wie in dem Post hier den Testsigning Mode aktiviert und die Treiber installiert.
Die DLL die ich vor ein paar Monaten hier hochgeladen hatte funktionierte nicht, auch die 64-bit Version der DLL ging nicht.
Also habe ich mir nochmal den Quellcode von Ast gezogen und dazu die aktuelle libusb-win32. Alles durch den Kompiler und Linker gejagt und es funktioniert (jedenfalls bei mir).
Die DLL kann hier heruntergleaden werden.
Setup:
Windows 7 Ultimate x64
STLCD 1.4.0.42
libusb-win32 1.2.0.0 (nur interessant für Entwickler)
Visual Studio 2010 Ultimate (nur interessant für Entwickler)
STLCD Config:
Port=USB
LCDType=5
Hier noch zwei Bilder des Aufbaus in Action:
Wäre nett, wenn jemand außer mir das nochmal testen könnte und kurz Rückmeldung geben würde obs geht.
Gruß hackspider |
|
|
|
|
60
|
Alles rund ums Modden / Tutorials / Re: USB-LCD Lowcost Edition
|
am: Juni 7, 2010, 19:43:18
|
Hi, L.B.
kann es sein, dass du das "Testsigning" mit der hier beschriebenen Abschaltung der "Erzwungenen Treibersignierung" verwechselts ?
Das Anschalten des Testsinging Modes hat keinen Einfluss auf bestehende Treiber. Genauere Infos findet man dazu bei Microsoft: Hier und Hier
Gruß hackspider |
|
|
|
|
|
Zeige Beiträge
