Camera Modul (OV9655) am STM32F4 Discovery Board

[Uwe B. (derexponent)]

Hallo,

für alle die ein Camera-Modul (mit OV9655 Chip) an Ihrem STM-Discovery 
Board anschließen wollen, findet Ihr auf meiner Seite die passende 
Library dazu
(und ein CooCox Projektordner)

das Modul hängt an einem I2C-Port und die Bilddaten werden per
DCMI-Schnittstelle und DMA verwaltet

im Moment werden die Daten im QVGA-Format (320x240 Pixel) direkt auf ein 
Display ausgegeben (30 Frames/sec bzw. bei mir weniger weil ich nur 
einen 16MHz Quarz angeschlossen habe :-)

der Quellcode basiert auf dem STM-Code für das STM324xG-EVAL-Board

Viel Spass damit
Gruss Uwe

http://mikrocontroller.bplaced.de

[vampire (Gast)]

--ganz große Klasse , deine ganze Website;
(hab mir grad dein Demo fat-pic auf CoIDE 1.5.1 umgeschrieben)
Probier alles nach und nach aus ! --

[Uwe B. (derexponent)]

Danke...sag bescheid falls etwas nicht funktioniert

[vampire (Gast)]

Anfrage:
-Könntest Du dir vorstellen, auf deiner Webseite ebenfalls das 
"Open407V-D" von Waveshare vorzustellen?
Einige User haben dieses Board und wären sicher an einer Portierung 
deiner Projekte darauf interessiert!
Nach und nach könnte ich dazu beitragen, wenn es Dir recht ist --
(anbei einige Bilder eines Projekts als Beispiel)
p.s.:
Mir fehlt die Zeit, eine eigene Website zu pflegen --

[Uwe B. (derexponent)]

@vampire,

Ich benutze meine Seite eigentlich nur zum upload von Treibern für 
verschiedene Module (SD-Karte, Display, Camera usw) das eigentliche 
"Projekt" drumrum muss dann der User schreiben.

Und ich würde nur ungern Code hochladen, den ich nicht vorher getestet 
habe ob er auch funktioniert...und ohne Hardware kann ich nicht testen.

Mein Anspruch sind Files die der Anwender sofort ohne was daran zu 
ändern oder Fehler zu suchen benutzen kann. (sofern er die gleiche HW 
benutzt :-)

Auch wenn Fragen zur Hard- oder Software dazu auftauchen, könnte ich 
dann nicht ASAP helfen.

Sorry, aber ich hoffe du verstehst das

Und dieses Board macht eigentlich nichts anderes als das was ich habe
(vlt. routet es andere CPU-Pins auf die Stecker) aber das anpassen der 
PortPins sollte das kleinste Problem für den User sein

P.S. ist das dein Projekt auf den Bildern ?
(USB-Stick am OTG-Port ... nice :-) ... das steht noch auf meiner ToDo !

Gruss Uwe

[vampire (Gast)]

--alles klar!
- ist das Projekt: Beitrag "ST-Discovery-Net-IO Anfang"

dein SD --> JPG hab ich schon mal auf das Open407V-D portiert;
(rechts die Schöne als *.bmp, links als *.jpg --auf 3,4" SSD 1289);

[Uwe B. (derexponent)]

schön das es funktioniert,
(hattest du probleme beim anpassen ?)

kennst du dich mit dem JPG-Format aus ?

ich frage mich ob es sich lohnt nach einem anderen
JPG-Encoder zu suchen (wegen der Geschwindigkeit)

der Encoder den ich benutze braucht für ein Bild 320x240
von SD-Karte 580ms...was ich etwas langsam finde

P.S. dein Projekt ist ziemlich Umfangreich...respekt
ich werd mir auf jeden Fall deine Sourcen
für die USB und ETH Teil ansehen


Gruss Uwe

[vampire (Gast)]

- die Jungs decodieren jpeg mit "Huffman Decode"-Table;
http://en.pudn.com/downloads263/sourcecode/embed/detail1210390_en.html
-keine Ahnung, ob das schneller ist?!

Uwe B. schrieb:
> P.S. dein Projekt ist ziemlich Umfangreich...respekt
> ich werd mir auf jeden Fall deine Sourcen
> für die USB und ETH Teil ansehen

ETH-Teil läuft ständig und unabhängig (polling ankommender request)-
USB hab' ich mangels Interesse dort(im Artikel) noch garnicht drin!
Das "Offset(Aufsteck-) Teil mit 2xPCF8574 und MAX3232, sowie 
SD-card-slot
ist nur dem Zurechtbiegen sich ausschliessender Pins geschuldet --

Anliegen war eigentlich, verschiedene Programme (Mal-,bewegte Zahnräder, 
Camera-Life, usw.) per Touch auszuwählen --

[vampire (Gast)]

- p.s.:
heute würde ich die ST-GUI-Lib für sowas nehmen!
Beitrag "Re: STM32 GUI Library von ST"

[vampire (Gast)]

-könntest Du mal das *.bin mit ST-Link Utility auf dein Board flashen?
Ich habe dein ursprüngliches Programm ja nur erweitert( paar if LCD-ID 
)auf Open407V-D;
Deshalb müsste dieses File, einmal auf dem F4D geflasht, sowohl für 
SSD1289, als auch für dein Display die selbe Ausgabe(s.oben) haben --

Würd' mich schon interessieren --
Danke !

[Uwe B. (derexponent)]

Die Files werden richtig geladen allerdings
stimmt die Anzeige nicht

ich vermute das Display steht noch im Portrait-Modus
statt im Landscape
beim ST7783 stelle ich das Register 0x0003 auf den Wert 0x1038
(für Landscape) und 0x1030 (für Portrait)

die Pixelposition X=0, Y=0 wird dadurch aber nicht beeinflusst
(die ist in jedem Mode die linke obere Ecke vom Display)

Gruss Uwe

[vampire (Gast)]

ok - danke vielmals für deine Mühe;
-deine Annahme ist richtig. Ich habe für das SSD1289 extra 
DISP_ORIENTATION eingeführt, um die Lage zu korrigieren(steht auf 
0[grad]];
R3 ist hier nicht das "Lageregister"(hat den Wert 0xA8A4)
- aber dies stellt ja kein Problem dar --

[vampire (Gast)]

- ich war nur neugierig, da ich dein Projekt ja neu aufgesetzt habe. Auf 
CoIDE v1.5.1 (will mir die bessren Einstellmöglichkeiten für z.B. 
Linkerscript, aber auch die Möglichkeit, ein .uvproj zu öffnen, 
erhalten)
Du hast ja bereits die v1.7.x;

[vampire (Gast)]

-ich hab hier mal die OV9655 an einem Open407I-C Board mit einem 
5"-Display
Die 320x240 Pixel sehen recht verloren aus, auf dem grossen LCD.
(Cam auf den Monitor gerichtet)
Ist aber nicht zu empfehlen ohne leistungsfähige ext.5Volt(USB reicht 
nicht),
ist auch nicht dein Programm --

[Uwe B. (derexponent)]

Hi vampire,

könntest du mal meine Library zum ansteuern des 320x240 LCD mit SSD1289 
Controller testen ? ... mir fehlt noch eine Rückmeldung ob sie 
funktioniert
(und ich hab kein entsprechendes Display)

wäre super

hier nochmal der Link :

http://mikrocontroller.bplaced.de

Gruss Uwe

[Hola (Gast)]

Wo bekommt man so ein Kameramodul? Ah, gibt's bei Ebay aus China für 8 
Euro.

http://www.ovt.com/products/sensor.php?id=6 :
"
The OV9655 image sensor is a low voltage CMOS sensor that provides the 
full functionality of a single-chip SXGA (1280 x 1024) camera and image 
processor in a small footprint package. The OV9655 provides full-frame, 
sub-sampled, scaled or windowed 8-bit/10-bit images in a wide range of 
formats, controlled through the Serial Camera Control Bus (SCCB) 
interface."

Es ist nicht der Sensor, der für das RaspberryPi board kommt (das wird 
ein
5MP (2592×1944 pixels) Omnivision 5647 mit I2C und CSI bus).

[vampire (Gast)]

@ Uwe B. (derexponent)
-ich würde Dir gern den Gefallen tun, nur habe ich CoIDE v1.5.1 und kann 
dein Projekt nicht öffnen.
Neu aufsetzen ginge, dauert aber zu lange.(umgekehrt, von *.cob --> 
coproj

[vampire (Gast)]

) gehts einfach;
---sorry, vertippt :)

[Uwe B. (derexponent)]

moin,moin,

wird zwar immer mehr Offtopic, aber ist ja mein Thread :-)

ich habe das ganze Projekt hochgeladen und im Unterordner
"tst_43/Debug/bin" ist das Binärfile drinn

das kannst du direkt mit dem ST-Link Utility flashen

aber damit du es einfacher hast hier im Anhang zwei Files
um das Display im Portrait und im Landscape Mode zu testen

es muss jeweils das komplette Display grün werden
und eine rote Linie gezeichnet werden

Portrait -> rote Linie auf der X-Achse (X= die Seite mit 240 Pixel)
Landscape -> rote Linie auf der Y-Achse (Y= die Seite mit 320 Pixel)

Gruss und Danke für die Tests

[vampire (Gast)]

moin, moin !
-auch wenn es den Anschein hat;
-ich bin nicht zu bequem, deine Soft zu testen, nur keines meiner Boards 
passt(völlig andere Pinbelegung)
Das Open407V-D hat ein Offset-Teil, um LAN und SDIO und LCD-FSMC 
gleichzeitig zu betreiben;
das HY-stm32f4xx wird auch für den STM32F103ZG verwendet und hat 
FSMC-NOR Bank4 und andere Änderungen;
kurz:
Ich müsste dein Programm umschreiben, auch auf CoIDE 1.5.1, denn diese 
Version brauche ich, um Linker-file und Compiler-switches zu ändern, was 
bei 1.7.1 nicht so einfach möglich ist;
-Ich kann es nicht testen --
-ausserdem wartet meine "Himbeere"(Raspberry-Pi) darauf, das ich die 
CPU-Last bei XBMC (Media-Center) deutlich vermindere, was mein 
eingerostetes Linux-Wissen arg strapaziert --
Gruß vampire

[Uwe B. (derexponent)]

ahh...Denkfehler von mir...kein Problem , schönes WE noch

[vampire (Gast)]

--Dir ebenfalls!

[Torsten S. (tse)]

Hallo,

k.A. ob das jetzt OT ist. Es geht um Deine SD-lib die hier schon erwähnt 
wurde.

Zuerst mal Danke dafür, funktioniert!

Beim studieren des Quellcodes ist mir allerdings etwas aufgefallen. Und 
zwar in stm32_ub_sdcard.c:

int MMC_disk_read(BYTE *buff, DWORD sector, BYTE count)
{
  int ret_wert=-1;
  SD_Error status = SD_OK;

  SD_ReadMultiBlocks(buff, sector << 9, 512, 1);

  /* Check if the Transfer is finished */
  status =  SD_WaitReadOperation();
  while(SD_GetStatus() != SD_TRANSFER_OK);

  if (status == SD_OK) {
    ret_wert=0;
  }
  else {
    ret_wert=-1;
  }


  return(ret_wert);
}

count wird überhaupt nicht verwendet, d.h. es wird immer nur 1 Block 
gelesen egal welchen Wert count hat. Genauso auch in MMC_disk_write(); 
Meinst Du vielleicht der folgende Codeschnipsel würde auch 
funktionieren?

int MMC_disk_read(BYTE* buff, DWORD sector, BYTE count)
{
  SD_Error status;

  if(count == 0)
    return -1;

  if(count == 1)
    status = SD_ReadBlock((BYTE*)buff, sector << 9, 512);
  else
    status = SD_ReadMultiBlocks((BYTE*)buff, sector << 9, 512, count);

  if(status != SD_OK)
    return -1;

  /* Check if the Transfer is finished */
  status = SD_WaitReadOperation();
  while(SD_GetStatus() != SD_TRANSFER_OK);

  if(status == SD_OK)
    return 0;

  return -1;
}

[Uwe B. (derexponent)]

Hi Torsten S,

lies dir mal die Doku von ChaN durch (die ist als HTML dabei)
da steht unter "disk_read"
...

The disk_read function reads sector(s) from the disk drive.
DRESULT disk_read (
  BYTE pdrv,     /* [IN] Physical drive number */
  BYTE* buff,    /* [OUT] Pointer to the read data buffer */
  DWORD sector,  /* [IN] Start sector number */
  BYTE count     /* [IN] Number of sectros to read */
);

Parameters

pdrv
  Specifies the physical drive number.

buff
  Pointer to the byte array to store the read data. The size of buffer must be in sector size * sector count.

sector
  Specifies the start sector number in logical block address (LBA).

count
  Specifies number of sectors to read. The value can be 1 to 128. Generally, a multiple sector transfer request must not be split into single sector transactions to the device, or you may not get good read performance.

ich vermute also deine Änderung wird keinen Vorteil bringen
aber kannst es ja mal ausprobieren, und hier das Ergebnis posten

Nachtrag....oder hab ich (mit meinem schlechten Englisch) den Text 
falsch verstanden ???

Gruss Uwe

[Torsten S. (tse)]

Uwe

Hab mir die originalen Quelltexte vom STM324xG-EVAL mal reingezogen. Die 
sind neuerdings etwas versteckt auf der Homepage von ST.

Dort wird count sehr wohl ausgewertet in einer ähnlichen Form wie ich es 
vorgeschlagen habe. Sonst macht es ja auch keinen Sinn.

Allerdings ist alles noch viel komplizierter als ich geahnt habe. In 
fatfs_drv.c wird im DMA-Modus darauf geachtet, das die Puffer auch schön 
an DWORD ausgerichtet sind. Wenn nicht, werden die Daten erst aufwendig 
in einen neuen, ausgerichteten Puffer kopiert und dann zur Karte 
geschickt.

Das bedeutet: In der vorliegenden Form ist es Zufall das es 
funktioniert. Am besten DMA deaktivieren und durch Polling ersetzen.

Was mich ärgert ist, das auf einem AVR eine SD-Karte via SPI angebunden 
mit FAT nur gefühlte 1/3 an Codezeilen braucht. Und sehr zuverlässig 
funktioniert. Dieses schicke SDIO beim STM32 hat soviel Overhead das 
einem wirklich die Haare zu Berge stehen.

[Uwe B. (derexponent)]

ich hab den Code auch von dem STM Beispielen und zwar
vom TFTP-Server...da ist eine komplette "diskio.c" enthalten
und an die hab ich mich gehalten
(die übergeben bei disk_read() immer nur eine Sectoranzahl von 1)

also für mich funktioniert das ganze zufriedenstellend,
werd da auch nichts mehr ändern falls kein gober BUG auftaucht

Gruss Uwe

[Torsten S. (tse)]

> ich vermute also deine Änderung wird keinen Vorteil bringen
> aber kannst es ja mal ausprobieren, und hier das Ergebnis posten
>
> Nachtrag....oder hab ich (mit meinem schlechten Englisch) den Text
> falsch verstanden ???

Uwe

Das Du diesen Code überhaupt für alle frei verfügbar gemacht hast ist 
mutig und sehr lobenswert. Nun ist es aber so, das es keine fehlerfreie 
Software gibt. Oder doch - dann zeig mir mal eine. Ich kenne keine ;)

D.h. ich wollte Dich zuerst um Erlaubnis fragen um meine Ergebnisse hier 
zu posten. In einer sachlich/kritischen Form. Es hilft keinem weiter 
alles schön zu reden wenn es nicht so ist.

Torsten

[Uwe B. (derexponent)]

Hallo Torsten,

sorry, wenn du mich falsch verstanden hast.

natürlich gibt es keine fehlerfreie Software
ich habe auf meiner Seite das auch nochmal ausdrücklich geschrieben,
das ich für jeden Hinweis auf einen BUG dankbar bin
(weil ich nicht alles selbst bis zur Unendlichkeit testen kann)

und du kannst natürlich gerne den Code benutzen und ändern
(kann dich ja auch schlecht davon abhalten :-)

aber in meinen Augen ist das eben kein "Fehler" im Sinne von
"wenn man den Code so benutzt kommt es zu einem Fehler"
sondern du machst den Lese Zugriff schneller (vermutlich)

ich bin aber mit der Lese Geschwindigeit zufrieden
(ca. 2,4MByte / sec) also werde ich da wie gesagt nichts ändern

es sein denn durch deinen geänderten Code kommst du auf 24 MByte/sec :-)

aber die Messergebnisse würden mich interresieren, also schreib
hier bitte ob bzw. wieviel schneller der Zugriff mit der Änderung ist.


Gruss und schönen Feiertag
Uwe

[Torsten S. (tse)]

Uwe B. schrieb:
> aber in meinen Augen ist das eben kein "Fehler" im Sinne von
> "wenn man den Code so benutzt kommt es zu einem Fehler"
> sondern du machst den Lese Zugriff schneller (vermutlich)

Hat ne Weile gedauert aber ich wollte sicher gehen.

Es ist so: schreibt man einige Strings auf die Karte funktioniert alles 
wie erwartet. sdio/fatfs drehen Däumchen vor Langeweile.

Gibt man diesen aber ordentlich was zu tun passiert es. Zum Beispiel 
wenn man das oft verwendete Bild in einem Rutsch vom Flash auf die Karte 
schreibt:

const uint16_t pic[76800] =
{
  0x9BA8,0xA3E9,0xAC0A,0xAC2A,0xA3E9,0x9B88,0xA3C8,0xAC0A,
  ... // weitere 9500 Zeilen weggelassen
};


FIL f;
if(f_open(&f, "0:/PIC.DAT", FA_WRITE | FA_CREATE_ALWAYS) == FR_OK)
{
  f_write(&f, &pic, 76800 * 2, 0); // *2 wegen uint16_t
  f_close(&f);
}

 Wenn man die Datei nun zurückliest erkennt man das Sektoren ausgelassen 
werden. Nicht überraschend: Mit dem Debugger kann man sehen das count > 
1 war.

Ein fieser Bug und später schwer zu finden.

> aber die Messergebnisse würden mich interresieren, also schreib
> hier bitte ob bzw. wieviel schneller der Zugriff mit der Änderung ist.

Daran habe ich auch schon gedacht. Man braucht aber ein einheitliches 
Szenario um Ergebnisse vergleichen zu können.

Wichtiger ist das die Daten richtig auf die Karte geschrieben werden.

[Uwe B. (derexponent)]

>Ein fieser Bug und später schwer zu finden.

ok, danke für den Hinweis...muss ich mir ansehen.

ich hab für die Geschwindigkeit-Tests Files in
1k, 10k, 100k, 1M, 10M grösse geschrieben und gelesen
und per Timer die benötigte Zeit gemessen

(allerdings ohne den Mount befehl...der lässt sich zeit :-)

Gruss Uwe

[Uwe B. (derexponent)]

Hi Torsten,

>Schade das Du meinen Bugreport fürs SDIO (Lib 13) noch nicht
>berücksichtigt hast - es sind wirklich nur ne handvoll Zeilen die
>eingepflegt werden müssen um Datenmüll auf der SD-Karte zu vermeiden.


ich hab im Moment nur begrenzte Zeit und teile sie auf mehrere
Baustellen auf...

glaub mir ich werde deine Änderungen (um den BUG zu beseitigen)
noch hinzufügen und testen...Danke vorab schonmal


Gruss

[Uwe B. (derexponent)]

@Torsten nochaml,

-ich hab mir das ganze jetzt nochmal angesehen
und auch ein Testprogramm geschrieben
um das BMP-Bild aus dem Flash (230454 Bytes)
auf die SD-Karte zu schreiben

und was soll ich sagen....meine Library funktioniert :-)
(Filecompare ergibt keinen einzigen Fehler)

aber ich weis jetzt auch warum :

du benutzt die File-Befehle von FATFS direkt

>f_write(&f, &pic, 76800 * 2, 0); // *2 wegen uint16_t

ich habe aber eine Funktion drumrum geschrieben,
die immer nur einen Block von maximal 512 Bytes schreiben kann
(wenn man da größere Werte übergibt, bricht sie mit einer Fehlermeldung 
ab)

>UB_Fatfs_WriteBlock(&myFile,myPointer,512,&anz);

natürlich muss ich diese Funktion in einer Schleife
aufrufen bis das komplette File auf die SD-Karte geschrieben ist

aber so habe ich nie den Fall, das count > 1 wird !!

und der Wert von 512 Byte ist die Puffergrösse die bei FATFS eingestellt 
ist, wenn ich da eine Grössere Zahl eintrage kommt es zu fehlern
(wie bei dir)

ich denke damit sollte alles klar sein, wer die FATFS-Funktionen direkt 
benutzt, muss sich was ausdenken um diesen Fehler den du bemerkt hast zu 
vermeiden. Aber mit meiner Library-Funktion kommt es zu keinem Fehler

wie siehst du das ?

Gruss Uwe

[Torsten S. (tse)]

Das ist eine Einschränkung die der Benutzer wissen sollte.

[Uwe B. (derexponent)]

>Das ist eine Einschränkung die der Benutzer wissen sollte.

ja, da ist richtig
werde einen Text hinzufügen