SPI bus frage

Da der SPI-Bus ja nun mal über eine Clockleitung verfügt, ist ein Delay 
zwischen den Bytes doch unerheblich.
Wenn die Daten aus einem Buffer kommen, würde ich mich des SPIF-Flags 
bedienen und das ganze per Interruppt laufen lassen.

LG EC

danke für deinen tip!
das problem ist, das die clockleitung zwischenzeitlich unterbrochen wird 
(aufgrund einer rf schnittstelle), und auf der empfängerseite 
automatisch wieder synchronisiert wird).

der clock auf der empfangsseite läuft automatisch weiter.

Die Empfängerseite find ich interessanter. Woher weiss der, dass neue 
Daten anstehen? Da der Takt durchläuft, muss er permanent die SPI auf 
neue Daten überwachen. Da macht der mit Sicherheit nichts anderes mehr 
als nur dies, für andere Jobs bleibt keine Zeit.

auf der empfängerseite kann der rf ic diese funktion übernehmen - sobald 
eine gewisse preamble sequenz detektiert wird, wird ein interrupt beim 
controller ausgelöst welcher dan sein spi interface aktiviert.
das problem ist aber  - sobald der controller sein spi aktiviert hat und 
daten liest, läuft der takt weiter - auch wenn der sender durch das 
neuschreiben des spi databytes eine verzögerung auf der datenleitung 
verursacht. gibts hierfür eine lösung?

Normales AVR-SPI ist nicht gepuffert, damit dürfte es in dieser 
Geschwindigkeitsklasse keine Lösung geben. Das USART-SPI neuerer AVR ist 
gepuffert, da könnte man mal per Oszi nachmessen, ob bei hinreichend 
schneller Beschickung kontinuierlicher Sendebetrieb stattfindet.

Controller mit höher entwickelten synchronen seriellen Schnittstellen 
(z.B. SSP/SSC bei diversen ARM7-Reihen, u.U. mit DMA) sind da klar im 
Vorteil.

aber von den "alten" avr 8bit ris shcafft das keiner?

Der SPI-Transmitter ist ungepuffert, d.h. es bleibt bestenfalls ein 
Bruchteil der Zeit eines einzigen übertragenen Bits, um das 
Senderegister rechtzeitig wieder zu füllen. Sofern es überhaupt 
prinzipiell geht (m.E. unwahrscheinlich).

also im fall der datenübertragung ist der controller NUR damit 
beschäftigt.

Hallo

Das gibt ja schon fast Schmerzen, was hier so alles steht.


Also bei SPI ist einer der Master, der andere Slave.

Master gibt den Takt aus, Slave empfängt.

(*)
Die Daten werden auf BEIDEN controllern ins SCHIEBEREGISTER geschrieben.

Dann taktet der Master exakt soviele Takte auf der Clockleitung wie Bits 
vorhanden sind.
Das heißt: beide Controller müssen die GLEICHE Einstellung der 
Datenlänge haben.
Normalerweiße üblich ist Datenlänge 8 Bit oder 16 Bit, je nach 
Schieberegister größe. Theoretisch ist aber jede länge von 1 Bit bis 
größe des Schieberegisters möglich.

Nach der entsprechenden Anzahl der Takte wird ein Receive Data Flag im 
Controller gesetzt. Diese Flag kann IRQ auslösen oder gepollt werden.

Danach werden die Daten auf BEIDEN Controller aus dem SCHIEBEREGISTER 
ausgelesen.
Sollen weitere Übertragungen erfolgen siehe (*)


Deine Aufgabe ist es dafür zu sorgen das beide Controller bereit sind 
bevor der Master den Takt anlegt. Wenn der Master mit dem Takten anfängt 
bevor der Slave seine Daten in das Schieberegister gelegt hat, sind die 
im Master empfangene Daten MÜLL.

Den Unterschied zwischen Pollen und IRQ in Punkto Systemauslastung muss 
woh nicht mehr erklärt werden, oder ?

also zu geschwindigkeit: der rf chip schafft sowieso nur max. 384 kbit 
(die 5mhz waren nur ein "dummes" beispiel) mit uart hab ich bereits 
verschiedene tests gemacht - aber das problem ist - ohne 
synchronisierung durch einen takt ist es ab ca 150kbit/s nicht mehr 
möglich die daten sauber zu dekodieren (zumindest nicht uart)