Hallo, mich würde mal interessieren, wie dieses TFT-Modul von Pollin angeschlöossen wird. Aus der Skizze im Datenblatt werde ich nicht schlau. Vielleicht blickt da jemand durch, ob das ein Folienleiter oder sonstwas ist. MfG
Das Teil hat laut Beschreibung bei Pollin einen 40pol. Folienleiter (viel Spaß), die Belegung ist im Datenblatt angegeben. Auflösung 960(W)×RGB×160(H) Pixel 262144 Farben Betriebsspannung 3,3 V- wahlweise rote oder weiße Hintergrundbeleuchtung 40-polige Flexprint-Buchse, FH28-40S-0.5SH(05) sichtbarer Bereich 230,4×38,4 mm Maße (LxBxH): 248×52,83×14 mm Da das Dislay ohne Controller kommt, ist die Ansteuerung nicht ohne.
:
Bearbeitet durch User
ist das wirklich so schwer zu lesen? Steht doch allem drin: Connector used: FH28-40S-0.5SH(05) (Hirose Electric Co., Ltd.)
:
Bearbeitet durch User
Das ist ganz einfach zu lesen, sagt aber nicht viel aus, wenn man das Teil noch nie zu Gesicht bekommen hat oder solche Bezeichnungen nicht alle Tage sieht: FH28-40S-0.5SH(05). Also erfordert es auf jeden Fall das speziell passende Gegenstück dazu. Da ein Flachbandkabel anzulöten dürfte wenig Aussicht auf Erfolg haben. "Da das Dislay ohne Controller kommt, ist die Ansteuerung nicht ohne." Deshalb: Am besten im Pollin-Lager reifen lassen. Danke für die Hinweise. mfG
Roehrenvorheizer schrieb: > Deshalb: Am besten im Pollin-Lager reifen lassen. Hihihihihi... Das Display ist schon ganz putzig wegen seines seltenen Formfaktors. Aber der Anschluß ist eigentlich ganz das Übliche: 40x 0.5mm Pitch. Tja, und zum Ansteuern braucht man eben nen µC der das kann oder einen separaten Grafikcontroller. Also nix für die Atmel 8 Bit AVR-Riege. W.S.
W.S. schrieb: > Tja, und zum Ansteuern braucht man eben nen µC der das kann oder einen > separaten Grafikcontroller. Also nix für die Atmel 8 Bit AVR-Riege. Nein, laut Datenblatt reichen 16 MHz Pixeltakt aus. Das ist zwar an der oberen Grenze was man mit einem ATMega mit 16 MHz machen kann, aber es geht noch. Ich sehe 2 Moglichkeiten: 1. 8-fach Umschalter mit Zähler und CPU-Takt an 2x4 Pins anschließen. Dann gibt man alle 4 Taktzyklen 4 Bits auf die Pins, die im Moment nicht ausgegeben werden. (2 externe ICs, eventuell noch mehr für Farbe) 2. Einfache OUT-Befehle. Sprich man hat eine Reihe von OUT-Befehlen die die Pixel nacheinander ausgeben. So kann man ohne externe Hardware jeden Takt einen anderen Pixel darstellen. Man kann zum Beispiel so die Schriftart speichern, und dann die einzelnen Buchstaben, zum Beispiel durch geschickte Nutzung des RET-Befehls aneinander reihen. (vorher oder währenddessen bearbeitet man einfach den Stack geschickt) Dabei verliert man zwar 4 Taktzyklen pro Zeichen, da man aber 960 Spalten hat hat man bei 80 Zeichen pro Zeile eh 12 Pixel pro Zeile. Natürlich ist das mit einem externen Controller u.U. einfacher, das bedeutet aber nicht, dass das ein kleiner Controller nicht kann.
Ich grabe den Thread mal wieder aus, weil ich mir auch ein paar dieser Displays hingelegt habe. Der Formfaktor gefällt mir. Nein, nicht weil ich 54:9 für das ultimative Breitbildformat halte, sondern weil ich in selbstgebauten Geräten nicht so in die Höhe gehen will. Dann umbaut man in der Regel nur mehr Luft. Und: Ein Display was die Frontplatte zu einem guten Teil ausfüllt ersetzt die sonst so schwierige Beschriftung derselben. Aber kommen wir zum Thema des Threads, der Ansteuerung. So ein TFT will kontinuierlich mit Daten gefüttert werden, wenn es vollfarbige Grafik sein soll brauchen wir hier ca. ein halbes Megabyte, was 60 mal in der Sekunde umgewälzt wird. Das ist mehr als vermutlich jeder Mikrocontroller an Board hat, wir reden also über was mit externem RAM. Ich habe eine ganze Weile gegoogelt umd bin zu folgenden Ergebnissen gekommen, ich sehe 3 prinzipielle Möglichkeiten: 1. LCD-Controller als Chip Es gibt ICs, die mit einem externen Speicher dran solche Displays ansteuern können. Ich fand Epson S1D13504/S1D13506 und Intersil Intersil TW8811/TW8823. Das sind recht alte Chips. Sie bieten Grafikbeschleunigung für Linien und Blit-Operationen, haben ein Host-Interface zu dem selbst mitzubringenden Hauptcontroller. 2. Mikrocontroller mit integriertem LCD-Interface Es gibt eine ganze Reihe Microcontroller der 32Bit-Liga (meist ARM), die externen Speicher verwalten können und ein LCD-Interface mitbringen. Da wären die üblichen verdächtigen Firmen und Produktreihen, NXP LPC, Renesas, TI TMS320, Atmel AT91SAM, STMicroelectronics STM32. Ein gewisses Problem für uns Hobbyisten ist, das diese Controller zunehmend in BGA-Gehäusen daherkommen. Die Controller gehen in Richtung SoC, Überleitung zur 3. Möglichkeit. 3. Linux-Board mit parallelem LCD-Interface Das Raspberry Pi eignet sich nun gerade nicht, aber es gibt andere. HDMI und LVDS sind die gängigsten Videointerfaces, wir brauchen RGB parallel. Das habe ich auf folgenden gängigen, preisgünstigen Boards gefunden: Banana Pi, Cubieboard 1 oder 2, Beaglebone Black. Es gibt noch exotischere, A20 Hummingbird, armStone A5, MarS Board. Auch interessant sind solche Boards in Form eines DIMM-Riegels, den man auf eigene Platinen integrieren kann. Aufgefallen sind mir die von Toradex, im Moment günstig ist das Colibri VF50 CoM. Interessant wäre, wenn "bare metal" Programmierung für so ein Board etabliert wäre, wie beim RasPi. Es muß ja nicht immer Linux sein, ich mag es gar nicht wenn ein Gerät nach den Einschalten erst bootet. Andererseits bieten die besseren SOCs auch OpenGL Grafikunterstützung, mit UI-Möglichkeiten von denen der gemeine Controllerprogrammierer nur träumen kann. Alles völlig ohne Anspruch auf Vollständigkeit, bitte gern weitere Chips und Boards ergänzen! Fazit: So ein Display sollte sich nach elektrischer Adaptierung "leicht" betreiben lassen (eine kleine Platine mit FFC Verbinder), ich würde es wohl zuerst mit einem Beaglebone oder Banana Pi versuchen. Jörg
So, dann grabe ich den Thread auch nochmal aus, ich hatte mir das Display auch wegen seines Formfaktors mitbestellt, bin dann lange nicht dazu gekommen, die nötigen Teile zu besorgen, um das Ding anzuschließen. Jetzt ist alles da und ich habe mal ein Proof of Concept zusammengesteckt: Auf dem Breadboard sind nur passive Breakouts für die 40- und 10-poligen 0.5 mm FFC-Stecker: FH28-40S-0.5SH(05) für den Datenport wie im DB und FH28-10S-0.5SH(05) aus der gleichen Serie fürs Backlight. Drumherum Unspektakuläres: 3.3 V-Versorgung, Pull-Ups für die im DB nicht näher beschriebenen vier Seriellen Pins (ist da ein EEPROM mit S/N on Board oder so?) und ein Pull-Up für den Reset. Rechts unter dem Display der 10-Polige Stecker mit ein paar Vorwiderständen fürs Backlight (3 x 47 Ohm für weiß, 1 x 300 Ohm für rot, damit beides leicht unterhalb der DC Charecteristics bei 19 V-Versorgung). Im Foto ist natürlich nur das weiße Backlight an. Mit dem roten kommt wirklich nur noch rot durch, für meinen geplanten Einsatzzweck - Statusdiplay am sonst "blinden" Server sicherlich nett zum Erregen von Aufmerksamkeit. Das zu sehende Testbild generiert ein MACHXO2 7000HE, ohne zusätzlichen Speicher wird das produktiv sicher nichts reißen, reicht aber mehr als allemal für das Testbild. Das Q&D Design anbei. Ein Beaglebone Black wäre natürlich eine Möglichkeit, ich wollte aber in diesem speziellen Fall eher kein komplettes Linux-Board nehmen, nur um dem Linux-Server ein Display zu geben. Die beiden Epson-Chips unterstützen, wenn ich das richtig sehe, kein 24 Bit RGB und die Intersils gehen mir zu sehr in Richtung TV, grundsätzlich wäre ein fertiger Controller natürlich eine gute Sache, hatte auch schonmal (kurz) gesucht, sind aber alle aufgrund der Farbtiefe oder der ungewöhnlichen Auflösung ausgeschieden. Bin mir noch nicht sicher, ob ich einen einfachen 2D-Controller baue, einen etwas ausgewachseneren GUI-Controller oder das Rendering komplett auf den Host auslagere und einen ganz simplen Controller dort als Framebuffer einbinde. Wird so oder so sicherlich noch eine ganze Weile dauern, aber zumindest habe ich das Display jetzt mal in Betrieb gesehen.
Pollin bietet auch ein vielleicht verwendbares Windows CE-Modul an für ~10 Euro, das auch parallele 12- und 18-Bit TFT-Interfaces bis zu 640x480 ("mit Einschränkungen") unterstützt, über ausreichend Ressourcen verfügt (je 32MB SRAM und Flash) und vom Hersteller dereinst wahlweise auch mit Linux angeboten wurde, das PicoMOD1: http://www.pollin.de/shop/dt/MTg1NzkyOTk-/Bausaetze_Module/Entwicklerboards/Einplatinencomputer_PicoMOD1_Windows_CE_5_0.html Es bliebe abzuklären, inwiefern vom Hersteller noch ein Rest-Support geleistet wird, ob die Entwicklungswerkzeuge noch verfügbar sind und ob sich Videogeometrie und Timings im erforderlichen Rahmen anpassbar sind.
Interessant, allerdings doch ein 10 Jahre altes Design, davon die WinCE-Version (Linux drauf flashen möglich? unbekannt). Aber vor allem "Lieferumfang: nur das Modul ohne Basisboard". Da lohnt sich ein aktuelles ARM-Board doch weit mehr denk ich.
Also ich suche noch ein Display für meinen Multimedia-Server, rein als Status-Display... Da wäre das schon cool. Aber die Größe wäre auch interessant für meinen WiFi Radio-Wecker, Nachts dann mit großer Zeitanzeige und extrem herunter gedimmtem roten Display... Da brauchts dann keine Brille zum ablesen.... Aber ich kann durchaus verstehen, dass man keinen Linux Controller nutzen will nur um von einem Linux Board ein paar Sachen anzuzeigen... Daher ein Kompromiss aus Embedded und ARM :) Das LCD hat 960*160 Pixel. Benutzt man eine Color-Palette und beschränkt sich auf 256 gleichzeitig darstellbare Farben, dann reichen 153600 Bytes aus, also 150kB. Ein STM32F4 Discovery hat 192kB und genug Rechenleistung das LCD anzusteuern. Setzt man die eigentliche Oberfläche des Displays aus wenigen Farben für Linien und Text zusammen, dann reichen die verbliebenen sicherlich noch aus, ein GIF von einem Albumcover darzustellen. Ich meine, dass es in Linux auch fertige Libs gibt, die Bilder in dieses Paletten basierte BMP übersetzen können. Ich habe zwar zig dieser Discoveries aber keines der LCDs... Da muss ich mal sehen, was ich noch von Pollin brauche um eine Bestellung lohnenswert zu machen. Gruß Ulrich
Leute, ihr seht den Wald vor Bäumen nicht. Das Display ist richtig saugut, hab's schon ausprobiert. Natürlich NICHT mit solchen Vorschlägen, wie sie hier gekommen sind, sondern eben ordentlich mit 65K Farben. Ich benutze einen LPC4088 mit externen 16 MB SDRAM (4M x 32). Das Einzige, was vergleichsweise heftig kommt, ist der Stromverbrauch. Das Display selbst will (wenn ich mich recht erinnere) einige 100 mA haben und die Beleuchtung will um einiges mehr, ich glaube 2x 100 mA bei 19 Volt. Für Batteriebetrieb also weniger gut, aber für Netzbetrieb kein Thema. W.S.
Doch doch das sehe ich :) wollte es ja nur einmal in Aktion sehen vor weiteren Überlegungen. Ist halt billig Non-RoHS NOS. Die RoHS-Variante ist um einiges teurer.
Habe mir gerade mal das Datenblatt angesehen von dem LCD... Also der Server hier nimmt im Standby die meiste Zeit <3W auf und der geplante Radiowecker sollte noch mal darunter bleiben. das LCD selbst benötigt bei 3V3 / 400mA fürs Panel. Das sind 1.32W. Die weißen LEDs sind 3 Ketten a 6 LEDs mit 18.5V*100mA, also 1.85W Das wären dann >3W Aufschlag auf die Stromaufnahme des Gerätes... Den CortexM4 noch nicht mit eingerechnet. Dazu kommt, dass zumindest meine Anwendungen mit 5V bzw. nur mit 3.3V betrieben werden, die 18.5V für die LED muss also extra über einen Boost-Wandler erzeugt werden. Das kann man zwar mit dem CortexM4 gleich mit erledigen... Oder ich steige auf 19V Notebook Netzteil um, dann muss ich aber die anderen Spannungen aus Buck Wandlern erzeugen... Bei einem Gerät, das 24/7 betrieben wird, muss man sich das überlegen, ob man das braucht.
Ulrich P. schrieb: > Die weißen LEDs sind 3 Ketten a 6 LEDs mit 18.5V*100mA, also 1.85W Du solltest allerdings überlegen, ob bei einem Wecker die ganze Zeit so ein "Flakscheinwerfer" erforderlich ist. Ein Dimmen der Helligkeit, angepasst an die Umgebungshelligkeit, könnte hier schon sehr viel Reduktion bringen. Ja, die Helligkeit solltest Du über die Hintergrundbeleuchtung und nicht über die auf dem Display dargestellten Inhalte anpassen.
Hi Rufus, das ist logisch. Natürlich relativiert sich die Stromaufnahme, aber ich kann das WiFi Radio mit 2..3W Standby und 4..5W Zimmerlautstärke betreiben. Wenn da das Display mit >1W zuschlägt, dann sind das 30% Aufschlag, die Hintergrundbeleuchtung ist dabei noch aus. Es wäre mir auch nie eingefallen, die Helligkeit über das LCD selber zu steuern :)
Bei der letzten Tour durch die Pollin Reste-Rampe habe ich mal zwei von den Dingern mitbestellt. Ich war positiv überrascht, Verarbeitung und Abschirmung sind sehr gut und das Display an sich sehr kontrastreich und blickwinkelstabil. Die sehr helle Beleuchtung kann man auf erträglichen Stromverbrauch runterdimmen. Jetzt brauche ich nur noch einen Einsatzzweck ;) Getestet habe ich mit einem ausgemusterten STM32F7-Discovery, dessen Display gebrochen war. Die Kontaktierung erfolgte etwas abenteuerlich, da ich nachts um 12 partout kein Flatflex-Kabel gefunden habe. 3.3V und 20V für die Beleuchtung werden per Step-Up/Step-Down generiert.
:
Bearbeitet durch User
Um mal zu zeigen wie hell die Hintergrundbeleuchtung ist, hier ein Vergleich mit einem (voll aufgedrehten) PC-Bildschirm. Zusammen mit der Blickwinkelstabilität wäre das schon was für den KFZ-Bereich. Für ~5€ jedenfalls ein absolutes Schnäppchen.
Rufus Τ. F. schrieb: > "Flakscheinwerfer" Wer mal genau hinschaut, wird feststellen, daß es zwei Hintergrund-Beleuchtungen gibt: die normale hier schon diskutierte UND eine zweite, bestehend aus roten LED's, die lediglich ca. 10..12 V braucht bei maximal 35 mA. Da ist man im Standby mit 100..300 mW dabei. W.S.
Hat sich eigentlich noch eine Alternative aufgetan um das LCD anzusteuern? Ich fände es schon sehr interessant, aber einem STM32F7 Kit das Touch abzureißen ist ebenso doof, wie einen STM32F4 rein als VGA-Karte zu betreiben...
Ja was denn für eine Alternative? Das Display braucht seinen Refresh wie alle Displays in dieser größenordnung und wer es benutzen will, nimmt einen µC, der ein dafür passendes Interface hat. Da wird man inzwischen bei ST fündig, ST ist ja hier geradezu Hype. Oder man legt sich nen passenden Typ von NXP zu, z.B. LPC4088, den es m.W. auch bei TME zu kaufen gibt. Dann noch ein externes RAM passender Größe dazu, Leiterplatte gemacht und ferrrrrticht. Von nix kommt nix und wer eine Anwendung basteln will, die so ein Display sinnvoll einsetzt, sollte auch adäquates Können besitzen. W.S.
Ulrich P. schrieb: > Hat sich eigentlich noch eine Alternative aufgetan um das LCD > anzusteuern? Ich fände es schon sehr interessant, aber einem STM32F7 Kit > das Touch abzureißen ist ebenso doof, wie einen STM32F4 rein als > VGA-Karte zu betreiben... Wenn dir der STM32 missfällt: auch andere Hersteller haben passendes im Angebot (NXP wurde ja schon genannt, TI hat z.B. den TM4C). Die Discovery-Reihe ist ja nur eine Sammlung von Evaluations-Boards, die MCU kannst du auch ohne das Board nutzen. Der STM32F429 z.b. kann Panels bis zu einer Größe von 1024x768 bedienen, reicht also für dieses Display aus. Da baust du dann noch ein bisschen SDRAM auf die Platine, 2-3 Schaltregler (je nachdem ob du die rote Beleuchtung brauchst) und fertig ist die Ansteuerung. Der LTDC braucht nur die Startadresse deines Framebuffers und benötigt keine weitere Rechenzeit. Die wird nämlich sowieso benötigt, um das Display sinnvoll mit Inhalt zu befüllen. Natürlich ist das ganze dann etwas teurer als die Brot und Butter AVR-Schaltungen auf dem Steckbrett, aber Pollin verschleudert das Display nicht umsonst für 5€ - von der Qualität her ist es tausend mal besser als der SSD1963/ILI9341-Kram, der bei Aliexpress verschleudert wird. Man muss aber eben etwas Zeit, Geld und Gehirnschmalz für das drumherum investieren. Edit: Damit das hier nicht nur Gemecker ist, im Anhang noch ein Bild von einer halbfertigen Wetter-Uhr, die beim rumspielen entstanden ist. Die Wetterdaten kommen von OpenWeatherMap, im Moment wird aber nur die aktuelle Temperatur ausgewertet.
:
Bearbeitet durch User
Super! Kann jemand ein kleines Demo (C Code) dafür veröffentlichen. So als Wegweiser. Danke!
Mit Demo (C Code) meinst du die Ansteuerung des Displays? Das lässt du dir nämlich am besten über CubeMX generieren, wenn es schnell gehen soll. Die entsprechend benötigten Werte für das Display findest du aber in dieser Passage:
1 | hltdc.Instance = LTDC; |
2 | hltdc.Init.HSPolarity = LTDC_HSPOLARITY_AH; |
3 | hltdc.Init.VSPolarity = LTDC_VSPOLARITY_AH; |
4 | hltdc.Init.DEPolarity = LTDC_DEPOLARITY_AL; |
5 | hltdc.Init.PCPolarity = LTDC_PCPOLARITY_IPC; |
6 | hltdc.Init.HorizontalSync = 125; |
7 | hltdc.Init.VerticalSync = 29; |
8 | hltdc.Init.AccumulatedHBP = 157; |
9 | hltdc.Init.AccumulatedVBP = 39; |
10 | hltdc.Init.AccumulatedActiveW = 1117; |
11 | hltdc.Init.AccumulatedActiveH = 199; |
12 | hltdc.Init.TotalWidth = 1149; |
13 | hltdc.Init.TotalHeigh = 210; |
14 | hltdc.Init.Backcolor.Blue = 0; |
15 | hltdc.Init.Backcolor.Green = 0; |
16 | hltdc.Init.Backcolor.Red = 0; |
17 | HAL_LTDC_Init(&hltdc); |
18 | |
19 | layer.WindowX0 = 0; |
20 | layer.WindowX1 = 960; |
21 | layer.WindowY0 = 0; |
22 | layer.WindowY1 = 160; |
23 | layer.PixelFormat = LTDC_PIXEL_FORMAT_ARGB8888; |
24 | layer.Alpha = 255; |
25 | layer.Alpha0 = 0; |
26 | layer.BlendingFactor1 = LTDC_BLENDING_FACTOR1_PAxCA; |
27 | layer.BlendingFactor2 = LTDC_BLENDING_FACTOR2_PAxCA; |
28 | layer.FBStartAdress = TFT_FRAMEBUFFER_2_ADDRESS; |
29 | layer.ImageWidth = 960; |
30 | layer.ImageHeight = 160; |
31 | layer.Backcolor.Blue = 0; |
32 | layer.Backcolor.Green = 0; |
33 | layer.Backcolor.Red = 0; |
34 | HAL_LTDC_ConfigLayer(&hltdc, &layer, 0); |
35 | |
36 | __HAL_LTDC_ENABLE(&hltdc); |
TFT_FRAMEBUFFER_2_ADDRESS befindet sich sinnvollerweise im Adressraum des externen Speichers. Wichtig: Das Display hat ein RGB666-Interface, du musst also vorher sehr wahrscheinlich noch umrechnen. Im Anhang noch ein Bild mit vollständigen Wetterdaten. Der Code dafür ist noch WIP und ziemlich chaotisch, eine Veröffentlichung erfolgt also ggfs. zu einem späteren Zeitpunkt. Gerade erstelle ich Stück für Stück ein Referenz-PCB, damit ich von den anfälligen Fädeldrähten wegkomme.
Das war ein Missverständnis... Mir ist der STM32 sowas von recht! Ursprünglich waren aber mal CPLDs, FPGAs und LCD-Treiber im Gespräch. Ich habe noch ein selbst geätztes Board mit einem Epson LCD Controller für ein Grayscale LCD herum liegen. Es stand quasi zur Auswahl: a) LCD + Controller an irgendeinen Controller b) LCD an einen Controller mit LCD Unterstützung Aber die STM32 verleiten zum Klotzen daher werde ich dann man das STM32F4-BB dran klemmen. Ich habe noch etliche SRAMs herum liegen, mal sehen, was da noch verwendbar ist. Mir schwebt da was als Messgeräte-Display vor und da wäre 666 deutlich oversized. Bei 8-Bit 323 käme man beim STM32F4DISCOVERY auch ohne externes RAM hin... Mal sehen was da geht. Werde erst mal ein paar dieser LCDs bestellen.
Hallo Leute, dies ist mein erstes Beitrag hier und ich bin leider kein Elektroniker, habe aber mir schon fast alles zum Löten besorgt. Ich habe ein Paar Stück davon bestellt und warte auf diese und habe mehrere Fragen bezüglich des Geräts jetzt schon. Ulrich P. schrieb: > Die weißen LEDs sind 3 Ketten a 6 LEDs mit 18.5V*100mA, also 1.85W Hat jemand herausgefunden wie die weiße LEDs angeordnet sind? Kann man evtl. nur eine einzelne Kette betreiben für die gesamte Fläche des Bildschirms? Oder beleuchten die einzelnen Ketten nur ein Teil des Bildschirms? Die FFCs, Adapter-PCBs und die 40Pin@0.5mm Buchsen habe ich schon bestellt. Aber wie ich LEDs anschließe weiß ich noch nicht. Ich behaupte nur dass es 10Pin@0.5mm Buchsen sind: Kann es jemand genauer sagen? So könnte ich nämlich die Bestellung abschließen und alles auf einmal kriegen! Gibt es die LED-Backlight Chips mit I2C(oder was auch immer), die gleichzeitig sowohl weiße als auch die rote LEDs ansteuern können. Oder muss man zwei separate Chips dafür nutzen und somit zwei I2Cs bzw. einen I2C-Multiplexer? Und was heißt ganz genau "LED Channels" bei Backlight-LED-Driver? Könnte jemand einen Layout mit folgenden Eigenschaften erstellen: - Hindergrundbeleuchtung-Steurung(I2C oder was auch immer) für rote und weiße LEDs inkl. FFC-Connector - 5V Eingang für Hindergrundbeleuchtung-Steurung - 3V3 Eingang für LCD - FH28-40S-0.5SH(05) FFC-Connector zum direkten Anschluss des LQ092B5DW01 - 2.54mm Pitch 40 Pin in zwei Reihen als Adapter ausgang - 2.54mm Pitch X Pin in zwei Reihen für I2C 3V3 und 5V - evtl. 2.54mm Pitch X Pin, falls Hindergrundbeleuchtung-Steurung die Hardware-Tasten unterstützt - evtl. 2.54mm Pitch X Pin, falls die Hindergrundbeleuchtung-Steurung geflasht werden muss PS: Ich würde mindestens fünf solche PCBs kaufen.
:
Bearbeitet durch User
Rafael K. schrieb: > Könnte jemand einen Layout.. Na du hast schon seltsame Ideen. Also: dieser kleine 10 polige Folienstecker ist gut für die weiße Normalbeleuchtung, die rote Sparbeleuchtung und einen Temperatursensor. Die zu applizierenden Spannungen für die Beleuchtungen sind sehr unterschiedlich. Für die weiße ist auf alle Fälle ein Aufwärts-Schaltregler nötig, sofern man keine 24 Volt zur Hand hat. Und ja, bei der weißen Beleuchtung solltest du alle 3 Stränge benutzen. Aber wie kommst du bei der Beleuchtung auf I2C ? Den Schaltregler für die Beleuchtung mußt du dir schon selbst designen, denn das hängt von deinen Randbedingungen ab. Nun und das Board mit nem geeigneten µC für dieses Display wirst du wohl auch selber designen müssen. Ich hab zwar sowas da - als nackte LP - aber erstens noch nicht ausprobiert und zweitens auch nur für meine Zwecke gestaltet und drittens nur für ne Vollversion von Eagle, da für die Freewareversion zu groß. Ich könnte das hier mal posten, aber ich habe schwere Zweifel, daß dies was nützt, weil hier eigentlich alle auf AVR oder STM32 abfahren und vom Rest der Welt nichts wissen wollen. W.S.
Ulrich P. schrieb: > Aber die STM32 verleiten zum Klotzen daher werde ich dann man das > STM32F4-BB dran klemmen. Ich habe noch etliche SRAMs herum liegen, mal > sehen, was da noch verwendbar ist. Mir schwebt da was als > Messgeräte-Display vor und da wäre 666 deutlich oversized. Bei 8-Bit 323 > käme man beim STM32F4DISCOVERY auch ohne externes RAM hin... Mal sehen > was da geht. Werde erst mal ein paar dieser LCDs bestellen. Wenn man bereit ist, mit mit einem für eine konkrete Anwendung ausreichenden Displayfähigkeiten auszukommen, ist auch der AVR u.U. natürlich noch im Rennen. Ich benutze das Display z.B. an einem Mega1284P. Es kann dann: 480x160 Pixel ("monochrom"), wobei monochrom hier nicht wörtlich zu verstehen ist. Tatsächlich sind es einfach nur zwei Farben, zwischen denen mit der genannten Auflösung gewechselt werden kann. Es ist allerdings externe Hardware nötig, mindestens ein ClockDoubler (XOR-Gatter-IC reicht). Das genügt dann für SW-Betrieb. Nimmt man noch ein paar billige Muxer mit Latch hinzu, kommt auch schon ordentlich Farbe in die Sache. Die beiden darstellbaren Farben sind dann nämlich softwaremäßig generierbarer. Eine, üblicherweise die Hintergrundfarbe, ist RGB565, die andere ist RGB232. Und sie sind über das dargestellte Frame auch änderbar. Derzeit kann ich nur zwei "Grafikmodi", bei dem einen sind beide alternativen Farben mit einer Auflösung von 60x20 im Framebuffer, bei dem anderen trifft das nur für die Vordergrundfarbe zu, während die Hintergrundfarbe mit 1x160 aufgelöst wird. (für schicke vertikale Farbverläufe des Hintergrunds). Ich arbeite derzeit daran, noch an ein paar weiteren Varianten im Rahmen der Möglichkeiten eines AVR zu realisieren. Macht richtig Spaß, ist fast wieder wie damals in den frühen 80ern, wo man aus der ähnlich begrenzen HC-Hardware diese schicken Effekte rausgelockt hat. Mit genug Power kann's ja auch jeder Blöde. Wo bleibt denn da noch der Spaß? Allerdings: Wenn man die Sache animieren will, kann es sehr schnell passieren, daß eine "Krüppellösung" wie meine das problemlos und schnell umsetzen kann, während sich die Voll-Lösung leicht mit der Bandbreite verhaspelt. Das hängt dann aber natürlich stark von der Art der gewünschten Animation ab. Z.B. ein vertikales Scrolling eines Farbverlaufs dürfte ich recht leicht sehr gefällig umsetzen können. Ob das eine Lösung mit vollständigem 18Bit-Framebuffer auch kann, oder ob man da eher die sattsam bekannten Tearing-Effekte zu sehen bekommt...
W.S. schrieb: > Aber wie kommst du bei der Beleuchtung auf I2C ? Na, wird es denn irgendwie anders gemacht heutzutage? Habe nach Chips gesucht und auf folgende Dinger gestoßen: - LP8553 :: 4-Ch. Ausgang: 50mA@0V-40V/Ch. http://www.ti.com/lit/ds/symlink/lp8553.pdf - TPS61187 :: 6-Ch. Ausgang: 30mA@V_in-38V/Ch. http://www.ti.com/lit/ds/symlink/tps61187.pdf Diese sind zu schwach für Weiße LEDs aber dennoch. Ich habe noch nicht herausgefunden ob die Chips die einzelne Kanäle ein- und ausschalten können: wäre schön wenn's so wäre. W.S. schrieb: > Also: dieser kleine 10 polige Folienstecker ist gut für die weiße > Normalbeleuchtung, die rote Sparbeleuchtung und einen Temperatursensor. Das weiß ich, steht auch im Dokument des LQ092B5DW01, dort steht aber kein Typ der benötigten Buchse. Ich möchte die Buchse bestellen, kenne aber keine Parameter des Foliensteckers :/ ! Wäre cool, wenn jemand es hier nennen kann, ansonsten muss ich warten bis die Dinger bei mir sind.
Habe analog zu Hirose FH28-40S-0.5SH(05) für den 40-Pol Hirose FH28-10S-0.5SH(05) für den 10-Pol genommen. Passt.
Hallo Leute, könnt Ihr bitte hier die von euch verwendete Chips für die LED-Beleuchtung auflisten. Evtl. mit der Zeichnungen und wichtigen Daten, Preisen & co. Ich habe ein Paar gefunden: Atmel MSL2023/MSL2024 "für weiß und rot" + für zwei LED-Farben bzw. unterschiedliche Spannungen der LED-Ketten + zwei PWM Eingänge + externe MOSFETS für die LED-Ketten + Preis: Mouser 3€/Stück@6000er-Menge | Voelkner 7€/Stück Texas Instruments LP8860-Q1 + vier Kanäle mit unabhängigen Strom-Konfiguration(bis 150mA/Ch) je Kanal + Helligkeit mit PWM, SPI bzw. I2C + Preis: Mouser 4€/Stück ? ob einzelnen Kanälen eigene Spannungen zugewiesen werden können ist unklar - (Edit)ist es ein Problem, dass minimale Ausgangs-Spannung 16V ist? Texas Instruments LP8861-Q1 ist die abgespeckte version von LP8860-Q1 und ist entweder nur für rot oder nur für weiß geeignet, da die Kanäle nicht einzeln konfiguriert werden können. Ich habe zur Zeit keine Ahnung wie man die Dinger richtig verwendet und welche Komponenten zusätzlich benötigt werden und wie man von weiß auf rot und umgekehrt und ob überhaupt umschlten kann oder wie man einen Initialzustand (z.B. weiße LEDs @ 50%-70%) in EEPROM schreiben kann. Falls es jemand weiß, wäre cool wenn es hier erklärt wird. Die fertigen(unter 15€) Boards für die Beleuchtung, die zumindest weiße LEDs ansteuern können, sind natürlich auch sehr nützlich! vielen Dank im Voraus RK
:
Bearbeitet durch User
Rafael K. schrieb: > könnt Ihr bitte hier die von euch verwendete Chips für die > LED-Beleuchtung auflisten. Evtl. mit der Zeichnungen und wichtigen > Daten, Preisen & co. Findest du das nicht ein wenig übertrieben? Die normale Beleuchtung braucht so etwa 18..20 Volt und für die rote braucht es so um die 10..12 Volt. Also nimm einen Boost-Regler deiner Wahl oder speise das Ganze aus einer dir genehmen Quelle, das ist doch kein Hexenwerk. Plane einfach, was du mit dem Display eigentlich machen willst, was Netzbetriebenes oder für's Auto oder was es denn sonst so geben mag. W.S.
W.S. schrieb: > Also nimm einen Boost-Regler deiner Wahl oder speise das Ganze aus einer > dir genehmen Quelle, das ist doch kein Hexenwerk. Plane einfach, was du > mit dem Display eigentlich machen willst, was Netzbetriebenes oder für's > Auto oder was es denn sonst so geben mag. Danke W.S. ich kannte die Dinger vorher nicht. Texas Instruments TPS61169 scheint dafür passend zu sein, wenn die drei weiße Ketten parallel geschaltet werden. Hier die Links: http://www.ti.com/product/tps61169 http://www.ti.com/lit/ds/symlink/tps61169.pdf W.S. schrieb: > das ist doch kein Hexenwerk. für mich schon, denn ich bin doch noch ein blutiger Anfänger! Ich will es am Panana Pi betreiben, dies wird wohl über 5V IPS_OUT leitung sein, was auch über 40Pin FFC-Kabel von der CON2 mitgeliefert wird. Habe eben versucht noch die für den Betrieb von TPS61169 benötigten komponenten zu berechnen und zu finden: Festinduktor: 4,7uH | 10uH z.B. SRU5018-100Y Widerstand zum setzen der maximalen Stroms(hier irgendwie bin ich auch nicht sicher, ob es richtig ist. Ist denn V_FB 18,5V?): 18,5V / 0,3A = 61Ω Eingangskondensator: keine Ahnung, da im Dokument keine Auswahlhilfe gegeben ist. Ausgangskondensator: keine Ahnung wie es man berechnet, da ich F_S und V_ripple nicht kenne. Kurz gesagt: habe ich gaar keine Ahnung welche Teile ich für die Beleuchtung nehmen soll um endlich mal eine PCB zu ätzen. Also bei den Chips in meinem vorherigen Beitrag meine ich alle mögliche Dinger, die für die regelbare Beleuchtung dieses Bildschirms geeignet sind. ------------------------------ Was Banana Pi angeht: ist im Anhang beigefügte Schaltung richtig? Also ich bin nicht sicher ob die Verbindungen "DataEnable <-> DE" und "DCLK <-> PCLK" richtig sind. Außerdem müssen die Änderungen in der Hardwarekonfigurationsdatei von Allwinner A20(die sogennante FEX Konfigurationsdatei, mehr gibt es dazu unter http://linux-sunxi.org/Fex_Guide#FEX_Description) vorgenommen werden. Die meisten Änderungen müssen in dem markierten Bereich https://github.com/LeMaker/fex_configuration/blob/master/fex/banana_pi_5lcd.fex#L447-L513 erfolgen. Ich denke, dass folgende Sachen gesetzt werden müssen:
1 | screen0_output_type = 1 |
2 | lcd_frm = 1 |
3 | fb0_format = 9 |
4 | lcd_x = 960 |
5 | lcd_y = 160 |
6 | lcd_dclk_freq = 18 |
7 | lcd_if = 0 |
8 | lcd_hv_if = 0 |
9 | lcd_hbp = 157 |
10 | lcd_vbp = 39 |
11 | lcd_vt = 1050 |
Außerdem sind die Einstellungen für die Ports PD00 bis PD27 wichtig und ich weiß nicht was man da setzen muss. In der Datei von dem oberen Github-Link sind alle einstellungen auf port:PDXX<2 ><0 ><3 ><default> was folgendes bedeutet port:PDXX<RGB-Interface?><PullUp aus><40mA><default> Hat jemand geschafft es auf einem Allwinner A20 Gerät zum Laufen zu bekommen?
Also bei mir klappt es nicht mit Banana Pi/Pro. Kann es sein, dass Bananas zu wenig 3v3 Strom liefern? Siehe 3v3 Netzteil des Bananas im Anhang. Wenn ich richtig verstanden habe kann SY8008B bis zu 1A liefern. Kann man anhand der Schema ganz genau sagen wiviel Strom das Ding produziert? Oder sind die von mir gesetzte Einstellungen einfach nur falsch?
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.