Ich würde mir gerne eine Grafikkarte zum Anschluss an µC bauen und suche "Mitstreiter" dafür. Das Teil kann z.B. an AVR, AVR32, ARM, usw. betrieben werden und Displays (TFT, LCD) und CRTs bis 800x600x16 oder TV-Geräte ansteuern. Das Gerätchen ist etwa ab hier Beitrag "Re: VGA Grafikkarte mit AVR und 8MB SDRAM" entstanden. Ich habe die Schaltung in folgenden Punkten abgeändert: - S1D13506 und EDO-RAM werden mit 3,3V betrieben, da ich nur 3,3V-RAM gefunden habe (für "PAL-Betrieb" sind dennoch 5V Eingangsspannung nötig) - Ausgangstreiber wurden ersetzt (wegen Umstellung auf 3,3V) und sind nun TSSOP- statt SO-Bauform - LT3463-Schaltung hinzugefügt um evtl. nötige LCD-(Bias-)Spannungen (max. +40V & max. -40V) "onboard" generieren zu können Beide Versionen sind Pinkompatibel, allerdings verträgt die "neue" Version max. 3,8V an den Eingängen und KEINE 5V-Pegel. LT3463- und/oder CRT/TV-Teil können auch weggelassen werden, falls nicht benötigt. Der LT3463 dürfte etwas schwierig zu Löten sein. Ich habe das Decal so erstellt, dass jedes Pad etwa 1mm über den Bauteilrand ragt und denke dass es so lötbar ist. Von dieser neuen Version existiert noch kein Prototyp, weswegen es keine Funktionsgarantie geben kann. Die Usprungsversion funktioniert aber und die Daten zur neuen Version wurden mehrfach geprüft. Preislich liegt das Ganze zwischen ~20€ und ~30€, je nach Ausbaustufe, zzgl. PCB. Für die Platine kommen dann noch max. $9,53 (6,20€) plus anteiliges Porto dazu. Und zuletzt noch das Porto zu euch (6€ für versicherten Versand inkl. einem kleinen Aufpreis für Zoll). Im Zip-File findet sich eine Aufstellung der Bauteile und Preise und der Schaltplan. Falls Interesse besteht würde ich die Platinen, die Sachen bei Digikey und die EDO-RAMs bestellen und dann an euch verschicken. Zuerst geht es aber nur um generelles Interesse.
Mit dem Controller können sowohl Monochrom- als auch Farb-LCDs und TFTs mit einer Auflösung von max. 800x600 (und max. 16bit Farbtiefe) angesteuert werden. Es ist auch möglich ein LCD und ein CRT gleichzeitig zu betreiben. Um die Kostengeschichte etwas übersichtlicher zu machen habe ich die Excel-Datei etwas überarbeitet. Es sind nun alle nötigen Teile enthalten und der Endpreis kann berechnet werden. Dazu einfach in Spalte G hinter den Bauteilbezeichnungen eingeben wie viele "Sets" gewünscht sind (also nicht 3 bei den Treibern eingeben, sondern 1). "Minimal" beinhaltet nur den Hauptteil ohne TV und LCD-Bias-Teile (~28€), bei "Maximal" sind alle Teile enthalten (~37€). Bei Versand- und Platinenkosten bin ich von 10St. ausgegangen - wenn mehr Leute mitmachen wird es noch günstiger. Es ist natürlich auch möglich nur Platinen oder nur Teile zu bekommen.
Hallo, wird es auch eine fertig bestückte Platine geben? Viele Grüße Siegfried
Es war nicht geplant sowas anzubieten. Hast du Bedenken wegen der Löterei oder möchtest du es getestet haben?
Mein Problem ist das Löten. Kalkulier doch bitte den Preis einer bestückten Platine und poste den Betrag. Vielleicht melden sich noch ein paar Leute, die auch einen fertigen Grafikcontroller möchten.
Das mit dem Bestücken ist vermutlich nicht so einfach: Bei so kleinen Stückzahlen, lohnt sich industrielles Bestücken nicht. Löten in einem Lötofen wird auch zu teuer, da alleine die Schablone für die Lötpaste schon irgendwo bei 50€ liegt. Da sollten es schon mindestens 20-30 Platinen sein, damit sich das lohnt. Bleibt also nur Handlöten, verbunden mit dem Risiko für den Lötenden. Wenn ich das also löten würde (was ich aber nicht mache, da 0,4mm für mich wirklich teilweise echt grenzwertig ist, und es daher bei mir nicht wirklich gut aussieht), würde ich schon 10-20€ dafür verlangen.
Für mich wäre es machbar 0,4mm Pitch von Hand zu löten. Wenn Interesse besteht schaue ich mir mal die Platine an. Je nach dem würde ich es anbieten, diese für 15-20€ zu bestücken, aber ohne Funktionsgarantie!
Mir ist schon klar, dass eine Serie sich erst ab 50 Stück - oder so - lohnt. Aber es kann gut sein, dass sich im Laufe der kommenden Woche noch Leute melden, die auch an einer bestückten Platine interessiert sind. Hier ein fünf Punkte Plan: - Bestellungen annehmen - Geld einsammeln - Platinen fertigen - Pakete versenden - Grafikcontroller einsetzen Beim zweiten Punkt sehe ich natürlich die üblichen Probleme.
Naja wenn es bei ein paar Ausnahmen bleibt, würde ich mich evtl. schon bereit erklären die anspruchsvolleren Bauteile (vor allem S1D13506 und LT3463 und evtl. noch die xxx245) zu löten. Ohne Funktionsgarantie - ich habe da aber keine Bedenken. Die restlichen Teile sind ja mindestens 0805 oder größer und dürften kein Problem sein, oder doch? @ Siegfried > - Platinen fertigen > - Pakete versenden > - Grafikcontroller einsetzen Was meinst du bei diesen Punkten im Einzelnen? Bei Punkt 2 habe ich weniger Bedenken - bei meiner MiniLA-Sammelbestellung vor ein paar Monaten gab es keine Probleme. Aber trotzdem: toitoitoi...
Hallo Michael, klar das ich dabei bin. Ich nehme 1 mal die max.Bestückung + Leiterplatte Gruß Udo
Hallo Michael, mich würde eine Sammelbestellung für ein funktionierendes projekt auch interessieren, ich habe in dem anderen Thread langsam den Überblick verloren, gibt es einen Ort, wo alles zum Projekt, also Schaltplan, Layout, Sourcecodes etc in aktueller Version vorhanden ist? Soweit ich verstanden habe bezieht sich dein Board auf jenes Projekt, und ist nur in der HW leicht unterschiedlich, und ich nehme an unkritisch (wenn die 3 Dinge die einzigen Änderungen sind). Ich würde dann auch gerne bei einer Sammelbestellung+Sammellayoutfertigung mitmachen... Gruß Moritz (email: nemidunam at aol punkt com)
Michael, wenn das wieder so gut wie beim minila läuft, wo ich genau gesagt bekomme was ich noch zusätzlich kaufen muss und danach nur noch alles zusammenlöten muss. na dann bin ich wieder dabei. mein minila läuft klasse und für so ne vga karte htte ich auch verwendung! Daniel
Hallo Michael Auch ich hätte Interesse an einer solchen Graka. Gruß Josef
@Michael Mein Gedanke war, dass jemand 50 Grafikkarten komplett aufbaut und anbietet. Die 5 Punkte sind einfach so aus dem Stegreif entstanden.
Hallo Michael, ich bin auch interessiert an einem Max-Paket + Leiterplatte gruß Sebastian (Sebastian.Wawersig aet googlemail dot com)
Ich habe die Schaltung nochmal etwas geändert, so dass der S1D13506 und das RAM auch mit 5V betrieben werden können. Um passenden Speicher müsst ihr euch aber selber kümmern - ich habe nichts gefunden. @ Siegfried Das ist mir etwas zu heikel - ich werde nur soviel bestellen, wie Leute mit machen wollen und bezahlt haben.
>Mein Gedanke war, dass jemand 50 Grafikkarten komplett aufbaut und >anbietet. Mit komplett anbieten wird das schwierig, schon wegen der rechtlichen Situation. Also besser als Bausatz...
Wer sich's nicht zutraut SMD zu löten, dem kann ich's löten. Aber auch ohne Garantie oder sonst was, nur löten. Ich kann's nicht testen und übernehme gar nichts außer einen "Lötdienst". Preise habe ich genannt, genaueres nachfragen.
Wer Interesse hat aber keine Email von mir erhalten hat soll mir doch bitte schreiben: myscha ät web punkt de Ich würde gerne wissen wer welche Version möchte und ob (teil-) bestückt oder in "Einzelteilen"...
Wenn Dein Board zu dem Pollin-Display (siehe Beitrag "G-LCD bei Pollin") passt, wäre ich auch dabei (Set zum Selbstlöten).
Für die die "bestellen" möchten: ich muss folgendes wissen - Vcc? (3,3V oder 5V; die 5V-Version ist ohne RAM) - LCD-Spannung? (3,3V oder 3,3V/5V) - inkl. CRT/TV oder ohne? - inkl. LT3463 & zugehörigem Hühnerfutter oder ohne? - (teil-) bestückt oder Bausatz?
Hallo Miachael, hätte auch intresse an dem maxiaml Paket. - Vcc 3,3V - LCD-Spannung 3,3V/5V geht das? - inkl. CRT/TV - inkl. LT3463 & zugehörigem Hühnerfutter - (teil-) bestückt bitte um Antwort dagron at gmx.de mfg Dagron
hallo, haette auch Interesse an so einer Platine ... Preis?
Kommt drauf an was du alles haben willst...
Ich bin zur Zeit knapp bei Kasse, aber ich werde das hier mitverfolgen. Ein funktionierendes Gerät (nur für LCD) wird mit allem Drum und Dran etwa 50€ kosten. Dann fehlt da noch der Speicherbaustein. Bekommt man die wirklich nicht bei Digikey? Im Datenblatt der Controllers steht auch nichts vom SDRAM (nur DRAM). Kann der Controller auch mit SDRAM umgehen? Wäre nicht schlecht, wenn man die Schaltpläne einsehen könnte. Pollin hat noch alte SD-RAM Riegel im Angebot. Man könnte sich doch zusammenlegen und ein paar kaufen. Da sind 8 bis 16 Bausteine pro Riegel drauf. Die kann man durchsägen und jeder bekommt ein RAM-Bausteine.
@ Maxim S. Es wird etwas günstiger als 50 Euro sein. Das ist dann aber inklusive RAM (außer du willst 5V Vcc haben). Die RAMs gibt's bei Digikey, allerdings mit 80St. Mindestabnahme und dann kostet eins ~3,44 Euro zzgl. 19%. Der Controller "unterstützt" EDO- oder FPM-DRAM. Ich kenne mich da nicht 100%ig aus, aber ich denke nicht dass der mit SDRAM so ohne weiteres läuft. Wenn du die 2,37 Euro für's RAM sparen willst kannst du natürlich auf alten EDO-Riegeln suchen gehen. Das geht solange es sich um ein paar dreht, aber wenn man dann 10St. braucht wird's schon schwieriger. Und wir sollten es vermeiden, unterschiedliche zu verbauen - das wird sonst lustig wenn's bei den einen geht und bei den anderen nicht... Anbei Schaltplan, Stückliste, "Bestell-File" und Layout.
SDRAM gehen nicht, dafür bräuchte man den S1D13513. Der ist dann nochmal eine ganze Nummer größer. Allerdings würde ich beim 13506 bleiben, der ist die verbesserte Version des 13504. Der 13513 dagegen eher eine Neuentwicklung mit etlichen unschönen "Features". Bezüglich DRAM verträgt der 13506 so fast jeden 256-1Mx16 DRAM. Bei mir hat bisher jeder DRAM funktioniert.
Hallo, alte EDO-Riegel hab ich letztens noch gefunden. Gruß Udo
@ Udo ... und schon entsorgt? Falls nicht kannst du ja mal schauen was für Chips drauf sind. Vielleicht macht es Sinn die Riegel auszuschlachten... Gerade 5V-Typen könnten für den ein oder anderen interessant sein.
Aus der Entsorgung gefischt... ;) Schreib ich morgen mal was da für Chips drauf sind. Gruß Udo
An EDO Riegeln sind 4 und 8MB Typen mit 2 ICs pro Seite geeignet. Das sind dann nämlich immer 1Mx16 DRAMs.
Also, auf den EDO-Riegeln, die ich hier habe, sind folgende Speicherbausteine verbaut: SEC KM44C4104CK-6 Toshiba TC514400ASJ-70 Siemtek IPC5117405BJ-60 Siemens HYB5117405BJ-60 ? VG2617405DJ-6 TI TMS417409DJ-60 dann hab ich noch andere RAM-Karten mit SEC KM23C4100CG-100 ? M5M44800CJ-7 ? M5M44260CJ-6 HP LH5B8GYA drauf. Kann man damit was anfangen? Gruß Udo
Udo wrote: > SEC KM44C4104CK-6 4Mx4 > Toshiba TC514400ASJ-70 1Mx4 > Siemtek IPC5117405BJ-60 4Mx4 > Siemens HYB5117405BJ-60 4Mx4 > ? VG2617405DJ-6 4Mx4 > TI TMS417409DJ-60 4Mx4 > dann hab ich noch andere RAM-Karten mit > > SEC KM23C4100CG-100 irgendein ROM > ? M5M44800CJ-7 512k x8 > ? M5M44260CJ-6 256k x16 > HP LH5B8GYA irgendwas kundenspezifisches von Sharp Die ganze Arbeit hättest du die sparen können, wenn du auf mich gehört hättest: > An EDO Riegeln sind 4 und 8MB Typen mit 2 ICs pro Seite geeignet. Deine haben dagegen 8 ICs pro Seite.
OK....wer braucht 4Mx4 Ram-Bausteine???? ;)) @Benedikt war keine Arbeit..... Aber das nächste mal hör ich auf dich... :) Du weißt doch, die Hoffnung stirbt zuletzt.... Gruß Udo
Wir können ja 2x M5M44800CJ oder 4x M5M44260CJ stacken... Sieht bestimmt witzig aus und macht das Ganze interessanter... ;) Hat noch jemand Interesse und sich bisher nicht gemeldet weil er sich nicht zutraut den S1D13506 zu löten? @ Siegfried Wie sieht's bei dir aus?
Es sollten jetzt alle, die mitmachen, meine Kontodaten bekommen haben - falls ich jemanden vergessen habe bitte ich um Entschuldigung und Meldung... ;)
Hier: Beitrag "Re: ARM7 Board kauffertig mit Grafikcontroller ?" gibt es auch ein paar Beiträge zum Thema.
Hallo Michael, hallo Benedikt, ich interessiere mich auch für das Thema und habe eine Frage: Mit welchem µC steuert ihr den S1D13506 an? Und wie schnell ist dann der Bildaufbau bei welcher Auflösung und Farbtiefe? Sprich, könntet ihr mir die Parameter eures Testaubaus nennen und die Geschwindigkeit des Bildaufbaus. Welchen µC-Type müste man verwenden um ca. 5 Bilder\s bei ~640x480 8bit hin zu bekommen? Gruß Berny
Hi, Platine könntest Du von mir haben, da ist nur ein Pad abgebrochen am TQFP Footprint, der sich aber mit einer Minibrücke wieder anschliessen lässt, wenn der Chip drauf ist. Sind die wichtigsten Bauteile dabei, nur der Epson Chip fehlt, den habe ich leider getoastet. Falls Interesse, für 15 Euro ist sie Dein. Ansteuerung ideal mit einer 32 Bit Maschine, schon wegen dem 32 Bit Daten/Adressbus.
32bit müssen es nicht unbedingt sein, da der Controller nur über einen 16bit Datenbus verfügt, aber unter 16bit würde ich garnicht erst anfangen. DMA wäre natürlich auch nicht schlecht, ansonsten ist der µC nur am Daten rüberschaufeln.
Wow, das geht ja schnell ;-) @ Christian K. Ja, warum nicht, da kann ich gleich testen. Schicke mir deine Kontakt und Kontodaten an MicroC.berny Ät web de @ Benedikt K. Also ein ARM7 wäre da schon was? Die von Atmel haben doch glaub ich DMA, meinst Du da würde man meine oben beschrieben Bildaufbaugeschwindigkeit hinbekommen? Wie schnell st dein System. Musst jetzt nicht messen, nur schätzen.
Das einzige Problem bei den ARMs ist, dass die meisten keinen Wait/Ready Eingang besitzen, um die RD/WR Signale zu verlängern, wenn der 13506 noch nicht bereit ist. Aufgrund des DRAMs der nur im Page Modus richtig schnell ist, werden die meisten Zugriffe gebuffert und irgenwann ist des Buffer voll bzw. beim Lesen weiß der 13506 nicht welche Adresse als nächtes gelesen wird, und braucht dann erstmal eine Weile bis er die Daten aus dem DRAM gelesen hat. Wenn man nur Schreiben möchte, dann funktioniert es mit etwas großzügigeren Wait States auch ohne dieses Signal. Allerdings auf Kosten der Geschwindigkeit. Ich betreibe den 13506 an einem AVR (wenns einfach sein soll) oder an einem M16C62 wenn es schneller sein soll. Das ist der einzige Controller mit 16bit Bus und Wait Eingang, den ich bekommen konnte. Ich benutze den Controller weniger für Vollbildanimationen und ähnliches, aber Datenraten von ein paar MByte/s sollten kein Problem sein. Wichtig ist halt, dass der Controller die Daten ausreichend schnell beischaffen kann. Ich weiß nicht wo du die Daten herbekommst, aber die Bilddaten zu berechnen dürfte weitaus mehr Zeit benötigen, als das reine Übertragen der Daten an den Controller. Falls die Daten nicht komplett neu berechnet werden müssen, kann man immer noch die Features des 13506 wie BitBLT oder ähnliches verwenden. Damit kann man die Ausgabe nochmal um einiges Beschleunigen.
Vollbildanimationen sollen es ja nicht werden. Höchstens auf kleineren Flächen, z.B. wir die kleine Eieruhr in Windows. Ich wollte die Bilddaten in SDCards speichern und bei Bedarf von dort direkt zum Controller schicken. Welche Controller haben den noch einen Wait-Eingang? Kann auch ruhig 32Bit sein. Ein paar MByte\s ist ja dann schon ausreichend für meine Anfordungen. Kennst Du den S1D13748? Der hat SRAM mit an Bord. Währe fürs Layout einfacher. Sorry, wenn ich dich so löchere, aber Du hast wohl, so wie man lesen kann schon einiges mit Grafik gemacht. Gruß Berny
Ich möchte den Epson mit einem AT32UC3A0xxx ansteuern. Der hat auch einen Wait-Eingang. Das Board dazu befindet sich aber noch in der Entwicklung.
@ Michael K. Das hört sich interessant an mit dem AT32UC3A0xxx! Hab jetzt nur mal kurz drüber geschaut. So von der Ausstattung und Geschwindigkeit kommt das so nach ARM7, nur mit Waiteingang ;-) Programmiert werden die Dinger mit JTAGICE MKII, AVR Studio gibt es auch. Da fühlt man sich als AVR-USER gleich zuhause. Ich glaube, da werde ich mich mal einlesen. Hast Du da schon was damit gemacht. Wie sieh das mit der C-Programmiererei mit dem Studio aus? Taugt das was? Gruß Berny
Berny wrote: > Vollbildanimationen sollen es ja nicht werden. Höchstens auf kleineren > Flächen, z.B. wir die kleine Eieruhr in Windows. Dafür würde ich dann z.B. die Sprites oder den Ink Layer verwenden. Dann kann man vieles in Hardware vom Controller erledigen lassen. Ich lade z.B. die Schriftarten zunächst komplett in den DRAM (2MB sind ja groß genug) und verwende dann die BitBLT Engine um die Buchstaben von 1bpp auf 8/16bpp zu erweitern und an die entsprechenden Stellen im Bild zu schreiben. Ebenso bei kleineren Animationen: Die kann man entweder über Sprites in das Bild einblenden oder mittels BitBLT aus einem Speicherbereich in das Bild kopieren lassen. So reduziert sich der Softwareaufwand auf einige Registerbefehle. Ich hatte mal Just-for-Fun ein kleines GUI geschrieben, das eine Windows ähnliche Bedienoberfläche mit dem 13506 erzeugt. Mit einer Maus dran usw. Damit habe ich dann BMP Bilder von einer SD Karte geladen die man per Mausklick anzeigen konnte. Das Laden war aber relativ langsam, da viel per Software gemacht werden musste (Dateisystem, Umrechnen 24bpp->16bpp usw.) > Kennst Du den S1D13748? Der hat SRAM mit an Bord. Währe fürs Layout > einfacher. Ich hatte ihn noch nie in der Hand, aber ich habe das Datenblatt schon gelesen. Er scheint nicht schlecht zu sein, hat zwar kaum Features und ist daher eher als Zusatz zu einem schnellen µC gedacht, aber wenns langsam gehen darf, ist der auch OK.
...Windows ähnliche Bedienoberfläche Interessant! Aha, diese BitBLT scheint wohl DIE Hardware-Waffe des 13506 zu sein. Ich bin ja erst am Chip suchen für mein Project und der 13506 gefällt mir immer besser. Kannst Du mir kurz beschreiben, was man mit dem BitBLT machen kann, so in wenigen Worten. Bis ich das im Datenblatt verstanden habe... Was natürlich nicht heissen soll, das ich das, wenn ich damit arbeite noch lesen muss ;-). Gruß
Vereinfacht gesagt ist BitBLT eine Art DMA: Man kann Speicherbereiche kopieren, löschen usw. und dabei auch logische Verknüpfungen zwischen Daten machen, also verodern, invertieren usw. Man kann z.B. sagen, überall wo das Bild rot ist, sollen die Pixel durch ein zweites Bild ersetzt werden oder ähnliches. Man sagt dem IC was es machen soll, und es macht das dann von alleine. Man muss nur warten bis es fertig ist.
Das hört sich gut an. Also kann man z.B. kleine Bildbereiche 64x64 Pixel (Icons) dadurch schnell ersetzen?
Benedikt, da der ARM ja nur Wait States hat und keinen Wait Eingang, macht es dann überhaupt Sinn die Epson Chips an den zu verbauen? Würde es helfen den Chip für gewisse Zugriffe runterzutakten und die Wait States auf 32 zu setzen? Oder ist da Chjaos vorprogrammiert?
Berny wrote: > Das hört sich gut an. Also kann man z.B. kleine Bildbereiche 64x64 Pixel > (Icons) dadurch schnell ersetzen? Ja. Die müssen vorher aber alle ins Grafikram kopiert werden. Christian K. wrote: > Würde es helfen den > Chip für gewisse Zugriffe runterzutakten und die Wait States auf 32 zu > setzen? Oder ist da Chjaos vorprogrammiert? Gute Frage. An einem ATmega8515 habe ich den 13506 schon mit 1 Wait State ohne den Wait Pin betrieben. Nur das Lesen (des RAMs) war eine Glückssache. Leider gibt es keine Angaben wie lange das Lesen maximal dauern kann, da das ganze von sehr vielen Dingen abhängt, aber ich denke so 1µs kann schonmal erreicht werden (worst case). Für das Schreiben gilt ähnliches: Wenn die Zeit zwischen den Zugriffen ausreichend groß ist, dann geht das Schreiben auch ohne viele Wait States, denn der 13506 besitzt einen 1 Word FIFO, um Schreibzugriffe zu beschleunigen. Man schreibt also nicht direkt ins RAM sondern in das FIFO und der 13506 schreibt den Wert dann in den Speicher. Wenn der nächste Schreibzugriff zu schnell kommt, wird der solange ausgebremst, bis das andere Byte geschrieben.
Hi Benedikt, wenn das so ungewiss ist, dann werde ich wohl doch den alten 13705 mit 80k internem RAM verwenden. Der hat zwar auch ein WAIT aber vielleicht äussert es sich da nicht so. Für s/w reicht der eh und Farbprogrammierung ist ja auch unendlich aufwendig für leute die das nicht jeden Tag machen und auch keine 3D- Videospiele programmieren wollen. Ich kann mir nicht vorstellen, dass es keinen plug & play GC für den ARM7 geben soll. Die müssen das doch bedacht haben. Kann man den LPC nicht einfach irgendwie "stoppen" wenn WAIT kommt? zB ihm den Takt einfach abdrehen? Wenn man statt über einen Quarz über ein Gatter geht, dann müsste man doch den Chip kurz anhalten können. Zumindest wenn der voll statisch ist. Möchte mit meinem Design nur keinen teuren Fehlschuss hinlegen... Christian
> Wenn man statt über einen Quarz über ein Gatter geht, dann müsste man doch > den Chip kurz anhalten können. Ich denke, dass Benedikt hier Beitrag "Re: VGA Grafikkarte mit AVR und 8MB SDRAM" auch sowas macht...
Ja, für den AVR aber wie stehts mit dem NXP Derivat LPC.....? Im Datenblatt steht, dass der über 100pf entkoppelt werden muss, wenn er an einen Taktgeber angeschlossen ist. Ich denke aber schon, die 1-2 us muss er verpacken können, sonst hätte er kein Controller werden dürfen :-)
Naja, der ARM hat eine PLL drin. Die interessiert es erstmal nicht, wenn der Takt gestoppt wird, denn die läuft für einige Takte noch weiter. Man müsste also den ARM ohne PLL betreiben (keine Ahnung ob das geht), oder lässt diese Pfusch Lösung sein.
Benedikt K. wrote: > Naja, der ARM hat eine PLL drin. Die interessiert es erstmal nicht, wenn > der Takt gestoppt wird, denn die läuft für einige Takte noch weiter. > Man müsste also den ARM ohne PLL betreiben (keine Ahnung ob das geht), > oder lässt diese Pfusch Lösung sein. Außerdem muss die PLL danach erst einmal wieder anlaufen.
> Hast Du da schon was damit gemacht. Wie sieh das mit der C-Programmiererei mit > dem Studio aus? Taugt das was? Ne, bisher habe ich noch nichts damit gemacht. Irgendwo hier im Forum gibt's aber ein Thema dazu - musst mal suchen. Ich bin derzeit noch am layouten...
Hallo, ich habe das Problem mal nach Epson in den USA geschickt, die antworten so binnen einer Woche. Die Kollegen mit denen ich das bekakelt habe sind der Ansicht: Passt nicht! Einen uC anzuhalten ist Murks und nicht praktikabel. Alternative wäre eine Softwareschnittstelle, ich weiss nur nicht ob der ARM Bus auch als IO nutzbar ist. Meiner Ansicht nach sind diese S1D1 Chips gar nicht für den ARM geeignet, da der AMBA Bus kein WAIT kennt. Da ich aber denke, dass ARM daran gedacht haben muss werden die sicherlich Grafikchips empfehlen können die dazu passen. Gruss, Christian
Christian K. wrote: > ich habe das Problem mal nach Epson in den USA geschickt, die antworten > so binnen einer Woche. USA oder Kanada ? Da bin ich mal gespannt, ob die einen Vorschlag dazu haben. Bisher war meine Kommunikation mit denen nie besonders ergebnisreich. > Alternative wäre eine Softwareschnittstelle, ich weiss nur nicht ob der > ARM Bus auch als IO nutzbar ist. Von Software würde ich abraten, beim Bittoggeln ist ein AVR fast schneller (kein Witz, ohne die fast IOs ist ein AVR wirklich schneller)... > Meiner Ansicht nach sind diese S1D1 Chips gar nicht für den ARM > geeignet, da der AMBA Bus kein WAIT kennt. Da ich aber denke, dass ARM > daran gedacht haben muss werden die sicherlich Grafikchips empfehlen > können die dazu passen. Würde mich auch mal interessieren. Außer von Epson kenne ich nur noch einige Controller von Fujitsu die man nirgends bekommt. Der Rest sind ASICs.
Sind eigendlich so Controller wie der AT91SAM9261 oder die grossen AVR32 mit LCD Controller eine Alternative für die S1D1 Chips? Jetzt nur von der Grafikgeschichte her betrachtet.
Ich hab noch nie mit denen gearbeitet, aber dem nach was das Datenblatt des AVR32 verspricht: Ja. Nur sind die halt nicht mehr per Hand lötbar.
Ach ja richtig, ich dachte der AT32AP7001 hätte auch einen LCD-Controller. Schade eigendlich. Aber solchen internen LCD-Controllern, fehlen dann doch bestimmt so Sachen wie BitBLT oder Hardware-curser usw.
>>Aber solchen internen LCD-Controllern, fehlen dann doch bestimmt so >>Sachen wie BitBLT oder Hardware-curser usw. Benny...... bevor Du sowas hinkriegst wirst Du erst einmal ganz viel fluchen. Es sind viele hundert Zeilen Programm nötig um Grafik auf dem Bildschirm zu haben. Die musst Du da erstmal reinkriegen, ohne SD Card mit FAT Treiber nix zu machen. Du arbeitest da auf Pixel Ebene und musst Dir alles selbst strukturieren, es sei denn Du verwendest Linux, da sind die High Level Routinen schon fertig und Du musst "nur" den Treiber anpassen, die set_pixel(x,y) Routine. Generell bieten ja auch NVidia, Herkules und ATI Grafik Chips an, mit einer 3D Engine, Rendering und Shading :-) Gern auch mit Do-it-yourself Ballgrid für den Heimwerker ;-) Vielleicht kommt ja bald der erste, der Doom III oder Unreal auf dem ARM oder AVR32 zum Laufen gekriegt hat. Handbuch so ca 1500 Seiten. Oder man nutzt gleich DirectX ;-) Am besten erstmal mit einem blinkenden Cursor anfangen....
@Christian K. Nee, ist schon klar. Bis ich da was hin bekomme, geht viel Zeit ins Land. Ich bin ja noch ganz am Anfang mit diesem Projekt. Muss ja erstmal ausloten, welche Hardware ich benötige um das umzusetzen, was ich vor habe. Bisher geht's so Richtung AVR32 und S1D13506. Linux werde ich wohl nicht verwenden, da kenne ich mich gar nicht aus. Und das bremmst doch auch bestimmt die ganze Sache?! Handbuch so ca 1500 Seiten..... Naja, die Datasheets der genannten Controller plus diverse Foren-Threads, da kommt auch einiges zusammen ;-) Aber Step by Step und dann wird's auch was.
>>Linux werde ich wohl nicht verwenden, da kenne ich mich gar nicht aus. >>Und das bremmst doch auch bestimmt die ganze Sache?! Irrtum! Enormer Vorteil: Das Rad nicht neu erfinden müssen. Du hast eine dokumentierte API, die nur noch an die Hardwareschicht angepasst werden muss. Die Routinen sind leer, die musst Du nur noch anpassen. Ab ARM9 ist sowas Standard, da wird nicht mehr ohne ein Betriebsystem gearbeitet. Zieh Dir auch mal ein freies FAT System von sourceforge.net. Kompiliert einwandfrei durch, volle DOS Funktionalität und ist wirklich easy-to-use. Fast 9000 Zeilen Code....
Prinzipiell habe ich nichts gegen Linux. Aber, wenn wir beim "Rad" bleiben wollen, wenn ich mein "Rad" neu erfinde, weiss ich warum es sich dreht. Das mit dem Linux ist für mich eine grosse Unbekannte. Zu verstehen, wie Linux aufgebaut ist, bekommt man ja noch so einigermassen hin, die Serielle Schnittstelle oder sowas anzusprechen, sprich Sachen von denen es Treiber gibt, wird auch noch zu schaffen sein. Aber dann für spezielle Sachen einen Treiber programmieren, das stelle ich mir schwierig vor. Im Moment wüste ich noch nicht einmal, wie man ein I/O-PIN auf high setzt. Oder stelle ich mir das zu kompliziert vor? Kennst Du einen guten Einstieg in die Linuxwelt für µC? Wenn möglich auf deutsch ;-)
Aber klar doch: http://elmicro.com/de/bu-emblinux.html Grundsätzlich kann man gleich hiermit anfangen, der Coldfire hat auch einen SVGA Contróller onboard: http://elmicro.com/de/cobra5329.html Nur mit 499 Euro nicht ganz billig. Wobei der nächste Schritt dann der ist sich einen ganz normalen PC hinzustellen, der zudem viel billiger ist :-)
Berny wrote: > Ach ja richtig, ich dachte der AT32AP7001 hätte auch einen > LCD-Controller. Schade eigendlich. > Aber solchen internen LCD-Controllern, fehlen dann doch bestimmt so > Sachen wie BitBLT oder Hardware-curser usw. Also ich glaub viel näher kommst du nicht mehr an den Grafikspeicher dran, wenn der LCD-Controller direkt im Mikrocontroller sitzt.
@Christian K. Ja, genau sowas meinte ich :-) Das Buch scheint, für den Anfang, brauchbar zu sein. Werd' ich mir mal zulegen. Es behandelt nur in einem Kapitel die erwähnte Hardware, sonst überwiegend die Software. Also ist, so denke ich, dieses Board nicht sooo dringend notwendig. Und wenn ich dann so den ersten Einblick in die Linuxwelt habe, kann ich mir ja dann überlegen, welche Hardware ich verwende. @ Simon K. Ja, da hast Du vollkommen Recht. Doch wie gesagt, die externen haben halt auch mehr Features. Und das gilt es abzuwägen.
Berny, ich denk es ist klar geworden. Man sollte sich bewusst machen was man will. irgendwann hört es mit der Mikrocontrollerei auf und man bohrt das Ganze soweit auf, dass man sich genausogut einen PC hinstellen kann. Ich werde mein Board auch mit dem 13705 machen, der ist zwar älter und hat weniger Features aber dafür leicht verständlich aber eben nur schwarz/weiss für monochrom Displays. habe noch so 10 Stück so schöne 640x480 LCD Displays ohne Hintergrundbeleuchtung von Laptops der ersten Generation. Das reicht auch für eine Anzeigeeinheit total aus, jedes bisschen Farbe braucht sowieso gleich Megabytes an Platz und man kann sich mit diesen Farbpaletten herumschlagen. ben.
Benedikt, schau Dir doch mal das Design hier an: http://www.olimex.com/dev/images/ARM/LPC/LPC2478-STK-sch.gif und versuche mal rauszukriegen welcher Grafikcontroller das ist. Ich habe nichts gefunden, 0.0.
@ Christian K. Ja, das kann man wohl soweit treiben, bis zum PC. Wenn man bedenkt, dass mein erster PC 16MHz hatte ;-). Ich habe bisher nur mit AVR gearbeitet und möchte eben eine Stufe höher. So ein Zwischending. So für Handheld-Anwendungen mit Grafik. Das System muss halt so schnell sein, dass der Aufbau eines Bildes weniger als eine Sekunde dauert. Ich denke mit dem AVR32 + S1D13506 bekommt man das gut hin. Ich habe mal in Youtube nach AVR32 gesucht und war überascht, was da grafikmäßig geht. Gut das waren die grossen AVR32, aber die haben da teilweise Computerspiele drauf laufen! Mit Linux, werd' ich erstmal warten, wenn ich ohne nicht mehr weiter komme, werd' ich#s mal mit versuchen ;-)
Hallo, schonmal die Spec vom LPC2478 angeschaut? Boaaah... ey! Leider unterstützt mein Rowley das nicht mit Linkerfiles, der Chip ist erst 2 Monate alt. Aber mit allem drum und dran. http://www.standardics.nxp.com/products/lpc2000/datasheet/lpc2478.pdf
Berny wrote: > @ Simon K. > Ja, da hast Du vollkommen Recht. Doch wie gesagt, die externen haben > halt auch mehr Features. Und das gilt es abzuwägen. Ne, das stimmt nicht. Der Haken ist, dass, wenn der Controller direkt im Prozessor sitzt und direkt den Bildschirmspeicher aus dem RAM nimmt, man alle "Features" wie zum Beispiel BitBLT auf einfachste Weise selbst implementieren kann. BitBLT ist nämlich nur ganz einfaches kopieren (u.U. mit logischer Verknüpfung). Sprich: Eine kleine Schleife, die die Daten von Buffer X mit Buffer Y verknüpft und nach Y schreibt, Fertig. Mit externen Controllern bist du doch viel unflexibler, weil du erst alles über eine definierte (langsamere) Schnittstelle in das externe Grafikram kopieren musst und nicht die eingebauten Maschinenbefehle benutzen kannst.
Berny wrote: > Ich denke mit dem AVR32 + S1D13506 bekommt man das gut > hin. Ich habe mal in Youtube nach AVR32 gesucht und war überascht, was > da grafikmäßig geht. Gut das waren die grossen AVR32, aber die haben da > teilweise Computerspiele drauf laufen! > Mit Linux, werd' ich erstmal warten, wenn ich ohne nicht mehr weiter > komme, werd' ich#s mal mit versuchen ;-) Wenn du einen externen Grafikspeicher benutzt, kriegst du garantiert kein Doom I zum laufen. Du musst den internen benutzen, weil der Grafikspeicher eben direkt im RAM liegt. Das heißt, die Anwendung kann über Linux's Framebuffer-Treiber direkt in den Grafik-RAM schreiben, das geht um einiges schneller, als erst über SPI o.ä. die ganze Soße herauszutakten.
@ Simon K. Das mit dem Doom, war ja nur ein Beispiel, was möglich ist. Ob jetzt intern oder extern... Ich weiss nicht, wie die das hin bekommen haben. So etwas ist auch nicht mein Ziel. ...als erst über SPI o.ä. Der S1D13506 wird ja schon über eine externes Memoryinterface angeschlossen, also die Daten werden parallel geschaufelt. ... die Anwendung kann über Linux's Framebuffer-Treiber direkt in den Grafik-RAM schreiben, Für den S1D13506 gibt es auch Treiber, soviel ich weiss. Jetzt nur so eine Überlegung, ohne Ahnung zu haben... So ein µC mit internem LCD-Controller, hat ja nur einen begrenzten internen RAM. Wenn man Bilddaten für z.B. 640x480 8Bit Farbe hat, ist der Ram ja zu klein, also muss man externen Speicher anschliesen. Hast Du einen µC plus externem LCD-Controller, der wiederum externen Memory hat, hast Du wieder die Bilddaten auf externem RAM. Aber was ist schneller, was ist einfacher?
@Berny: Ich habe Deine Mail verloren. Geld ist angekommen, die Platine geht morgen abend auf die Reise. Bitte maile mir nochmal Deine Adresse an admin_at_der-scirocco.de
Hab noch EDO-Riegel mit NEC 4218165-60 / 42pol. drauf gefunden. Gruß Udo
Angehängte Dateien:
-
s1d135.jpg
200 KB
Hallo zusammen, ich räume gerade meinen Schreibtisch auf. Habe mir darmals auch so eine Platine zugelegt, aber nie dazu gekommen mit dieser zu experimentieren. Der EPSON s1d135 und der DC/DC IC im 10DFN Package ist bereits bestückt. Habe für Platine und Bauteile seinerzeit ca. 50 Euro hingelegt und verkaufe das nun für lau. Wer Interesse an der Platine und den Teilen hat, bitte mit Vorstellung was man ausgeben möchte bei mir melden. Fetten Gruß Katherine
Hallo Katherine Ich weiß ist schon wieder über einen Monat her, aber hast du die Platine noch? Was für ein EPSON Controller ist da nochmal genau drauf? Vielleicht kannst du nochmal ein schärferes Bild von der Platine machen. Wenn es der EPSON S1D13506 ist, würd ich die nehmen. Gruß Steffen
Moin Steffen, sorry, die ist schon längst weg. Fetten Gruß Katherine
Hallo zusammen, ich habe bei mir noch drei TFTs herum liegen und möchte diese gerne für ein Projekt (fast Wetterstation ;) ) verwenden. Bisher habe ich mich mit TFTs noch nicht beschäftigt. Seit ca. drei Tagen bin ich nur noch am googeln um mich da etwas einzulesen. Jetzt bin ich auf diesen Beitrag hier gestoßen, der zwar schon etwas älter ist doch eigentlich genau das richtige für mich ist, oder? Wäre es damit möglich die TFTs zu betreiben? Gibt es alternativen? Es müssen keine schnelle Grafiken geladen werden. Wäre evtl. sogar denkbar, Grafiken in einem Eprom zu speichern und diese dann zu verwenden. Wenn diese GraKa nichts sein sollte, was gibt es denn für Alternativen? In den Angehängten Dateien sind die Datenblätter der TFTs. Gruß Wolfgang
Wolle schrieb: > Wäre es damit möglich die TFTs zu betreiben? Gibt es alternativen? So wie ich den Thread eben beim überfliegen verstanden habe, braucht der Grafikcontroller EDO-DRAM. Das war anno 2008 schon alt und ist heute erst recht nicht mehr zu bekommen. Aktuell würde ich sagen: NXP LPC2478. Das Teil hat 80k internes RAM, aber nur 16k davon sind für den LCD-Controller nutzbar. Du brauchst also externes RAM. TQFP208, d.h. 208 einzelne Pins im 0.5mm Raster wollen verlötet werden. Das ist machbar. NXP hat einen Nachfolger mit Cortex M3 Kern in Arbeit, aber der ist wohl noch nicht wirklich lieferbar. Microchip PIC24FJ256DA210. TQFP100, d.h. noch gut lötbar. 98k internes RAM, ist recht viel, reicht aber für VGA trotzdem nicht aus, d.h. externes RAM braucht man ohnehin. Das wäre jetzt der Controller, den ich mir am ehesten anschauen würde, einfach weil der Aufwand begrenzt ist. Alle anderen Controller mit internem Grafikcontroller sind schon BGA und damit nicht mehr einfach so mit Hausmitteln verarbeitbar. (abgesehen davon, dass das Layout dann 4 oder 6 Lagen haben müsste) Ansonsten: Spartan 3A FPGA, 512k SRAM dran, und los gehts mit VHDL-Programmierung. fchk
Hallo Frank, hab mir das mal angeschaut, die Alternativen werden schon ne Nummer zu viel für mich. Das Löten ist kein Problem. Hab alles was man so braucht. In der Fa kann ich auch BGA löten und einen Reflow Ofen hab ich hier auch stehen. Den DRam der in der Steuerung angegeben ist würde ich auch noch bekommen. Ist zwar nicht mehr ganz so leicht aber er ist noch verfügbar. Meinst Du das es dann damit geht? Gruß Wolfgang
Wolle schrieb: > hab mir das mal angeschaut, die Alternativen werden schon ne Nummer zu > viel für mich. Was meinst Du mit "zu viel"? > Das Löten ist kein Problem. Hab alles was man so braucht. In der Fa kann > ich auch BGA löten und einen Reflow Ofen hab ich hier auch stehen. > > Den DRam der in der Steuerung angegeben ist würde ich auch noch > bekommen. Ist zwar nicht mehr ganz so leicht aber er ist noch verfügbar. > > Meinst Du das es dann damit geht? "Kriechen" meinst Du wohl? In Prinzip ja. Leider hast Du für die STN-Panels keine vollständigen Datenblätter, sondern nur Product Briefs reingestellt, daher kann ich hier nur raten, aber ich rate mal ja. 4 Bit Farbtiefe solltest Du hinbekommen. Mehr geht mit dem Epson-Controller nicht. An was für einem Controller willst Du das Zeug betreiben? 160k und mehr mit einem 8-bitter zu verwalten macht heutzutage eigentlich keinen Sinn mehr, wo 32 Bit Controller nicht mehr unbedingt teurer sind. Das sind dann zu viele Klimmzüge, die das ganze nachher unnötig langsam macht. Ich halte einen LPC2478 eigentlich für die angemessene Lösung für solche Displays. Ich habe hier auch ein Board dafür rumliegen, das aber für STN Monochrom Panels vorgesehen war und deswegen kein externes RAM brauchte. Ich habe sogar schon die Nachfolgeversion mit externem RAM designt, aber daraus ist nie fertige Hardware geworden. Das ließe sich aber ändern. fchk
Ich meine das diese Alternativen für mich zu viel sind, da ich mich mit C nicht wirklich auskenne. Bisher habe ich das Ganze mit Bascom gelöst bekommen. Ich habe mir auch schon oft vorgenommen mich endlich mit C zu beschäftigen doch um dieses als "Lernprojekt" zu verwenden, ist wohl zu viel. Eigentlich bräuchte ich eine Lösung die wie eine "Grafikkarte" für die AVRs funktioniert. Für das Projekt, für das ich das Display verwenden will, ist noch kein AVR festgelegt. Dies kann gerne ein 16 oder 32er sein. Ich bin wohl für dieses Thema doch noch zu viel "Anfänger" :( Gruß Wolfgang
Wolle schrieb: > Ich meine das diese Alternativen für mich zu viel sind, da ich mich mit > C nicht wirklich auskenne. Bisher habe ich das Ganze mit Bascom gelöst > bekommen. Ich habe mir auch schon oft vorgenommen mich endlich mit C zu > beschäftigen doch um dieses als "Lernprojekt" zu verwenden, ist wohl zu > viel. Ja, genau. Lerne erstmal C, dann hast Du was fürs Leben, und dann sehen wir weiter. > Eigentlich bräuchte ich eine Lösung die wie eine "Grafikkarte" für die > AVRs funktioniert. Für das Projekt, für das ich das Display verwenden > will, ist noch kein AVR festgelegt. Dies kann gerne ein 16 oder 32er > sein. Bascom ist hierfür das falsche Werkzeug, und der AVR ist auch nicht unbedingt eine sinnvolle Wahl für diese Displays.(*) Nimm besser irgendwelche kleinen Textmodus-Displays, das passt besser zu Deinem AVR, und fange JETZT mit C an. (*) Ja, natürlich werden jetzt irgendwelche Fanboys mit ihrem beschränkten AVR-Horizont kommen und sagen, dass es doch geht, aber ehrlich, es gibt auch ein Leben jensets von AVR. fchk
Naja, du brauchst für diese Displays 512Kx16 und schätzungsweise einen Pixeltakt von mindestens 16 MHz. Sowas kannst du noch mit statischem RAM (2x 256Kx16, 10ns) und einem CPLD hinbekommen. Ein CPLD mit 128 Macrozellen dürfte grad eben so ausreichen. Ich erwähne deshalb die CPLD-Variante, weil man damit das Display gegenüber dem Controller als ein zwar langsames (ca. 5..7 Waitstates), aber simples RAM erscheinen lassen kann und weil das Ganze an jedem ausreichend großen Controller läuft (mind. 18 Adressbit und 16 Datenbit) und keinen Setup benötigt. Strom ein und geht. Dann vom Programm nur noch ablöschen und fertig. Die Farben würde ich auf 16 Bit reduzieren: 5 Rot, 5 Blau, 6 Grün. Im Prinzip würdest du einen 32 MHz Takt brauchen, wo abwechselnd CPU und Bildschirm auf das RAM zugreifen können. Für die CPU braucht es dann 16 Latches, wo die Daten gepuffert werden und die Zugriffszeit der CPU muß deutlich länger als 63 ns sein, da ihre Daten ja nur im 16 MHz-Takt gespeichert / gelesen werden können. W.S.
Frank K. schrieb: > So wie ich den Thread eben beim überfliegen verstanden habe, braucht der > Grafikcontroller EDO-DRAM. Das war anno 2008 schon alt und ist heute > erst recht nicht mehr zu bekommen. Ich hatte den seinerzeit über ebay bei nem Kerl aus den Staaten bekommen. Wenn man etwas Zeit in die Suche inverstiert, halte ich das auch jetzt noch für möglich. Ich kann aber auch mal nachsehen, ob ich noch welche übrig habe. Ich hatte damals mehr bestellt als ich brauchte.
Hallo Dieser Beitrag ist ja schon sehr alt, aber auch sehr Interessant. Ich habe einen S1D13504 auf einer Platine gefunden und wollte mal fragen, ob der hier verwendete Code dafür auch zu gebrauchen ist? Oder sind die Controller zu unterschiedlich? Über eine Antwort würde ich mich sehr freuen. LG Thomas
Hallo, ich suche Kontakt zu Leuten die sich mit dem S1D13506 damals (oder vielleicht auch heute noch) beschäftigt haben. Eine Mail an Benedikt K. , dem "Mastermind", blieb leider unbeantwortet. Hintergrund ist ein Projekt mit diesem IC für den Atari ST. Viele Dank, André
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.