Hallo Forum, Die 4kb meines 664 werden zu knapp, und ich möchte externen Ram von mindestens 64kB (so das Adressen nich größer als 16bit). Hintergrund ist, das ich viele tausend 8bit/10bit ADC Samples, bzw Messergebnisse Buffern will, bald mit Mhz Samplerate. Was ist dann der beste Durchsatz, den ich mit externen Rambaustein realisieren kann? Welchen Typ Ram sollte ich bestenfalls nehmen, welche Features gibt es, sollte er haben für besten Durchsatz? Gibt es so Dinge wie Burstmode, wo je Clock ein Byte ausgegeben oder geschrieben wird, mit Autoinkrement? Oder gäbge es Chips die ein doppeltes R/W-Interface haben, also auf die ein Schreiber und ein Leser gleichzeitig (an verschiedenen Adressen) zugreifen kann? Ich würde evtl meinen pipeline ADC (max 60Mhz, würde ihn gerne auf 1Mhz sampeln lassen) mit parallelinterfacfe dann direkt auf den externen Ram schreiben lassen, und von AVR (20Mhz) lesen lassen, paralleler (inkrementeller) Lesezugriff wäre dann fein (Möglichkeit A), oder ich lagere alles andere an Variablen bis auf Stack auf extern (Dann wäre schneller Random Access gut), um den internen Ram für die Berechnungen auf den Samples zu benutzen (Möglichkeit B). Da vermutlich pipelined Sachen mit inkrementellen Zugriff schneller sind wohl eher A. Empfehlungen für bestimmte Typen nehme ich natürlich auch gerne an. Ich kenne bisher nur die einfachen Rams ohne interne Adressschaltwerke.
Gast
#900788
>wo je Clock ein Byte ausgegeben oder >geschrieben wird, mit Autoinkrement? Ja, es gibt (Assembler)Befehle mit autoincrement/dekrement. >Was ist dann der beste Durchsatz Besagte Befehle können eine Speicherzelle (Byte) beschreiben (benötigen mW. 2 Prozessor=Quartztakte) >mit parallelinterfacfe dann direkt auf den externen Ram >schreiben lassen Weiß nicht genau was du meinst, aber du könntest eine kleine Hardware bauen, die so konstruiert ist, dass der parallele Lesevorgang aus dem ADC gleichzeitig ein Schreibvorgang in den RAM ist. Musst dir nur Gedanken über die Adressen machen... >einfachen Rams ohne interne Adressschaltwerke. ??
Moritz, >>Gibt es so Dinge wie Burstmode, wo je Clock ein Byte ausgegeben oder >>geschrieben wird, mit Autoinkrement? Erstaunlicherweise gibt es GENAU DIE Modi, die im Datenblatt genannt werden. Das Datenblatt ist kostenlos und sofort und ohne Ansehen von Rasse, Alter, Geschlecht verfügbar. Du weisst aber schon was ein Datenblatt ist? >>Oder gäbge es Chips die ein doppeltes R/W-Interface haben, >>also auf die ein Schreiber und ein Leser gleichzeitig (an verschiedenen >>Adressen) zugreifen kann? Schau mal hier: http://de.wikipedia.org/wiki/Dual-Port-RAM Schau mal auf der Website von Ulrich Radig, der hat solche Dinger aus alten Motherboards mal für eine GraKa verwendet (glaube ich), zwar eine andere Applikation, aber gleiche Funktionsweise. Jochen Müller
Matthias Lipinsky wrote: > Ja, es gibt (Assembler)Befehle mit autoincrement/dekrement. Ich verstehe nicht ganz was du meinst, es geht doch um externes Ram, das der Assembler LD/ST Autoinkrement hat ist mir bewusst, aber sowas bräuchte ich ja als Externes Analogon. Also Implizites Autoinkrement, ohne das man die Adresse zuvor (neu) anlegen muss. > > Besagte Befehle können eine Speicherzelle (Byte) beschreiben (benötigen > mW. 2 Prozessor=Quartztakte) Das gilt für internes Ram, mit Autoinkrement müsste ein Externer aber pro Clock ein Byte schreiben können oder nicht? Ich brauch ja schoin mehrere ASM Befehle (=mehrere AVR Clocks) im AVR, um Bytes von Intern an den Port zu legen. > > Weiß nicht genau was du meinst, aber du könntest eine kleine Hardware > bauen, die so konstruiert ist, dass der parallele Lesevorgang aus dem > ADC gleichzeitig ein Schreibvorgang in den RAM ist. Musst dir nur > Gedanken über die Adressen machen... Wenn der Chip nicht explizit Parallelen Zugriff gestattet, wie soll das gehen? Ich müsste die Zugriffe dann in der HW irgendwie serialisieren. > > >>einfachen Rams ohne interne Adressschaltwerke. > > ?? Ich meine damit vermutllich was als statische Rams bezeichnet wird: Adresse anlegen, und ein statisches Logiknetzwerk wirft das Byte raus, ohne das intern ein Schalt*Werk* (also mit internen Zustandsspeichern) zugange ist. Ich suche dann vermutlich Spielarten von dynamischen Rams, da gibts ja einige.
Jochen Müller wrote: > Erstaunlicherweise gibt es GENAU DIE Modi, die im Datenblatt genannt > werden. Das Datenblatt ist kostenlos und sofort und ohne Ansehen von > Rasse, Alter, Geschlecht verfügbar. > Du weisst aber schon was ein Datenblatt ist? > Ich beziehe mich im ganzen Post auf externe Rams, wie der AVR bzw dessen Ram funktioniert ist mir bekannt. Da ich noch keinen Kandidaten habe, dessen Funktionsweise ich aus dem Datenblatt ersehen kann hilft diese Information ja wenig, es sei denn ich würde eine Liste von Bauteilbezeichnungen unterschiedlicher RAMS bekommen, von denen ich mir dann die Datenblätter saugen und vergleichen kann, was auch nicht so verkehrt wäre wenn ichs mir recht überlege :).
> Schau mal hier: http://de.wikipedia.org/wiki/Dual-Port-RAM > Schau mal auf der Website von Ulrich Radig, der hat solche Dinger aus > alten Motherboards mal für eine GraKa verwendet (glaube ich), zwar eine > andere Applikation, aber gleiche Funktionsweise. > > Jochen Müller Danke für das Stichwort, das war was ich meinte, die scheinen aber teuer und rar zu sein, vielleicht baut man es sich doch per HW selber...
Teuer nicht, aber rar schon, weil nicht mehr hergestellt. Jedenfalls in der von Radig erwähnten Video-RAM Version. Segor hat noch solche VRAMs, in 64Kx4 und 256Kx4 Versionen. Damit sind Abtastraten bis zu 40Ms/s möglich. Allerdings nur was das RAM angeht, der AVR kommt natürlich nicht annähernd damit hinterher, die so schnell gespeicherten Daten wieder aus dem RAM rauszufischen. Es sollte möglich sein, mit max. etwa 2MB/sec auszulesen.
Gast
#900810
>Ich verstehe nicht ganz was du meinst, es geht doch um externes Ram, das >der Assembler LD/ST Autoinkrement hat ist mir bewusst, aber sowas >bräuchte ich ja als Externes Analogon. Also Implizites Autoinkrement, >ohne das man die Adresse zuvor (neu) anlegen muss. >Das gilt für internes Ram, mit Autoinkrement müsste ein Externer aber >pro Clock ein Byte schreiben können oder nicht? Ich brauch ja schoin >mehrere ASM Befehle (=mehrere AVR Clocks) im AVR, um Bytes von Intern an >den Port zu legen. Würd ich nicht sagen. LD/ST mit Auto Inc/Dec tut WÄHREND der Ausführung des Befehls: Die Adresse inc/dec, an den Adressausgang geben und das ensprechende Datum lesen/schreiben. Alles innerhalb zweier Taktzyklen. Der externe ist meines wissens (ohne waitstates) so schnell. (der interne glaub nur ein takt) Wozu soll der RAM eine Adresse zählen, wenn du die explizit anlegst? >ch meine damit vermutllich was Ja, das ist klassischer SRAM. PS: guck dir mal den AT45DB642 an. der hat nen Paralleleingang, ohne Adressenangabe. Incrementiert intern hoch.. Aber den reizt du NIE mit dem Atmel aus..
Du kannst dir übrigens auch mal die Xmegas ansehen. DMA und ggf. Event-Konzept könnten für dich interessant sein.
Gast
#900878
Hab ich was verpasst? Dual-Port-RAMs aus Caches von alten Mainboards? Das sind schnelle asynchrone SRAMs, mehr nicht. Dann habe ich auch noch irgendwie im Hinterkopf das Zugriffe auf den externen Speicher mindestens 2 Takte brauchen. Die Idee mit dem Dualport-RAM würde z.B. Sinn machen wenn man den Transfer vom Wandler in den Speicher von einem CPLD/FPGA machen läßt und parallel mit einem Controller die Daten lesen möchte. Wenn es nur der Controller sein soll ist das schon angesprochene DMA eine Variante oder einfach ein möglichst schneller Controller. Jens
Jens wrote:
> Hab ich was verpasst?
Nö, Jochen hat da nur Mist erzählt.
Er hat wohl die Beschreibung der Grafikkarte von Radig wo er mittels
abwechselndem Lese/Schreibzugriff einen Quasi Dualport RAM schafft mit
echten Dualport (VRAMs) verwechselt.
Gast
#900943
Ich wuerd ein FPGA nehmen und dem das RAM beibringen. Den AVR nur dazu verwenden, um die Modi umzuschalten.
Gast
#901010
> Oder gäbge es Chips die ein > doppeltes R/W-Interface haben, also auf die ein Schreiber und ein Leser > gleichzeitig (an verschiedenen Adressen) zugreifen kann? Es gibt Microcontroller (z.B M16C) die haben eine oder mehrere DMAs eingebaut. Da geht sowas alleine im Hintergrund waehrend der Prozessor was anderes macht. > Die Idee mit dem Dualport-RAM würde z.B. Sinn machen wenn man den > Transfer vom Wandler in den Speicher von einem CPLD/FPGA machen Eigentlich nicht. Dualport-Ram ist ziemlich exotisch und sehr teuer. Es ist dann besser wenn man ein sehr schnelles Ram nimmt und der FPGA das simuliert. Und wenn es noch schneller sein muss dann koennte man ja auch zwei Rams parallel am FPGA betreiben und die Zugriffe verteilen, bzw. 16Bit auf einmal schreiben. Genug Beine haben die Teile ja. Olaf
Olaf wrote: > Es gibt Microcontroller (z.B M16C) die haben eine oder mehrere DMAs > eingebaut. Da geht sowas alleine im Hintergrund waehrend der Prozessor > was anderes macht. Nicht ganz: Beim M16C wird die CPU angehalten, während per DMA Daten übertragen werden. dsPICs haben dagegen einen echten Dualport SRAM (zumindest 1-2kByte davon) mit dem wirklich im Hintergrund per DMA Daten übertragen werden.
Danke euch für die vielen Antworten, Also Fazit, Dualport brauche ich nicht, weil AVR eh zulangsam. 2MB/s sind toll, muss mal gleich nachrechnen obs hinhaut. Weitere Unklarheiten: @Matthias Lipinsky "Würd ich nicht sagen. LD/ST mit Auto Inc/Dec tut WÄHREND der Ausführung des Befehls: Die Adresse inc/dec, an den Adressausgang geben und das ensprechende Datum lesen/schreiben" Meinst du das im Zusammenhang mit integrierten Schnittstellen für externes RAM, wie sie wohl auf anderen/größeren Kontrollern zu finden sind? Der 644 hat sowas nicht, ich muss ein LD vom ExtRam also per Software wrappen: .macro _LD ;@0: Dest.Adr IntRam, @1:lowbyte der SpeicherAdr für ExtRam ldi r20, @1 out PortA, r20 (für max speed sei das obere adressbyte als kontant angenommen, muss dann nicht gesetzt werden, spart takte) (in HW vielleicht ein ReadClock erzeugen, spart 2 takte) (Waitstate? Digital IO Synchlatch (1.5 AVR clocks soweit ich mich entsinne) nop nop in r20, PortD sts @0, r20 .endmacro ich komme hier also bestenfalls auf 7 clocks, wobei vermutlich noch 2-3 nops mehr für Waitstate rein müssen. wäre dann ~2 MB/s schöner fände ich es so: ;ExtRamadresse wurde gesetzt in r20, PORTD ;AVR-CPU Clock wird nach außen geführt, und erzeugt synchronen Readclock, ExtRAM autoinkrementiert, st Y+, r20 in r20, PORTD st Y+, r20 in r20, PORTD st Y+, r20 ... so würde ich einen happen ins ram kopieren, und brauche dafür vom avr her nur 3 clocks. Also gibt es derartige Autoinkrement-Funktionen bei Rams? Ist das dann typisch dyn. RAM, oder kann stat. RAM solche features auch besitzen? Mit Waitstate ist wohl die Zeit gemeint zwischen Read-Befehl und Anliegen der Datenbits, welche bei stat. Ram in der Bauteilbezeichnung angegeben sind? Z.b. finde ich bei Katalogen unter statischen Rams Werte zwischen 50-100ns, das wären immerhin 3-5 AVR-Takte, gibt es keine RAMs die sagen wir mal auf 10ns kommen (mit pipepline?). @Jörg Mein 644 hat leider kein DMA oder Externes Ram-Interface, da meine Schaltung und Programm inzwischen quasi fertig ist muss ich nun dabei bleiben (obwohl rückblickend man ruhig 10 euro mehr für die nächste Controller-Liga investieren hätte können). Übrigens, warst du es nicht der mir mal letztes Jahr zu multiplexten Widertandsmessungen in DSE weitergeholfen hat? Vielleicht interessiert es dich ja zu hören, dass es sich genau um die Anwendung handelt, und nach 10 Monaten Krampf sogar halbwegs funktioniert :). Danke auch nochmal an der Stelle, damals in der Konzeptfindungsphase hat du mich auf die richtige Idee mit der 4-Wire Multiplexten Messung gebracht...
Moritz E. wrote: > Mein 644 hat leider kein DMA oder Externes Ram-Interface, da meine > Schaltung und Programm inzwischen quasi fertig ist muss ich nun dabei > bleiben OK. Bringt dir vielleicht ein Upgrade auf einen ATmega1284P dann was? Der hat 16 KiB internen SRAM. > Übrigens, warst du es nicht > der mir mal letztes Jahr zu multiplexten Widertandsmessungen in DSE > weitergeholfen hat? Kann ich mich zwar nicht mehr dran erinnern, aber kann schon sein, ich lese relativ regelmäßig in d.s.e mit.
Moritz E. wrote:
> 2MB/s sind toll, muss mal gleich nachrechnen obs hinhaut.
Wenn du dich damit auf meine Angabe beziehst: die bezog sich sich auf
eine externe Beschaltung mit VRAM (= spezielles Dual-Port RAM).
Ich mach das bei einem Mega32 mit externem Adresszähler. 74HC4040 + 74HC4024, Der AVR muß dann halt einen Reset durchführen und kann danach fröhlich reinschreiben per out und Write Strobe (3clk) dann einen höchzählen (2clk)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
Man hat dan natürlich keinen "ram" mehr sondern ein "lam" ;) Aber ich habs eh so verstanden das du Meßwerte buffern willst, da will man meistnes ja eh einen großen Block ins Ram reinschaufeln und später wieder ausgeben. Sind dan bei 16Mhz maximal 3,0517578125 MB/sek ... mußt natürlich noch das abziehen was du verbrauchst um den ADC wert einzulesen :) Waitstates nutz ich zumindest nicht, benutzen tu ich ein altes Cache Ram aus nem Mainboard ich glaub mit 15ns
Jörg Wunsch wrote: > OK. Bringt dir vielleicht ein Upgrade auf einen ATmega1284P dann > was? Der hat 16 KiB internen SRAM. Tatsache da ist mir doch ein Pinkompatibles upgrade entgangen. Nur scheint die Reichelt-Seite sich nicht laden zu wollen.
Wobei man den ADC auch direkt in das Läubi'sche RAM reinschreiben lassen kann. Der AVR muss dann nur die Strobes liefern, der ADC hängt direkt am Datenbus und liefert die Daten für's RAM. DMA für Arme. Später schaltet man den ADC dann ab und liest an aller Ruhe aus. Wenn man statt der langsamen SBI/CBI- die schnelleren OUT-Befehle benutzt, ist damit deutlich mehr drin als gezeigt. Bei äquidistantem Sampling über grösseren Strecken 4 Takte, also 5Ms/s inklusive ADC. Bei kürzeren Strecken 2 Takte, also 10Ms/s. Ein asynchroner Zähler wie der HC4040 kommt dann allerdings nicht mehr mit, dafür muss er fixer sein. Schwierig wird es nur, wenn kontinuierlicher Betrieb verlangt ist. Aber dann ist eher die Software im AVR und dessen weitere Kommunikation relevant.
Blöde Frage - du verwendest nicht den internen ADC des Controllers, oder? Der kann bei dieser Geschwindigkeit meines Wissens nach nicht mithalten. Und wenn du eh einen externen ADC benutzt, wäre das lineare Schreiben der Daten in einen RAM ohne Controller-Bremse vermutlich einfacher. >Schwierig wird es nur, wenn kontinuierlicher Betrieb verlangt ist. Aber >dann ist eher die Software im AVR und dessen weitere Kommunikation >relevant. Was soll denn mit den Daten passieren? Wenn die wirklich kontinuierlich verarbeitet werden sollen, dann kann man sich u.U. eh den Puffer sparen. schöne Grüße Kai
Joar okay, hab ich jezt ganz überlesen das er Externen ADC nutzen will, dann kann mans natürlich noch besser machen, sollte ja nur ein Denkanstoß sein ;)
Moritz E. wrote: [ATmega1284P] > Tatsache da ist mir doch ein Pinkompatibles upgrade entgangen. Nur > scheint die Reichelt-Seite sich nicht laden zu wollen. Der ist noch zu neu für Angelika. ;-) Benutzt du die DIL- oder die TQFP-Version?
PS: Wenn man den Takt für ADC, Zähler und RAM einem Timerausgang entlockt, sind auch bei grösseren Speichertiefen CLK/2 also 10Ms/s drin.
Wie wäre es mit einem AVR-Modul mit 128 KiB SRAM? http://alvidi.de/produkte.html ...
Gast
#901456
Ob es eine gute Idee ist einen AVR an der absoluten Grenze zu betreiben um Daten von einem ADC abzuholen? Sobald mit den Daten etwas passieren soll muß dann das Einlesen unter- brochen werden. Ist das so gewollt? Jens
Gast
#901464
> Der ist noch zu neu für Angelika. ;-)
Gibt es den 1284P denn IRGENDWO?
Gast wrote: >> Der ist noch zu neu für Angelika. ;-) > > Gibt es den 1284P denn IRGENDWO? Musst du die Distributoren fragen... Ich habe mal einen über ,,dunkle Kanäle'' bekommen, um den AVR-GCC (bzw. die avr-libc) damit testen zu können. Außerdem ist er auf dem AVR Raven-Kit verbaut.
Gast
#901523
Für Kontakte zu dunklen Kanälen sind hier andere schon 'gesteinigt' worden. Jens
Jens wrote: > Für Kontakte zu dunklen Kanälen sind hier andere > schon 'gesteinigt' worden. Naja, wenn nach Möglichkeit zeitgleich mit der offiziellen Verkündigung eines neuen Chips auch der Compiler und die Tools bereit gestellt werden sollen, dann geht das nur mit frühzeitigen Samples.
Gast
#901551
Ich kann mir die Story in etwa vorstellen ;-). Den Seitenhieb konnte ich mir irgendwie nicht verkneifen. Jens
Gast
#901559
Hat jemand eine ungefähre Ahnung, wann der 1284P verfügbar sein wird (geht es hier um Wochen, Quartale oder wird das 2008 möglicherweise nichts mehr)?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.