Hallo Ich habe ein Verständnisproblem mit der Funktionsweise eines synchronen FIFO. Sorry daß ich etwas ausholen muß, aber ich denke zum Verständnis ist das notwendig. Evtl. steh ich auch nur auf der Leitung, aber ich komm nicht dahinter. Es geht um folgendes ... Es sollen Daten eines AD-Wandlers möglichst schnell über USB an den Rechner geschickt werden. Ich rede hier von etwa 500k-samples und mehr. Der AD-Wandler muß in einem festen zeitlichen Raster ausgelesen werden. Unterbrechungen (weil z.B. wenn Windows grad was anderes machen will) sind nicht erlaubt. Ich takte daher die Daten des AD-Wandlers mit einem ATMega in ein asynchrones FIFO (im Moment CY7C433 - 4k x 9Bit). Mit einem zweiten Prozessor (einem Tiny13) takte ich die Daten mit einer komplett unabhängigen Timedomain in den USB-chip (FT245R). Das ganze funktioniert aktuell sehr gut, die Datenrate liegt bei ca. 450kByte/s ... soweit sogut! Nun besteht die Forderung die Datenrate deutlich zu erhöhen. Ich habs bereits bis 800kByte/s geschafft, allerdings läuft nun das 4k FIFO ab und zu über und Daten gehen verloren. Ich brauche also ein größeres FIFO und habe mich aus verschiedenen Gründen (u.a. wegen der programmierbaren Statusflags) für ein CY7C4251 mit 8k x 9Bit entschieden. So nun zum eigentlichen Problem: -------------------------------- Beim asynchronen FIFO (also beim aktuellen Design) werden die FULL- und EMPTY-Flags vom Lese- UND vom Schreibpointer beeinflußt. Um Daten aus dem FIFO zu lesen, warte ich also einfach solange bis der Daten im FIFO vorliegen (das EMPTY-Flag geht dann auf high). Sobald keine Daten mehr im FIFO sind geht das EMPTY-Flag zurück auf Low und ich höre auf Daten auszulesen. Mit dem FULL-Flag gehts beim Schreiben ähnlich. Sobald es auf high geht ist das FIFO voll und es wird nichts mehr reingeschrieben. Beim synchronen FIFO siehts leider etwas anders aus. Hier wird das EMPTY-Flag NUR (!!!) vom Lesepointer beeinflußt. Es geht also nicht automatisch auf high sobald die ersten Daten im FIFO geschrieben werden, sondern erst nachdem der Lesetakt anliegt. Damit habe ich nun vor dem Lesen keine Info mehr ob Daten im FIFO sind oder nicht. Beim Reinschreiben gibts die gleichen Probleme. Das FULL-Flag wir nicht durch Auslesen des FIFO gelöscht, sondern erst mit dem nächsten Schreibtakt :-( Hier noch Links auf die jeweiligen Datenblätter: http://www-hades.gsi.de/daq/rc99/fe/cy7c419.pdf http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c4251_8.pdf Hab ich nun mit dem synchronen FIFO total daneben gegriffen oder steh ich nur aufm Schlauch? Kennt sich einer mit diesen Teilen besser aus?
das thema FIFOS habe ich mal in der schule gelernt, bringt uns aber nicht bei deinem problem weiter. allerdings halte ich das für ganz einfach, wenn ich mich nicht irre: du machst eine lese operation und wenn dabei das empty flag auf low geht verwirfst du den versuch und probierst es solange bis es wieder geht. beim schreiben eben genauso bloß andersrum.
@ Gerhard (Gast) >Rechner geschickt werden. Ich rede hier von etwa 500k-samples und mehr. Du redest vor allem am Problem vorbei. 500kSample in welcher ZEIT? >sind nicht erlaubt. Ich takte daher die Daten des AD-Wandlers mit einem >ATMega in ein asynchrones FIFO (im Moment CY7C433 - 4k x 9Bit). Da kanns ja nicht zu schnell sein. >bereits bis 800kByte/s geschafft, allerdings läuft nun das 4k FIFO ab >und zu über und Daten gehen verloren. Ich brauche also ein größeres FIFO >und habe mich aus verschiedenen Gründen (u.a. wegen der programmierbaren >Statusflags) für ein CY7C4251 mit 8k x 9Bit entschieden. Nimm einen AVR mit mehr RAM oder externem SRAM, dort kannst du relativ einfach das FIFO in Software nachbauen. >Beim synchronen FIFO siehts leider etwas anders aus. Hier wird das >EMPTY-Flag NUR (!!!) vom Lesepointer beeinflußt. Es geht also nicht >automatisch auf high sobald die ersten Daten im FIFO geschrieben werden, >sondern erst nachdem der Lesetakt anliegt. Logisch, ist ja ein SYNCHRONES FIFO. Und selbst ASYNCHRONE FIFOs brauchen heute freilaufende Takte auf beiden Seiten. Die "echt" asynchronen Dinger mit Strobe Signalen OHNE freilaufende Takte sind Schnee von gestern und bei heutigen Datenraten und Speichertiefen nicht mehr brauchbar. Siehe die Entwicklung von DRAM zu SD-RAM im Artikel Speicher. > Damit habe ich nun vor dem >Lesen keine Info mehr ob Daten im FIFO sind oder nicht. Klar, einfach den Takt laufen lasssen ;-) >Hab ich nun mit dem synchronen FIFO total daneben gegriffen oder steh >ich nur aufm Schlauch? >Kennt sich einer mit diesen Teilen besser aus? Siehe oben. MFG Falk
Hallo Falk >500kSample in welcher ZEIT? Sorry ... pro Sekunde natürlich >Nimm einen AVR mit mehr RAM oder externem SRAM, dort kannst du relativ >einfach das FIFO in Software nachbauen. Nein. Das ist um Größenordnungen zu langsam um die geforderte Datenrate zu schaffen! >Und selbst ASYNCHRONE FIFOs >brauchen heute freilaufende Takte auf beiden Seiten. Auch Nein. Siehe Datenblatt CY7C433. Ich habe oben schon bemerkt, dass es aktuell damit sauber läuft. >Klar, einfach den Takt laufen lasssen ;-) Hm, wenn das FIFO voll ist darf ich doch nix reintakten oder ??? O.K., das muß ich mir nochmal genau überlegen ...
Ich denke, bei diesen Datenraten wäre ein µP mit DMA-Controller und RAM angesagt. Auch die erwähnten 800kByte/s sind bei USB oberer Anschlag und nicht sicherzustellen. Gerade gestern war hier ein Beitrag, wo jemand einen H8SX/1668 angesprochen hatte. Hiermit wäre das Problem lösbar. Das ist allerdings eine andere Liga als Tiny13 :-)
@Gerhard (Gast) >Nein. Das ist um Größenordnungen zu langsam um die geforderte Datenrate >zu schaffen! Hmm, naja, stimmt. Aber ein AVR ist dann sowieso nicht wirklich das Mittel der Wahl. Ein kleiner CPLD kann die Datenübertragung viel besser und einfacher steuern, auch bei 10 MB/s. >>Und selbst ASYNCHRONE FIFOs >>brauchen heute freilaufende Takte auf beiden Seiten. >Auch Nein. Siehe Datenblatt CY7C433. Ich habe oben schon bemerkt, dass >es aktuell damit sauber läuft. Lies mal mein Posting nochmal. Es gibt "alte" asynchrone FIFOs ohne Takt, die neueren sind alle MIT freilaufendem Takt. Hier liegt auch einer der beliebten Fallstricke. Asynchron wird wie so oft mehrdeutig verwendet. Im Bereich der FPGas: Syncrones FIFO: Ein einziger Takt für schreiben und Lesen Asynchrones FIFO: GEtrennte Takte für schreiben und lesen Klassische Bezeichung für RAMs Asynchron: Datentransfer nur über Steuersignale, z.B. RD, WR, CS, siehe SRAM oder DRAM im Artikel Speicher Synchron: Datentransfer über Steuersignale, welche Synchron zu einen freilaufenden Takt generiert werden. siehe SD-RAM im Artikel Speicher >Klar, einfach den Takt laufen lasssen ;-) >Hm, wenn das FIFO voll ist darf ich doch nix reintakten oder ??? Takt laufen lassen heisst doch nicht notwendigerweise dass es Daten aufnimmt! >O.K., das muß ich mir nochmal genau überlegen ... Und mal das Datenblatt lesen. "The input port is controlled by a free-running clock (WCLK) and two Write-enable pins (WEN1, WEN2/LD)." Na, dämmerts? MFG Falk
>"The input port is controlled by a free-running clock (WCLK) and two >Write-enable pins (WEN1, WEN2/LD)." > >Na, dämmerts? Ja, es dämmert. Ich hab mich von folgendem Satz im Datenblatt verleiten lasen:
1 | The Read (RCLK) and Write (WCLK) clocks may be tied together for |
2 | single-clock operation or the two clocks may be run independently for |
3 | asynchronous Read/Write applications. |
Ich muß wohl zumindest beim Schreiben zum Writeclock auch den WEN1 bedienen. Danke erstmal für die Tipps ...
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.