>da wird aber nichts weiteres zu geschrieben, was ich benötige.
Dann sag doch mal welchen SPI Chip du bearbeiten möchtest.
Vieleicht kann man dir dann sagen was du benötigst.
Ich möchte den MCP23S17 nutzen. Mir gehts hier aber erst einmal allgmein
ums Verständnis.
Aber wenn
1
uint8_tspi_masterTransmit(uint8_tdata)
2
{
3
SPDR=data;
4
while(!(SPSR&(1<<SPIF)));
5
returnSPDR;
6
}
SPDR erst gesendet wird, dann verändert sich der Wert doch nicht.
Wenn der Slave auf den Wert 0xff wartet, befindet sich dann automatisch
die Antwort von meinem Slave in diesem SPDR register?
Ja, denn der SPDR des Masters bildet mit dem des Slaves ein
Schieberegister, wird ein Bit gesendet wird gleichzeitig eins empfangen.
Daher musst du auch häufig Dummy Bytes schicken, wenn Du Sensorwerte
eine einlesen willst.
Das ist Quatsch.
Im SLave kannst du natürlich nicht die Funktion spi_masterTransmit
aufrufen.
Die Sache funktioniert SLave seiteig völlig anders.
Wenn der Master seinen Transmit macht, dann muss im Slave das
rausgehende Byte bereits im SPDR Register sein.
SPI ist ein Byteaustausch. Die Begriffe Senden bzw. Empfangen verlieren
hier ihre klassische Bedeutung. SPI ist mehr ein gleichzeitiger
Byteaustausch.
Du und dein Kumpel sitzen sich am Tisch gegenüber. Jeder hat vor sich
einen Zettel auf den er etwas aufschreiben kann. Auf dein Kommando hin
(du bist der Master) nehmt ihr beide euren Zettel jeweils mit der
rechten Hand und schiebt ihn zum Gegnüber, der ihn mit der linken Hand
entgegen nimmt.
Daher: Wenn der Master sendet (den Zettel rüberschiebt) muss die Antwort
vom Slave bereits auf dem Zettel stehen (im SPDR Register), den er zu
dir rüber schiebt. Da ein Slave logischerweise auf die Art nicht sofort
auf das soeben von dir übertragene Byte antworten kann, muss der Master
daher meistens noch ein weiteres Byte nachschieben, mit der er sich dann
die richtige Antwort auf das zuvor übertragene Kommando holt. Dabei aber
nicht vergessen: Der Slave benötigt seinerseits ein wenig Zeit um die
Antwort bereit zu stellen.
Der Slave kann von sich aus überhaupt nichts machen. der Slave kann nur
warten, bis sich der Master sein Byte geholt hat und im Gegenzug
gleichzeitig das nächste Byte geschickt hat.
1
SPDR=255;
2
3
while(1)
4
{
5
uint8_treceiveData;
6
if(PINA&(1<<PINA7)){
7
// das erhaltene gleich wieder ins SPDR stellen, so dass
8
// es der Master in der nächsten Runde wieder zurück kriegt.
Hermann Mikroc schrieb:> hab mal versucht das ganze mit zwei AVRs zu machen
Slave SPI mit einem Controller ist nichts, was man sich als
Anfängeraufgabe aufstellt. Anders als ein in Hardware realisierter
SPI-Slave ist ein Controller ziemlich langsam. Die Zeit, die er
braucht, bis er auf ein Kommando des Masters hin seine Slave-Daten
bereitstellen kann, ist viel länger als bei den üblichen per SPI
angesprochenen ICs.
Konzentrier' dich also lieber drauf, deinen eigentlichen Slave zum
Laufen zu bekommen, statt mit einem Slave-AVR noch eine zweite
Baustelle aufzumachen.
Und nochmal: damit du ein Byte empfangen kannst, musst du ein Byte
zuvor senden und dann auch warten, bis es rausgetaktet ist. Daher
empfängt man per SPI Daten typischerweise, indem man ein Dummy-Byte
ausgibt. Du musst also minimal den Opcode (8 Bit), eine
Registeradresse (8 Bit) und ein Nullbyte (Dummy-Byte) schreiben,
erst danach kannst du den Inhalt des adressierten Registers lesen.
Zwischendrin muss /SS auf low bleiben.