Hallo Ich hänge schon länger an diesem Problem fest. Die Kamera funktioniert eignetlich supper, nur wird das Bild nicht mit den richtigen Farben dargestellt (siehe Anhang). Das OV9655 Modul habe ich an ein STM32F429I-Disco angeschlossen und betreibe dies über das DCMI-Modul (musste dazu ein paar Pins multiplexen: Bild einlesen, Tristate-Buffer aktivieren, LCD-Parallelport einschalten, Bild anzeigen,...) Die Farbverschiebung kann auch nicht von einem "festklemmenden" Pegel kommen (habe ich mit einem Oszi und Logic-Analyzer geprüft. Auch die Pixelwerte im RAM ergeben am PC das selbe Bild wie auf dem Display. Das Display selber gibt alle Farben ohne Probleme aus. Testweise habe ich die Kam in den Test-Mode versetzt und habe das Streifenmuster auf dem Display angezeigt. Hier existieren auch Rot, Grün nicht. Hat jemand eine Idee? Gruss Patrick
Angehängte Dateien:
-
IMG_0960.JPG
92 KB -
IMG_0961.JPG
100 KB
Patrick B. schrieb: > Pins multiplexen: Hast du analysiert, welcher Teil der RGB-Bitfolge nicht stimmt? Deckt sich das vielleicht mit den multiplexten Pins?
Nein, überhaupt nicht. Die Pins, die merfach verwendet wurden sind VSYNC, PXCLK und D5. Ich habe momentan ein andere Vermutung: Das OV9655-Modul gibt das RGB565-Format in 2 Bytes aus. Der DMA sollte dies dann eigentlich gemütlich in eine 16-Bit Variable packen und im Speicher ablegen.
1 | DMA_StructInit(&DMA_InitStructure); |
2 | DMA_InitStructure.DMA_Channel = DMA_Channel_1; |
3 | DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)DCMI_DR_ADRESS; |
4 | DMA_InitStructure.DMA_Memory0BaseAddr = (uint32_t)IMAGE_ADRESS; |
5 | DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory; |
6 | DMA_InitStructure.DMA_BufferSize = IMAGE_SIZE / IMAGE_PACKAGES; |
7 | DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; |
8 | DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; |
9 | DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word; |
10 | DMA_InitStructure.DMA_MemoryDataSize = DMA_PeripheralDataSize_HalfWord |
11 | DMA_InitStructure.DMA_Mode = DMA_Mode_Circular; |
12 | DMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh; |
13 | DMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable; |
14 | DMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full; |
15 | DMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single; |
16 | DMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_Single; |
17 | DMA_Init(DMA2_Stream1, &DMA_InitStructure); |
18 | DMA_DoubleBufferModeConfig(DMA2_Stream1, IMAGE_ADRESS + (IMAGE_SIZE / IMAGE_PACKAGES), DMA_Memory_0); |
19 | DMA_DoubleBufferModeCmd(DMA2_Stream1, ENABLE); |
Dies ist die einzige Konfiguration, bei der der DMA sich selber nicht wieder deaktiviert (dies sollte eigentlich nur bei einem Fehler mit den Speicherbreiten und BufferSize passieren. Ich vermute, dass der DMA hier die Daten falsch zusammensetzt.
vielleicht nützt dir das was: Beitrag "Re: stm32f429 Expansion board" Ich würde mal eine einzelne Farbe aufnehmen und dann analysieren, was an der RGB-Bitfolge nicht stimmt.
Patrick B. schrieb: > Das OV9655-Modul gibt das > RGB565-Format in 2 Bytes aus Das widerspricht allerdings der Initialisierung der DMA: Patrick B. schrieb: > DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word; > DMA_InitStructure.DMA_MemoryDataSize = DMA_PeripheralDataSize_HalfWord Wo, du als Quelle Words (32bit) angibst. Wenn die DMA anders nicht anläuft, prüfe doch mal die Fehlerflags derselben. Ich schlag mich gerade mit einem ähnlichen Problem auf dem Disco-F4 Board rum, bei dem die DMA auf den Audioausgang einfach nicht klappen will. Testweise könntest du mal statt der DMA den DCMI Interrupt benutzen, um die Daten zu schaufeln - Moment ich schau mal gerade, ob es sowas gibt... Jo, gibt es. Kapitel 15.7 im RM0090 listet sie auf. Mir ist bei CMSIS aufgefallen, das sie ab und zu mal nicht das initialisieren, was man in der Init Struct vorgibt. Es kann also sein, das du das DCMI besser 'zu Fuß' initialisierst, als über die CMSIS Funktionen. Ich musste z.B. das Masterclock Output Bit persönlich setzen, obwohl ichs in der I2S Init eigentlich schon auf ENABLE gesetzt hatte.
:
Bearbeitet durch User
- vergleich mal! Ansonsten hol Dir die fertige Lib von : http://mikrocontroller.bplaced.net/wordpress/?page_id=6
Hab mal eine andere Kamera angeschlossen -> das gleiche Ergebniss. Ebenso mit der Initialisierung von kettenrad und von Waveshare. Der DMA sollte eigentlich passen, da das DCMI die 8-Bit Packete selber schon in ein Word packt, befor der DMA getriggert wird. Also müssen nur 2 Pixel in einem Word auf 2 HalfWord aufgeteilt werden. Ich werde morgen mal ein schnelleres Oszi anschliessen. Ev. stimmt ja etwas mit dem Timings nicht. Das LCD und die Cam sowie deren Initialisierung kann schon mal ausgeschlossen werden, da die Teile in verschiedenen Varianten getestet wurden.
Moin, der OV9655 gibt per default YUYV aus, wenn ich mich richtig erinnere. Sieht so aus, als ob im ersten Bild die typischen Streifen auftreten (Kammstruktur, wenn YUV422 als RGB 'verstanden' wird). Hast Du den Chip richtig konfiguriert? Guck sonst mal ins Datenblatt, wenn Du einen Registerdump postest, lässt sich genaueres sagen. Grüsse, - Strubi
Angehängte Dateien:
-
IMG_0962.JPG
140 KB -
IMG_0963.JPG
110 KB
Sollte eigentlich passen. Habe aber noch einen Fehler gefunden: Bei der AF Zuweisung habe ich mich bei einem Pin um eine Zeile vertan, und somit stimmte dieser Bit-Wert nie. Jetzt habe ich zumindest schon "realistischere" Farben. Leider sind je nach Helligkeit des Objektes noch Grünflächen im Bild, und ich habe echt keine Ahnung, welche Register ich hier anpassen muss. Habe schon mit den Gains und den Maximalwerten gespielt, aber ohne grossen Erfolg. Selbst wenn die Kamera einen statischen Bereich filmt, flimmern zum teil grüne Pixel auf dem Display, als ob die Werte variieren. Eigentlich brauche ich dann am Schluss nur ein Schwarzweissbild (möchte noch etwas Bildverarbeitung im Matlab machen) aber dazu müssten die Farben über das Bild gesehen annähernd stimmen. Gruss
Patrick B. schrieb: > flimmern zum teil > grüne Pixel auf dem Display, als ob die Werte variieren. Das klingt schon eher nach einem Timing Problem.
Patrick B. schrieb: Leider sind je > nach Helligkeit des Objektes noch Grünflächen im Bild ... Da ich dein Programm nicht kenne, kann ich nur vermuten! Sieht so aus, als wenn sich der Grünanteil aus RGB-565 das höherwertige Bit der Nachbarfarbe "borgt". Hast du eine swap-Funktion aktiv? Stimmt das Bitgeschiebe? Ist deine Beschaltung richtig? Ist die Cam auf 2byte RGB-565 eingestellt(Register)? Bei mehr als 2 DMA-Streams hat der STM32F4xx Probleme. z.B.: DMA -OV-Cam; DMA-Display; plus DMA-SD Karte,u.o. NOR-/NAND-Flash, I2C-Touch u.o. I2s-Audio, u.o. Beschleunigungssensor/Gyro; -alles Fragen, die nur du beantworten kannst!
Ich will dir keinesfalls die Lust am Ausprobieren nehmen! Aber halte dich doch an die bewährten Anleitungen von u.b.(der exponent) in dem obigen Link und portiere seine Beispiele für den stm32f4xx auf deinen f429. Nur versuche nicht, wie ich, möglichst ALLE Funktionen gleichzeitig, gesteuert über Touch-screen Menü, in einem Mammut-projekt unterzubringen. Das könnte scheitern. Mein Versuch ist seit ~1 1/2 Jahren in meiner Ablage verschollen. Realisiert habe ich es dann mit einem flachgemachten Raspberry-Pi und später, noch kompakter, mit einem Odroid-W. Gutes Gelingen ... !
kettenrad schrieb: > Da ich dein Programm nicht kenne, kann ich nur vermuten! > Sieht so aus, als wenn sich der Grünanteil aus RGB-565 das höherwertige > Bit der Nachbarfarbe "borgt". > Hast du eine swap-Funktion aktiv? Nein, wüsste nicht wie. Das Bild wird vom DMA in den Speicher gelesen, dann wird vom LCD-DMA das ganze wieder ausgelesen. > Stimmt das Bitgeschiebe? Konnte ich bis jetzt noch nicht 100%ig testen. Werde ich aber spätestens morgen können (mit LA und besserem Oszi, als ich hier habe) > Ist deine Beschaltung richtig? > Ist die Cam auf 2byte RGB-565 eingestellt(Register)? Es gibt nur 2-Byte Modi (RGB555, RGB565...) > Bei mehr als 2 DMA-Streams hat der STM32F4xx Probleme. z.B.: > DMA -OV-Cam; > DMA-Display; > plus > DMA-SD Karte,u.o. NOR-/NAND-Flash, I2C-Touch u.o. I2s-Audio, u.o. > Beschleunigungssensor/Gyro; Habe ich bei einem STM32F407 auch schon gemerkt. Aber bei mir laufen nur 2 DMAs und das nicht einmal gleichzeitig (Da die Cam auch Pins des LCDs nutzt). Und so ein Monsterprojekt ist es noch nicht. Das einzige, was programmiert ist, ist dass ein Bild eingelesen werden soll, und dann auf dem LCD dargestellt wird.
Patrick B. schrieb: > Eigentlich brauche ich dann am Schluss nur ein Schwarzweissbild (möchte > noch etwas Bildverarbeitung im Matlab machen) aber dazu müssten die > Farben über das Bild gesehen annähernd stimmen. Hast Du die Rohdaten denn schon einmal gespeichert und in Matlab offline weiterverarbeitet? So mache ich gerne Prototypen-Implementierungen: - Daten offline in Matlab verarbeitet - Routine dann als MEX-Funktion implementiert und offline getestet - Dann auf den Controller geschoben. So habe ich weniger Baustellen gleichzeitig.
Angehängte Dateien:
-
IMG_0964.JPG
120 KB -
IMG_0968.JPG
140 KB -
IMG_0969.JPG
110 KB
Ja, habe das RGB565 Bild auch schon am PC in ein RGB888 Bild umgewandelt und dargestellt. Die Farben sind etwas "klarer" aber diese Ungenauigkeit ist immer noch vorhanden. Habe jetzt noch festgestellt, dass es stark von der Helligkeit des Objektes abhängt. Irgendwie ist das automatische Gain-Control der Kamera noch nicht richtig. Achja, selbiger Effekt mit der Lib von Uwe. Ich habe mir mal auf dem uC das Bild in die einzelnen Komponenten maskiert (siehe Anhang). Das Rot-Bild ist sehr stabil, ganz im gegensatz zum Grün. Hier gibt trotz ebenen Flächen und normaler Ausleuchtung extreme Unterschiede (helle und dunkle Flecken). Das Blaue verhält sich ähnlich wie Rot. Also muss das Problem im Grünanteil liegen (entweder schon von der Kamera oder bei DCMI-DMA)
:
Bearbeitet durch User
<Also muss das Problem im Grünanteil liegen (entweder schon von der Kamera oder bei DCMI-DMA) - messe bitte mal in spannungslosen Zustand am LCD und der Cam die Anschlüsse gegen Masse und Vcc. Die Datenleitungen auch gegeneinander. (Die Widerstandswerte müssen in etwa gleich sein) Der Fehler sitzt meist im Detail und frei nach Murphys-Law sowieso immer da, wo man ihn nie vermutet ...
Pins untereinander haben alle ~780kOhm, gegen VCC und GND jeweils etwa 450kOhm. Habe auch schon die ganze Verdratung, Pins, Pads, Defines etwa 10mal kontrolliert... Bin momentan echt am verzweifeln.
- obwohl eigentlich anderes wichtiger, habe ich schonmal den Staub von meinem STM32F429I-Disco gepustet und irgentwo ist auchnoch eine ov9655. Dauert aber noch...
- ich war offenbar dochschon zu lange raus! So geht's nicht: DMA und DCMI können nicht auf gleichen Pins liegen. PCLK->PA6->G2(Grün D2); SCL->PB8->B6; SDA->PB9->B7; D1->PC7->G6; Das beisst sich,wenn der DMA - stream startet. Habe ich nurnicht gleich gesehen und du hast es auchnicht erwähnt. Nicht sehr nett ... Umbelegen notwendig. Bei begrenzter Pinanzahl schwer, aber machbar. Viel Spass ...!
Patrick B. schrieb: > Die Pins, die merfach verwendet wurden sind > VSYNC, PXCLK und D5. 3. Post... Das I2C habe ich selber geschrieben (Bit-Bang) und läuft einwandfrei (getester mit LA, OSZI, und einem HMCxxx). Die Pins sind über einen 74HCT126 gemuxt, damit die CAM und das STM nicht gleichzeitig als Master agieren. Ebenso werden die DMAs LCD_Funktionen und sonstiges schön umgeschaltet (zuerst das eine aktiv, dann das andere....). Ausserdem wird weder das Touchscreen Modul noch sonst ein I2C dings verwendet. Werde mir mal das ganze auf einem SMT32F407 ohne Display und dergleichen anschauen...
:
Bearbeitet durch User
Patrick B. schrieb: > SMT32F407 ohne Display Wenn du das 429-tft im Spi-Modus betreibst, kannst du die Bilddaten in den DRAM laden.
@ Patrick B. (p51d) Eine Frage noch zum F429-Discovery: Wo wird eigentlich das 565-RGB von der Cam in 666-RGB fürs Display formiert? Hast Du da hardwaremäßig die höherwertigen Bits auf die niederwertigen gespiegelt?
kettenrad schrieb: > SCL->PB8->B6; > SDA->PB9->B7; PA8 und PC9 (I2C3) sollten aber gehen, wenn die Kamera nicht gerade die gleiche Adresse wie der Touchcontroller benutzt. Gebe aber gerne zu, das die Pinbelegung des ganzen F429 Disco ein einziger Mist ist und mich auch schon wahnsinnig gemacht hat. Ein Glück gibts die Liste von UB: http://mikrocontroller.bplaced.net/wordpress/?page_id=2848
:
Bearbeitet durch User
- schlimmer ist, das man PA6-Pixelclock nicht altern. frei bekommt. Da müsste man unzugängliche Verbindungen kappen ... ... oder den DCMI-Pixelclock anderweitig erzeugen?!
Angehängte Dateien:
-was denkst du, was passiert, wenn der Pixelclock auf eine LCD-Datenleitung durchschlägt? Dann haste massive Fehlfarben und Blautöne überall .. .. upps, das war ja der Ausgangspunkt!
kettenrad schrieb: > Wo wird eigentlich das 565-RGB von der Cam in 666-RGB fürs Display > formiert? Das Display wir selber schon im RGB565 Format angesteuert (oder hab ich da was übersehen, muss ich noch prüfen). Und wieso gespiegelt? Ja, das Discovery ist der reinste Mist. Einzig das RAM und das Display laufen gut. Will man was anderes, hat man nur Probleme. ST hat es sich hier sehr einfach gemacht und das Gehäuse 1-2Nummern zu klein gewählt. Für die Cam habe ich das I2C selber auf freien Pins im Bit-Bang-Modus geschrieben, dann HSYNC, PXCLK, und DCMI_D5 über einen Tri-State Buffer geführt (um Konflickte zu vermeiden). Das I2C Signal des Touch geht auch auf eine DCMI Datenleitung (der Clock nicht), weswegen ich auf die Hand-Version ausgewichen bin). Habe es für heute aufgegeben. Werde morgen mit besseren Messmittel in der Schule schauen. Gruss
- alles klar und ebenfalls: -Gute Nacht-! (Lt. Schaltplan sind jeweils 6 Datenleitungen pro Farbe am LCD)
- zum Spiegeln: Es ist durchaus gebräuchlich, aus RGB 565 <-> RGB666 zu machen, indem man das höchstwertigste Bit einer Farbe(der ein Bit fehlt) mit dem niederwertigsten zusammenschaltet (quasi- spiegelt), um zumindest definiertes "Schwarz" und "Weiss" zu erhalten ..
Hab nochmals die Funktionen des Displays angeschaut:
1 | #define LCD_COLOR_WHITE 0xFFFF
|
2 | #define LCD_COLOR_BLACK 0x0000
|
3 | #define LCD_COLOR_GREY 0xF7DE
|
4 | #define LCD_COLOR_BLUE 0x001F
|
5 | #define LCD_COLOR_BLUE2 0x051F
|
6 | #define LCD_COLOR_RED 0xF800
|
7 | #define LCD_COLOR_MAGENTA 0xF81F
|
8 | #define LCD_COLOR_GREEN 0x07E0
|
9 | #define LCD_COLOR_CYAN 0x7FFF
|
10 | #define LCD_COLOR_YELLOW 0xFFE0
|
11 | |
12 | /**
|
13 | * @brief Clears the hole LCD.
|
14 | * @param Color: the color of the background.
|
15 | * @retval None
|
16 | */
|
17 | void LCD_Clear(uint16_t Color) |
18 | {
|
19 | uint32_t index = 0; |
20 | |
21 | /* erase memory */
|
22 | for (index = 0x00; index < BUFFER_OFFSET; index++) |
23 | {
|
24 | *(__IO uint16_t*)(CurrentFrameBuffer + (2*index)) = Color; |
25 | }
|
26 | }
|
So wie ich das sehe, sind die Bilddaten des Displays im RAM immer im RGB565 Format. Also sollte man doch auf die Framebufferadresse gleich die Bilddaten schreiben können. Und wegen der Mehrfachbenutzung sollte es keine Probleme geben, werde noch den "Umschaltcode" posten.
OK, hab mir das ganze mal auf dem KO angeschaut: Soweit ich das sehen kann, gibts keine Probleme. Die Signale sind alle auf High, befor die positive Flanke von PXCLK kommt. Achja, der Wechsel zwischen Display und Cam:
1 | /**
|
2 | * @brief Changes the alternating function setting for PXCLK, HREF and D5
|
3 | * from DCMI to the LCD controller
|
4 | * @param None
|
5 | * @retval None
|
6 | */
|
7 | inline void SwitchFromCameraToLCD(void){ |
8 | // ToDo ASM/CSMIS code für schnellen wechsel
|
9 | DCMI_Cmd(DISABLE); // Disable DCMI |
10 | DMA_Cmd(DMA2_Stream1, DISABLE); // Disable DMA |
11 | |
12 | // Disable Tri-state buffer
|
13 | GPIO_ResetBits(CAM_TRISTATEBUFFER_PORT, CAM_TRISTATEBUFFER_PIN); // Reset bit |
14 | |
15 | GPIO_PinAFConfig(DCMI_D5_PORT, DCMI_D5_PIN_SOURCE, GPIO_AF_LTDC); |
16 | GPIO_PinAFConfig(DCMI_PXCLK_PORT, DCMI_PXCLK_PIN_SOURCE, GPIO_AF_LTDC); |
17 | GPIO_PinAFConfig(DCMI_HSYNC_PORT, DCMI_HSYNC_PIN_SOURCE, GPIO_AF_LTDC); |
18 | |
19 | RCC_PLLSAICmd(ENABLE); |
20 | while(RCC_GetFlagStatus(RCC_FLAG_PLLSAIRDY) == RESET); // Wait for PLLSAI activation |
21 | //LCD_DisplayOn();
|
22 | |
23 | // Enable LCD
|
24 | // LTDC_Cmd(ENABLE);
|
25 | }
|
26 | |
27 | /**
|
28 | * @brief Changes the alternating function setting for PXCLK, HREF and D5
|
29 | * from LCD controller to the DCMI
|
30 | * @param None
|
31 | * @retval None
|
32 | */
|
33 | inline void SwitchFromLCDToCamera(void){ |
34 | // ToDo ASM/CSMIS code für schnellen wechsel
|
35 | // Disable LCD
|
36 | //LCD_DisplayOff();
|
37 | LTDC_Cmd(DISABLE); |
38 | RCC_PLLSAICmd(DISABLE); |
39 | |
40 | GPIO_PinAFConfig(DCMI_D5_PORT, DCMI_D5_PIN_SOURCE, GPIO_AF_DCMI); |
41 | GPIO_PinAFConfig(DCMI_PXCLK_PORT, DCMI_PXCLK_PIN_SOURCE, GPIO_AF_DCMI); |
42 | GPIO_PinAFConfig(DCMI_HSYNC_PORT, DCMI_HSYNC_PIN_SOURCE, GPIO_AF_DCMI); |
43 | |
44 | // Enable tri-state buffer
|
45 | GPIO_SetBits(CAM_TRISTATEBUFFER_PORT, CAM_TRISTATEBUFFER_PIN); // Set bit |
46 | |
47 | DMA2_Stream1->M0AR = IMAGE_ADRESS; |
48 | DMA_SetCurrDataCounter(DMA2_Stream1, IMAGE_SIZE / IMAGE_PACKAGES); // Set data to be transfered |
49 | DMA_ClearFlag(DMA2_Stream1, DMA_FLAG_TCIF1); |
50 | DMA_ClearFlag(DMA2_Stream1, DMA_FLAG_HTIF1); |
51 | DMA_ClearFlag(DMA2_Stream1, DMA_FLAG_TEIF1); |
52 | DMA_Cmd(DMA2_Stream1, ENABLE); // Enable DMA |
53 | DCMI_Cmd(ENABLE); // Enable DCMI |
54 | DCMI_CaptureCmd(ENABLE); // Enable capture |
55 | }
|
Ich klemme das Display also komplett ab (kein Clock, UND kein LTDC Controller), und selbst wenn es falsche Bitwerte übernehmen würde, so würde das Display gleich mit den richtigen überschrieben und dann würden die RAM Daten auch das korrekte Bild darstellen. Mhm
- ich habe mir die doppel layer-Geschichte mal angesehen. Der LTDC Controller ist für mich auch Neuland. Die von mir bisher genutzten Sainsmart-ILI Displays sind da unkomplizierter. Ich sehe auch die Funktionen LCD_LayerInit(), die prüft auf 16-/24-/32-bit Pixelgrösse. Das war mein Zweifel an den 3x 8bit für RGB (und ColorAlpha); und LCD_SetColorKeying(uint32_t RGBValue), die die von mir oben angefragten Maskierungen macht; Ich bin doch schon über 1 Jahr weg vom STM32 und nur allmählich finde ich mich wieder rein .. Mit PutPixel(int16_t x, int16_t y)(/LCD_DrawLine --> 1 Pixel) müsste man doch eine ähnliche Ausgabe der Kamera-Daten (ohne den sdRAM) erreichen können? So wie bei den mir bekannten Displays ... ? Aber das muss ich erstmal verdauen!
Noch 'ne Frage: Du schaltest mit dem Tri-state-Buffer die unglückseelig angeordneten Pins um. Das funktioniert. Allerdings sicherlich nur bei "one-shot" capture. Oder willst du etwa streamen(als Vorschau-Bild vor dem speichern auf z.B. SD-Karte)?
Ich streame das ganze momentan auf das Display (Display aktualisieren dauert ~12ms, Pixels von Hoch- in Querformat umschieben nochmals 12ms, da ich bis jetzt noch nicht herausgefunden habe, wie ich den LTDC umkonfigurieren kann, damit er mir die Addressleitungen tauscht. Das Bild einlesen etwa 30ms). Mach alles in allem Flotte 15-20 Bilder pro Sekunde. Es soll wie du gesagt hast eine Vorschau sein, damit man sieht was man später fotografiert. Das Bild selber soll dann in einem nächsten Schritt auf VGA oder SXGA vergrössert werden. Nach dem Foto wird es in ein 8Bit Grauwertbild umgerechnet und an den PC gesendet (damit dort die Zahlen von einem Sudoku erkennt werden und dieses gelöst wird). Am Schluss soll die Lösung auf dem LCD des Discovery angezeigt werden. Ich habe mich schon etwas weiter dem Fehler genähert: Der Wert des 1. Pixels vom Testbild ist bei mir 0x38C4 (also zuerst 0x38, und dann 0xC4, was ich heute mit dem KO gemessen habe). Der DCMI schreibt mir ins DR Register 0xC438C438 (B3,B2,B1,B0). Der DMA schiebt es mir dann auf das RAM als 0xC438C438 (also Addresse 0 hat 0x38 und Addresse 3 hat entsprechen C4). Da der Controller aber Little-Endian hat, werden beim 16-Bit Zugriff aus den ursprünglichen 0x38C4 neu 0xC438. Mal schauen, ob ich die CAM dazu bringe die Bytes zu drehen, oder der DMA (obwohl HalfWord und Word als MemSize keinen Unterschied machen im Speicher) mir das Endian-Problem löst. Obwohl es aus reiner Logik ja kein "sauberes" Bild mehr geben sollte, wenn die Bytes vertauscht sind. Momentan habe ich nur ein paar Fehler... mhm gaaanz komisch.
:
Bearbeitet durch User
Patrick B. schrieb: > Mal schauen, ob ich die CAM dazu bringe die Bytes zu drehen, oder der > DMA (obwohl HalfWord und Word als MemSize keinen Unterschied machen im > Speicher) mir das Endian-Problem löst. > Warum nicht einfacher das uint32_t RGBValue (aus void LCD_SetColorKeying(uint32_t RGBValue) der LTDC-Ausgabe --> Firmware ST) mit der oben von mir erwähnten swap- Funktion neu ordnen? Oder zu Fuß mit shift und mask in 2 bytes und diese richtig rum wieder mit shift und | zusammensetzen? Dies in die LCD-Ausgabe und einfach weiter ... p.s.: Sudoko-Master seiner Schule. Nun ja, jeder muss sich irgentwie motivieren :)
Patrick B. schrieb: > auf VGA oder SXGA vergrössert werden. Dein Ansatz ist falsch. Du brauchst das sdram, nicht das tft. Auf das tft passt nur qvga. sdram geht nur zusammen mit spi-tft. Da kannst du dir den Aufwand mit dem Anpassen des Datenstroms auf das tft sparen.
grundschüler schrieb: > Patrick B. schrieb: >> auf VGA oder SXGA vergrössert werden. > > Dein Ansatz ist falsch. Du brauchst das sdram, nicht das tft. Auf das > tft passt nur qvga. sdram geht nur zusammen mit spi-tft. Da kannst du > dir den Aufwand mit dem Anpassen des Datenstroms auf das tft sparen. Das stimmt so nicht! Mit spi-tft bekommt man nur einfacher die Pins frei für die Kamera. Aber dafür hat er ja schon einen workaround mit tri-state-buffer und ständigem um- initialisieren der entsprechenden Pins. Das stm32f407 Discovery hat zwar noch weniger Pin, lässt sich aber alles hinbiegen: http://www.mikrocontroller.net/topic/goto_post/2879178 -hier wurde es bereits gemacht..
kettenrad schrieb: > Das stimmt so nicht! stimmt doch. Es geht nicht um die Pins für die Camera sondern um die Pins für das sdram. Das tft ist mit 320x240x16bit einfach zu klein, um mehr als 1/4vga zu speichern. Wo sollen die Pixel für höhere Auflösungen denn hin? Wenn du mehr als qvga Auflösung wilst, brauchst du einen schnellen Speicher von entsprechender Größe. Dafür hat das 429 den sdram. Das winzige tft mit rund 20 Datenleitungen zu betreiben und dafür auf das sdram zu verzichten, ist kein guter Ansatz. zumindest ub hat nur qvga. Bei vampire weiß ich es nicht. Beitrag "STM32 DCMI OV2640 höhere Auflösung"
-bei vampire kann man in den auskommentierten Funktionen sehen, das das Vorschau-/Sucherbild (FSMC) durch den USER-Button(Auslöser) beendet wird und die OV-Cam im Interrupt mit neuen Registerwerten(JPEG) neu gestartet wird, um auf die SD-Karte zu speichern. Ähnliches könnte ich mir auch hier vorstellen. Das Vorschaubild bleibt ja wohl im GRAM des Displays, während der nächste Frame meinetwegen in den SDRAM des F429 gespeichert wird ..
Es stellt sich halt die Frage, ob es nach den gemachten Erfahrungen überhaupt sinnvoll ist, das DCMI zu benutzen. Die bescheuerte Pinbelegung des Disco F429 hilft da ja überhaupt nicht... Wenn man sowieso externe Hardware braucht, um für jeden Frame Pins umzuschalten, könnte ein neuer Ansatz vllt. besser das USB-OTG benutzen mit einer schlichten USB Kamera. Das hilft natürlich dir erstmal nicht weiter, könnte aber für andere Mitleser (z.B. mich) mögl. eine Lösung sein, wenn sie mal Bilder grabben wollen.
.. oder gleich über LAN/WLAN an den PC zur Auswertung und Berechnen. Ich hätte für die vom TO gewählte Aufgabe sicherlich einen Mini-PC ähnlich Raspberry-Pi oder Odroid gewählt. Kompakt, Cam-Projekte bereits vielfach im Net, Berechnungen direkt vor Ort(Sudoko-App) --> und alles in allem, billig.
kettenrad schrieb: > Ähnliches könnte ich mir auch hier vorstellen. Das Vorschaubild bleibt > ja wohl im GRAM des Displays, während der nächste Frame meinetwegen in > den SDRAM des F429 gespeichert wird .. Das Problem ist doch dass Parallel-tft und sdram wegen Doppelbelegung von pins NICHT gleichzeitig funktionieren. Du kannst auch nicht das parallel-TFT als Vorschau benutzen und dann jpeg auf sd-Karte schreiben, weil die sd-karte dazu viel zu langsam ist. Matthias Sch. schrieb: > Es stellt sich halt die Frage, ob es nach den gemachten Erfahrungen > überhaupt sinnvoll ist, das DCMI zu benutzen. Die Das 429-DCMI ist einfach klasse. Es geht doch damit alles, nur nicht mit dem parallelen Anschluss des TFT. DCMI auf sdram. Sdram als Vorschau auf spiTFT + weiter auf sd-Karte oder ins lan. Geht doch alles. Man muss nur das sdram benutzen. Schließlich hat man es beim Kauf des Disco mitbezahlt. Wenn man das sdram nicht benutzt, bekommt man von Stm doch kein Geld zurück. Wo habt ihr den das Problem mit der Verwendung des sdram?
grundschüler schrieb: > Es geht doch damit alles, nur nicht mit > dem parallelen Anschluss des TFT. Aber warum sollte ich dann den lahmen Anschluss über SPI fürs Display haben wollen, wenn ich eine simple USB Cam viel einfacher anschliessen kann als per DCMI? DA SDRAM und TFT onboard sind, nutze ich die beiden lieber mit voller Geschwindigkeit und docke dann die Kamera per USB an. Nicht das ich das wirklich wollte - ich habe das F429 nur für einen einzigen Zweck angeschafft, und den erfüllt es.
Angehängte Dateien:
.. welche Doppelbelegung von Pins SDram und LCD meinst Du?
.. ah, sehe grad: Da hab' ich dich falsch verstanden. Du meintest die Doppelbelegung LCD - DCMI!
grundschüler: <Es geht doch damit alles, nur nicht mit <dem parallelen Anschluss des TFT. DCMI auf sdram. Sdram als Vorschau auf <spiTFT + weiter auf sd-Karte oder ins lan. Geht doch alles. why not? Nur, wenn ich die Bilddaten der Vorschau schon im sdRAM habe, kann ich sie auch parallele aufs LCD ausgeben und bei "Auslöser" dahin übertragen, wo ich sie noch brauche ..
.. so bleibt die schnelle doppel-layer LTDC-Ausgabe für andere Anwendungen erhalten;
kettenrad schrieb: > welche Doppelbelegung von Pins SDram und LCD meinst Du? PE11 bis PE15: FMC_D8 == LCD_G3 usw. Matthias Sch. schrieb: > lahmen Anschluss über SPI ??? der 429-spi ist alles andere aber nicht lahm
-hast Du ein anderes Board?
+------------------------+-----------------------+----------------------
------+
+ LCD pins assignment
+
+------------------------+-----------------------+----------------------
------+
| LCD_TFT R2 <-> PC.10 | LCD_TFT G2 <-> PA.06 | LCD_TFT B2 <->
PD.06 |
| LCD_TFT R3 <-> PB.00 | LCD_TFT G3 <-> PG.10 | LCD_TFT B3 <->
PG.11 |
| LCD_TFT R4 <-> PA.11 | LCD_TFT G4 <-> PB.10 | LCD_TFT B4 <->
PG.12 |
| LCD_TFT R5 <-> PA.12 | LCD_TFT G5 <-> PB.11 | LCD_TFT B5 <->
PA.03 |
| LCD_TFT R6 <-> PB.01 | LCD_TFT G6 <-> PC.07 | LCD_TFT B6 <->
PB.08 |
| LCD_TFT R7 <-> PG.06 | LCD_TFT G7 <-> PD.03 | LCD_TFT B7 <->
PB.09 |
------------------------------------------------------------------------
-------
| LCD_TFT HSYNC <-> PC.06 | LCDTFT VSYNC <-> PA.04 |
| LCD_TFT CLK <-> PG.07 | LCD_TFT DE <-> PF.10 |
-----------------------------------------------------
Angehängte Dateien:
-
image.PNG
270 KB
du hast recht sdram und rgb-tft gibt keinen Konflikt, war die falsche Tabelle. das ist alles schon etwas länger her. Ich wollte sdio, dcmi und sdram nutzen und habe mir danach den tft-modus ausgesucht. Bei meinem Projekt sind zum Ende die Pins knapp geworden. Der paralelle tft-Anschluss wäre da sicher nicht mehr gegangen. Warum auch? das spi-tft ist zumindest für Fotos schnell genug. Videos wollte ich mir auf dem 2,4" tft nicht ansehen. Fakt ist, dass man auf dem tft nur 240x320=76.800 Pixel speichern kann. Größere Bilder müssen also auf das sdram.
- hatte mich schon gewundert. Allerdings kollidiert hier der unter dem IC über VIA-durchkontaktierte und direkt an das LCD geführte PA6(Pixel-ClockDCMI), der nicht gedoppelt ist. Die anderen sind zumindest alternativ noch mindestens ein 2.-mal auf anderen Pins. Fabrikationstechnisch keine Glanzleistung! DCMI war offensichtlich nie vorgesehen..
Angehängte Dateien:
-
test.jpg
80 KB
So, nach den ganzen Weihnachtsfesten und letzten Prüfungen hatte ich nun wieder etwas Zeit gefunden. Fazit: Ich hasse und liebe Lackisolierte Drähte. Momentan habe ich noch 2 Probleme, bei denen ihr eventuell Rat weisst: 1) Der DMA sollte im double-buffer-mode laufen, damit das Bild "kontinierlich" eingelesen werden kann. Beim transfer complete interrupt wird nicht immer der Buffer sofort gewechselt. Eignetlich sollte am Anfang der Buffer0 gefüllt werden. Dann nach dem TCI Buffer1 und die Addresse von Buffer0 so erhöht werden und so weiter, damit am Schluss ein komplettes Bild entsteht. Nur werden die Buffers verzögert oder gar nicht gewechselt.
1 | DMA_StructInit(&DMA_InitStructure); |
2 | DMA_InitStructure.DMA_Channel = DMA_Channel_1; |
3 | DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)DCMI_DR_ADRESS; |
4 | DMA_InitStructure.DMA_Memory0BaseAddr = (uint32_t)IMAGE_ADRESS; |
5 | DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory; |
6 | DMA_InitStructure.DMA_BufferSize = IMAGE_SIZE / 8; // (640*480) und 2 Pixels pro Word |
7 | DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; |
8 | DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; |
9 | DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word; |
10 | DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; |
11 | DMA_InitStructure.DMA_Mode = DMA_Mode_Circular; |
12 | DMA_InitStructure.DMA_Priority = DMA_Priority_High; |
13 | DMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable; |
14 | DMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full; |
15 | DMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single; |
16 | DMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_Single; |
17 | DMA_Init(DMA2_Stream1, &DMA_InitStructure); |
18 | |
19 | DMA_DoubleBufferModeConfig(DMA2_Stream1, (uint32_t)(IMAGE_ADRESS + (IMAGE_SIZE / 2)), DMA_Memory_0); |
20 | DMA_DoubleBufferModeCmd(DMA2_Stream1, ENABLE); |
21 | DMA_Init(DMA2_Stream1, &DMA_InitStructure); |
22 | |
23 | |
24 | void DMA2_Stream1_IRQHandler(void){ |
25 | static uint32_t transfers = 0; |
26 | |
27 | if(DMA_GetITStatus(DMA2_Stream1, DMA_IT_TCIF1) != RESET){ |
28 | transfers ++; |
29 | |
30 | switch(transfers){ |
31 | case 1: |
32 | if((DMA2_Stream1->CR & DMA_SxCR_CT) == 1){ // The current target memory is Memory 1 |
33 | DMA2_Stream1->M0AR = IMAGE_ADRESS + IMAGE_SIZE; |
34 | }
|
35 | break; |
36 | |
37 | case 2: |
38 | if((DMA2_Stream1->CR & DMA_SxCR_CT) == 0){ // The current target memory is Memory 1 |
39 | DMA2_Stream1->M1AR = IMAGE_ADRESS + IMAGE_SIZE / 2 * 3; |
40 | }
|
41 | break; |
42 | |
43 | case 3: |
44 | if((DMA2_Stream1->CR & DMA_SxCR_CT) == 1){ // The current target memory is Memory 1 |
45 | DMA2_Stream1->M0AR = IMAGE_ADRESS; |
46 | }
|
47 | break; |
48 | |
49 | case 4: |
50 | DCMI->CR &= ~(uint32_t)DCMI_CR_ENABLE; //DCMI_Cmd(DISABLE); |
51 | DMA2_Stream1->CR &= ~(uint32_t)DMA_SxCR_EN; //DMA_Cmd(DMA2_Stream1, DISABLE); |
52 | DMA2_Stream1->M1AR = IMAGE_ADRESS + (IMAGE_SIZE / 2); |
53 | state = SCALE_IMAGE_LCD_ENABLE; |
54 | transfers = 0; |
55 | break; |
56 | }
|
57 | DMA_ClearITPendingBit(DMA2_Stream1, DMA_IT_TCIF1); |
58 | }
|
59 | }
|
Nun zum 2. Problem: Im Anhang habe ich ein Bild mit 640*480 Pixel. Da ich keine Referenz habe wollte ich mal wissen, ob solche Farbverläufe (rot markiert) vom RGB565 Format herrühren, oder ob sich da sonst noch irgendwo Fehler verstecken (Hardware oder Register setup). Achja, zur Fragestellung SDRAM oder LCD (da ich hier anscheinend ungenau war): Das Bild wird im SDRAM gespeichert, dann verkleinert auf das LCD kopiert. Besten Dank Gruss
:
Bearbeitet durch User
-von Anfang an dein Programm komplett als *.zip hätte Mißverständnisse garnicht erst aufkommen lassen. Oder sind da noch Patente ausstehend? zu 2.: helle Lichtquelle gegen schlecht ausgeleuchteten Hintergrund kann zu "Pixelfeuern" führen. gain-Register event. nachjustieren. zu 1.: bisher scheint keiner eine brauchbare Lösung gefunden zuhaben. Beitrag "Re: Ab 3.DMA stellt die CPU die Arbeit ein?" und http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/ .. aber vielleicht hier?!
- ST hat diesen Fehler offenbar zur Kenntnis genommen http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/ERRATA_SHEET/DM00037591.pdf - und ignoriert! Nach dem Motto: "Da unsere Neuwagen unter gewissen Umständen den im Prospekt angegebenen Höchstverbrauch pro 100km etwas übersteigen können, haben wir Ihnen einen aufblasbaren Tret-Roller inclusive Reservekanister(leer) formschön in den Kofferraum integriert(gegen Aufpreis). Damit können Sie die nächste Autobahn-Tankstelle in kürzester Zeit erreichen."
Angehängte Dateien:
-
st-404.gif
14 KB
kettenrad schrieb: > - ST hat diesen Fehler offenbar zur Kenntnis genommen > http://www.st.com/internet/com/TECHNICAL_RESOURCES... > Siehe Bild. Falschen Link gepostet?
ST schrieb:
"
We confirm your findings and it is a limitation that concerns only our
DMA2, and here is the detailed description :
DMA2 controller could corrupt data when managing AHB and APB2
peripherals in a concurrent way :
Description :
This case is somehow critical for peripherals embedding FIFO and
generates data corruption. For memories, the impact is a multiple access
but the data is not corrupted. AHB Peripherals embedding FIFO are DCMI,
CRYPT, HASH. on STM32F2/40xx without CRYPTO only the DCMI is impacted.
Implications:
The data transferred by the DMA to the AHB peripherals could be
corrupted in case
of a FIFO target or multiply accesses in case of memories access.
Workarounds :
Avoid concurrent AHB and APB2 transfer using DMA2. One of the following
approach could be used to solve the issue:
If DMA2 is used to manage AHB peripheral (DCMI, CRYPT, HASH), we can
use the Cortex-M CPU to manage APB2 peripherals.
If DMA2 is used to manage APB2 peripheral, we can use the CPU to
manage AHB peripheral (DCMI, CRYPT, HASH).
Obviously, we will update our errata on web soon .
Thank you again for your findings .
Cheers,
STOne-32 { STM32 moderator }
"
*aus dem Blog;
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fWarning%20limit%20simultaneous%20DMAs%20to%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=636
Angehängte Dateien:
-
Sudoku_SXGA2.jpg
60 KB
Hallo Habs nach etwas ausprobieren nun geschaft, die Kamera im SXGA Format zu betreiben. Dabei wird das Bild immer komplett eingelesen und dann für das Display skalliert. Nur stimmen die Farben leider noch nicht ganz, und um ehrlich zu sein, habe ich keine Ahnung, an welchen der 200 Register da man was drehen muss. Im Anhang hab ich euch ein Sudoku, bei dem eigentlich der Hintergrund ein schönes Weiss (von einem Blatt aus dem Drucker) und die Zahlen schön Schwarz sein sollten. Nur ist eben alles etwas grau. Den Weisswert im Zentrum habe ich im Photoshop mal angeschaut (R=208, G=197, B=195), und anhand der Werte kann man sagen, dass der Abgleich zwischen den Kanälen schon nicht schlecht ist. Und der Kontrast wird auch ziemlich mies, sobald man sich vom Zentrum entfernt. Oder habe ich mich bei der Qualität der Kamera dermassen verschätzt? Was bewirken die Matrix- und Gamma-Register der Kamera? Achja, falls jemand interesse hat, kann ich das Projekt (wenns mal fertig ist) hier hineinstellen. Frohe Weihnachten, Gruss
mhm, ist das ein Bild direkt von der Kamera (oder wars zu gross)? Wenn ja, was hast du für Einstellungen?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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.