Hallo liebe Community, ist es möglich einen FIFO Speicher in "Software" auf einem ATmega8515 @ 20 MHz zu simulieren? Am Besten mit einer SD Karte. Für eine Schreibaktion (1 Byte) wären ca. 1us Zeit. Was sagen die Profis dazu? Mit freundlichen Grüßen, Christian
>ist es möglich einen FIFO Speicher in "Software" auf einem ATmega8515 @ >20 MHz zu simulieren? Ja. >Am Besten mit einer SD Karte. Für eine >Schreibaktion (1 Byte) wären ca. 1us Zeit. Da bist du mit einer SD Karte aber an der falschen Adresse.
@ Christian Karle (christiankarle) >ist es möglich einen FIFO Speicher in "Software" auf einem ATmega8515 @ >20 MHz zu simulieren? Am Besten mit einer SD Karte. Sicher. Aber wie schnell soll dein FIFO sein? > Für eine Schreibaktion (1 Byte) wären ca. 1us Zeit. Das ist recht schnell. 1MB/s Datendurchsatz schaffst du mit dem AVR + SD-karte nicht. Bei meinen Experimenten bin ich auf bis zu 700kB/s beim reinen Lesezugriff gekommen. Beitrag "Re: Geschwindigkeitsfrage AVR auf SD" Dort ist schon ein FIFO im FatFs drin, nämlich 512 Byte.
> Da bist du mit einer SD Karte aber an der falschen Adresse.
Zu was würdest Du mir raten? Es handelt sich um größere Datenmengen...
Im Extremfall um mehrere MB...
Die müssen iwie raus aus dem uC, dieser dient nur zur Kommunikation mit
dem Bus und der Pufferung eines Paketes.
> Dort ist schon ein FIFO im FatFs drin, nämlich 512 Byte.
Kann ich den "frei" beschreiben?
>Kann ich den "frei" beschreiben?
Das Schreiben "von der Seite" her wiederspricht aber dem FIFO-Konzept.
Ein FIFO ist nämlich ein ganz normaler Speicher mit einer
Anfang/Ende-Verwaltung. Das Beschreiben, unter Umgehung der dafür
vorgesehenen Routinen, bringt die Verwaltung durcheinander bzw. legt
diese still.
Ok, einmal abgesehen vom FIFO, wie bekomme ich eine so enorme Datenmenge schnellstmöglich aus meinem ATmega auf ein anderes Speichermedium. Bzw. Welches externe Speichermedium ist schnell und groß genug?
Der FIFO wird "normal" (in Reihenfolge der Bytes) beschrieben, ein Byte kommt, das nächste rutscht hinterher etc...
>Zu was würdest Du mir raten? Es handelt sich um größere Datenmengen... >Im Extremfall um mehrere MB... Dann ist der kleine ATMega evtl. der falsche uC. >Die müssen iwie raus aus dem uC, dieser dient nur zur Kommunikation mit >dem Bus und der Pufferung eines Paketes. Worum geht es eigentlich?
@ Christian Karle (christiankarle) >Ok, einmal abgesehen vom FIFO, wie bekomme ich eine so enorme Datenmenge >schnellstmöglich aus meinem ATmega auf ein anderes Speichermedium. Auf welchem sind die Daten denn jetzt? 1MB/s kontinuierlicher Datendurchsatz ist mit einem AVR IMO nicht drin. Ich würde mal bestenfalls mit 250kB/s rechnen (Die Daten müssen REIN und wieder RAUS). ATXMega könnte mit DMA und höherem Takt etwas besser sein, aber 1MB/s halte ich für unrealistisch. >Welches externe Speichermedium ist schnell und groß genug? SD-Karten schaffen 1MB/s relativ leicht, selbst im langsamen 1 Bit SPI Modus. Aber der Prozessor muss das mitmachen. Nimm lieber einen schnellen ARM mit ausreichend RAM und SDIO Interface zur SD-Karte, damit geht das relativ sicher und einfach.
Christian Karle schrieb: > ist es möglich einen FIFO Speicher in "Software" auf einem ATmega8515 @ > 20 MHz zu simulieren? Am Besten mit einer SD Karte. Für eine Wenn du es Byte für Byte beschreiben willst, ist SD nicht die richtige Wahl. Überhaupt ist M8515 damit überfördert, ob einzelne Bytes oder Buffer. Bei 20MHz kommst du höchstens auf 10MHz SPI-Geschwindigkeit, das sind 800nS pro Byte, dazu kommen noch die Adressen und Commands - - no way dass M8535 das schafft. Selbst mit XMEGA ist das kaum zu schaffen, den die Daten müssen erst empfangen werden, das ist nochmal teilen durch zwei (mindestens)... P.S. Soviel ich weiss,gibts M8515 nur bis 16MHz. RAM ist 512Bytes, das ist sowieso zu wenig... Falk Brunner schrieb: > Nimm lieber einen > schnellen ARM mit ausreichend RAM und SDIO Interface zur SD-Karte, damit > geht das relativ sicher und einfach. Genau.
:
Bearbeitet durch User
Falk Brunner schrieb: > Auf welchem sind die Daten denn jetzt? 1MB/s kontinuierlicher > Datendurchsatz ist mit einem AVR IMO nicht drin. Natürlich ist das drin. Allerdings nicht auf eine SD-Karte. > Ich würde mal > bestenfalls mit 250kB/s rechnen (Die Daten müssen REIN und wieder RAUS). Nun ja, es kommt halt darauf an, wie sie rein- und rauskommen. Wenn z.B. die Quelle eine simple Abtastung eines Ports mit Vmax ist (viel was anderes kann es ja kaum sein, weil die sonstigen Schnittstellen allesamt schon von Haus aus kein MByte/s schaffen), dann kostet das Lesen genau einen Takt. Wenn man das dann auf einen 8Bit-Port mit Strobe/Ack-Signalspiel rausschreibt, dann ergibt sich folgende Schleife: .equ ctrl_idle=1<<strobe .equ ctrl_data=0 ldi regidle,1<<strobe ldi regdata,0 loop: in tmp,data_in_port ; 1 1 sbic ctrl_pin,ack ; 2 1 rjmp loop ; 2 out ctrl_port,regidle ; 1 out data_out_port ; 1 out ctrl_port,regdata ; 1 rjmp loop ; 2 ;-- ; 8 Macht bei 20MHz Takt einen Durchsatz von 2,5MByte/s, wenn er nie auf den Abnehmer der Daten warten muß. Und wenn er in jedem Zyklus einmal durch die Warteschleife muß, sind es immer noch 1,67MBytes/s. Aber schon dann wäre ja der Abnehmer der Daten der beschränkende Faktor und nicht der AVR.
@ c-hater (Gast) Unser Oberschlaumeier mal wieder am Mikrophon. >> Auf welchem sind die Daten denn jetzt? 1MB/s kontinuierlicher >> Datendurchsatz ist mit einem AVR IMO nicht drin. >Natürlich ist das drin. Allerdings nicht auf eine SD-Karte. Aber darum ging es. Und auch andere Medien und IO-Modi sind da nicht viel besser im REALEN Datendurchsatz. >Nun ja, es kommt halt darauf an, wie sie rein- und rauskommen. Wenn z.B. >die Quelle eine simple Abtastung eines Ports mit Vmax ist (viel was >anderes kann es ja kaum sein, weil die sonstigen Schnittstellen allesamt >schon von Haus aus kein MByte/s schaffen), dann kostet das Lesen genau >einen Takt. Das reich aber nicht. >Wenn man das dann auf einen 8Bit-Port mit Strobe/Ack-Signalspiel >rausschreibt, dann ergibt sich folgende Schleife: >Macht bei 20MHz Takt einen Durchsatz von 2,5MByte/s, wenn er nie auf den >Abnehmer der Daten warten muß. Und wenn er in jedem Zyklus einmal durch >die Warteschleife muß, sind es immer noch 1,67MBytes/s. Aber schon dann >wäre ja der Abnehmer der Daten der beschränkende Faktor und nicht der >AVR. Herzlichen Glückwunsch zum Nachbaeu eines 8 Bit Registers ind Software! Eine äußerst sinnvolle UND performante Applikation!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.