Atxmega-Board mit 128KB SRAM

[avr (Gast)]

Hi

Gibt es ein bezahlbares Atxmega-Board mit mindestens 128KB SRAM? Fast 
alle, die ich gefunden habe nutzen SD-RAM, der mir zu langsam ist.

Sowas für den Xmega:
http://www.alvidi.de/shop/product_info.php?info=p28_AVR-Entwicklungsmodul-mit-128-KB-ext--SRAM-und-ATMEGA128A-V2-0.html

[m.n. (Gast)]

avr schrieb:
> die ich gefunden habe nutzen SD-RAM, der mir zu langsam ist.

Wie schnell muß es denn überhaupt sein?
Bei dem angegeben Link wird das RAM sehr diffus "mit 10ns Reaktionszeit" 
beschrieben, was für einen ATmega/ATXmega doch völlig nutzlos ist. Diese 
µCs sind viel zu langsam dafür, in der Zugriffs- und in der 
Verarbeitungszeit :-)

Lustig diskutiert wurde/wird hier 
Beitrag "ARM: kompliziert?", wie man einen AVR 
ersetzen kann. Ein STM32F4 Dicovery-Board sollte bezahlbar sein und hat 
schon 192kB RAM auf dem Chip.

Oder Du strickst Dir selber ein ext. statisches 55ns-RAM an Deine 
Schaltung, was auch immer diese letztlich machen soll.

[avr (Gast)]

m.n. schrieb:
> Wie schnell muß es denn überhaupt sein?

Es geht um Grafikroutinen, die in Assembler geschrieben sind. Da ist der 
Ram der Flaschenhals. Der Rest lässt sich dank Assembler gut optimieren.

[Steffen H. (avrsteffen)]

avr schrieb:
> Es geht um Grafikroutinen, die in Assembler geschrieben sind. Da ist der
> Ram der Flaschenhals. Der Rest lässt sich dank Assembler gut optimieren.

Darf man fragen was du machen willst? Soll das mal ein LCD/TFT 
Controller werden?

Steffen

[avr (Gast)]

Eine Assembler-Grafik-Lib für RGB-Scart. Auf dem Atmega8515 hab ich es 
teilweise schon getestet - allerdings kommt man da bei 25fps auf ~7 
Takte pro Pixel @16Mhz. Das ist mir aber zu langsam. 6 Takte/Pixel 
reichen um ein Bitmap zu kopieren. 8 Takte/Pixel für eine Linie. Da aber 
noch ein bisschen Rechenleistung frei sein soll und noch Funktionen für 
Transparenz dazukommen werden reicht das nicht aus. Auf dem Atxmega hat 
man schon ohne DMA ~14 Takte/pixel @32Mhz.

[m.n. (Gast)]

avr schrieb:
> m.n. schrieb:
>> Wie schnell muß es denn überhaupt sein?
>
> Es geht um Grafikroutinen, die in Assembler geschrieben sind. Da ist der
> Ram der Flaschenhals. Der Rest lässt sich dank Assembler gut optimieren.

Na gut. Keine Antwort ist auch eine Antwort.

[avr (Gast)]

m.n. schrieb:
> Na gut. Keine Antwort ist auch eine Antwort.

Ram = Flaschenhals -> Ram so schnell wie möglich -> 3 Takte / Zugriff.