Hallo,
kennt jemand ein ARM7 Board (nur die NXP Chips bitte, weil ich die
kenne), gern auch mit dem LPC 2214 und etwas RAM dran, was am Bus einen
Grafikcontroller hat mit dem man die netten Pollin Displays ansteuern
kann?
Also sowas in der Richtung der Epson Controller S1D13705 für max 640x480
Pixel. Es sollte über JTAG programmierbar sein also keine Bootloader,
Spezialsoftware etc haben, auch brauche ich kein Betriebssystem da ich
das ja selbst schreiben will aus Spass am machen.
Problem ist, dass ich meine Schaltung nicht 2-seitig routen kann und 4
Lagen Platinen viel zu teuer als Einzelstücke sind.
Gruss,
Christian
Ich würde eher den S1D13706 empfehlen. Der ist neuer und hat ein paar
Features mehr. Er läuft dafür nur mit 3,3V, aber das ist ja nicht
schlimm.
Ein Problem an dem Bus ist, dass die ARMs keine Waitstates unterstützen.
Dadurch muss man das Timing relativ großzügig auslegen. Auch hier ist
der schnellere 13706 etwas besser als der ältere 13705.
So eine Schaltung sollte aber auch 2 lagig machbar sein. Fertig habe ich
sowas aber noch nie gesehen (außer als teures Zubehör zu Displays.)
Schau dir mal die Boards von Embedded Artists www.embeddedartists.com
an. Das fuer den LPC2468 hat einen externen Graphic Controller auf der
Zusatzplatine, das fuer den LPC2478 benuetzt den integrierten des Chips
(Verfuegbarkeit?)
Beide sind im Bezug auf Graphic Controller nur mittelmaessig
dokumentiert und kommen auch mit ucLinux, was auch bei Bedarf ignoriert
werden kann. Es sind jedenfalls die einzigen Boards, fertig aufgebaut
mit Graphic Controller fuer NXP LPC2000, die mir auf die schnelle
einfallen.
Gruss, Robert
Hallo,
ich habe mir diese Boards angeschaut, leider sind es mehr oder weniger
Mini PC's, die nur sinnvoll mit einem Betriebssysstem zu nutzen sind, da
ich kaum in der Lage bin Ethernet /USB Protokolle etc alles selbst zu
schreiben und vermutlich noch eine Menge mehr dazugehört diese Boards in
Betrieb zu nehmen, die ja auch nicht ganz billig sind. Und Linux iust
für mich eine Welt mit sieben Siegeln wenn es um Systemprogrammierung
geht, kann gerade mal mit der KDE ein wenig klicken.
Ich habe es schon ausprobiert, ich kriege die nicht 2-seitig hin wenn
ich den Grafikchip mit Bus anpappe, wozu auch nur der 2214 geeignet ist.
Es sind zu viele Leitungen bzw fehlt mir auch der Nerv tagelang manuell
zu routen, wenn es sowas fertig gibt. Diese Fine-pitch Gehäuse zu löten
ist ja mehr Glücksache, wenn die nicht 100% stimmig liegen ist der
Prozessor samt Board für die Tonne.
Das MAM hat aber meines Erachtens schon Waitstates im ARM bzw. kann man
den ja runtertakten wenn man auf den Bus zugreift.
Alternative wäre es einen Grafikcontroller mit Schieberegistern
anzudocken, die Epson Chips sind ja recht gut konfigurierbar was den Bus
angeht. Leider verliert man damit die Fähigkeit aus dem Grafikram des
S1d.... zu lesen, man kann nur noch reinschreiben und das reduziert ja
den Umfang des Machbaren ganz erheblich.
Hat das jemand schon mal gemacht? Sind diese Grafikcontroller auch
geeignet, sagen wir einen 16 Bit Software Bus anzudocken und wieviel
Arbeit macht es den mit Daten zu füttern? Die Steuerleitungen müssten
dann ja manuell bedient werden statt über den Bus Controller.
Dann könnte ich den LPC verwenden den ich habe und der hat keinen
externen Bus aber dafür 32kb Ram und 512kb Flash.
Christian
Christian wrote:
> Hat das jemand schon mal gemacht? Sind diese Grafikcontroller auch> geeignet, sagen wir einen 16 Bit Software Bus anzudocken
Funktionieren tut das, ist aber recht langsam, vor allem auf einem ARM.
Der braucht ja glaube ich 4 Zyklen für einen IO Zugriff in dem schnellen
Modus. Normalerweise ist es noch langsamer. Mehr als 1-2 MByte/s ist
dann auf keinen Fall möglich (nur reine Schreibzugriffe).
Ich würde daher auf jedefall zu einem µC mit Hardwarebus greifen. Aber
wie bereits gesagt: Spätestens beim Lesen ist das Timing entweder sehr
langsam zu machen, oder es ist eben die Wait Signal des S1D1370x
auszuwerten. Denn das RAM des S1D1370x wird auch durch die Bildausgabe
belastet, so dass es ein paar Takte dauern kann, ehe die Leseanfrage
beantwortet werden kann.
Hallo Benedikt,
ich habe seinerzeit ja Dein Projekt mit dem Atmel aufmerksam verfolgt
aber irgendwie noch nicht die Kurve gekriegt zwischen Frau+Kinder +
meinen Oldtimern den Umstieg zu schaffen von diesen 8 Bittern weg. Die
ersten Erfahrungen mit dem ARM7 und dem Olimex Board waren schon klasse,
nur leider dauerte es ohne einen HAL (Hardware Abstraction layer) beim
Compiler eben viel länger was Gescheites zu schreiben, bei dem VIC im
ARM habe ich mir die Hirnzellen gebrochen, weil der echt komplizierter
ist als die INT Struktur vom PIC.
Du sagst, dass es langsamer sei. Ziel sind bei mir keine laufenden
Bilder sondern mehr oder weniger ein kleiner Rechner mit einem
Grafikdisplay, der mit printf (.....) mir Ergebnisse ausgibt, die er zB
über Infrarot empfängt oder ein Funkmodul. Vielleicht noch ein paar
Diagramme darstellen von Messkurven. Kleine Steueraufgaben wahrnimmt,
was eben so anfällt in der Hobbywerkstatt. Den Textmode würde ich im ARM
als Puffer liegen haben, dann in Pixel umrechnen und in den Speicher des
S1D schieben wollen. Für Grafik ist nicht genug Platz im Arm, die müsste
ich mehr oder weniger im S1D bearbeiten, also byteweise auslesen,
verändern und zurückschreiben. Auch hier keine schnellen Vorgänge.
Scrolling müsste aber schon sein, da Messkurven ja wachsen.
Meinst Du, das ist damit machbar? Es sind ja nur 320 x240 Zeilen auf
diesem Pollin s/w Display, die müssten doch recht fix übertragbar sein.
Christian
Stelle mir halt vor dann sowas ähnliches auf dem Tisch zu haben, nur
statt mit 5 x uC die über SPI verbunden sind, weil einer das nicht
schafft eben mit einem ARM7.
Hallo Christian,
falls es Dich interessiert:
wir haben in der Arbeit ein kleines Projekt mit der Embedded Artist
Platine LPC2468-OEM16 und einem S1DA04 der seinerseits ein NEC LCD mit
320x240 ansteuert, gebaut. Die ganze Test Firmware wurde mit einem
Imagecraft Compiler und NoICe entwickelt und funktioniert fuer
Instrumentanwendungen sehr gut. Die Geschwindigkeit der
Graphicansteuerung ist passable. Die Hardware hat auf Anhieb
funktioniert;-)) und die Schaltung ist eigentlich verhaeltnismaessig
einfach. Es ist wichtig dass die Clock fuer den Epson 40 MHz betraegt
und nicht vom LPC kommt. Ein paar Wait states zwischen dem LPC und dem
S1D sind auch notwendig.
Ein Oszillogramm Display mit zig Updates/s und gleitendem
Bildschirmraster ist problemlos moeglich. Es gibt allerdings noch
Probleme mit der Synchronisierung des Prozessor mit dem dem S1D die sich
als periodisches Schimmern neben den Linien bemerkbar machen. Das
benimmt sich wie ein langsamer Schwebungsvorgang. Fuer ein paar Sekunden
sieht alles gut aus und dann schimmert es fuer eine Sekunde und
verschwindet wieder. Um das zu beheben wird es noch einiger Arbeit
beduerfen. Es ware warscheinlich besser einen Graphic Chip mit
groessererem Speicher zu verwenden da man besser den Prozessor/Graphics
Datenaustausch entkoppeln kann. Damit muessten sich die o.g. Probleme
leicht loesen lassen.
Der ganze Testaufbau wird uebrigens mit einem FORTH Interpreter fuer
debugging gesteuert. FORTH ist fuer die Hardwareentwicklung sehr
nuetzlich, finde ich, da man alles sehr schoen vom Terminal kommandieren
kann und komplizierte Befehle im Handumdrehen von der Commandline
eintippen kann. Da erspart man sich viel Kompileren.
Der Epson Graphics Controller wird vom externen Bus des LPC2468
angesteuert. Das LCD braucht ueberiegens noch einen SPI Interface Zugang
zum Setzen der LCD Register.
Sonst wuerde ich vorschlagen direkt mit dem LPC2478 zu arbeiten. Da
erspart man sich die ganze zusaetzliche Verdrahtung des S1DA04
Fuer ein einigermassen gutes Layout solltest Du schon in den sauren
Apfel einer 4-layer Platine beissen mit einer guten internen Ground
plane und der 3,3V und 2.5V Versorgung mit genuegend
Keramikkondensatoren. ;-(
Jedenfalls gibt es bei solchen Projekten noch massenhaft fuer mich zum
lernen. Ich nehme an das die o.g. Probleme von vielen Entwicklern schon
geloest wurden - aber jeder Anfang ist schwer. Jedenfalls wuerde ich
mich freuen wenn das bei Dir auch einigermassen funktionieren wird.
Gruss,
Gerhard
Gerhard. wrote:
> Es gibt allerdings noch> Probleme mit der Synchronisierung des Prozessor mit dem dem S1D die sich> als periodisches Schimmern neben den Linien bemerkbar machen.
Meinst du damit eine Syncronisation zwischen den Schreibdaten und der
Framerate des Displays ?
Dazu gibt es normalerweise ein Flag, das den Bildbeginn angibt.
Interessanerweise finde ich das beim 13A04 nicht.
Hallo Herhard,
das Board kostet wie ich sehe 109 Euro ist also bezahlbar. Diese Effekte
verstehe ich nicht so ganz, man schieb ja nur Daten rein ins Dual Port
RAM und der Epson müsste damit klarkommen. Probleme sehe ich eher da,
dass es einiges an Kabel ist, um den Bus mit dem Epson zu verdrahten,
denke mal dass man da nicht beliebig lang werden darf. Lieber wäre mir
der Grafik Chip auf der Platine.
Das Problem ist garantiert schon tausendfach gelöst worden., soviele
Bildschirmgeräte wie es gibt, allerdings standen da auch keine
Hobbywerker hinter sondern Entwickler, die 8h Zeit pro Tag dafür haben.
4 Lagen sind aus der Hobbykasse nicht zu bezahlen, 270 Euro würde ein
Board kosten, meine Frau killt mich: "Christian, unser Sohn braucht ein
neues Fahrrad, hast Du daran mal gedacht?" :-) Sobald RAM ins Spiel
kommt oder ein externer Bus ist es mit 2 Lagen (fast) vorbei.
In der Doku des Chips, den Benedikt meint steht, dass der auch an einem
8 Bit Kanal betrieben werden kann, mit Adressleitungen sind es dann
16+8+5 = 29 Leitungen, die ich meinem ARM7 2436 mit 80 Pins abknöpfen
muss, der damit natürlich viele seiner Peripheriemöglichkeiten verliert,
eigentlich alle, da die Ports mehrfach belegt sind und ich natürlich
Byteweise adressieren will. Die Hochspannungs Einheit für die
Beleuchtung würde ich fertig kaufen und huckepack auf die Platinen
montieren.
Ich werde die Idee nochmal durchdenken mit den Schieberegistern, also
nur schreiben aufs Grafikram. 60kb durchreichen dürfte ja fix gehen, wie
gesagt nur statische Anzeigen. Vielleicht ein externes NVRAM mit SPI
Interface als Grafikspeicher, darin gemütlich die nächste Grafik
vorbereiten und wenn sie fertig ist an den Grafikcontroller
durchreichen. Ob das nun 0,5 Sekunden dauert ist nicht tragisch.
Wenn ich wüsste wieviel Arbeit es ist sich in diese uCLinux Sache
einzuarbeiten..... wäre schon toll SD Karten einfach auf High-Level
Ebene anzusteuern ohne sich um den ganzen Bitkram Gedanken zu machen :-)
Christian
Hallo Benedikt,
"Meinst du damit eine Synchronisation zwischen den Schreibdaten und der
Framerate des Displays ?
Dazu gibt es normalerweise ein Flag, das den Bildbeginn angibt.
Interessanerweise finde ich das beim 13A04 nicht."
Genau. Das wollen wir als naechstes anpacken. Zur Zeit wird die Flag
noch nicht mitverwendet. Da wir auf den LPC2478 umsteigen ist die
Loesung dieses Problems eigentlich nur noch fuer Hobbyzwecke
interessannt; -)
Gerhard
Christian,
ich gaube schon dass man es mit einer zweiseitigen Platine gehen
koennte. Man muesste vielleicht erfinderisch sein wie man die 2.5V und
die 3.3V hinfuehrt. Vielleicht koennte man eine Kupferfolie auf
Kaptonband kleben un dann mit kurzen Drahtstuecken mit den
entsprechenden Chip Pins verbinden. Zumindestend wuerde das mehr Platz
fuer eine GND Flaeche lasssen. Das Problem ist auch dass die LPC2468
OEM16 Platine zwei 100 Pin Verbinder mit nur 0.6 mm Pinabstaenden
aufweist. Das macht das Layout schon hoellisch .
Muss jetzt gleich weg.
Gruss,
Gerhard
Hallo Michael,
gibt es für diese Karte eine Spec oder Beschreibung, Schaltplan?
Besonders für das Interface zum Controller? Kosten?
Ziel sind diese 320x 240 NINYan Displays aber ich habe auch uralte
monochrome 640x480 Dual-Scan Displays hier ohne Hintergrundbeleuchtung.
Bin da sehr interessiert. Zu kaufen gibts das auch professionell aber
kostet rund 600 Euro.
Christian
PS: Nicht dass wir uns missverstehen, unter Display verstehe ich diese
halbintelligenten Dinger, wo die Bytes direkt mit Sync Signalen
zeilenweise reingeschoben werden, keine analogen Signale wie bei CRT
Geräten.
zB
http://www.pollin.de/shop/detail.php?pg=NQ==&a=OTM1OTc4OTk=
Der 13506 kann beides. Er hat einen analogen Ausgang für CRT und TV und
einen digitalen mit bis zu 16bit Daten. Er kann analog und digital
gleichzeitig.
Die Ansteuerung mit dem Hardwarebus sollte auch kein Problem sein, da
der 13506 ein Schreibfifo hat. Nur das Lesen kann man ohne Verwendung
des Wait Signals vergessen. Denn der Zugriff auf den DRAM ist verdammt
langsam (außer sequentielles Lesen).
Alles zusammen (als Bausatz) kostet 36,84 Euro inkl. Versand zzgl. etwa
6 Euro für Kleinkram bei Reichelt (musst du noch selbst bestellen).
Daten siehe Anhang. Das Teil ist Pinkompatibel zu Benedikt's
"Original-Version", wird aber nur mit 3,3V angesteuert statt mit 5V.
Hallo Michael,
Mann.... das kommt dem ja schon richtig nahe! Wie ich sehe ist der ganze
Bus herausgeführt (kann man also mit einem 40 Pinner PIC vergessen :-)
Also müsste ich da nur noch Glue Logic dranpappen, damit ich ggf. meine
serielle Ansteuerung schaffe. Inverter ist auch drauf. Und wenn Benedikt
sagt, dass der auch CRT ansteuern kann ist das doch super, auch wenn
z.Zt. nicht bemnötigt.
Sind diese 3245 am Ausgang 3,3v -> 5V Konverter? Ich weiss nicht mit
wieviel diese Displays arbeiten , glaube es waren 5V. Die Aufgabe
bestünde also darin mein Olimex Board mit ein paar HCT... zu bestücken,
sehr viele Flachbandkabel zu verdrahten, den Chip zu konfigurieren und
dann loszulegen.
Sind die getetestet worden?
Glaube Du hast grad Deinen letzten Bausatz an den Mann gebracht :-))
Christian
Christian wrote:
> Wie ich sehe ist der ganze> Bus herausgeführt (kann man also mit einem 40 Pinner PIC vergessen :-)
Nein, nicht wirklich:
Gerade dadurch, dass der ganze Bus rausgeführt ist, ist alles flexibel.
In dem anderen Thread habe ich eine Schaltung gezeigt, wie man das ganze
an einen AVR anschließen kann. Den Datenbus kann man nämlich problemlos
auf 8bit reduzieren. Nur die 21bit Adressen sind alle notwendig.
> Sind diese 3245 am Ausgang 3,3v -> 5V Konverter?
Ja.
> Ich weiss nicht mit> wieviel diese Displays arbeiten , glaube es waren 5V.
Die 320x240 NAN YA Displays können 3,3V oder 5V. Die sind flexibel.
> Sind die getetestet worden?
Die alte Version (mit 5V) läuft bei mir seit längerem problemlos an
einem AVR und auch an einem M16C.
Ich habe schon etliche Controller von Epson ausprobiert, der 13506 ist
eindeutig in meiner persönlichen Lieblingsliste ziemlich weit oben, da
er ziemlich unkritisch ist. Gegenüber dem Vorgänger 13504 wurde einiges
verbessert, der Nachfolger 13513 hat einige unschöne Features, man
könnte es schon fast als Bugs bezeichnen.
Andere Epson Controller sind da weitaus störanfälliger als der 13506.
Hallo Benedikt,
ich habe mir die fertige Platine nochmal angeschaut und mir alles für
den 13506 Epson runtergeladen. Der Chip ist wesentlich komplexer innen
als mein 13705 der nur s/w kann und einen internen 80k Speicher hat.
Allein die HAL zu verstehen von Epson und die zum Laufen zu kriegen
dürfte eine Weile dauern, keine Ahnung ob die den GNU CC verwendet haben
und sich das alles plug & play compilieren lässt. Alles selsbt zu
schreiben dürfte verfehlt sein, wenn die das schon gemacht haben. Diese
Bitschieberei ist nicht so mein Ding.
Ohne jetzt jeden Thread bis ins Detail gelesen zu haben stört mich das
SDRAM. Mir fehlt der Nerv mich mit der Ansteuerung auseinander zu
setzen, da ich keinerlei Werkzeuge haben zu prüfen, was da auf dem Board
passiert, das wäre ein nervtötendes Herumraten wenn der Code nicht
läuft.
Das SDRAM ist am Epson angeschlossen, er stellt dazu leitungen bereit.
Die Fraga lautet nun: Übernimmt der 13506 nun die Verwaltung (Refresh
etc) dieses Chips völlig von allein, so dass man über den Bus nur ein
RAM mit Bytes sieht wie bei einem SRAM oder muss man sich da wirklich
noch mit SDRAMs auseinander setzen? Im Datenblatt finde ich auf die
Schnelle dazu nichts.
Falls ja und man muss sich um das SDRAM kümmern, dann nehme ich lieber
den 13705, der viel einfacher ist und ein internes 80ßk Ram hat und baue
den in eine Platine ein, ich verwende ja eh nur kleine s/w Displays.
Gruss,
Christian
Christian K. wrote:
> Alles selsbt zu> schreiben dürfte verfehlt sein, wenn die das schon gemacht haben. Diese> Bitschieberei ist nicht so mein Ding.
Die HAL finde ich etwas nervig. Ich kann dir aber Beispielcode geben,
der die wichtigsten Sachen initialisiert.
> Die Fraga lautet nun: Übernimmt der 13506 nun die Verwaltung (Refresh> etc) dieses Chips völlig von allein, so dass man über den Bus nur ein> RAM mit Bytes sieht wie bei einem SRAM
Ja, das macht er alles. Man muss dem nur sagen wie der Angeschlossen
ist. Von außen sieht man nur den 21bit Adress und den 8/16bit Datenbus.
Mit dem DRAM selbst kommst du garnicht in Kontakt.
>>Ja, das macht er alles. Man muss dem nur sagen wie der Angeschlossen>>ist.
GOTTSEIDANK !! seufz
Werde mir das Datenblatt des 13506 dann im September mit nach Mallorca
nehmen, liest sich am Strand sicherlich besser :-)
Ohne HAL ist das Programmieren aber noch nerviger und dauert viel länger
bzw ist auch nicht gerade OSI/ISO good engineering style.
Was wäre Deine Empfehlung bzgl der Spannungen:
ARM = 3.3V (fix)
Grafikkarte = 3.3V ?
Display NIN Ya Pollin = ?
Hallo,
das Boadr ist gekommen...... und eigentlich ärgere ich mich über das
verblasene Geld :-(((
Ihr habt vergessen die Lötpads des 0,4er Finepitch lang genug zu machen,
so dass das Lot an die Pins kriechen kann, wenn man mit der Lötspitze
vorher fährt, so decken die Pins die Padfläche voll ab. 0,4 fine pitch
ist ohne entsprechende optische Geräte wie ein Stereomikroskop und
spezielle Lötausrüstung nur für Experten, die das jeden Tag machen,
keinesfalls aber für ein Hobbylabor. 0,5er wäre kein Thema gewesen, da
sind die Abstände gross genug.
Ergebnis: Tausend Kurzschlüsse hinter den Pins, der Epson Chip ist im
Einer, einige Pins sind leicht verbogen beim Auslöten mit der
Heissluftpistole.
Wenn ich einen neuen Chip habe werde ich es als letzt Chance zu einem
unserer Kunden ins Labor bringen, damit da ein Crack das versucht.
Frustriert,
Christian
Tut mir leid das zu hören!
Deswegen habe ich gefragt, ob du es selber löten willst... ;) Das Decal
ist das aus dem Original, sprich dasselbe wie bei der letzten
Sammelbestellung.
Ich habe inzwischen 5 St. von den Dingern gelötet, mit (gutem)
Flussmittel, ner Lupe von ner 3. Hand und Entlötlitze ging das ganz gut.
Und ich mache das auch nur jedes Schaltjahr mal...
Hi,
leider sind mir 40 die Augen auch nicht mehr so gut, trotz Brille.
Problem war, dass sich Kurzschlüsse hinter den Pins befanden. Ich denke
aber, dass die Leute die das jeden Tag machen hinkriegen. Die Platine
ist ja noch ok. Und dann geht wohl das Drama los das Teil ans Laufen zu
kriegen, ohne etwas "sehen" zu können, denn erstmal muss ja die
Kommunikation über die Schieberegister laufen und man programmiert
"blind" in der Hoffnung, dass es richtig ist was dann in den Chip
reingeschrieben wird. Ich habe leider nicht so viele Leitungen frei wie
der Chip benötigt.
Benedikt, hattest Du da Spezialtools? Oder vielleicht einfach mal eine
RAM Zelle beschreiben und rücklesen? Ich denke es dauert ne Weile bis
der Bildschirm irgendwas sinnvolles zeigt....
Gruss,
Christian
Ich habe als erstes das Product Code Register ausgelesen, um zu sehen ob
die Kommunikation allgemein geht.
Dann das DRAM eingeschaltet und mit dem Oszi nachgemessen, und mich dann
bis zum eigentlichen Display Controller vorgearbeitet. Man kann da ja
zum Glück viel messen und so direkt sehen ob die Einstellungen das
gewünschte bewirken.
Ich muss zugeben, dass ich bei der ersten Platine auch Kurzschlüsse
hinter den Pins hatte, dummerweiße genau an einem Vcc/GND Pärchen. Das
lag daran, dass ich mit viel zuviel Lötzinn gelötet hatte. Die nächsten
paar gingen dann besser, da waren die Kurzschlüsse an leichter
zugänglichen Stellen.
Hallo,
so, der Versuch unter dem Stereo Mikroskop war erfolgreich, geht sehr
gut mit smd Lötzinn, Entlötlitze und einer Hohlkehle. Die besten
Ergebnisse hatte ich wenn ich die vollgetränkte Entlötlitze direkt auf
die Pins drückte.
Ich hoffe, dass die Bauteilposition richtig ist (grosser Punkt des Chips
deckungsgleich mit Punkt auf der Platine) und der Epson Chip auch
richtig auf der Platine sitzt, sonst springe ich aus dem Fenster :-)
Benedikt, ok? Passt das?
Gruss,
Christian
Christian K. wrote:
> Ich hoffe, dass die Bauteilposition richtig ist (grosser Punkt des Chips> deckungsgleich mit Punkt auf der Platine) und der Epson Chip auch> richtig auf der Platine sitzt, sonst springe ich aus dem Fenster :-)
Ich hoffe das Fenster ist nicht zu hoch...
Leider hast du genau den falschen Punkt genommen. Bei mir sitzt das IC
genau um 180° versetzt drauf.
Keine Ahnung wer sich das hat einfallen lassen, aber irgendwie gibt der
kleine Punkt Pin 1 an. Meist ist das auch links unten wenn das IC so
liegt, dass man den Text lesen kann.
Benedikt,
hast Du noch einen dieser Epson S1D13506FAA Chips übrig? Habe den grad
mit der Heissluftpistole wieder runtergeholt, hat aber wohl nicht
überlebt, wäre unwahrscheinlich und die Sache nicht wert. Leider
verlangt Digikey 18€ Versandkosten, das ist viel zu viel für nur einen
Chip.
Christian
Schön mal eine 13506 Platine zu sehen, genau sowas hatte nämlich
befürchtet: Das wird riesig.
Spricht irgendetwas gegen den 13A05 mit integriertem SRAM um
damit ein QVGA TFT/OLED mit 8bpp anzusteuern?
Einen Blitter hat der ja auch, wobei ich mir nicht sicher bin
ob der Speicher dafür auch groß genug ist um damit etwas sinnvolles
zu tun.
Christian K. wrote:
> hast Du noch einen dieser Epson S1D13506FAA Chips übrig?
Nein, leider nicht.
Ich habe mir damals nur soviele gekauft wie ich für den Eigenbedarf
brauchte. Wenn ich das gewusst hätte wieviele an dem interessiert sind,
hätte ich ein paar mehr bestellen sollen.
let wrote:
> Spricht irgendetwas gegen den 13A05 mit integriertem SRAM um> damit ein QVGA TFT/OLED mit 8bpp anzusteuern?
Nein, eigentlich nicht. Der einzige Nachteil ist halt der kleine
Speicher:
Bei 16bpp und 320x240 werden 150kByte benötigt, also etwas mehr als die
Hälfte. Somit hat man nicht mehr genug Speicher für eine 2. Seite in der
man das neue Bild aufbauen kann, während die alte angezeigt wird.
Ich würde daher vielleicht eher zum S1D13743 greifen, der hat zwar
weniger Features, hat aber 464kB und kann 24bpp.
Hi,
woher könnte man dieses Epson Steinchen denn noch bekommen? Es gab doch
da diesen Versand in Polen aber der Name fällt mir nicht mehr ein.....
Tausche auch gegen S1D13705, den habe ich noch über.
Christian
Benedikt K. wrote:
>Ich würde daher vielleicht eher zum S1D13743 greifen,
Guter Tip, den kannte ich noch nicht. Oder besser gesagt,
der ist mir noch nicht aufgefallen. Ich "kenne" eigentlich
keinen dieser Controller.
Bei dem Chip könnte man dann auch Bilder anzeigen lassen
oder auch Farbverläufe.
Christian K. wrote:
> woher könnte man dieses Epson Steinchen denn noch bekommen?
Versuch es mal bei: http://www.csd-electronics.de/
Wenn er ihn nicht im Shop gelistet hat, einfach mal anrufen oder E-Mail.
Gruß
Udo
Nettopreise [EUR]: 20.21
Naja, eine Apotheke eben. Hier kostet der 8,85 Euro. Mal schauen wie ich
den Schukat aus dem Kreuz leiere :-) Die sind gleich nebenan bei
Solingen.
CSD hat den leider nicht bzw habe ich noch keine Antwort von denen.
Wenn 4-Lagen nicht so teuer wäre im Einzel-Musterbau, dann würde ich
gleich ein ganzes Board mit dem LPC2214 144pinner designen, wo tutto
kompletti alles drauf ist, was das Leben schöner macht incl schönem
Grafikdisplay. Kein Netzwerk aber mehr so ein Steuer und Regelgerät.
Leider habe ich keine Ahnung, wie sich der LPC2214 mit dem JTAG Wiggler
unter Rowley debuggen lässt, da er externes Flash verlangt aber auch
ein internes hat. Könnte mir vorstellen, dass das sehr kompliziert
werden könnte da drauf Programe zu entwickeln, da die ja übers JTAG
direkt ins Flash müssten.
Und die Einchip Lösung LPC 2138 hat leider zu wenig Pins und keinen
externen Adressbus aber dafür massig Flash und RAM.
