mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik schnelle Speichererweiterung für ATmega128


Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
für die Entwicklung einer großen (70 RGB LEDs Radius) Propeller Clock 
benötige ich wie sich einiges schon denken können eine Menge Daten.
Für die Ansteuerung möchte ich einen ATmega128 mit 16MHu benutzen, der 
aber allein mit der Ansteuerung der LED Treiber schon zu 86% ausgelastet 
ist. Da die Daten über Hardware SPI übertragen werden, kann ich während 
der Übertragungszeit selbstverständlich auch andere Dinge tun, deshalb 
sind die 86% eher eine Nenngröße...
Da ein Bild eine Größe von ca 86kByte hat, kann ich gerade mal ein Bild 
speichern, was selbstverständlich zu wenig ist. Jetzt bin ich am 
Überlegen wie ich den Speicher erweitern kann. Ich könnte beispielsweise 
den ATmega2560 verbauen, dann hätte ich doppelt so viel, allerdings 
würde auch das nicht reichen, da ich mind 10 Bilder, besser mehr 
speichern wollte.

So... und jetzt kommt die eigentliche Frage: Was könnt ihr mir 
empfehlen?
Habe mir FRam angeschaut, ist aber recht teuer dafür, dass man nur so 
wenig speichern kann...
Wie wäre es mit Flash Eeprom? Da würde Preis und Speichervolumen passen.
Wegen der kurzen Zeit in der die Daten übertragen werden müssen 
(6,9MBit/s) kommt eigentlich nur eine Parallelansteuerung in Frage...
Was habt ihr da für Ideen?

Vielen Dank schonmal

wiedermal der Kai

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
70 RGB LED's?
Wuff.

Bekommt man da nicht so langsam unter anderem Probleme mit der 
Ansteuerung, da ja die äusseren LED's eine dann erheblich grössere 
Fläche als die inneren LED's abdecken?

Und die 86KB jetzt können ja wohl nur FLASH sein?
Dürfte ja relativ langsam zu lesen sein, zumindest als Daten?

Aber Hardware-SPI und nebenbei was machen?
Nicht so wirklich mit den AVR's, wenn der SPI schnell sein soll.
1 Byte jeweils als Sende- und Empfangs-Puffer sind ja eher ein Witz.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>iner großen (70 RGB LEDs Radius) Propeller Clock

Haben wir schon gebaut. 64 RGB Leds. aber GROSS??

>schon zu 86% ausgelaste
Da machst du was falsch.

>bertragungszeit selbstverständlich auch andere Dinge tun
Träumer!

>Bild eine Größe von ca 86kByte hat, kann ich ger
Welche Auflösung hast du?

>6,9MBit/s) kommt eigentlich
Nochmal: TRräumer!

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kritiker (ist nicht böse gemeint)
Ich habe schon eine Propeller Clock mit 72 SMD RGB LEDs und den MAX6957 
am Laufen. Auflösung ist allerdings nur 240 Aktualisierungen/Umdrehung. 
Natürlich drehen sich die äußeren LEDs schneller, als die Inneren, dafür 
habe ich allerdings ein VB Programm geschrieben, das mir das umrechnet.
Bilder/Videos kann ich heute hoffentlich machen und hochladen.
Jetzt zu der großen Propeller Clock.
Ich möchte 70 Stück 10mm RGB LEDs (Treiber wird diesmal TLC5922) nehmen 
und komme damit wohl auf einen Durchmesser von über 1,5 Meter, was man 
durchaus als groß bezeichnen kann. Als Auflösung habe ich mit 440 
Aktualisierungen/Umdrehung gerechnet.
Sicherlich kann man die Zeit während der Übertragung auch beim AVR 
nutzen! Genau das tue ich nämlich bei der Version, die bereits läuft 
denn die Übertragung von einem Byte braucht immerhin 16 Clocks, 
währendessen man einiges machen kann.

Die 86% habe ich folgendermaßen berechnet:
Ein Treiber kann 5 RGB treiben und braucht 112 Bit
mit 70 LEDs und 10U/s komme ich auf 6,9MBit/s was bei einer SPI Frequenz 
von 8MHz durchaus möglich ist. 6,9 / 8  =  86%

Gibt es denn solchen Speicher, den ich etwa in der geforderten 
Geschwindigkeit ansprechen kann?

Grüße
Kai

PS: Ein Bild von der Platine mit den 72 RGB SMDs hab ich schonmal 
angehängt

Autor: Kai Franke (kai-) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
angehängt...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm einen 128k oder 512kByte SRAM (gibts z.B. bei Reichelt billig). Pro 
Byte benötigt ein mega128 4 Takte (mit 1 Waitstate). Viel nebenbei 
machen geht daher nicht, da du zwar nur 5 der 17 Takte was machst, aber 
da noch sinnvoll eine Nebentätigkeit einbauen wird nichts.
Wenn ich richtig gerechnet habe, brauchst du 1568Bits für die 70 LEDs, 
macht 196Bytes, also 3332 Takte bzw. 208,25µs. Mit dem ganzen Overhead 
der noch dabei ist (Interrupt usw.) ganz grob rund 220µs. Theoretisch 
sind also bei 440 Aktualisierungen pro Umdrehung 10,3 Umdrehungen pro 
Sekunde drin (bei 100% Auslastung !)

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mich nicht irre ist SRAM doch flüchtig und fällt daher raus. 
Die verschiedenen Bilder sollen nach Möglichkeit auch bei Power-off 
erhalten bleiben. Wenn das allerdings die geschickteste Möglichkeit ist, 
werde ich das SRAM eben konstant mit Strom versorgen, ist nur ein 
bisschen unschön wegen Batteriewechsel usw.
10U/s sind das, was ich erreichen will, da ich zwei Propeller habe und 
damit auf 20U/s komme.
Eine Nebentätigkeit außer den Reedkontakt abfragen ist nicht geplant.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Kai Franke (kai-)

>10U/s sind das, was ich erreichen will, da ich zwei Propeller habe und
>damit auf 20U/s komme.

???
Es sind immer noch 10U/s, nur eben dann 20 Bilder/s.

>Eine Nebentätigkeit außer den Reedkontakt abfragen ist nicht geplant.

Ich würde lieber einen Hallsensor nehmen. Kostet praktisch auch nix und 
ist schneller und verschleissfrei.

MfG
Falk

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hast Recht, wollte auch 20 Bilder/s schreiben...
Bin noch am überlegen ob ich einen Reedkontakt, Hallsensor oder IR 
Schranke nehme, ist aber auch erst einmal uninteressant.
Wie mach ich das jetzt mit dem Speicher?
Ist Flash Eeprom schnell genug?

@Benedikt: hab versucht deine Rechnung nachzuvollziehen, allerdings weiß 
ich nicht wieso du 196Byte x 17 und nicht x 5 rechnest?
Wenn es tatsächlihc nur 5 Clocks braucht um 1 Byteabzuholen, wär das 
doch ideal!
Dann könnte ich doch über SPI ein Byte rausschicken (dauert 17 Clocks) 
und hole dann während der Übertragung ein neues aus dem SRAM (dauert 5 
Clocks). Dann kann ich wieder senden.
Jetzt müsste man Flash Eeprom nur noch genauso schnell ansteuern können 
und ich wär super glücklich :)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Franke wrote:
> Ist Flash Eeprom schnell genug?

Geht auch. Gibts bei Reichelt auch für wenig Geld. Ich würde die 29Fxxx 
nehmen und nicht die 29Cxxx. Die sind zwar beim Löschen langsamer, 
lassen sich aber Bytweise beschreiben.

> @Benedikt: hab versucht deine Rechnung nachzuvollziehen, allerdings weiß
> ich nicht wieso du 196Byte x 17 und nicht x 5 rechnest?

Du brauchst:
- 4 Takte zum Lesen eines Bytes (aus einem SRAM oder Flash, ab und zu 
noch etwas mehr, da du ja nur 32kByte wirklich per Hardware ansteuern 
kannst, die restlichen Adressleitungen musst du per Software machen)
- 1 Takt zum Schreiben in das SPIDR

Das SPI Interface braucht aber 17 Takte um ein Byte zu senden. Mit 
anderen Worten: Du hast nach jedem Byte 12 Takte Zeit, die du irgendwie 
verbringen musst.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ins FLASH speicherst du deine Bilder in kompimierter Form. Beim PowerUp 
enpackst du diese Bilder ins SRAM. Statt internen FLASH könntest du aber 
auch einen externen SPI FLASH oder sogar eine SD/MMC Karte nehmen.

Deine Auslastung von 89% könnte man noch drastisch reduzieren. Dazu 
musst du aber höchst wahrscheinlich deine Verdrahtung der Shiftregister 
verändern. Du hast sie jetzt wohl als einfache Kaskade verschaltet an 
der die RGB LEDs gemischt verschaltet sind, also RGB von 1. LED dann RGB 
von 2. LED usw. Die bessere Verdrahtung wäre es den Rot-Grün-Blau Kanal 
separat zu kaskadieren. Also für 70 Rot-LEDs eine Kaskade, eine weitere 
für alle Grün und noch eine für Blau. Du hast also dann 3 Daten-eingänge 
für 3 Kaskaden. Statt nun auf einer Datenleitung per SPI die Daten zu 
senden wird per Software auf 3 Datenleitungen in parallel die Daten 
rausgeschoben. Wenn man jetzt noch das Pixelformat der Farbbytes 
entsprechend wählt und einen Port des ATMegas als programmierbaren 
Multiplexer konfiguriert dann hast du eine direkte Hardwarebasierte 
Dekodierung der Farbpixel. Damit kommst du auf einen höheren 
Datendurchsatz pro AVR Takt samt Dekodierung als wenn du das SPI dafür 
benutzt. Bei 64 RGB LEDs und 512 Spalten pro Umdrehung und 64 
darstellbaren Farben, kommst du auf ca. 20% Prozessorlast.

Man benötigt dann pro 1 Datenbit für Rot+Grün+Blau Kaskade exakt 5 AVR 
Takte um aus dem externen SRAM das Pixel zu laden, dekodieren und in die 
3 Kaskaden zu schieben. Das *64 LEDs ergibt 320 AVR Takte in der ISR. 
Diese ISR muß pro Pixelspalte 2 mal aufgerufen werden um effektiv pro 
Pixel mit 64 Farben arbeiten zu können. 640 Takte * 512 Spalten = 327680 
Takte pro Umdrehung, grob gerechnet also 350000 Takte = 21ms = 47 Bilder 
pro Sekunde = 100% CPU Auslastung. 20/47*100% = 42% Auslastung bei 20 
Bilder/sec.

Gruß Hagen

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen vielen Dank!
Du hast mir echt geholfen, ich werde also wohl ein Flash ansteuern und 
das ganze byteweise während der Übertragung auslesen.
Die Übertragung wollte ich wie bei der schon funktionierenden PropClock 
machen.
Ein Reedkontakt (oder ähnliches) gibt ein Signal, woraufhin der 
Controller die benötigte Zeit durch 440 teilt und den OCR1 auf den Wert 
setzt.
Während des Interrupts werden die Treiber angesteuert (so schnell wie 
möglich). Danach springe ich wieder in die main routine und habe Zeit 
(wird nciht viel sein) auf den nächsten Reedkontakt warten.

Na dann.... auf in den Kampf, das Projekt gibts dann hoffentlich bald in 
der Codesammlung :)

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hagen: Das Prinzip klingt wirklich logisch und vielversprechend, 
allerdings wird das auf meiner Platine schlecht umsetzbar sein, da ich 
nur ein Doppellayer machen wollte. Verschiedene Treiber für verschiedene 
Farben würden einen riesigen Routingaufwand auf meheren Layern geben.
Die TLC5922 mögen eben nur SPI.
Verkabelt habe ich sie so, dass ich die Daten und Clock Leitung parallel 
angeschlossen habe und jeder Treiber hat sein eigenes CS
Sollten es mehr LEDs werden, muss ich aber wohl die Darstellung ändern

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieviele Fraben pro Pixel willst du darstellen ?

Gruß Hagen

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit dem Treiber schaffe ich 128 Stufen, also über 2mio Farben und das 
ist hübsch, muss aber nicht sein :P

Autor: Gunni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kai Franke:
Du hast weiter oben geschrieben, das du bereits eine "kleine" version 
geaut hast.
Hast du da mal Bilder von? Würde gerne mal sehen, wie es fertig 
aussieht.
gruß Gunni

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,
mir ist dank Hagens Beitrag eben noch eine Idee gekommen:
Da das daisy-chaining bei diesem Treiber eine zu hohe Verzögerungszeit 
hat, steuer ist jeden Treiber über seinen eigenen CS an. Wäre es nicht 
viel sinnvoller alle SCLK und CS Signale parallel zu schalten und jedem 
seinen eigenen Dateninput geben? Klar müsste ich die SPI dann über 
Software steuern, allerdings könnte ich alle Treiber gleichzeitig und 
viel viel schneller mit Daten versorgen und ich habe genausoviele Pins 
verbraucht.
Dann wäre eventuell auch noch der Anschluss einer SD Karte denkbar, da 
die SPI Schnittstelle wieder frei wäre.

Autor: Kai Franke (kai-) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@gunni: Ein Bild von der Platine habe ich weiter oben schonmal 
angehängt, im Betrieb habe ich noch kein Bild gemacht, weil ich es für 
meine Handy Kamera nicht schnell genug drehen konnte. Sobald ich es 
schaffe, werde ich auch Bilder posten.
Im Anhang hab ich mal den Vorgänger mit nur 20 RGB LEDs und noch keiner 
Entstreckung wegen der Drehung (schon länger her). Das ganze ist in den 
Fahrradspeichen betrieben, deshalb das Loch in der Mitte

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SD Karte kann Probleme geben, außer du verwendest einen externen RAM. 
Das Problem bei der SD Karte ist nämlich, dass diese nur 512Bytes 
ununterbrochen liefern kann, danach muss sie den nächsten Sektor in den 
internen Puffer nachladen. Das geht zwar meist sehr schnell, aber ob das 
schnell genug ist, müsste man ausprobieren.

Was du machen könntest: 8 von den LED Treibern parallel schalten, RD\ an 
den SPI Clock, D0-7 an die 8 Dateneingänge.
Bei jedem Lesen eines Bytes aus dem externen RAM/Flash würden die Bits 
dann automatisch in den LED Treibern landen. Quasi so eine Art Pesudo 
DMA. Damit wären bei 4MHz bis zu 4MByte/s möglich...

Wenn der SRAM groß genug ist, könnte man im Hintergrund an einer anderen 
Stelle in diesem das nächste Bild laden, und dann die Anzeige auf dieses 
umschalten.
So würde die Geschwindigkeit der SD Karte keine Probleme machen, man 
könnte ein richtiges Dateisystem verwenden, und sogar die Bilder als 
24bit BMP Dateien speichern. Die Umwandlung des Formates würde dann beim 
Laden in den RAM passieren.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
externes SRAM brauch ich bei der SD Karte wohl nicht, da ich einen 
mega128 verwenden wollte und der ja schon 4kB hat wenn ich mich nicht 
irre.
Wegen den 512Byte habe ich eine SD Karte auch anfangs ausgeschlossen, 
weil die Schnittstelle bis zum Ende der Übertragung "blockiert" ist.

Das mit dem RD hab ich ehrlich gesagt nicht kapiert, scheint zur 
Speichererweiterung des mega128 zu sein, aber SDRAM kommt wie gesagt 
nicht in Frage, da ich die Bilder auch noch bei Power OFF gespeichert 
haben möchte.
Mit meiner "Idee" könnte ich die Daten allerdings um einiges schneller 
übertragen. Nehmen wir an ich wollte 80 RGBs ansteuern, dafür bräuchte 
ich 16 Treiber. Also wären zwei PORTs für die Datenübertragung 
zuständig.
Der Code könnte zB so aussehen:

unsigned char Bild[ne Menge];

CS = AN;
PORTD = Bild[0];
PORTB = Bild[1];
SCLK = 1;
SCLK = 0;
PORTD = Bild[2];
PORTB = Bild[3];
SCLK = 1;
SCLK = 0;
.
.
.
CS = AUS


damit wär ich bestimmt um einiges schneller als 4MBit/s und hab noch 
genug Zeit das nächste Bild zu holen

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PORTD = Bild[0];

Bist du sicher, dass das so geht??

Du gibst die Bits ja so parallel aus, und nicht, wie beim Empfänger(SPI) 
seriell erwartet wird...

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin mir eigentlich recht sicher, dass das funktionieren sollte, da 
der Empänger ja seine SPI bekommt (über Software SPI mit CS und SCLK)
selbstverständlich müssen die Daten in der richtigen Form vorliegen, der 
Helligkeitswert der ersten roten LED ist somit in dem Array unter dem 
Index
Bild[0], Bild[2],...., Bild[10], Bild[12] immer als MSB gespeichert.
Ein VB Programm bekommt das locker hin

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ok. Da du ja nur darstellen willst, sollte das gehen.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde schon mit externem SRAM arbeiten und SD Karte. 
Normalerweise möchte man in einer einfachen Animation zb. pro Sekunde 1 
Bildwechsel vollziehen, und damit jedes dieser Bilder für zb. 20 
Umdrehungen anzeigen. Also würde man im SRAM den dekodierten Bildpuffer 
und die FAT-/Datei Buffer für die SD Karte ablegen. Während der 
Display-Puffer angezeigt wird wird im Hintergrund von der SD Karte 
gelesen und das neue Bild dekodiert in einen 2. Display-RAM-Puffer. Wenn 
die 1 Sekunde rum ist schaltet man nur zwischen diesen beiden 
Displaypuffern um. Zudem bestehen viele Animationen defakto nur aus 2-3 
Hintergrundbildern und dadrüber dann vereinzelte Sprites=kleinere 
bewegte Objekte. Auch dafür lohnt es sich einen 64-512Kb SRAM 
anzuschließen. Wenn man es geschickt anstellt so kann man also ganz in 
Ruhe von SD Karte die Daten im Hintergrund lesen, dekodieren und in SRAM 
Objekte umwandeln. Im Vordergrund steuert der AVR die LEDs an und 
berechnet die Animationen, eg. bewegt die Sprites. Je mehr SRAM 
vorhanden ist desto besser. Gleiches gilt für Fonts.

Problematischer finde ich den 7Bit/LED Modus der Shiftregister. Denn die 
Dekodierung der Pixeldaten und anschließende Umformung in 7 Bit Packete 
für das 8 Bit SPI kompatibel, halte ich für relativ Zeitaufwändig. Diese 
verbrauchte Prozessorzeit musst du nämlich auch noch berücksichtigen, 
neben der reinen Ansteuerung der Shiftregister. In meinem obigen 
Rechenbeispiel ging ich von anderen Voraussetzungen aus. Dort wird keine 
Softwaredekodierung der Pixeldaten mehr benötigt. Ein Pixel = 8 Bits = 6 
Bit Farbinformation jeweils 2 Bit für RGB. Das lässt sich über das DDR 
Register eines Ports des AVRs quasi als Multiplexer geschaltet, 3* 2 zu 
1, dekodieren. In meiner Rechnung ist also keinerlei Softwaredekodierung 
der Pixeldaten mehr notwendig, ergo: die 47% Auslastung beinhaltet die 
komplette Darstellung einer 64 Farbenbitmap.

Gruß Hagen

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Franke wrote:
> externes SRAM brauch ich bei der SD Karte wohl nicht, da ich einen
> mega128 verwenden wollte und der ja schon 4kB hat wenn ich mich nicht
> irre.

Kai Franke wrote:
> Da ein Bild eine Größe von ca 86kByte hat

Irgendwas passt an deinen Aussagen also nicht....

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Denn die Dekodierung der Pixeldaten und anschließende Umformung in 7 Bit 
>>Packete für das 8 Bit SPI kompatibel, halte ich für relativ >>Zeitaufwändig.

Die Sache ist, dass der Controller ein 7 x 16 = 112 Bit Register hat in 
die ich Daten reinschiebe. Da 112 wieder durch 8 teilbar ist, muss ich 
14 Byte reinschieben um 5 RGBs anzusteuern (ich benutze aus Gründen der 
einfachereren Rountingmöglichkeiten nur 15 Ausgänge)
Um ehrlich zu sein ist mir die Dekodierung um Hintergründe und Fonts usw 
zu unterscheiden ein wenig zu kompliziert, mir reicht es wenn ich 
mehrere Bilder anzeigen kann.

@ Benedikt
Ich hatte es nicht so gedacht, dass gleich ein ganzes Bild ausgelesen 
wird, sondern, dass immer 512Byte in das SRAM geladen werden (über hard 
SPI) und dann über Soft SPI an die Treiber verteilt werden.
Währendessen kommen die nächsten 512Byte von der SD Karte an. Wenn das 
nicht möglich sein sollte lass ich mich auch gerne etwas besseren 
belehren, habe noch nie mit SD Karten gearbeitet

PS: Echt super Unterstützung hier im Forum!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Franke wrote:
> Ich hatte es nicht so gedacht, dass gleich ein ganzes Bild ausgelesen
> wird, sondern, dass immer 512Byte in das SRAM geladen werden (über hard
> SPI) und dann über Soft SPI an die Treiber verteilt werden.
> Währendessen kommen die nächsten 512Byte von der SD Karte an.

Wie bereits gesagt: Gleichzeitig ausgeben und die neuen Daten einlesen 
ist nur schwer möglich.

Das was ich beschrieben habe, ist genau das was Hagen nochmals genauer 
erklärt hat:
Bild von der SD Karte in ein externes RAM laden und die Bits so 
umformen, dass diese optimal ausgegeben werden können.

Für jedes Byte das aus dem externen RAM gelesen wird, erzeugt der AVR 
einen Impuls auf der RD\ Leitung. Diesen kann man auch als Schiebetakt 
für SPI nutzen. Nur so erreicht man wirklich 4MByte/s.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PS: Echt super Unterstützung hier im Forum!

Natürlich. Sind ja hier alles Leute, die den ganzen Tag (auf Arbeit) 
nichts anderes zutun haben, als diese Seite hier zu pollen ;-)

**duck und weg**

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab bei deinem ersten Beitrag wohl das Byte überlesen und es durch Bit 
ersetzt ;)
Das wär wohl wirklich die schnellste Möglichkeit, allerdings muss ich 
mir überlegen ob ich deshalb wirklich noch externes SRAM anschließen 
will oder ob mir die paar MB, die ein externer Flash hat auch reichen

Autor: Kai Franke (kai-) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hab gerade mal ein Testprogramm für den mega8 geschrieben, weil ich 
gerade keinen mega128 da habe, aber vom Timing sollten die ja gleich 
sein...
habe zwei Ports zur Datenübertragung, einen Pin für CS und einen für 
SCLK gewählt und die Datenübertragung von 16mal 112Bit simuliert. Vorher 
den Timer1 resettet und danach den Wert auf dem LCD ausgegeben.
Ergebnis: 1411 Clocks
Wenn ich mich nicht vertan hab, komme ich bei 16MHz dann auf 2,54MByte/s

Nach den 1411 Clock hab ich dann genug Zeit die nächsten 112 x 16 Bit 
aus dem Speicher ins SRAM zu laden

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.