AVR32: 32bit vs 16bit SDRAM Anbindung

Der AVR32 hat doch einen 32-Bit Datenbus oder? Demnach ist der 
theoretische Datendurchsatz dann doppelt so hoch. Wichtig ist aber 
natürlich auch, dass du entsprechend mit den Werten umgehst und nicht 
alles byteweise sondern auch wirklich wort- bzw. langwortweise machst. 
Wenn der Speicher 32Bit breit angebunden ist und du immer nur Bytes 
liest wirds dadurch nicht wirklich schneller. Wenn der Zugriff per DMA 
ist sollte es eigentlich entsprechend gecached werden. Ganz sicher bin 
ich mir da allerdings nicht.

Also der Zugriff des LDC-Controllers auf den Speicher geschiet per DMA, 
der Zugriff des User-Programms direkt halfword-weise, da jedes Pixel 2 
Byte besetzt.

Im Embedded-Journal( 
http://www.ixbat.de//files/admin/projekte/epjournal/EPJ_01_download.pdf 
) steht, dass 320*240 Videos mit 24fps mit nur 30% CPU-Leistung 
abgespielt werden, bei mir werden dazu ca 85-100% benötigt.

Mark P. wrote:
> Also der Zugriff des LDC-Controllers auf den Speicher geschiet per DMA,
> der Zugriff des User-Programms direkt halfword-weise, da jedes Pixel 2
> Byte besetzt.
>
> Im Embedded-Journal(
> http://www.ixbat.de//files/admin/projekte/epjournal/EPJ_01_download.pdf
> ) steht, dass 320*240 Videos mit 24fps mit nur 30% CPU-Leistung
> abgespielt werden, bei mir werden dazu ca 85-100% benötigt.

Wie schnell läuft dein AVR32 denn? Läuft dein Programm aus dem Flash 
oder aus dem RAM?

Mit den Standard-140MHz. Da ist ein Linux drauf - das Programm läuft 
also aus dem RAM, daran wird aber bestimmt micht liegen, da z.b. der 
mplayer (das Programm zum Abspielen von Videos) derselbe ist wie beim 
Grasshopper.

Aha! Du machst das unter Linux, welches Codec hat denn dein Video? Das 
ist ja maßgeblich für die aufzubringende Prozessorleistung.

EDIT: Vergiss es ;) Ich sehe gerade dass du die Videodaten "selber" 
erzeugst. Hm

>Aha! Du machst das unter Linux, welches Codec hat denn dein Video? Das
>ist ja maßgeblich für die aufzubringende Prozessorleistung.

Codec is der interne vom mplayer, den ich nach der Anleitung auf 
avr32linux.org compiliert habe.

>EDIT: Vergiss es ;) Ich sehe gerade dass du die Videodaten "selber"
>erzeugst. Hm

Äh? Nein, ich meinte dass ein normales mp4 Video bei mir fast 100% CPU 
braucht während es aufm Grasshopper schon mit 30% läuft. Selber erzeugen 
kann ich die Daten im Moment nicht, weil ja wie gesagt das Bild total 
verschwommen und verschoben ist.

Dann versuch bitte dein Problem näher zu beschreiben, denn hier kann man 
viel und vor allem auch falsch hereininterpretieren (wie man sieht).

Mark P. wrote:
> Ich hab ein 640*480*16bit LCD am
> NGW100 hängen und bekomm dabei max 18 fps hin, wenn der Speicher ins
> User-memory gemappt ist und in einer endlosschleife mit einer Konstanten
> ständig überschrieben wird.



MPEG4 Videos werden idR mit dem H.264 Codec komprimiert sein. Ich habe 
mir das PDF oben nicht genau angeschaut, da du ja leider keine 
Seitenzahlen angegeben hast. Ist bei der Angabe aus dem PDF (die 24fps 
bei 30% Last) auch mit einem mp4 Codec mit gleicher Bitrate etc. 
angegeben?

Wenn die Videos, die du vergleichst nicht das gleiche Codec, die gleiche 
Bitrate (Audio sowohl Video), etc.. haben, wie willst du die Angaben 
dann vergleichen?

Sorry, die Seite anzugeben wäre wirklich sinnvoll gewesen. Es steht auf 
Steite 16 direkt am Anfang. Ich habe viele verscheidene Videos mit 
verschiedenen Codecs probiert, durchschnittlich 320*240 30fps mit ca 
400-500kb/s -> 90-100% Auslastung, 320*240 15 fps, 250-300kb/s -> 
40-50%. Das ist ein gewaltiger Unterschied zu den 30% bei 24 fps und 
900kbps.

Das Hauptproblem ist aber eben die Tatsache, dass die Kamera nicht 
richtig funktioniert, wenn das LCD angeschlossen ist.

Also auf der Atmel Homepage steht:

MPEG4 software decode - 75 MHz
# 30 fps QVGA (320x240) MPEG-4

MPEG2 software decode (DVD) < 75 MHz
# PAL/NTSC (720x576) decode

Da steht jedoch nicht wie die Auslastung ist. Daher sollte man davon 
ausgehen, dass sie dort bei nahezu 100% ist.

Man muss natürlich auch bedenken, dass mehr Geräte auf dem Datenbus auch 
bedeuten, dass die Datenrate auf alle dort angeschlossenen Geräte 
aufgeteilt wird - auch bei DMA-Zugriff.

>MPEG4 software decode - 75 MHz
># 30 fps QVGA (320x240) MPEG-4

>MPEG2 software decode (DVD) < 75 MHz
># PAL/NTSC (720x576) decode

>Da steht jedoch nicht wie die Auslastung ist. Daher sollte man davon
>ausgehen, dass sie dort bei nahezu 100% ist.

Jaja, aber 100% bei 75MHz. Sowohl Grasshopper als auch NGW100 laufen 
jedoch mit je 140MHz, also fast dem dopelten.

Eben demnach wirds auch nicht 30% sondern wohl eher so 50% sein, 
vorrausgesetzt die Speicher können auch ein doppelt so schnelles Timing 
ab.