TI Concerto F28M35x mit Xilinx Spartan 6 verbinden

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.

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