SPI Master Slave ohne ChipSelect-Leitung

Beschäftige dich mal mit der SPI Schnittstelle, es gibt da viel zu 
lesen.
Was du vorhast, hat mit SPI (fast) nichts zu tun.

Warum willst Du auf die Chip Select - Leitung verzichten? Sie ist ein 
unverzichtbarer Bestandteild der SPI-Schnittstelle und dient der 
Aktivierung bzw. Deaktivierung des SPI-Moduls des Slave-Bausteins sowie 
sehr häufig der Signalisierung des Nachrichtenendes. Ein Slave kann 
übrigens niemals selbstständig Daten senden, auch nicht bis das ein 
Stopbefehl kommt. Der Slave kann nur auf ein Adressbyte des Masters 
antworten, und auch nur dann, wenn vom Master weitere Clock-Signale 
gesendet werden.

@Ralph:
Ich habe nochmal einmal nachgelesen, Du hattest Recht - ich hatte die 
Funktionsweise vom Hardware-SPI noch nicht verstanden.
Ich habe das jetzt so verstanden:
Der Master schreibt zuerst in den MOSI ein Request-1-Byte, der Slave 
sollte im MISO ein Ready-Byte stehen haben.
Mittels des Master-Taktes werden die Bits aus MOSI und MISO gleichzeitig 
übertragen.
Wenn der Master das Ready erhalten hat, weiß er dass er Daten vom Slave 
abfragen kann. Nun kann der Master wieder ein Request-2-Byte schicken, 
gleichzeitig antwortet der Slave auf das Request-1-Byte ... usw. - 
richtig so?
@Roman:
Ich möchte kein Chip-Select-Pin nutzen, da ich zwischen 2 PIC's (auf 
getrennten Platinen) Daten austauschen will. Dazu will ich 2 
LVDS-Teiber-IC's einsetzen um duch die Differenzen-Signale Störungen zu 
unterdrücken.
Ich habe vor das ganze so Aufzubauen:
-PIC_1 (auf Platine 1) = Master
-PGA   (auf Platine 1) = Slave_1 (PGA=Programmable Gain Amplifier)
-PIC_2 (auf Platine 2) = Slave_2
Der PGA erhält eine Chip-Select Leitung.
Wenn ich an den PGA ein Byte senden will ziehe ich die 
Chip-Select-Leitung auf Masse und sende das Byte. PIC_2 erhält das Byte 
auch, aber weiß dass es nicht für ihn bestimmt war. Das sollte doch 
funktionieren - oder?

Ich verstehe immer noch nicht, warum du unbedingt auf CS verzichten 
willst. Macht das für Dich einen Unterschied, ob die Verbindung zwischen 
Deinen PIC's dreipolig oder vierpolig ist?
Es würde uns weiterhelfen, wenn Du uns darüber aufklären würdest.

Dein Slave überprüft auf JEDEN Fall, ob sich was an seinem CS-Pin tut. 
Wenn Du keine CS-Leitung hier anschliessen willst, musst Du so oder so 
zumindest den CS-Eingang an deinem PIC 2 an Masse legen. Du könntest an 
Deinem PIC_1 jeden x-beliebigen freien Pin für eine zweite CS-Leitung 
verwenden; auf der Masterseite ist das komplett egal. Du müsstest in 
Deiner PIC2-Applikation  dann keine softwaremäßige 
Empfänger-Unterscheidung durchführen.

Wenn Du Nachrichten im SPI-Burst-Modus übertragen willst ( empfiehlt 
sich auf jeden Fall bei mehr als einem Dutzend Bytes ), kommst Du gar 
nicht um eine CS-Verbindung herum, da hierüber das Paketende 
signalisiert wird.

Hallo Roman,
danke erstmal für Deine Antworten - ich find es ist wichtig das jemand 
die richtigen Fragen stellt - sonst kocht man ewig in seinem eig. Saft.
Die Platinen sollen in einem kleinen Gehäuse untergebracht werden. D.h. 
das Platinenlayout soll so platzsparend wie möglich sein. Wenn ich CS 
bzw. SS benutzen möchte, sollten diese Signale auch über den LVDS-IC in 
Differenzensignale umgewandelt werden ==> ein zusätzlicher LVDS-IC + 2 
zusätzliche Leitungen + größere Steckverbinder.

Ich habe mir angeschaut wie der SPI-Burst-Modus (bzw. Framed SPI Mode) 
funktioniert. Wegen dem zusätzlichen Hardwareauffwand werde ich diesen 
aber vermutlich nicht verwenden. Aber trotzdem interessiert mich ob ich 
es richtig verstanden habe:
Folgendes Szenario:
PIC_1 = Master Mode
PIC_2 = Framed Slave Mode
Der Master generiert den Takt (SCK), der "Framed Slave" erzeugt den 
Slave-Select-Impuls (SS).
Nach dem Slave-Select-Impuls werden die Daten kontinuierlich aus den 
Puffern von Master und Slave übertragen. Dabei muss sicher gestellt 
werden, dass die Puffer entsprechend gefüllt bzw. geleert werden. Wenn 
der Slave einen weiteren Slave-Select-Impuls sendet ist die Übertragung 
beendet - richtig so?

Ich habe vor alle 200µs 4 mal 16 Bit zu übertragen. Bei beiden 
Controllern handelt es sich um dsPIC33F256 @ 40 MIPS (16Bit-Mode + 
Slave-SS-disable möglich). Ich habe vor, über einen Timer-Interrupt im 
Master die Anfrage an den Slave auszulösen. Danach sendet der Master 4 
mal ein Request (jedes mal wenn Interrupt beim SPI-Empfang aufgetreten 
ist) dabei überträgt der Slave seine Daten. Der Slave schreibt die Daten 
via DMA direkt aus dem RAM in den Puffer (bei jedem 
SPI-Empfangs-Interrupt). Das sollte doch so funktionieren ohne das die 
PIC's nur damit beschäftigt sind die SPI-Schnittstelle zu bedienen - 
oder?

Hallo,

zu Deinem Szenario: Ein Slave erzeugt nicht das CS-Signal. Er kann nur 
etwas auf Anfrage des Masters ( SCLK-Clock-Signal ) senden. Das Problem 
ist, dass Du Deinen beiden "Kommunikationspartnern" den selben Status 
zukommen lassen willst. Genau das ist aber nicht das Konzept von SPI, wo 
Du prinzipiell mit zwei Hierachie-Ebenen arbeitest. In Deinem Fall 
müsstes Du also Deinen Master bestimmen lassen, wann der Slave etwas 
senden soll. Dafür würde ich dann den Master regelmäßig pollen lassen. 
Was ich finde was für Dich viel besser geeignet wäre, ist eine 
Verbindung mittles UART. Hierbei benötigst Du nur zwei Leitungen und 
kannst von beiden Seiten jederzeit Nachrichtenpakete nach belieben 
versenden. Wenn Du die UART für die uC-Programmierung über RS232 
verwendest, könntest Du auch die Alternativen prüfen. Pic's hab ich 
bisher immer nur so geflasht und kenne die sonstigen Möglichkeiten daher 
nicht. Ich bin mir aber ziemlich sicher, dass es für Pics`s etwas 
Vergleichbares wie die Programmierung über ISP oder JTAG bei den Atmels 
geben muss. Zu Deiner letzten Frage: Je mehr Interrupts Du auslöst, 
desto mehr wird Dein Hauptprogramm aufgehalten, um diese bearbeiten.