Hallo, ich hab eine Frage bezueglich des "Timings" von Mikrocontrollern. Habe bisher Erfahrung mit FPGA-"Programmierung" aber noch nicht mit uC. Also, es geht darum, dass ein ARM auf einem Board einige Kommunikationsschnittstellen steuert. Die Controller dafuer sind soweit vorhanden. Es werden Daten ueber eine Ethernet-Schnittstelle per TCP/IP empfangen und in einen angeschlossenen RAM geschrieben. Nun moechte ich ueber eine andere Schnittstelle mehrere FPGAs anschliessen, an welche bestimmte Daten davon gesendet werden. Ein Protokoll dazu kann selbst ausgedacht werden. Allerdings muss ich dafuer etwas zum Verhalten des uC wissen. Also, gesendet wird moeglichst ohne Rueckleitung von den FPGAs, es gibt einfach nur ein enable und einen Datenpaketbroadcast mit einem Header ueber den der angesprochene FPGA dann seine Daten erkennt (Header+Daten ca. 50 Bit). Im FPGA-Denken wuerde ich nun Taktflanken im Protokoll definieren und z.B. sagen, enable geht auf high und ein Datenpaket wird komplett uebertragen, ein Datenbit pro Clockcycle bis enable wieder low ist. Geht das ueberhaupt mit einem uC oder laeuft das eher asynchron zum FPGA bzw. braucht mehrere Takte um z.B. ein Bit rauszusenden oder muss den Takt mitsenden oder wie auch immer? Also kann ich ein derartiges Kommunikationsverhalten voraussetzen oder muss man das anders machen? Ich muss am Ende nicht das uC-Programm schreiben aber dem dafuer Zustaendigen sagen, was ich wie brauche aber dazu muss ich erstmal wissen was moeglich ist. Vielen Dank.
@ ampa (Gast) >ich hab eine Frage bezueglich des "Timings" von Mikrocontrollern. Habe >bisher Erfahrung mit FPGA-"Programmierung" aber noch nicht mit uC. Hmm. >Nun moechte ich ueber eine andere Schnittstelle mehrere FPGAs >anschliessen, an welche bestimmte Daten davon gesendet werden. Ein Wieviele Daten sollen in welcher Zeit transoportiert werden? Wieviele FPGAs werden denn angeschlossen? Spontan würde ich sagen, dass entweder SPI oder memory mapped IO in Frage kommen. SPI MfG Falk
Ich würde auch spontan auf SPI tippen. Wichtig dabei ist, dass du in Blöcken von 8 Bits arbeitest, da Hardware-SPI-Implementierungen in der Regel nur ganzzahlige Vielfache von 8 Bits ausgeben können. Auch wenn du eigentlich nichts zurück geben willst, kann es dabei sinnvoll sein, den Rückkanal trotzdem zu implementieren. Damit kann der steuernde Controller dann (wenn ein bestimmtes, definiertes Bitmuster als Antwort gesendet wird) feststellen, dass er nicht ,,in die Luft redet''.
Hallo Falk, Danke soweit. Wieviele FPGAs maximal angeschlossen werden sollen, ist noch nicht ganz klar, vier oder acht etwa, wobei nicht alle Plaetze immer belegt sein muessen. Wieviele Daten in welcher Zeit gesendet werden sollen, ist auch erstmal nicht wichtig, es geht mir nur um die Synchronisation uC -> FPGA. Der FPGA ist dann schon schnell genug, um was mit den Daten anzufangen bevor neue kommen.
Achso, wegen der Daten pro Zeit war die Geschwindigkeit der Schnittstelle gemeint, die ist auch erstmal zweitrangig. Also ich denke ich werde I2C nehmen (unidirektional) oder ist das dafuer eher unueblich? Hat das groessere Nachteile gegenueber SPI?
ampa wrote: > Also ich denke ich werde I2C nehmen (unidirektional) oder ist das dafuer > eher unueblich? Hat das groessere Nachteile gegenueber SPI? Unnützer Stress und fehleranfälliger. I²C hat Sinn, wenn man entweder viele Geräte adressieren will (wie im System Management Bus in einem PC) -- SPI braucht pro Gerät ein "slave select"-Signal, oder wenn der Slave u. U. lange brauchen kann (Microcontroller), bis er bereit ist. Zumindest letzteres hast du ja nicht.
@Joerg Wie meinst du das mit dem fehleranfaelligeren I2C? In meinem Fall waere glaub ich I2C besser, da ich erstens nicht so viel Leitungen zur Verfuegung habe (SPI braucht ja viele chip selects) und zweitens die Geraete idealerweise ueber eine Adresse ansprechbar sein sollten um sie an verschiedene Plaetze der Leitung zu haengen. Aber lass mich auch belehren, wenn SPI oder andere Varianten besser sind.
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.