Hallo Ihr, ich möchte via SPI zwischen 2 PIC's Daten austauschen. Das ganze soll ohne ChipSelect-Leitung gesteuert werden. Der Master-PIC soll dem Slave-PIC mitteilen, dass dieser Daten senden darf. Der Slave-PIC darf solange Daten senden bis der Master-PIC einen Stop-Befehl sendet. Durch die getrennten Daten- Sende- und Empfangsleitungen sollte das doch funktionieren - oder?
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.