Open407I-C (Board für STM32) mit OV9655 (Kameramodul) auf 5"-Touchdisplay

Als welcher angemeldeter Nutzer hast du dein Bild hochgeladen?
Gab es wirklich nichts unanständiges was du zuvor geschrieben hast?

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.

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.

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.

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.

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.

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:

> 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.

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.

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.

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?

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

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.

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.

vampire schrieb:
> -- Viel Erfolg !

Danke :)

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.

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.

Hmm, genau das hatte ich auch vor

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.

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.

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

Stimmt, war ein typo.
Sind aber trotzdem noch 10MHz zuviel.

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.

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.

Ich hab die CD vom Open407I-C Kit verloren, gibts die irgendwo zum 
Download? Kann die mir vielleicht jemand kopieren?

hat sich erledigt, hab von Wvshare einen downloadlink bekommen.