Hallo, ich möchte den STM32F4 mit dem Epson S1D13781 parallel verbinden. Der STM unterstützt 8080 und 6800 Modes, im DB vom Display Controller wird von direct und indirect 16 bit mode gesprochen. Ich möchte den Displaycontroller wie in ST AN2790 per FSMC ansteuern. In dieser AN werden CS, /RD, /WR, RS und D0-15 verwendet. Der Epson hat aber CS, /WR, /RD, /UB, /LB, P//C und D0-15. Wie passen die zusammen?
P/C ist RS und kommt an A0 bzw A1. /UB und /LB sind die Byte Strobes NBL[1] und NBL[0], und /CS kommt an ein NE[] Signal. fchk
Danke schonmal, ich versuche jetzt mal folgende Einstellungen: FSMC Bank1, NOR/PSRAM1 -> NE[1], A0, Basisadresse:0x60000000 STM32 S1D13781 ----------------------------- FSMC_NE1(PD7) CS# FSMC_NWE(PD5) WR# FSMC_NOE(PD4) RD# FSMC_NBL0(PE0) UB# FSMC_NBL1(PE1) LB# FSMC_A[0](PF0) AB1 FSMC_D[0..15} DB0-15 Beim AB0/TE(Epson) bin ich mir noch unsicherer, gehört der ans NWAIT(STM)?
Ich möchte den STM32F4 im das LQFP100 Gehäuse verwenden, nun hat der aber keinen FSMC_A0. Gem. AN2790 soll man einen A16-A23 verwenden. Aber welchen nehme ich denn nun, bzw. was ist überhaupt die Aufgabe von P/C oder RS?
Gnubbel schrieb: > zw. was ist überhaupt die Aufgabe von P/C oder RS? Was sagt denn das Datenblatt des S1D13781 dazu?
Rufus Τ. Firefly schrieb: > Was sagt denn das Datenblatt des S1D13781 dazu? Natürlich habe ich ins Datenblatt geschaut. Seite 16: This input pin has multiple functions, AB1 and P/C#. See Section 4.4, “Host Interface Pin Mapping” on page 20 for details. Und auf Seite 20 steht dass es bei Indirect 16-bit Mode eben P/C# ist, und nicht AB0.
Sieh Dir mal die Beschreibung der beiden 8-Bit-Betriebsarten an, die als "Direct 8-Bit" und "Indirect 8-Bit" bezeichnet werden. Einerseits die Diagramme auf Seite 12, aber vor allem die Timingdiagramme auf den Seiten 42 und 44 und vor allem die Tabelle 9-15 auf Seite 45. P/C# wählt zwischen Commando (nur beschreibbar, Low) und Data (beschreib- und lesbar, High) aus. Im direkten Modus wird der Adressbus mit immerhin 19 Adressleitungen mit dem ansteuernden Prozessor/Controller verbunden. Damit kann der Speicher des LC-Controllers direkt vom ansteuernden Prozessor/Controller adressiert werden. Kleine µC oder µC ohne externes Speicherinterface sind hiermit aber deutlich überfordert. Für die gibt es den indirekten Modus, der nur eine Adressleitung erfordert - die mit P/C# zu verbinden ist. Alle anderen Adressleitungen bleiben unbenutzt.
Rufus Τ. Firefly schrieb: > P/C# wählt zwischen Commando (nur beschreibbar, Low) und Data > (beschreib- und lesbar, High) aus. Also kann ich dann mit den Adressen von 0x60000000 - bis 0x6000FFF auf die Commands zugreifen und mit Adressen von 0x60010000 - 0x6001FFFF auf die Daten, wenn A16 mit P/C verbunden wird? Also gut, ein C# kann heißen Commands wenn low, aber für was steht P? Ist es so dass UB# und LB# dem Baustein nur mitteilen dass jetzt im unteren oder oberen Byte gültige Daten liegen(write) oder gelegt werden sollen(read)? Das würde für den 16 bit Modus bedeuten dass sie also bei jeder Kommunikation low sein müssten. Belegung nach jetzigem Stand: STM32 S1D13781 ----------------------------- FSMC_NE1(PD7) CS# FSMC_NWE(PD5) WR# FSMC_NOE(PD4) RD# FSMC_NBL0(PE0) UB# FSMC_NBL1(PE1) LB# FSMC_A[16](PD11) AB1 FSMC_D[0..15} DB0-15
Du willst das Ding im 16-Bit-Modus ansteuern. OK, dann ist zwar einiges anders, aber eines bleibt gleich: Wird das Ding im "indirekten Modus" angesteuert, dann gibt es keine Adressleitungen, aber das Signal P/C#. Im "direkten Modus" gibt es Adressleitungen, aber kein Signal P/C#. Wenn Du also Adressleitungen Deines µC mit dem Controller verbindest, gibt es kein P/C#. LB# und UB# stehen in der Tat für die Auswahl der genutzten Datenbushälfte, sind beide aktiv (low), so wird ein 16-Bit-Zugriff durchgeführt, ist nur eines davon aktiv, gibt es einen 8-Bit-Zugriff. Sieh Dir die Blockdiagramme im Datenblatt auf den Seiten 10 und 11 an, dort sind die 16-Bit-Interfaces beschrieben. Bist Du Dir sicher, daß Du diese Betriebsart auch wirklich verwenden möchtest? Wäre eine Ansteuerung per SPI nicht wesentlich einfacher?
Rufus Τ. Firefly schrieb: > Bist Du Dir sicher, daß Du diese Betriebsart auch wirklich verwenden > möchtest? Wäre eine Ansteuerung per SPI nicht wesentlich einfacher? 1. Ja, denn ich weiß ja noch nicht was ich mal alles anzeigen will, oder in welchen Projekten das noch verwendet werden soll. Bei unseren Stückzahlen muss man schon etwas flexibles bauen um es auch wieder verwenden zu können. Also einmal richtig anschließen, und dann für die nächsten Jahre Ruhe. 2. Ja, natürlich wäre SPI einfacher, da gibt es sogar eine Referenz mit STM32 für. Also glücklich bin ich überhaupt nicht damit wie es aussieht, mir fehlt da irgendwie noch ein ALE oder so etwas. Wenn es ganz doof läuft, versuche ich doch ein größeres Gehäuse und schließe den Displaycontroller komplett an.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.