Ladies, Gentlemen,
Ich bräuchte mal etwas auf die "Sprünge geholfen kriegen" zu SPI.
Eine kleine Steuerung mit Motörchen, etc. wird über einen AVR bedient.
Bisher über RS232.
Da die Steuerung nach jedem Kommando immer schwer kalkulierbare Zeit
benötigt, um "fertig" zu melden ist RS232 für mich ganz praktisch: Ich
sende halt ein Kommando und warte bis der Slave "von sich aus" etwas per
RS232 zurücksendet. (mit bischen Timeout-Drumherum)
Opional möchte ich SPI ergänzen, da dies aber Master-gesteuert ist muss
ich ja jede Antwort aus dem Slave heraus-clocken. Ich habe KEINE
BUSY-Leitung oder sowas, halt nur SCK,MOSI,MISO.
Wie würde man dies üblicherweise lösen?
Den Slave permanent per SPI abfragen, bis er statt "z.B. 0" ein
Ergebnisbyte sendet?
Oder gibt es irgendwelche Slave-seitigen Tricksereien mit den
SCK/MOSi/MISO-Pegeln, um sowas wie "busy" zu signalisieren?
Dank schonmal für ein paar Denkanstösse...
Ich habe hier einen ADC, der sein "Ready" auch auf MISO ausgeben kann.
Hat aber Nebenwirkungen:
- Keine weiteren Teilnehmer auf dem SPI Bus möglich
- Der Master muss MISO auswerten können, obwohl kein Takt und auch kein
CS=LOW ist
- Wenn der Slave Software ist, braucht er eventuell zusätzliche Zeit um
bei fallender Flanke von CS von GPIO auf SPI umzustellen, bevor der
erste Taktzylus auf SCK beginnt
Eventuell ist simples Polling einfacher.
Jim Beam schrieb:> Wie würde man dies üblicherweise lösen?> Den Slave permanent per SPI abfragen, bis er statt "z.B. 0" ein> Ergebnisbyte sendet?
Bei SD Karten macht man es genau so.
Jim Beam schrieb:> Eine kleine Steuerung mit Motörchen, etc. wird über einen AVR bedient.> Bisher über RS232.>> Da die Steuerung nach jedem Kommando immer schwer kalkulierbare Zeit> benötigt, um "fertig" zu melden ist RS232 für mich ganz praktisch: Ich> sende halt ein Kommando und warte bis der Slave "von sich aus" etwas per> RS232 zurücksendet. (mit bischen Timeout-Drumherum)
RTS/CTS hast du warum genau dafür nicht benutzt? Immerhin ist es genau
dafür da: Damit der Sender den Empfänger fragen kann, ob dieser zum
Datenempfang bereit ist und der Empfänger dem Sender auch sagen kann,
dass er zum Datenempfang bereit ist.
Jim Beam schrieb:> Opional möchte ich SPI ergänzen, da dies aber Master-gesteuert ist muss> ich ja jede Antwort aus dem Slave heraus-clocken. Ich habe KEINE> BUSY-Leitung oder sowas, halt nur SCK,MOSI,MISO.>> Wie würde man dies üblicherweise lösen?
Mit einer IRQ-Leitung natürlich. So wird das normalerweise gemacht. Wenn
der Slave von sich aus was zu melden hat, tut er das per interrupt
request kund.
Wenn du die Strippe nicht investieren willst, bleibt nur Polling. Eine
Busy-Leitung braucht man dann nicht, nur ein geeignetes Protokoll auf
dem normalen SPI-Kanal.
Man kann auch beides kombinieren. Idealerweise so, daß einerseits
Polling möglich ist, andererseits auch Interruptsteuerung. Typisches
Beispiel für so einen Slave sind z.B. die RFM12.
Jim Beam schrieb:> Opional möchte ich SPI ergänzen
Wo? Auf beiden Seiten? Dann kannst Du die 3 Leitungen doch beliebig
missbrauchen. Eine aussuchen, Portpin parallel, ggf. Widerstand oder
Gatter beim slave, und im master auswerten. Du kannst z.b. slave-out
invertieren.
Pollen ist aber sauber und gut, wenn's geht, machen.
Du kannst neben den 4 nötigen SPI-Leitungen noch eine 5. Leitung als
Interrupt benutzen. Sobald der Slave ein Byte in das Senderegister
gestellt hat, zieht er sie auf low und der Master kann es raustakten.
Jim Beam schrieb:> Wie würde man dies üblicherweise lösen?
Man würde entweder
A) das erste Bit, das vom Slave zurückkommt, als Ready-Bit nehmen. Dann
kann man bei geeignetem SPI Mode und aktivem SS# das Busyflag schon ganz
ohne Takt lesen. Oder man könnte es per Polling eintakten.
Oder man könnte
B) eine zusätzliche Busy-Leitung auf einen Portpin/Interrupteingang
legen.
Beide Ansätze haben Vor- und Nachteile. Einfacher handzuhaben ist der
Ansatz B.
Jim Beam schrieb:> Ich habe KEINE> BUSY-Leitung oder sowas, halt nur SCK,MOSI,MISO.
Das ist eine Leitung zuwenig. Man braucht praktisch immer auch noch CS.
Hier gab es in der Vergangenheit regelmäßig Beiträge wo Leute das
Problem hatten das beim Einschalten zusätzliche SCK Pulse erkannt wurden
und so die SPI Daten um ein oder mehrere Bits verschoben sind.
CS löst das Problem weil dort der Bitzähler bei der fallenden Flanke auf
Null gesetzt wird.
Jim M. schrieb:> CS löst das Problem weil dort der Bitzähler bei der fallenden Flanke auf> Null gesetzt wird.
Es gibt einige ICs, die auf ein Startbit synchronisieren, z.B. der
MM5450. Wenn man dort 35 mal 0 einschiebt, ist das Register garantiert
synchron und übernimmt ab dem nächsten 1-Bit korrekt die Daten.
Nur bei solchen ICs darf man /CS dauerhaft auf GND legen.
Lothar M. schrieb:> A) das erste Bit, das vom Slave zurückkommt, als Ready-Bit nehmen. Dann> kann man bei geeignetem SPI Mode und aktivem SS# das Busyflag schon ganz> ohne Takt lesen.
Das kann in der Tat klappen, in den Modis mit CPHA = 0 wird das erste
Bit ja schon ohne Taktflanke angelegt. Der Master muß dann beim Lesen
immer das letzte Bit = 1 senden und für MISO den PCINT enablen oder MISO
pollen.
Das Protokoll wird dann etwas komplexer, da ja immer nur 7 Bit Daten
möglich sind.
Dann kommt man mit nur 4 Leitungen aus.
