DMA-Datentransfer OV7670 -> ARM-MCU

[leluno (Gast)]

Ich möchte den 8-bit Datenstrom eines OV7670 per DMA zunächst in den RAM 
eines LPC1768 speichern.

Der DMA soll durch pclk, vsync und href gesteuert werden.

Wenn ich das manual richtig verstanden habe, muss ein 
Software-Burst-Request ausgelößt werden.

D.h. die CPU wertet vsync, href und pclk aus und schreibt dann in 
DMACSoftBreq  1<<9. Der DMA wertet dies dann als Timer0/mach1 und leitet 
den Datentransfer von src nach dest ein.

Ist  das ungefähr zutreffend?

[leluno (Gast)]

ich habe jetzt das Beispiel AN10850 - Memory to IOPin - umgesetzt

Erstes Problem: Mir ist nicht klar, wie das Pin-Register dem 
DMA-Zielregister  DMACCDestAddr zugewiesen wird.

Funktion und Funktionsaufruf in der main:

/* extensions for test DMA to FIOPIN */
int32_t dma_start_m2pin(int32_t ch,
                     void *src,
                     void *dest,
                     DMAC_LL_T *plli,
                     int32_t trans)
{
  int32_t sts = _ERROR;

  /* Verify that the selected channel has been allocated */
  if (dmadrv_dat.alloc_ch [ch] == TRUE)
  {
    /* Setup source and destination and clear LLI */
    dmadrv_dat.pdma->dma_chan [ch].src_addr = (uint32_t) src;
    dmadrv_dat.pdma->dma_chan [ch].dest_addr = (uint32_t) dest;
    //dmadrv_dat.pdma->dma_chan [ch].dest_addr = (uint32_t) 0x2009C054+3;

    dmadrv_dat.pdma->dma_chan [ch].lli = (uint32_t) plli;

    /* Use linked list control word if available */
    if (plli != NULL)
    {
      dmadrv_dat.pdma->dma_chan [ch].control = plli->next_ctrl;
    }
    else
    {
      /* Setup channel configuration */
      dmadrv_dat.pdma->dma_chan [ch].control =
          (DMAC_CHAN_INT_TC_EN |
          DMAC_CHAN_SRC_AUTOINC | DMAC_CHAN_DEST_WIDTH_8 |
          DMAC_CHAN_SRC_WIDTH_8 | DMAC_CHAN_DEST_BURST_1 |
          DMAC_CHAN_SRC_BURST_1 |
          DMAC_CHAN_TRANSFER_SIZE(trans));
    }

    /* Start channel transfer */
    dmadrv_dat.pdma->dma_chan [ch].config_ch =
      (DMAC_CHAN_FLOW_D_P2M | DMAC_CHAN_ENABLE | DMAC_SRC_PERIP(9) );

    sts = _NO_ERROR;
  }

  return sts;
}



...   
/* Use DMA to copy the data  PIN2/2-6 */
  dma_start_m2pin(dmach, (void *)(MEMSTART_U),(void *)(&(LPC_GPIO2->FIOPIN)), NULL, MEMSIZE);
//pin 3/25
//  dma_start_m2pin(dmach, (void *)(MEMSTART_U),(void *)(&(LPC_GPIO3->FIOPIN)), NULL, MEMSIZE);
....

Es wird doch nur der Anfang des Pin-Registers übergeben, woher weiß das 
Programm welcher Pin gemeint ist?


Wie ändere ich die DMACCDestAddr so, dass der von mir gewünschte PIn 
3.25 blinkt?

[leluno (Gast)]

Vielen Dank für die breite Unterstützung. Es werden immer ganze 32-bit 
Register übertragen. Die Auswahl der Pins geschieht über Transfer Width. 
Die LEDs blinken jetzt per DMA.

[leluno (Gast)]

kleine DMA-Fortschritte. Das Programm überträgt den Registerinhalt 
DMA_SRC nach GPIO3-Port und läßt die dort angeschlossenen LEDs blinken. 
Request-Quelle ist Timer1 und LPC_GPDMA->DMACSoftSReq=(1<<9):

void dma_ch0_m2p(void){
    LPC_SC->DMAREQSEL = (1<<1);//i.V.m. DMAC_SRC_PERIP(9)LPC_GPDMACH0->DMACCConfig
    LPC_SC->PCONP |= (1<<29);//Enable clock to DMA controller
    LPC_GPDMA->DMACConfig=DMAC_CTRL_ENABLE;
    LPC_GPDMACH0->DMACCSrcAddr = DMA_SRC;
//   LPC_GPDMACH0->DMACCDestAddr = DMA_DST;
   LPC_GPDMACH0->DMACCDestAddr = &(LPC_GPIO3->FIOPIN);
    LPC_GPDMACH0->DMACCControl =   \
    (DMAC_CHAN_INT_TC_EN |
      DMAC_CHAN_SRC_AUTOINC | DMAC_CHAN_DEST_WIDTH_32 |
    DMAC_CHAN_SRC_WIDTH_32 | DMAC_CHAN_DEST_BURST_1 |
    DMAC_CHAN_SRC_BURST_1 |
    DMAC_CHAN_TRANSFER_SIZE(DMA_SIZE/4));
    LPC_GPDMACH0->DMACCConfig |= \
      (DMAC_CHAN_FLOW_D_P2M | DMAC_CHAN_ENABLE | DMAC_SRC_PERIP(9) );
}

Als nächstes wird ein Eingangsport mittels DMA in den Ram eingelesen.

[Dirk K. (dekoepi)]

Danke für die Dokumentation deiner Fortschritte. Auch, wenn keiner 
antwortet: Andere sind grade an ähnlicher Stelle oder sind es in einem 
Jahr, da kann das immer noch hilfreich sein :)

Ich habe mich gestern endlich dazu durchgerungen, die Non-FIFO-Kamera an 
den STM32F103 anzuschließen. Das Verkabeln alleine hat länger als eine 
Viertelstunde gedauert. Jetzt muss ich mich nur aufraffen, I2C zu 
basteln, XCLK auf PA8 mit Takt versorgen, ... das dürfte noch ein paar 
Tage dauern bei mir. Ganz am Ende steht dann auch die Idee, die Daten 
per DMA umzuschieben.

[leluno (Gast)]

Dirk K. schrieb:
> Auch, wenn keiner
> antwortet

Danke für die aufmunternden Worte. ich befinde mich wohl in der 
LPC-Diaspora. Beim Stichwort STM-DSM wird erhält man sicher mehr 
Unterstützung. Wahrscheinlich auch beim Stichwort DSM-Bascom - aus 
Neugier, Schadenfreude oder Mitleid.

LPCs hat kaum jemand. Dass es DMA gibt, habe ich vor einer Woche nicht 
gewusst. LPC-Anwender mit DMA-Kenntnissen sind wohl sehr selten.

Im Prinzip ist es für die Aufgabebstellung OV7670 aber egal, ob man mit 
LPC oder Stm arbeitet. Gleicher Arm-Kern und ähnliche Eclipse-Ide. Ich 
habe hier noch ein StmF103-board rumliegen, an welches ich mich bislang 
nicht herangetraut habe, einfach weil ich mit LPC sehr zufrieden bin. 
Vielleicht löte ich dafür aber jetzt den Anschluss an eine 
2o-Pin-Streifenrasterplatine zusammen, dann kann die Cam auch an dieses 
board.

Jedenfalls lese ich ideinen thread immer mit. Ich denke, wir können uns 
bei der Umsetzung der OV7670 Aufgabe gegenseitig unterstützen, da wir 
beide das Problem der Umsetzung des parallelen Dateneingangs auf seriell 
haben.

[leluno (Gast)]

Ein kleiner Teilerfolg, das erste brauchbare Foto auf dem Display- noch 
auf dem Atmega1284.

Der code ist soweit optimiert, dass mit einem Prescaler 17 (->knapp 
1Mhz) alle Pixel gelesen werden können:

#if fifo==0
//++++==================================================
void get_picture(u8 teilbild){
u16 zl_row=0,zl_offset,gw_offset;
u8 n,i,offset;
u32 index,zl_pix=0;

lgw(1,1,"xxx ");
zl_row=15;

if(!vsync){while(!vsync);}
zl_pix=12799;
zl_row=0;
while(vsync);
//lw("1");


while(zl_row<20*teilbild){
while(!href);//Warten auf href_h
while(href);
zl_row++;
}



zl_row=20;
//start frame
while(zl_row){
while(!href);//Warten auf href_h
while(href){;
// +++ px ++++
  while(!pclk);
    buffer[zl_pix]=PINA;
    zl_pix--;
  while(pclk);
}//zl_row
zl_row--;
}//end frame



lgi(19,16,zl_row);lw("/");li(zl_pix+1);lw("/");li(ov_prescaler);
//alle Pixel erkannt:153600pix
if (zl_pix<153600 && ov_prescaler<32){
//ov_prescaler++;
// CLKRC register: Prescaler = 0-31 15

//n = wr_OV7670(0x11, (registerValue & 0b11000000) | ov_prescaler);
}
//wait;


//Bild malen:
//  for(i=0;i<max_y;i++){

  lcd_setcursor(0,20*teilbild);
  lcd_write_index(0x0022);
   cs_lcd_off;
  LCD_Write_Data_Start();


//  240x320x2=153600 bytes
u16 tmp;
  for( index = 12799; index < 12800; index-=2 )  {
    lcd_write_data_only((buffer[index]<<8)+buffer[index-1]);
  }
cs_lcd_on;
}//end sub
//----===================================================
#else

[leluno (Gast)]

Der spi-Durchbruch:

zl_row=240;
//start frame
while(zl_row){
while(!href);//Warten auf href_h
while(href){;
// +++ px ++++
  while(!pclk);

//    buffer[zl_pix]=PINA;
//    zl_pix--;

SPDR=PINA;
//while(!(SPSR & (1<<SPIF)));
  
  while(pclk);
}//zl_row
zl_row--;
}//end frame

statt in den buffer zu schreiben, wird das spi-tft direkt beschrieben. 
Das TFT ist im Prinzip ein Speicher mit 240x320x2=153.600byte. Statt des 
TFTs könnte man sicher auch andere spi-speicher nehmen.

Die Geschwindigkeit geht jetzt beim 16Mhz-Atmega hoch bis prescaler-12 
(ca. 1,5Mhz)

[leluno (Gast)]

das Programm ließ sich relativ einfach vom avr auf den arm übertragen. 
Auch der arm liefert inzwischen ein brauchbares Bild.

Überaschende Erkenntnis: Die Verarbeitungsgeschwindigkeit ist beim 
100Mhz-Arm nur halb so groß, wie beim AVR. Unter Prescaler 32 liefert 
der Arm kein brauchbares Bild.

Kann es sein, dass die Verarbeitungsgeschwindigkeit des AVR-Spi/Spi-Takt 
8Mhz größer ist als beim  Arm-SSP/Takt 25Mhz?

[Dirk K. (dekoepi)]

Auf meinen stm32f0/1 ist SPI zwar eine Zicke, ich bin jedoch schneller 
als auf dem AVR (ATmega328p). Mit 18 MHz SPI erreiche ich im Polling von 
der Kamera mit umschalten und neu-adressieren sauber etwa 500 kByte/s.

Das DMA-Initial-Setup compiliert ohne Fehler, jetzt muss ich 'nur noch' 
den Transfer darauf umstellen. Sehe noch nicht, wie das klappen soll, 
dass der DMA auf PCLK wartet, um das nächste Byte zu übertragen. Aber 
kommt langes Wochenende, kommt Rat ;-)

[leluno (Gast)]

Dirk K. schrieb:
> Warten auf PCLK

Meine Überlegung dazu:
pixelweise in einen fifo-buffer schreiben lassen, wenn 512 byte 
geschrieben sind, durch einen software-single-request die 
DMA-Übertragung auslößen...

[leluno (Gast)]

Als Problem beim Speichern auf sd-Karte stellte sich heraus, dass eine 
gleichzeitige Steuerung des Pixelinputs und des Fat-Überbaus 
erforderlich ist. Ich wollte den Pixelinput über Interrupt steuern, das 
verlangsamt aber das Programm. Zwischenzeitlich durfte ich beim 
Hauptzollamt das AL422-Fifo-Modul abholen.

Das Fifo-Modul läuft inzwischen auf dem Atmega. Der Fifo ist eher 
schwieriger zu programmieren, da die Rücksetzung des Speichers nicht 
ganz einfach ist. Das Modul läuft mit Prescaler 30=>400khz sehr stabil. 
Der Datentransfer erfolgt zur Zeit aber noch innerhalb des vsync-Zyclus, 
so dass im Prinzip nur eine Zeile im Fifo zwischengespeichert wird. Das 
hat den Vorteil, dass der Code zukünftig für ein Mt9d112-Modul genutzt 
werden kann.

[leluno (Gast)]

Der Durchbruch mit dem Fifo-Modul:

Das Schreiben in den Fifo wird über einen vsync-Interrupt beendet. 
Dadurch entfällt die Überwachung der Zeilen beim Lesen des Fifos. Die 
write-Geschwindigkeit darf so hoch sein, dass zum Zeitpunkt vsync 50% 
des Bildes gelesen sind - der Rest passt in den Fifo. Sie muss höher als 
die Lesegeschwindigkeit sein.

Nach Umsetzung im Programm schafft der AVR wahrscheinlich auch das 
Schreiben eines vollständigen Bildes in eine sd-Karte. Die bekommt er 
als nächsten Schritt verpasst.

Durch das parallele Arbeiten mit AVR und ARM ist darüberhinaus ein für 
beide Systeme einsetzbarer Code entstanden.

[Grundschüler (Gast)]

Das Programm schreibt jetzt QVGA auf die sd-karte. Die Bitmap-Datei wird 
nach dem Schreiben geöffnet und in das Lcd eingelesen.

Beim Wechsel auf VGA kommt es zu unerklärlichen Problemen. Dies auch bei 
einem Format von 640x120 was eigentlich programmtechnisch keinen 
Unterschied  zu 320x240 machen dürfte. Die Bilder werden zerstückelt.

[Dirk K. (dekoepi)]

Püh, habe ich nicht alleine Probleme mit dem 640x480-Modus - beruhigt 
mich zumindest etwas.

Gestern kam meine OV5642 an. Werde wohl die RAM-Bank und die olle OV7670 
auf Halde für seeeehr gelangweilte Tage legen und mich langsam mit 
SD-Karte auseinandersetzen. Da soll das fertige JPEG aus der Kamera 
direkt hin.

Nicht die optimale Lösung, aber die OV7670 raubt mir irgendwie nur die 
Nerven ;)

[Grundschüler (Gast)]

Dirk K. schrieb:
> 640x480-Modus

Der ov7670 ist nicht das Problem. Mit

#if H_PX==320
#define ovregCOM7 0b00010100 //QVGA
#else
#define ovregCOM7 0b00000100//VGA
#endif

kann man zwischen den Formaten schalten.
Es werden rund 420 Zeilen auf dem Lcd einwandfrei angezeigt(jedes 
2.Pixel jede 2.Zeile).

Das Problem ist der AL422, der mit meinem code nicht wirklich 
zwischenspeichert. Laut Datenblatt braucht er durchgehenden Schreibe- 
und Lesetakt von >1Mhz. Das passt mit meinem Code bislang nicht.

[Dirk K. (dekoepi)]

Ach siehste, OV7670 mit AL422B habe ich ja auch noch rumfliegen. Der 
nächste graue Herbst/Winter kommt bestimmt ... ;)

Kannst du die CLKs für R/W nicht einfach via XCLK abgreifen?

[Grundschüler (Gast)]

Dirk K. schrieb:
> XCLK

das habe ich gerade gemacht - wck mit pck verbunden. Das Problem ist 
dass ich jetzt den schnellen Modul-Takt überwachen muss, während ich 
bislang die Lesegeschwindigkeit auf die SD-Karte/lcd angepasst hatte. 
Wenn ich deine relativ schnellen Speichermodule hätte, wäre ich schon 
fertig. Hauptproblem ist die langsame Geschwindigkeit der sd-karte.

[Grundschüler (Gast)]

Grundschüler schrieb:
> pck

muss rck heißen

[Dirk K. (dekoepi)]

Der FIFO soll doch deshalb von Vorteil sein, weil du dir die Bytes 
raustaktest, wie es grade passt? Also FIFO-PCK togglen, Byte lesen. Der 
Speichertakt ist doch nur RAM Refresh und hat mit der 
Ausgabegeschwindigkeit nichts zu tun?
Missverstehe ich am FIFO etwas?

[Grundschüler (Gast)]

Dirk K. schrieb:
> Missverstehe ich am FIFO etwas?

Ich fürchte leider ja. Mein bisheriger code beruhte auf genau dieser 
Annahme. Das funktioniert auch, solange man direkt nach dem Schreiben 
liest.

zl_hrref =300;
while(zl_hrref);//Zeilen Vorlauf
al422_writeStop();
al422_readStart_cyc();
müsste eigentlich 300 Zeilen in den Fifo laden und dann mit dem Lesen 
beginnen. Ein brauchbares Bild bekomme ich aber nur, wenn der Vorlauf 
zl_hrref sehr klein ist. D.h. es werden nur wenige Zeilen 
zwischengespeichert. Es reicht, um QVGA-Bild auf sd-Karte zu speichern, 
mehr nicht.

==>Der Beitrag scheint Spam zu enthalten: "hrref="

[Dirk K. (dekoepi)]

Ich würde mich hierdran orientieren - das funktioniert ja offenbar ;)
http://www.haoyuelectronics.com/Attachment/OV7670%20+%20AL422B(FIFO)%20Camera%20Module(V2.0)/OV7670%20+%20AL422B(FIFO)%20Camera%20Module(V2.0)%20Schematic.pdf

Die RCK steuerst du dann anstatt PCK, hatte ich oben falsch. Der AL422B 
nimmt sich ja den höheren Takt von WCK/RCK, sodass WCK über den 
OV7670-PCK ausreichend versorgt ist. Zumindest als Idee vielleicht mal 
probieren.

[Grundschüler (Gast)]

Stillleben mit morgendlicher Kaffeetasse im 640x480 Format. Nicht 
wirklich befriedigend, denn es erfolgt eine Zerlegung in drei 
Teilbilder:

#define lcd0_sd1 1

   void get_picture(){//
   u32 n,i,j,offset=0, timespan,ii,zl_tbild;
   u32 index,zl_pix=0,zl_pix8=0,zl_pixx,restzeit=0;
   //zl_px=153600;//2x240x320
   extern_int_hr_ef_init();
   extern_int_hr_ef_enable();
   //++
 //lcd_streamwrite_start();
 #if (!lcd0_sd1)//{
 lcd_streamwrite_start(0);
 #else//}else{
 f_write_Bmpheader(H_PX,V_ZL*3);
 //SysTick->CTRL &= ~NVIC_SYSTICK_ENABLE;
  #endif//}//
// TimeTick=0;
   //1. rücksetzen///////////////

 zl_tbild=0;
 for(zl_tbild=0;zl_tbild<3;zl_tbild++){//3 teilbilder

 al422_writeReset();

   while(!(vsync));while(vsync);

   if(zl_tbild>0){
 zl_hr_ef=160*zl_tbild;
 while(zl_hr_ef);
  }
   al422_writeStart();

 // zlsum_hr_ef=0;
zl_hr_ef=1;
 while(zl_hr_ef);



  led1_on;
fifo_wren_high;
//al422_writeStop();
  // while(!vsync);
 zl_hr_ef=1;
 while(zl_hr_ef);


 al422_readStart_cyc();
   /////////////// read schleife ///////////////
 for(i=0;i<(V_ZL/ZEILEN);i++){
          zl_px=BLOCK;
           zl_hr_ef=ZEILEN;
           while(zl_px){//buffer-modus
           al422_readData_cyc();
           buf_fifo[BLOCK-zl_px]=Value_Datenbus;
           //buf_fifo[BLOCK-zl_px]=RED;//Value_Datenbus;
         zl_px--;
         //zl_px--;
           }//zl_px

 #if (!lcd0_sd1)//{
           if(H_PX==640){
    lcd_streamwrite_px4(buf_fifo,BLOCK);
           }else{
    lcd_streamwrite_px(buf_fifo,BLOCK);
           }
    #else//}else{
     f_write(&Fil, buf_fifo, BLOCK, &bw);
 #endif//}//
 //         lcd_streamwrite_px(buf_fifo,BLOCK);//22-3-394122
  //             DMA_transfer_SSP0x(0);//lcd tested ok

 //           restzeit=0;
 //          while(zl_hr_ef)restzeit++;//Anpassung Geschwindigkeit cmos
 }//for
 }//zl_tbild

 //fifo_wren_high;//ende write
 // fifo_rden_high;
 al422_writeStop();
 al422_readStop();

 #if (!lcd0_sd1)//{
 lcd_streamwrite_stop();
 lgw(20,5,"LCD");li(restpixel);lw("-");li(zl_Bild);
 lcd_pixel(120,120,YELLOW);
 lcd_pixel(121,121,YELLOW);
 lcd_pixel(122,122,YELLOW);
 lcd_pixel(123,123,YELLOW);
 #else//}else{
   f_close(&Fil);
   wait;

   bmp_to_lcd(0);
   lgw(20,5,"SD ");li(restpixel);lw("-");li(zl_Bild);
   wait;
   wait;
   wait;
   wait;
   wait;
 #endif//}//
   wait;

   }//end sub get_picture

Problem bleibt der AL422 Fifo. Er scheint seinen Speicherinhalt zu 
verlieren, wenn nicht unmittelbar nach dem Schreiben gelesen wird. Fifo 
vollschreiben und dann in Ruhe lesen geht nicht. Laut Datenblatt sollen 
beide  Taktzyklen kontinuierlich mindestens 1MHZ betragen. Bei 1MHz 
W-Clock werden die Bilder jedoch zerstückelt.

Auch der Versuch, W+R-Clock zu verbinden und den Fifo mittels 
RClock-Interrupt auszulesen war nicht erfolgreich. Der Fifo funktioniert 
nicht wie er soll und ich weiß nicht wirklich woran es liegt.

Immerhin klappt das Speichern auf SD-Karte mit den Teilbildern recht 
ordentlich. Ich werde jetzt erst einmal versuchen, das Programm in einen 
Webserver zu integrieren.