Ich möchte das bei Reichelt erhältliche Display [1] mit 18bit-Schnittstelle an einem LPC1788 betreiben. Bei der Hardwareentwicklung kommen mir tausend Fragen, die ich nicht so recht zu lösen weiß. Langsam frustriert mich die ganze Sache auch ziemlich. Entweder, der Chip ist wirklich nicht verständlich dokumentiert, oder ich bin schlicht und ergreifend noch nicht weit genug, um das alles zu verstehen. Folgende (und noch mehr) Fragen tauchen momentan bei der Hardwarenetwicklung auf. Die Seitenangaben beziehen sich auf [2]. 1. Das SDcard-Interface beinhaltet einen Pin SD_PWR (p408). Damit kann anscheinend die Karte genau dann aktiviert werden, wenn auch wirklich eine Kommunikation erforderlich ist. Im Datenblatt wird nicht erwähnt, ob der Pin die Karte direkt treiben kann, oder ob ein Transistor erforderlich ist. Außerdem lässt sich einstellen, ob der Pin active low oder high agieren soll (p33). Im "power up mode" (p410) sei er aber immer high (p421), je nach Einstellung also nicht active. Damit verperrt man sich doch die Möglichkeit, die Karte mit einem P-Channel zu versorgen und muss stattdessen Masse schalten? Oder eben tatsächlich aus dem Pin versorgen, aber das verkraftet der doch nicht, oder? 2. Die Hardware muss mit einem AVR Eval Board kommunizieren. Dafür steht nur noch die RS485-Schnittstelle zur Verfügung und ich möchte UART1 verwenden. Es happert allerdings schon daran, dass ich im Datenblatt nicht erkenne, welche Pins denn für die Datenübertragung verantwortlich sind. Ich finde nur die Angabe, dass DTR und RTS als "RS-485/EIA-485 output enable signal" verwendet werden können (p432). 3. In einer Tabelle (p309) werden die für die Ansteuerung eines LCD benötigten Pins bzw. Signale beschrieben. Ich verstehe das so, dass NXP gerne die LSBs des Displays anschließen würde. Ich würde aber intuitiv sagen, dass die MSBs besser geeignet wären. Konkret peile ich eine Ansteuerung im 1:5:5:5-Modus an. Ich muss also, soweit ich das verstanden habe, die drei LSBs (je eines pro Farbe) zusammenschließen, was anscheinend aber der Controller für mich übernimmt? vielleicht kann mir da jemand auf die Sprünge helfen, wo jetzt was hingehört. Ich habe auch schon versucht, die Probleme mit NXP zu klären. Die haben allerdings 5 Werktage Bearbeitungszeit. Das ist zu lange, da ich eine Deadline gestellt bekommen habe. Hoffentlich könnt ihr mir stattdessen helfen. [1] http://www.reichelt.de/LCD-Module-Touch-Grafik/TFT-DIS-5-7-MT/index.html?ACTION=3&GROUPID=3011&ARTICLE=101752&SHOW=1&START=0&OFFSET=500& [2] http://www.nxp.com/documents/user_manual/UM10470.pdf
1. Lohnt sich das wirklich für deine Anwendung, eine solche Powercontrol zu implementieren? Lege die Karte doch an Dauerversorgung, wenn es nicht auf den letzten mA ankommt. 2. Natürlich findest Du keine direkten RS485 Signale. RS485 "entsteht" per Treiberbaustein (z.B. SN75176 als Urgestein) aus den normalen RX/TX Signalen. Bitte Tutorials lesen
3. Eine entsprechende Beschaltung eines LCDs an den LPC findet sich sicherlich bei vergleichbaren Evalboards, suche mal danach.
Daniel schrieb: > Konkret peile ich eine > Ansteuerung im 1:5:5:5-Modus an. Ich muss also, soweit ich das > verstanden habe, die drei LSBs (je eines pro Farbe) zusammenschließen, Nee, mach das mal nicht so. Bei den Bits halte dich besser an das, was Windows CE auch macht: 5-6-5. Also 5 Blau, 6 Grün, 5 Rot. Du nimmst natürlich bei Blau und Rot die jeweiligen MSB's. Die 2 übrig bleibenden LSB's kannst du entweder schlichtweg auf Masse legen oder du schaltest sie parallel zu den MSB's. Dann hast du einen kleinen Sprung mittendrin, aber das fällt normalerweise nicht auf. Und der Pin SD_PWR soll dazu dienen, die Spannungsversorgung der SD-Karte einzuschalten. Er kann und soll die Karte nicht direkt treiben, sondern allenfalls den Enable-Eingang eines Spannungsreglers betätigen. W.S.
Harald schrieb: > Lohnt sich das wirklich für deine Anwendung, eine solche Powercontrol zu > implementieren? Lege die Karte doch an Dauerversorgung, wenn es nicht > auf den letzten mA ankommt. Okay, das ist vielleicht wirklich nicht notwendig, aber der FET tut nicht weh, ich werde ihn implementieren. Man kann ihn ja trotzdem unbestückt lassen und eine Lötbrücke schließen. Harald schrieb: > Natürlich findest Du keine direkten RS485 Signale. RS485 "entsteht" per > Treiberbaustein (z.B. SN75176 als Urgestein) aus den normalen RX/TX > Signalen. Bitte Tutorials lesen Das werde ich tun. Habe zuvor bei Wikipedia und Roboternetz (jaja, schon klar :-) nachgelesen, bin aber irgendwie davon ausgegangen, dass ein so hoch integrierter Baustein wie der LPC1788 diesen Treiber schon eingebaut hat. Harald schrieb: > Beschaltung MCIPWR siehe auch hier > http://www.olimex.com/dev/pdf/ARM/LPC/LPC2378-STK-... Sieht mir nach einem Inverter und P-Channel aus. Werde ich wohl auch so machen. Danke für den Link. Harald schrieb: > Eine entsprechende Beschaltung eines LCDs an den LPC findet sich > sicherlich bei vergleichbaren Evalboards, suche mal danach. Ja, das habe ich versucht. Wollte mir das Board von EA ansehen, da kommt man aber erst an den Schaltplan bzw. an einen Zugangcode, wenn man ein Board kauft. Werde mir morgen mal die Dokus zu den anderen beiden verfügbaren Boards reinziehen. Den SD_PWR haben wir jetzt mal durchgekaut, trotzdem vielen vielen Dank für deine Antwort, W.S.. So, du sprichst aber einen ganz wichtigen Punkt an: W.S. schrieb: > Nee, mach das mal nicht so. > Bei den Bits halte dich besser an das, was Windows CE auch macht: 5-6-5. > Also 5 Blau, 6 Grün, 5 Rot. Du nimmst natürlich bei Blau und Rot die > jeweiligen MSB's. Die 2 übrig bleibenden LSB's kannst du entweder > schlichtweg auf Masse legen oder du schaltest sie parallel zu den MSB's. > Dann hast du einen kleinen Sprung mittendrin, aber das fällt > normalerweise nicht auf. Dieser Modus kam mir etwas seltsam vor, scheint aber ein "Industriestandard" zu sein, da ich das jetzt schon bei mehreren Herstellern entdeckt habe (NXP, ST und wohl MS). Er wird auch vom LPC1788 direkt unterstützt. In der angesprochenen Tabelle, die ich jetzt mal so dilettantisch, wie es mir möglich war, kopiert und angehängt habe. Da lese ich doch, dass ich im 5:6:5-Modus die RGB0-Bits anschließen soll und bei rot und blau die RB5-Bits vernachlässigen darf. Es erscheint mir absolut einleuchtend, dass ich die MSBs verwenden muss, da ein weißes Bild sonst einen Grünstich bekommen würde. Die Tabelle von NXP verstehe ich aber genau anders herum. Oder ist BLUE0/RED0 etwa das MSB? Ich ging immer davon aus, dass BLUE5/RED5 die MSBs sind? Und stimmt diese Bezeichnung auch mit dem Pinout des LCDs überein (siehe Anhang)? Mein Projektleiter wusste auch nicht wirklich weiter und meinte, wir sollten einfach stupide nach den Datenblättern verkabeln. Wenn NXP also "BLUE0" an LCD_VD[19] haben möchte, schließen wir einfach Reichelts "B0" an und sehen, was dabei herauskommt. Oder kann man das vielleicht auch nur durch ausprobieren herausfinden? Danke für eure schon jetzt goldwerte Hilfe.
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.