SPI Schieberegister und RX_Buffer TI-Controller TMS320F28035

[Mark J. (markjo)]

Hallo Leute,

ich habe 2 Microcontroller über SPI verbunden, der eine agiert als 
Master und der andere als Slave. Ich verwende die Controller von TI 
TMS320F28035. Das Senden der Daten funktioniert sie kommen erfolgreich 
im SPIDAT Register an das ist das Schieberegister, danach sollte das 
Schieberegister die Daten an dem Buffer SPIRXBUF weiterleiten. Mein 
Problem ist jetzt dass das Schieberegister immer die Daten empfängt aber 
nicht immer an dem Buffer weiterleitet von 4-5 senden funktioniert es 
ca. 4 mal und dann leitet er die Daten nicht richtig weiter sondern nur 
halb oder keine erkennbaren Daten. Kann mir jemand vielleicht 
weiterhelfen warum die Daten nicht immer an dem RXBuffer weitergeleitet 
werden, was ja eigentlich sein müsste.

Danke für eure Hilfe im Vorraus.

Mfg
Mark

[Walter T. (nicolas)]

Welches Protokoll hast Du denn für EOT (end of transmission) definiert? 
timeout oder deselect?

Du musst halt irgendwie sicherstellen, dass bei jedem sendeseitige 
Byte-Ende auch empfangsseitig 8 Bit durchgelaufen sind.

Edit: Tippfehler. Es war ein langer Tag.

[Mark J. (markjo)]

was meinst du genau mit end of transmission ich habe jetzt nicht gesehen 
das man das genau festlegen kann. Ich verwende aufjedenfall keinen FIFO. 
Der RX Buffer hat aufjedenfall 16 bit und ich sende zweimal 
hintereinander 8 Bit also im SPIDAT kommen die aufjedenfall immer an nur 
er überträgt die wie gesagt nicht immer vollständig in dem RX-Buffer. 
Weißt du welches Register für das End of Transmission bei TI zuständig 
ist? ;)

[Mark J. (markjo)]

hier habe ich mal eine Tabelle erstellt für das Schieberegister und die 
Buffer vom Slave und Master. Als Beispiel daten habe ich die 0x1234 
gesendet beim ersten senden klappt es aber beim 2ten und 3ten dann nicht 
mehr wie man sieht landen dann die daten vom Schieberegister nicht mehr 
in dem Buffer. nach dem 6ten senden ist wieder alles Inordnung.

[Peter D. (peda)]

MCs sind oftmals nur schlecht als SPI-Slave geeignet. Das Problem ist, 
daß SPI kein Handshake kennt, d.h. keinerlei Flußkontrolle besitzt.
Man kann sich behelfen, indem man dem SPI-Interrupt die absolut höchste 
Priorität gibt, so daß keine andere Task ihn verzögern kann.
Oder der Master legt nach jedem Byte eine ausreichende Pause ein, was 
das SPI aber erheblich ausbremst.