Hallo, ich möchte gerne Regelungsparameter von einem TI Concerto F28M35x Microcontroller übertragen, um dann anschließend auf einem Xilinx Spartan 6 die neuen Stellgrößen (1x8 bit) zu berechnen. Innerhalb von 5ms sollen 8x16 bit empfangen, die neue Stellgröße berechnet und wieder an den Microcontroller gesendet werden. Im Datenblatt des Concerto wird das External Peripheral Interface (EPI) aufgeführt. - Was wäre hierbei das Gegenstück zu EPI auf der Spartan 6 FPGA Seite? - Ist es empfehlenswert die Daten über SPI oder UART seriell zu übertragen, wenn man in Zukunft komplexere Regelmodelle verwenden möchte? Vielen Dank für eure Antworten
Ian Kloev schrieb: > Spartan 6 die neuen Stellgrößen (1x8 bit) zu berechnen. Innerhalb von > 5ms sollen 8x16 bit empfangen Also 200 * 128 = 25.6 kBit/Sekunde hin und 1600 Bit/Sekunde zurück. > Im Datenblatt des Concerto wird das External Peripheral Interface (EPI) > aufgeführt.
1 | The EPI is a high-speed parallel bus for external peripherals or memory. |
2 | It has several modes of operation to interface gluelessly to many types |
3 | of external devices. The EPI is similar to a standard microprocessor |
4 | address/data bus, except that it must typically be connected to just one |
5 | type of external device. |
Mit dem EPI dürftest Du in den Bereich von mehren 10 MBit/s kommen. Angesichts der vielen Leitungen etwas oversized. Mit UART oder SPI solltest Du locker 1 MBit/s schaffen. Ob das auch für spätere Anwendungen reicht mußt Du selbst entscheiden. Duke
So schlappt scheint der Ti-Prozessor doch gar nicht zu sein. Wenn man den ganzen Kommunikationsoverhead weglässt, hätte er nicht genug Zeit sum selber rechnen? Der DSP 28xx Teil soll sogar eine Floating-Point Unterstützung haben.
PittyJ schrieb: > So schlappt scheint der Ti-Prozessor doch gar nicht zu sein. Wenn man > den ganzen Kommunikationsoverhead weglässt, hätte er nicht genug Zeit > sum selber rechnen? Ja es ist richtig, dass der Ti nicht so schwach ist. Allerdings möchte ich das ganze auf einem FPGA implementieren. Den Regelungsalgorithmus möchte ich hierbei mit dem Matlab/Simulink HDL-coder implementieren. Duke Scarring schrieb: > Mit UART oder SPI solltest Du locker 1 MBit/s schaffen. Ob das auch für > spätere Anwendungen reicht mußt Du selbst entscheiden. UART oder SPI gibt es hierbei eine Empfehlung? SPI sollte im normalfall schneller sein?
Ian Kloev schrieb: > SPI sollte im normalfall > schneller sein? SPI geht bei manchen (nicht allen) Mikrocontrollern sogar bis 50 Mbit/s. Also: Ja.
britzl schrieb: > SPI geht bei manchen (nicht allen) Mikrocontrollern sogar bis 50 Mbit/s. Was dann mindestens um den Faktor 1000 oversized wäre. Ein Tipp aus der Praxis: Nicht so schnell wie möglich, sondern nur so schnell wie nötig...
:
Bearbeitet durch Moderator
Ian Kloev schrieb: > UART oder SPI gibt es hierbei eine Empfehlung? In Deinem Fall würde ich UART empfehlen. Da musst Du nicht ständig mit SPI pollen, sondern wartest ganz entspannt per Interrupt auf die Antwort vom FPGA. > SPI sollte im normalfall > schneller sein? Ja. Duke
Ian Kloev schrieb: > Allerdings möchte > ich das ganze auf einem FPGA implementieren. Den Regelungsalgorithmus > möchte ich hierbei mit dem Matlab/Simulink HDL-coder implementieren. Achje, wieder so eine vollkommen aus der Praxis gerissene akademische "Lösung". Dass man das aber auch nie mal rauskriegt aus den Leuten...
Christian R. schrieb: > Achje, wieder so eine vollkommen aus der Praxis gerissene akademische > "Lösung". https://en.wikipedia.org/wiki/Model_predictive_control ...
Hallo, da sich nun leider nicht alle EPI Pins auf unserem Eval Board ausführen lassen würde ich sehr gerne einen eigenen Parallelbus in C implementieren. Ist hierbei mit einer höheren Datenrate als mit SPI zu rechnen oder spielen aufgrund von skew die Laufzeitunterschiede durch die Realisierung in C eine grosse Rolle welche höhere Taktraten nicht zulassen werden.
Ian Kloev schrieb: > einen eigenen Parallelbus in C > implementieren. Ist hierbei mit einer höheren Datenrate als mit SPI zu > rechnen Evtl. Ja, allerdings ist Dein Mikrocontroller dann möglichweise ausgelastet, wenn Daten geschaufelt werden. Für SPI u.ä. gibt es auf den ARMs meistens DMA-Systeme, die die Daten im Hintergrund transferieren. > oder spielen aufgrund von skew die Laufzeitunterschiede durch > die Realisierung in C eine grosse Rolle welche höhere Taktraten nicht > zulassen werden. Kommt drauf an, was Du für Laufzeitunterschiede meinst. Wenn Du direkt auf die Ports zugreifst (da sollte C oder Assembler egal sein), hängt die Transferrate eher von Deinem Protokoll bzw. Handshake ab. Elektrische Laufzeitunterschiede spielen bei einem 'Softwareprotokoll' eher selten eine Rolle. Duke
Bitte 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.