LVDS to LCD (TFT)

>benötigt man um an ein LVDS Interface ein 18-Bit farbiges TFT
>anzuschließen einen bestimmten IC dazwischen?
Ja. Einen LVDS Receiver.

ein kleine zusatzfrage noch: wenn dieses TFT einen Touch (AD7843 Touch 
Controller oder einen anderen) besitzt, wie bekomm ich die SPI-Signale 
am besten zum Hauptprozessor? Der Prozessor gibt u.a. LVDS, LPC und SMB 
aus.

Gruß
Bernd

> Auf welcher Leitung (LVDS)
> werden die Farbinformationen R1, R2, R3, etc. übertragen?
Auf allen. Zeitlich verteilt  :-o
Du hast bei 3x6Bit vermutlich 3 LVDs Datenleitungen und 1 Taktleitung. 
Diese werden vom LVDS-Receiver in die parallelen Daten und Sync-Signale 
umgewandelt (z.B. vom DS90C384).

> wie bekomm ich die SPI-Signale am besten zum Hauptprozessor?
Am besten mit SPI.

> Der Prozessor gibt u.a. LVDS, LPC und SMB aus.
Naja, es ist eigentlich egal, was er ausgibt. Er soll ja einlesen 
:-/
Lass mal diese Salamitaktik der Informationszuteilung bleiben und 
schreibe alles, was nötig ist, dass man dir einen brauchbaren Tipp geben 
kann:
Welcher Prozessor?
Welches Betriebssystem?

Als Prozessor befindet sich der Intel Atom Z530 auf dem Board und als 
Grafikprozessor der Intel GMA 500.

Als Ein- bzw. Ausgabesignale stehen mir PCIe, SDIO, SATA, SDVO, LVDS, 
SMB, I2C, JILI, LPC und USB 2.0, Ethernet zur Verfügung.

Hier ist der Link zu diesem Board
http://de.kontron.com/products/computeronmodules/com+express/nanoetxexpress/nanoetxexpresssp.html

SPI steht mir leider nicht zur Verfügung.

>LVDS-Receiver in die parallelen Daten und Sync-Signale
>umgewandelt (z.B. vom DS90C384).

Ist bei mir das erste Board (oder soll es werden) mit einem x86 
Prozessor: versteh ich das richtig, dass das Bus-Timing ähnlich wie bei 
einem ARM per Register oder ähnlichem eingestellt werden können?


Als Betriebssystem wird Windows CE eingesetzt.

Gruß
Bernd

> versteh ich das richtig, dass das Bus-Timing ähnlich wie bei
> einem ARM per Register oder ähnlichem eingestellt werden können?
Wenn du selber aufwendige Hardware anschliessen willst, dann ist dein 
Knotenpunkt die PCIe-Schittstelle. Vergiss die uC-Denkweise am besten 
komplett... :-o
Glaub mir: du willst garantiert nicht auf dem Prozessorbus 
herumwursteln. Um die (grob geschätzt 1265 bis 3698) Register im 
Chipsatz richtig eingestellt zu bekommen, dafür gibt es beim PC das 
BIOS. Später nach dem Booten übernimmt evtl. das OS (WinCE) eine 
Neuinitialisierung der angeschlossenen Komponenten.

Stell dir das Board ganz einfach wie einen PC vor. Wo schliesst du an 
einen PC die Hardware an? Richtig:
>  USB 2.0
Genau dort wird Hardware (Tastatur, Maus, Touch) an einen PC 
angeschlossen.
> Als Betriebssystem wird Windows CE eingesetzt.
Dann bekommst du nämlich auch Treiber für deine angeschlossene Hardware.

Nachtrag:
>>  USB 2.0
> Genau dort wird Hardware (Tastatur, Maus, Touch) an einen PC
> angeschlossen.
Und deshalb gibt es Touch-Controller mit USB-Interface
(z.B. ehemals Hampshire TSharc, jetzt bei Microchip erhältlich)

vielen Dank für deine Erklärungen - muss wirklich noch von diesem 
µC-Denken weck kommen.

>Wenn du selber aufwendige Hardware anschliessen willst, dann ist dein
>Knotenpunkt die PCIe-Schittstelle.

Gilt das auch für eine mögliche Kommunikation mit einem ARM7 oder ARM9 
Controller? Gibt es hier einen PCIe-to-ExternalMemoryInterface 
Controller? Oder bieten hier DualPort-RAMs eine sehr gute Alternative 
Daten zwischen den beiden Prozessoren auszutauschen?

USB stellt zwar sicherlich auch eine Alternative dar, kommt beim ARM7 
aber nicht so häufig vor bzw. ist nur 1x vorhanden, um z.B. externe 
User-Peripherie anzuschließen etc.

Gruß
Bernd

> Oder bieten hier DualPort-RAMs eine sehr gute Alternative
> Daten zwischen den beiden Prozessoren auszutauschen?
Wie gesagt: du kommst nicht an irgendeinen Speicherbus des PCs, deshalb 
kannst du nicht einfach irgendwelche RAMs anschliessen. Du wirst eine 
PCIe-Bridge brauchen, um einen Local-Bus für die Verbindung zum ARM zu 
bekommen.

Lothar Miller schrieb:
> Wenn du selber aufwendige Hardware anschliessen willst, dann ist dein
> Knotenpunkt die PCIe-Schittstelle.

Man kann den LPC deserialisieren und bekommt einen 8-Bit ISA. Nur muß 
man dann auch etwas in den Registern rumpokeln damit man die Adresse auf 
den LPC bekommt. Geht alles, möchte man mit CE aber nicht selbermachen. 
Ich selber würde auch vom CE die Finger lassen. Entweder embeddedXP 
(wenn schon Mickeysoft) oder Linux. Da hat man deutlich mehr 
Möglichkeiten.

Und nochwas: An den 'Prozessorbus' wirst du bei dem Board sowieso nicht 
rankommen. Der dürfte komplett 'unter Flur' verlegt sein.

> Man kann den LPC deserialisieren und bekommt einen 8-Bit ISA.
Für ein neues Design würde ich mir das aber nochmal genau durch den 
Kopf gehen lassen.

> Ich selber würde auch vom CE die Finger lassen.
Das kommt auf die Anwendung an: CE ist (treibermäßig) relativ gut 
unterstützt und vor allem die Interruptantwortzeiten sind annähernd 
deterministisch. Allerdings gibt es auch hier Fallstricke (gut versteckt 
im BIOS), insbesondere wenn es um Interruptantwortzeiten unter 50us 
geht... :-/

ich denk mal als Austauschbus mit anderen Prozessoren dient dann 
wirklich nur der PCIe Bus oder USB (wenn dieser beim ARM nicht 
anderweitig verwendet wird).

Gruß
Bernd

Lothar Miller schrieb:
>> Man kann den LPC deserialisieren und bekommt einen 8-Bit ISA.
> Für ein neues Design würde ich mir das aber nochmal genau durch den
> Kopf gehen lassen.

Der LPC ist im US15W drin. Man könnte Kontron fragen ob die eine SIO 
unterstützen. Dann kann man u.U sogar den eingebauten SPI benutzen 
(Nuvoton hat sowas). Wenn man will geht vieles. Eine PCIe-Local Bridge 
macht das Mainboard unnötig kompliziert.


>> Ich selber würde auch vom CE die Finger lassen.
> Das kommt auf die Anwendung an: CE ist (treibermäßig) relativ gut
> unterstützt und vor allem die Interruptantwortzeiten sind annähernd
> deterministisch. Allerdings gibt es auch hier Fallstricke (gut versteckt
> im BIOS), insbesondere wenn es um Interruptantwortzeiten unter 50us
> geht... :-/

Ich meinte gerade den Atom/US15W. Der wird zwar unterstützt, aber die 
Funktionen sind doch recht rudimentär.

Edit: wenn das Tempo keine Rolle spielt: Warum nicht I2C?