-- oder nur für mich? Wollte gestern einen Beitrag mit Bild hochladen(künstlerisch bearbeitet entsprechend Ostern mit Randweichzeichner) und wurde nach ca. 20min. gelöscht; Nehme an, einem Moderator hat die "Unschärfe" des Bildes nicht gepasst! Seitdem bin ich offenbar gesperrt -- -- Aus Gründen der Übersichtlichkeit habe ich mir die Freiheit genommen, den Thread dorthin zu verschieben, wo er letztlich hingehört, und den Threadtitel zu ändern. -rufus
:
Verschoben durch User
Als welcher angemeldeter Nutzer hast du dein Bild hochgeladen? Gab es wirklich nichts unanständiges was du zuvor geschrieben hast?
-- ich poste schon ene Weile als "vampire" das Bild ist eher nicht jugendgefährdend und die angehängte Software ist gezipped die Darstellung der Ausgabe einer OV9655 auf einem 5"-TFT unter CoIDE an einem OPEN407I-C Board --
Ist ja ein winziges Bild auf dem Monitor, schafft das Kameramodul nicht mehr? Bald kann man sich die 5M Pixel Kameras für die Raspberry-Pi Boards kaufen, da hast du dann eine bessere Bildqualität und kannst alles in C oder C++ schreiben. vampire schrieb: > -- wer richtet eigentlich die Richter ? Naja, man kann in dem Forum ja nur Beiträge schreiben und Artikel verfassen, daher kann dir ein Mod. nicht wirklich Schaden zufügen wenn er etwas von dir löscht. Auch bei einem Servercrash haftet keiner für deinen Daten-Verlust. Dir entsteht also kein wirklicher Verlust und wenn es dir so wichtig gewesen wäre hättest du dir davon eine Kopie gemacht. Wenn du angemeldet wärst, dann gibt es immer einen Mod deines Vertrauens und den kannst du dann mal anschreiben und da er dich vielleicht sogar kennt (oder sich deine alten Beiträge schauen kann) kann er dich etwas einschätzen und hilft dir vielleicht (wenn er Zeit und Lust hat) bei deinem Anliegen.
-- mich ärgert nicht der verlorene Beitrag, das müssen interessierte Nachnutzer verschmerzen, sondern die Selbstverständlichkeit eine Sperre für weitere UP-loads einzurichten -- p.s.: CoIDE ist ebenfalls C/C++ und die Bildgrösse lässt sich auswählen; (die gleiche Soft beschreibt auch das 7"-Display von Waveshare, da sind die Verhältnisse Pixel zu Bildgrösse etwas angenehmer) --
vampire schrieb: > Nehme an, einem Moderator hat die "Unschärfe" des Bildes nicht gepasst! Der nicht vorhandene Informationsgehalt des Beitrages zum Bild könnte auch ein Grund dafür gewesen sein, warum einer meiner Moderatorenkollegen ihn gelöscht hat.
-- mich ärgert nicht der verlorene Beitrag, das müssen interessierte Nachnutzer verschmerzen, sondern die Selbstverständlichkeit eine Sperre für weitere UP-loads einzurichten -- p.s.: CoIDE ist ebenfalls C/C++ und die Bildgrösse lässt sich auswählen; (die gleiche Soft beschreibt auch das 7"-Display von Waveshare, da sind die Verhältnisse Pixel zu Bildgrösse etwas angenehmer) -- Hans Jelt schrieb: > und hilft dir vielleicht (wenn er Zeit und Lust hat) bei > deinem Anliegen. Achso! Verstehe: Erst kommt Gott, dann der Moderator, der sich mal grad zuständig fühlt, dann eine ganze Weile nichts, dann kommen da noch welche, achja, die Foren-User -- -- seltsam ist das schon --
@ Rufus Τ. Firefly (rufus) (Moderator) -- dann wird es jenem Moderator sicher ein Leichtes sein, die gelöchte Software wieder einzufügen und die User entscheiden zu lassen -- --zum Zeitpunkt des Löschens war die Software bereits 3x und das "verschwommene" Bild > 30x runtergeladen(nach 20 min) -spricht nicht für Desinteresse --
vampire schrieb: > Hans Jelt schrieb: >> und hilft dir vielleicht (wenn er Zeit und Lust hat) bei >> deinem Anliegen. > > Achso! Verstehe: > Erst kommt Gott, dann der Moderator, der sich mal grad zuständig fühlt, > dann eine ganze Weile nichts, dann kommen da noch welche, achja, die > Foren-User -- > -- seltsam ist das schon -- Ja, eigentlich sollte der gemeine User gleich nach Gott kommen. Eine Frechheit, dass man erst warten muss, bis mal ein Mod online kommt. Sollen die doch ihre Arbeitszeit und nicht online verbrachte Freizeit nach den bedürfnissen der User richten.
--das führt zu nichts!! Selbstverständlich achte ich die ehrenamtliche Arbeit der Moderatoren. Ich weise ausdrücklich darauf hin, das es nicht meine Absicht war oder ist, dieses zu verleugnen! Ende meiner Ausführungen --
vampire schrieb: > -- dann wird es jenem Moderator sicher ein Leichtes sein, die gelöchte > Software wieder einzufügen und die User entscheiden zu lassen -- Vermutlich ja. Der fehlende Informationsgehalt Deines Beitrages aber ändert sich dadurch nicht. Was irgendwelche "Uploadsperren" betrifft, so ist mir nichts derartiges bekannt. Dein Beitrag hätte jedenfalls besser in diesen Thread hier gepasst: Beitrag "Re: Camera Modul (OV9655) am STM32F4 Discovery Board" Aber: Da nicht ich derjenige war, der Deinen Beitrag entsorgt hat, sind das nur Vermutungen.
Rufus Τ. Firefly schrieb: > Vermutlich ja. Der fehlende Informationsgehalt Deines Beitrages aber > ändert sich dadurch nicht. Nachtrag: Bevor ich den Beitrag verfasst habe, suchte ich nach Beiträgen über das 5/7" - Displays nicht nur hier im Forum. Und fand nichts -- (korrigiere mich, wenn ich da was übersehe) Daher ist die erfolgreiche Umsetzung der Initialisierung eines solchen Displays in C durchaus als inhaltsreich anzunehmen, was deinem Mod.-kollegen wohl ob des verschwommenen Bildes entgangen ist. Schwamm drüber --
vampire Lass Dich nicht ärgern. Deine Beiträge verfolge ich schon eine Weile und finde sie hochinteressant. Und zwar weil für einen AVR zu ARM-Umsteiger alles nicht so einfach ist. Keiner hat Lust für sein Hobby tausende Euro für eine IDE auszugeben. Deswegen ist jede Info in der Art "das funktioniert mit CoIDE" bestimmt für viele willkommen. Hans Jelt Ja, das Kamerabild ist wirklich winzig auf dem 5 Zöller. Ich wäre froh wenn ich überhaupt eins hätte...
Torsten S. schrieb: > das Kamerabild ist wirklich winzig auf dem 5 Zöller. Ich wäre froh > wenn ich überhaupt eins hätte... Ist doch toll jetzt kannst du es anhand des Bildes des TOs nachbauen... ... mal ehrlich, wer außer eventuell drei eingeweihten Personen soll etwas mit den Textfetzen anfangen? Stell doch den Sourcecode + etwas beschreibung und von miraus leicht verschwommenem Bild in die Codesammlung rein, dann haben auch alle was davon. vampire schrieb: > eine Sperre für weitere UP-loads einzurichten So etwas gibt es nicht, oder nur Andreas persönlich kann das einrichten, vermutlich war der Upload aufgrund folgenden Problems gestört: Beitrag "Re: Artikeländerung speichern funktioniert nicht mehr"
Läubi .. schrieb: > Ist doch toll jetzt kannst du es anhand des Bildes des TOs nachbauen... > > ... mal ehrlich, wer außer eventuell drei eingeweihten Personen soll > etwas mit den Textfetzen anfangen? Stell doch den Sourcecode + etwas > beschreibung und von miraus leicht verschwommenem Bild in die > Codesammlung rein, dann haben auch alle was davon. Genau das ist der Punkt - der Sourcecode wurde mit veröffentlicht. Läubi Du hast das Thema verfehlt/verschlafen. Durchgefallen - setzen.
-für die Codesammlung ist es meiner Meinung nach noch zu unausgegoren. Ich hoffte da auf die Mitarbeit des Forums! Ich kriege die Urfassung nichtmehr so hin. Es ist besagte Kamera auf Open407I-C( müsste auch auf anderen Boards machbar sein); CoIDE 1.5.1 und daraus geflasht(mit ST-Link eines F4-Discovery-- die 3 Leitungen)
Torsten S. schrieb: > Genau das ist der Punkt - der Sourcecode wurde mit veröffentlicht. Streich das "mit". Da wurde Sourcecode mit einem eher nichtssagenden Bild veröffentlich, aber praktisch ohne jeden Hinweis darauf, wozu das ganze gut sein soll. Da hätte EINE ZEILE Text mit Inhalt genügt. Das hier
1 | -Open407I-C mit OV9655 auf 5"-Touchdisplay |
2 | CoIDE 1.5.1 Toolchain GNU_Tools_ARM_Embedded\4.6_2012q2\bin |
3 | geflasht mit ST-Link eines F4-Discovery(3 Drähte)aus der IDE heraus; |
ist eindeutig zu knapp.
Rufus Τ. Firefly schrieb: > -Open407I-C mit OV9655 auf 5"-Touchdisplay > CoIDE 1.5.1 Toolchain GNU_Tools_ARM_Embedded\4.6_2012q2\bin > geflasht mit ST-Link eines F4-Discovery(3 Drähte)aus der IDE heraus; Zu knapp? Für wen? oder Was fehlt?
Rufus Τ. Firefly schrieb: > ist eindeutig zu knapp. Ja das stimmt. vampire In der LCD.c kommt mir etwas nicht ganz geheuer vor: #define LCD_REG (*((volatile unsigned short *) 0x6F000000)) /* RS = 0 */ Eigentlich gibt es 4 Regionen die beginnen der Reihe nach ab: 0x60000000 0x64000000 0x68000000 0x6c000000 Die letztere hast Du bestimmt gemeint.
-kann man so und so machen kommt letztendlich darauf an, welche GPIO-Pins Du aktivierst Hier ist noch eine Besonderheit des von mir verwendeten Boards. Da sitz noch ein LVC139 drauf, der die CS-Leitungen(PG12<-> FSMC_NE4) für SRAM und Flash-ROM gesteuert durch PG5 <-> FSMC_A15 und PG13<-> FSMC_A24 aufteilt. Ist 'ne Eigenheit des Boards; Zum Nachbau ist nur FSMC_NE4 fürs LCD wichtig --
- ist Dir übrigens aufgefallen, das der Beitrag schon wieder weg ist?
Achso, das wußte ich nicht. Habe auch ein 5er LCD mit SSD1963. Ein feines Teil. Allerdings schmiert es nach einer Weile bei mir regelmäßig ab. Oft Pixelfehler bis komplett Bild aus. Egal ob FSMC mit den langsamsten Werten oder Höchstgeschwindigkeit. Ursachenforschung läuft.
-dieses LCD erzeugt die Hintergrund-Beleuchtung aus 3,3Volt; das heist, die Versorgung mit 5 Volt(USB?) wird erst runter, dann hoch transformiert. Ich habe eine ext. 5Volt Versorgung (mind. 1A) gewählt.
-hier siehst Du einen fetten Tantal-Elko über GND/3,3V(links) und eine Masseverbindung von der Platinen-Masse zum Displ.-gehäuse(rechts-oben die Kupferfolie)
vampire schrieb: > -dieses LCD erzeugt die Hintergrund-Beleuchtung aus 3,3Volt; > das heist, die Versorgung mit 5 Volt(USB?) wird erst runter, dann hoch > transformiert. > Ich habe eine ext. 5Volt Versorgung (mind. 1A) gewählt. Ja das ist leider ungünstig gelöst. Versorgt wird bei mir das Board[*1] und LCD[*2] nicht via USB sondern auch mit einem externen Netzteil. Das LCD alleine zieht bei mäßiger Beleuchtung ~ 300mA. [*1] EBay Artikelnummer: 180923405960 [*2] EBay Artikelnummer: 221044250453 die alte Version wo der SSD den max. möglichen Abstand zu den Pins hat.
vampire schrieb: > -hier siehst Du einen fetten Tantal-Elko über GND/3,3V(links) und eine > Masseverbindung von der Platinen-Masse zum Displ.-gehäuse(rechts-oben > die Kupferfolie) Das Gehäuse habe ich auch schon ohne Erfolg geerdet. Einen fetten Elko probiere ich.
Hans Jelt schrieb: > Auch bei einem Servercrash haftet keiner für deinen Daten-Verlust. > > Dir entsteht also kein wirklicher Verlust und wenn es dir so wichtig > gewesen wäre hättest du dir davon eine Kopie gemacht. ... schon mal Ähnliches gehört! Allerdings im Zusammenhang mit Banken. Offenbar leiden da einige Manager ebenfalls unter Realitätsverlust, maßloser Selbstüberbewertung und fehlendem Unrecht-Bewußtsein. Mist gebaut? Auf keinen Fall zugeben! Mir kann ja doch keiner, ich stehe über den Dingen. Geld weg? Hättest halt Rücklagen bilden müssen! p.s.: Im vorigen Jahrhundert, in den 30-igern, waren die betroffenen Manager wenigstens so couragiert, sich aus den Fenstern ihrer Bankhochhäuser zu stürzen. Heute halten sie geprellten Kunden das Fenster auf: "Flieg, Du bist eine weiße Taube ..." So, nun kannste bösewicht/vampire wieder den Zugang zum Server sperren. Es muß ja auch Märtyrer geben ...
-- ich weis nicht, ob Du noch da bist, denn der Beitrag wurde ja schonwieder ins Nirwana verschoben, also auf Verdacht: das Verblassen des Display nach kurzer Zeit, sowie Pixelfehler konnte ich nur beseitigen, indem ich alle Pins des SSD1963 und des Flachbandsteckers mit Löthonig nachgelötet habe. Dann mit einem härteren Pinsel und Spiritus alle Flussmittel beseitigt und im Stereomicroskop auf event. Brücken geprüft . Auch die Ladekondensatoren rundrum nachlöten. Erst dann lief das Display zufriedenstellend --
Bin noch da. Das Display wird schlagartig dunkel. Sehr merkwürdig, weil das Backlight via PWM vom GLCD angesteuert wird (eine Brücke zulöten). Als wenn sich der SSD verschluckt. Habe jetzt Widerstände 470R in alle Datenleitungen eingeschliffen, das hab ich beim Expansionsboard zum Discovery gesehen, dort sind es sogar sagenhafte 2k. Nun kann ich sogar das SRAM zur gleichen Zeit ansprechen, das ging vorher nicht. Als nächstes probiere ich mal ein kleines pinkompatibles 3.5'' LCD ob das besser läuft. vampire, hast Du mal nen Link zu Deinem LCD?
die Beschaltung ist wie bei dem 3,2" - nur musst Du dem 3,2-LCD noch +5V auf den nichtgenutzten Pin3 anlegen, da diese für die HBL benötigt werden -- Dazu habe ich 2 2x20pin Postenbuchsen stumpf aufeinander gelötet und dabei die +5V von Pin3 auf Pin2(des 3,2") umgebogen. Dadurch kannst Du sowohl das 5" als auch das3,2"-Display aufstecken --
--hat das 3,2"-Display von sainsmart nicht den SSD1289 Chip?
vampire schrieb: > --hat das 3,2"-Display von sainsmart nicht den SSD1289 Chip? Nein, mein 3.2er ist von egochina[1] und hat nen ssd1289. Bin gerade fleißig am umschreiben. Welche Artikelnummer hat Deins? Ja, auf die 5V fürs BL hab ich schon aufgepasst. [1] ebay artikel 200475566068
-ups, -weis ich nicht mehr. War ja auch nicht erst gestern, sodern im letzten Jahr. Anbei mal ein Bild, wie es auf deinem Display aussehen könnte(ist die ST-GUI LIB) auf F103 -- Mein Selbstbau Baseboard nimmt sowohl HY-STM32F4xx-Core 144(wie deins!), als auch HY-STM32F1xx-Core 144 wie grad auf dem Bild --
http://www.ebay.de/itm/SainSmart-3-2-TFT-LCD-Modul-Touch-Panel-PCB-adapter-SD-Reader-fur-Arduino-2560-/221075052240?pt=Bauteile&hash=item33791996d0 war wohl dieses --
vampire schrieb: > --hat das 3,2"-Display von sainsmart nicht den SSD1289 Chip? Ops. Ich meinte natürlich "Ja". Das kommt davon wenn man mehrere Sachen gleichzeitig macht. Dein 3.2er war billiger ;) sainsmart kannte ich bis heute noch garnicht. Und welches 5er hast Du? Worauf ich hinaus will ist das mein 5er nun in einer neuen Version verfügbar ist mit stark geänderte Layout. Der SSD1963 sitzt nun fast unmittelbar neben dem Pinheader.
-mein "5-er" ist ebenfalls sainsmart. Allerdings nicht mehr auf der Website zu finden. Vielleicht noch in der Bucht -- Und hier die Rückseite(und ein 3,2-LCD als Grössenvergleich --
Wie vielleicht schon zu erkennen, habe ich den Thread verschoben und umbenannt. Zu den Kritikpunkten waren unter anderem, daß nicht-eingeweihte nicht erkennen konnten, worum es sich bei den genannten Komponenten überhaupt handelt. Da hier mittlerweile nicht mehr Verschwörungstheorien über das Sperren von Benutzern ausdiskutiert werden, sondern tatsächlich technische Inhalte, halte ich diesen Thread mittlerweile für erhaltenswert, daher die Verschiebung.
Das gleiche habe ich auch! vampire Vielen Dank erstmal für Deine Hilfsbereitschaft, bin beeindruckt. Ich haue erst mal in die Tasten um zu gucken ob das 3.2er besser geht und berichte dann darüber.
Torsten S. schrieb: > vampire schrieb: >> -- Viel Erfolg ! > > Danke :) Es hat ne Weile gedauert. Der 1289 und der 1963 sind zwar ähnlich aber nicht identisch. Das kleine 3.2er läuft exzellent und mit Höchstgeschwindigkeit am FSMC. Keine Pixelfehler oder Ausfälle. Der einzige Nachteil: es ist so klein. Das macht mich erst recht nachdenklich.
--haste an dem 5" Display schon alles nachgelötet? Ich werde die HBL wohl von den 3,3V für den SSD1963 trennen. Also dem Converter 5Volt anbieten und die Ausgangsspannung reduzieren, -mal sehen; Ich bin dabei, den Touch auszuwerten. Dabei sind Spannungsschwankungen am 7843 das reine Gift für stabile Werte -- kannst ja mal 'nen Blick draufwerfen -- (SD-Teil ist in main.c ausgeklammert, funktioniert aber --)
Guten Abend vampire Nein, habe nichts nachgelötet. Die Platine sieht professionell aus. Wenn ich drauf rumlötete - naja. Erkennen kann ich nichts mit bloßem Auge. Ich glaube das das ein Stromversorgungsproblem ist. Das LCD ist einfach zu hungrig und bringt den 3.3V Regler auf dem HY-Board - obwohl der ~700mA schaffen soll - durch die Peaks des Backlights an seine Grenzen. Den Konverter direkt mit 5V zu speisen ist mir auch schon durch den Kopf gegangen und wahrscheinlich die sinnvollste Lösung um das herauf- und herunter- transformieren zu reduzieren. Dazu müßte man die Platine sezieren. Das hab ich mich noch nicht getraut.
vampire schrieb: > kannst ja mal 'nen Blick draufwerfen -- Das mache ich sehr gerne. Anbei meins für das 3.2er. Ist nur quick & dirty um die Funktion zu testen.
- und hier das Ganze -mit Pinguinen- :) einfach die main.c austauschen --
- na dann, tschüss - bis morgen!
-selbst nochmal geladen und: änder in TouchPanel.c bitte noch void TP_DrawPoint(uint16_t Xpos,uint16_t Ypos) { GLCD_SetPixel(Xpos,Ypos,LCD_COLOR_YELLOW); /* Center point */ GLCD_SetPixel(Xpos+1,Ypos,LCD_COLOR_YELLOW); GLCD_SetPixel(Xpos,Ypos+1,LCD_COLOR_YELLOW); GLCD_SetPixel(Xpos+1,Ypos+1,LCD_COLOR_YELLOW); } die Farbe --
-- so, habe jetzt die HBL(5" Display) auf 5 Volt gelegt.(2 Leiterzüge durchtrennt und 2 Fädeldraht-Brücken) Ergebnis: -nun bleiben die TS-Werte konstant- - konstant falsch; naja, wenigstens was!
Hmm, genau das hatte ich auch vor
- ich will Dir nicht davon abraten, -aber wart' doch erst ab, ob's was bringt! Ich schau mir mal die Spannungen genauer an(Jitter,Peaks) im Mom. glaub ich fast, daß irgentein Register im Value nicht ganz stimmt -- Haste schonmal http://www.mikrocontroller.net/attachment/175334/sd-fat-lcd-touch.7z auf 5" geflasht?
Compiler läuft nicht durch. Das ist ein Nachteil von CoIDE, es kommt mit relativen Pfaden nicht zurecht. Bestimmt verstecken sich die fehlenden Dateien an anderen Plätzen auf Deiner Platte:
1 | GCC HOME: C:\CooCox\GNUARM_4_7\bin |
2 | compile: |
3 | [mkdir] Created dir: D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\sd-fat-f4_LCD+touch\Debug\bin |
4 | [mkdir] Created dir: D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\sd-fat-f4_LCD+touch\Debug\obj |
5 | [cc] 200 |
6 | [cc] 6 total files to be compiled. |
7 | [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F407ZG -DSTM32F4XX -D__FPU_USED -D__ASSEMBLY__ -DUSE_STDPERIPH_DRIVER -ID:\sd-fat-lcd-touch\sd-fat-lcd-touch -ID:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\TouchPanel -ID:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch -ID:\sd-fat-lcd-touch -ID:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\common D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\cmsis_boot\startup\startup_stm32f4xx.c '"D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\lcd .c"' D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\TouchPanel\TouchPanel.c D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\AsciiLib.c D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\stdio\printf.c D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\common\fonts.c |
8 | [cc] In file included from D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\lcd .c:25:0: |
9 | [cc] D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\lcd.h:32:23: fatal error: stm32f4xx.h: No such file or directory |
10 | [cc] compilation terminated. |
11 | [cc] In file included from D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\TouchPanel\TouchPanel.c:16:0: |
12 | [cc] compilation terminated. |
13 | [cc] D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\TouchPanel\TouchPanel.h:19:23: fatal error: stm32f4xx.h: No such file or directory |
14 | [cc] D:\sd-fat-lcd-touch\sd-fat-lcd-touch\sd-fat-f4_LCD+touch\stdio\printf.c:9:19: fatal error: usart.h: No such file or directory |
15 | [cc] compilation terminated. |
Ein Binary zum schnellen ausprobieren ginge auch...
Ich glaube die Ursache für das instabile Verhalten gefunden zu haben: das Flexkabel zum Modul ist gebrochen. Mist.
-wenn das da tatsächlich eingerissen ist, kannst Du es nurnoch mit einem Tropfen 2-komponenten Epoxi sichern. Das wäre wirklich schade -- Ich benutze CoIDE 1.5.1 mit GNU_Tools_ARM_Embedded\4.6_2012q2\bin und habe das 7z-file in einen völlig neuen Ordner entpackt(Eigene Dateien) und geöffnet. Kompiliert durch -- Zum Test das sd-fat-f4_LCD+touch.bin
-Du musst noch die Farbe ändern(s.oben) in TouchPanel.c
-achja, die fehlenden *.h files musst Du deinem System entsprechend in Configuration --> Include Path einfügen;
Das läuft nicht. Weder das .bin von oben noch das .elf was ja schon in Deinem Projekt enthalten war. Unsere Hardware ist einfach zu verschieden. Was ich auch vermisse ist die main.c War nicht so einfach mein board wiederzubeleben. CoLinkEx2 als auch STLink2 warfen "Can not stop MCU" oder so ähnlich. Erst nach einem Reset mit geänderten boot-jumpern war ein "Erase Chip" erfolgreich.
vampire schrieb: > -wenn das da tatsächlich eingerissen ist, kannst Du es nurnoch mit einem > Tropfen 2-komponenten Epoxi sichern. > Das wäre wirklich schade -- Und wie ich mich ärgere. Bin aber selber Schuld: Ich Trottel habe doch zuerst die Stiftleisten von oben statt von unten eingelötet. Bei der anschließenden Korrektur-Operation muß es passiert sein. Das neue ist bestellt.
- schade, das es bei Dir solche Schwierigkeiten macht! Grade die Pinguine sind lustig(nach dem Stress, den wir hatten); "Can not stop MCU" - das hatte ich auch manchmal (nur mit dem HY-F4xx Core 144); Haste die neuere Ausführung des 5" bestellt? Mitlerweile glaube ich den Grund zu kennen, weshalb das alte LCD nichtmehr angeboten wird -- Wenn man bedenkt, das die Datenleitungen erst nach weit hinten zum SSD1963 Chip führen, und von da fast ebensoweit zurück zum Flachbandstecker(ungeschirmt) --
-überschreib mal mit dieser main.c; (hat tatsächlich die alten Pfade übernommen) --
vampire schrieb: > Haste die neuere Ausführung des 5" bestellt? Die alten sind "out of stock" > Mitlerweile glaube ich den Grund zu kennen, weshalb das alte LCD > nichtmehr angeboten wird -- > Wenn man bedenkt, das die Datenleitungen erst nach weit hinten zum > SSD1963 Chip führen, und von da fast ebensoweit zurück zum > Flachbandstecker(ungeschirmt) -- Genau das ist der Punkt. Das funktioniert zwar wenn man die GPIO-Pins einzeln wackeln läßt aber nicht mehr mit FSMC bei 100MHz.
Hat zwar nichts mit dem Touch zu tun aber da gibt es noch mehr Unstimmigkeiten. Es geht um die Initialisierung des SSD1963. Im Beispielcode von waveshare/powermcu, den Du auch verwendest, steht LCD_WriteCom(0xE2); //PLL multiplier, set PLL clock to 120M LCD_WriteRAM(0x23); //N=0x36 for 6.5M, 0x23 for 10M crystal LCD_WriteRAM(0x02); LCD_WriteRAM(0x04); //dummy Lass uns mal nachrechnen: VCO = Input clock x (M + 1) = 10MHz x (0x23 + 1) = 360MHz PLL frequency = VCO / (N + 1) = 360MHz / (0x02 + 1) = 130 MHz Das ist zuviel weil nur max. 110MHz erlaubt sind. Besser 100MHz verwenden wie im DS beschrieben: LCD_WriteCom(0xE2); LCD_WriteRAM(0x1d); LCD_WriteRAM(0x02); LCD_WriteRAM(0x54); //dummy
so, wenn Du dies in CoIDE-->workspace kopierst und (hier) entpackst, müsste es auch bei Dir kompilieren --
vampire schrieb: > im Mom. glaub ich fast, daß irgentein Register im Value nicht ganz > stimmt -- -könnte mit ein Grund sein; hab's grad probiert -- macht nichts aus! Torsten S. schrieb: > LCD_WriteCom(0xE2); > LCD_WriteRAM(0x1d); > LCD_WriteRAM(0x02); > LCD_WriteRAM(0x54); //dummy
-LCD_WriteCom(0x00E2); //PLL multiplier, set PLL clock to 120M LCD_WriteRAM(0x0023); //M=0x36 for 6.5M, 0x23=35 for 10M crystal LCD_WriteRAM(0x0002); //N=2 LCD_WriteRAM(0x0004); die Werte stimmen doch, um auf PLL 120MHz zu kommen; Torsten S. schrieb: > VCO = Input clock x (M + 1) = 10MHz x (0x23 + 1) = 360MHz VCO = 10MHz x ({dezimal] 35 + 1) = 360MHz Torsten S. schrieb: > PLL frequency = VCO / (N + 1) = 360MHz / (0x02 + 1) = 130 MHz PLL = 360MHz / ([dezimal] 2 + 1) = 120 MHz eben (s.o.) //PLL multiplier, set PLL clock to 120M
Stimmt, war ein typo. Sind aber trotzdem noch 10MHz zuviel.
-moin, moin ! haste dein neues 5" schon bestellt? Ich werde in einem Anflug von Grössenwahn ein 7" raussuchen; Mal sehen, wo und welches -- die Touchwerte zoomen in meinem Programm sowohl in x- wie auch in y-Richtung; das lasse ich mal ganz links liegen und strafe es mit Nichtbeachtung! - habe vor, via Joy-Stick(einfacher Schalter von Conr.) und ST-GUI Lib. weiterzumachen --
moin ;) Habe sogar schon ne Versandbestätigung und das am nächsten Tag. Bei irgendeinem 7er habe ich gesehen das dort vernünftigerweise das BL auf einen extra Pin gelegt wurde um es mit 5V zu versorgen. Hmm, wo war das blos... Eigentlich würde mir ein 320x240 reichen wenn es das größer geben würde. Die größten Schriftarten wirken auf dem 5er etwas verloren und sind aus größerer Entfernung schlecht zu erkennen.
-gibts auch ohne Touch(20€ billiger etwa 50€ gesamt); -schon bestellt! Übrigens ist das Pixelverhältnis zur Bildgrösse angenehmer als bei 5" --
Ich hab mir doch tatsächlich die Mühe gemacht und http://www.mikrocontroller.net/attachment/175432/sd-fat-lcd-touch.7z auf einen USB-Stick geladen. Dann auf einem 2. Rechner CoIDE 1.7.1 und 4.7.2013q1 rauf und das Projekt geöffnet; Umständlich, das man Libraries und USER per Hand kopieren muß; Auch das Flashen aus der IDE ist nichtso sein Ding.(manchmal gleich, mitunter überhaupt nicht); Auch das Bearbeiten des Compiler Control String( löschen -Wall) mag das neue CoIDE garnicht und auswählen verschiedener Linkerscripts, -> denkste; Fazit: --entäuschend !!! Aber es compiliert immerhin, so wie ich oben erwähnt hab' (workspace) und läuft --
positiv: das Neue hat scheinbar keine Probleme mit Floating Point --
-- und LTO , falls mir mal der 1MB-Flash knapp wird :)
Nachtrag: Die bestellten LCDs sind aus dem fernen Osten angekommen. Welche Freude ;) Es gibt gute und schlechte Neuigkeiten. Das 5.0 mit der neuen Platinenrevision läuft stabil und mit Höchstgeschwindigkeit am FSMC-Bus. Keine Pixelfehler. Den Elch-Test, ähm EMV-Test (Schreibtischlampe ein/ausschalten) besteht es ebenfalls nicht. Blöd ist, das das Panel ein um 180° gedreht verbautes Panel hat. Nun muß ich meine Platine auf den Kopf stellen. Per Software nützt nichts weil die Farben bei diesen TFTs aus einem andern Blickwinkel umkippen. Viel ärgerlicher ist aber das es keinen Jumper mehr gibt um den beim SSD1963 vorhandenen PWM-Ausgang für das Backlight zu nutzen. Nun muß ich auch noch einen extra Pin vom STM32 opfern. Die Stromaufnahme habe ich nicht gemessen. Das Steckernetzteil erwärmt sich auf jeden Fall deutlich weniger. vampire Bin mir nicht sicher ob das in Deinen Thread passt. Das Open407 habe ich nicht. Dafür aber noch mehr Sachen über die ich gerne berichten würde wenn ich Deine Erlaubnis habe.
- Du brauchst doch keine Erlaubnis von mir! Seh' nur zu, daß Du keinem Mod. "auf den Schlips tritts". Probier mal: LCD_WriteCom(0x0036); //rotation LCD_WriteRAM(0x0000); zu ändern in: LCD_Write_COM(0x36); //rotation” LCD_Write_DATA(0x03); Du kannst auch den Pin für BL mit einem Pullup dauerhaft einschalten; (hab ich auch ...) p.s.: und probier auch mal die kleinen Pinguine --
-- zum Abschluss: 320x240 Pixel von der OV9655 auf dem neuen 7-inch Display! (montiert auf das "Open407I-C", einem Dev.-board für den STM32F407/417) -ist die 5"-Variante leicht angepasst!
Ich hab die CD vom Open407I-C Kit verloren, gibts die irgendwo zum Download? Kann die mir vielleicht jemand kopieren?
- und hier mit Pinguin; CoIDE 1.5.1 lässt sich leicht aufwärts portieren(CoIDE 1.7.1); @Sven S. (cell85) -die Chinesen werden gern bezichtigt, auchmal copyrights umzudeuten. Ich weis allerdings nicht, ob auch in umgekehrte Richtung?
hat sich erledigt, hab von Wvshare einen downloadlink bekommen.
@vampire Interessiere mich auch für den Anschluss eines 5" oder 7" TFT an das OPEN407I-C board. Das angeführte LCD ist aber, soviel ich verstanden habe, nicht direkt steckerkompatibel (34, 40 pins). Wie hast du das gemacht?
@ Fritz (Gast): Es ist Zufall, das ich in diesem Forum überhaupt nochmal reinschaue! Vor Monaten habe ich meine Aktivitäten als "erhardd, vampire, bösewicht usw." eingestellt. Zuviele unbelehrbare "Oberköche", -zuwenig Substanz. Hoffe, die Pic helfen Dir! (wegen dem Erweiterungs- "türmchen" habe ich das 7"-Displ. höhergesetzt ...
Besten Dank einmal, das hilft mir sehr weiter. vampire schrieb: > Vor Monaten habe ich meine Aktivitäten als "erhardd, vampire, bösewicht > usw." eingestellt. > Zuviele unbelehrbare "Oberköche", -zuwenig Substanz. Schade, laß dich nicht unterkriegen, aber solche "Oberköche" gibt es scheinbar in jedem Forum. Deine Posts waren aber doch sehr informativ.
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.