TI Concerto F28M35x mit Xilinx Spartan 6 verbinden

[Ian Kloev (Gast)]

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

[Duke Scarring (Gast)]

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.

The EPI is a high-speed parallel bus for external peripherals or memory.
It has several modes of operation to interface gluelessly to many types
of external devices. The EPI is similar to a standard microprocessor
address/data bus, except that it must typically be connected to just one
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

[PittyJ (Gast)]

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.

[Ian Kloev (Gast)]

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?

[britzl (Gast)]

Ian Kloev schrieb:
> SPI sollte im normalfall
> schneller sein?

SPI geht bei manchen (nicht allen) Mikrocontrollern sogar bis 50 Mbit/s.
Also: Ja.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Duke Scarring (Gast)]

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

[Christian R. (supachris)]

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...

[Ian Kloev (Gast)]

Christian R. schrieb:
> Achje, wieder so eine vollkommen aus der Praxis gerissene akademische
> "Lösung".

https://en.wikipedia.org/wiki/Model_predictive_control ...

[Ian Kloev (Gast)]

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.

[Duke Scarring (Gast)]

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