Datenbereitstellung für SPI

King Julian schrieb:
> Momentan ist es so gelöst, dass die zu einem Command gehörenden Signale
> auf dem FPGA in Records gebündelt sind und.......
Mein erster Eindruck: du denkst viel zu abstrakt.

> Ein shared memory wäre eventuell eine Möglichkeit aber da gewisse
> Signale quasi Echtzeit geschrieben werden (mit jedem Taktzyklus) stelle
> ich mir die Implementation da etwas schwirig vor.
Wie wird denn in deinem Zielsystem so ein Shared Memory implementiert? 
Meinst du evtl. gar Shared Variable?

Letztlich ist eine SPI Übertragung was simples: du empfängst ein 
Kommando und sendest zugleich die Antwort auf das (Achtung, jetzt kommt 
der Trick:) vorhergehende Kommando. Du setzt also nach dem Empfang 
eines Kommandos ganz entspannt das Ergebnis zusammen und sendest dieses 
Ergebnis bei der nächsten Übertragung zurück (während du schon wieder 
ein neues Kommando empfängst).
Dann hast du echten Vollduplex Betrieb und quasi die doppelte Datenrate, 
weil du gleichzeitig sendest und empfängst. So wie es der SPI 
eigentlich vorsieht.

Wenn dir das Verfahren nicht ganz klar ist, dann sieh dir mal den AD7490 
an. Der macht es genau so.

> quasi Echtzeit
Wenn du eine halbwegs brauchbare Beschreibung hinlegst, dann ist 
Echtzeit locker etwas im 10ns Bereich. Ein Taktzyklus eben...

King Julian schrieb:
> Was ist der sauberste Weg so eine Zuweisung zu realisieren?
Nimm ein DPRAM und schreib oder ließ es byteweise ab dem Offset.
Dann brauchst du nur einen einzigen Zeiger mit 7 oder 8 Bit, der mit dem 
Offset geladen und hinterher nach jedem Byte inkrementiert wird.
Eine kleine FSM verwaltet das Ganze.

Wenn du Messages mit variabler Laenge bearbeiten willst bist du 
eigentlich schon bei einem Controller und bearbeitest Microcode. Fuer 
SPI braucht man keinen CRC, weil SPI sowieso nur kurze Laengen hat, 
maximal ueber eine Leiterplatte, nie ueber einen Stecker.

Was soll's denn werden ?

King Julian schrieb:
> Da das FPGA aber keinesfalls falsche Daten in den Registern haben darf
Wir drehen uns im Kreis...
> haben wir uns mal für einen CRC entschieden.
Wenn ich der Projektleiter wäre, würde ich ein besseres Argument hören 
wollen.

> Wie stell ich bei einem DP Ram sicher, dass nicht gelesen und
> geschrieben gleichzeitig wird? Oder ist das gar kein Problem?
Es ist kein Problem im Sinne eines atomaren Zugriffskonflikts. Du liest 
entweder das alte oder das neue Byte.
Allerdings ist es ein Problem, wenn die gerade gelesenen Daten Teil 
eines größeren Konstrukts sind und z.B. 4 Bytes zusammen gehören. Dann 
ist es durchaus kritisch, wenn die Hälfte alte und die andere Hälfte 
neue Daten enthält. Aber dieses Semaphorenproblem ist besonders aus der 
Softwareentwicklung allseits bekannt und muss durch passende Sperr- und 
Freigabemechanismen behandelt werden.