SPI mit ATMEGA8 - mehrere Bits

else {  PORTD = 0b11111111; _delay_ms(100);        // schnelles Blinken, 
wenn das Signal vom Gewünschten abweicht
      PORTD = 0b00000000; _delay_ms(100);
      PORTD = 0b11111111; _delay_ms(100);
      PORTD = 0b00000000; _delay_ms(100);
      PORTD = 0b11111111; _delay_ms(100);
      PORTD = 0b00000000; _delay_ms(100);
      PORTD = 0b11111111; _delay_ms(100);
      PORTD = 0b00000000; _delay_ms(100);
      PORTD = 0b11111111; _delay_ms(100);
      PORTD = 0b00000000; _delay_ms(1000);
  }

delay?
Dir ist aber schon klar, dass man sich mit delays so gut wie jedes 
Timing zunichte machen kann?

Wenn du wissen willst, was der Slave krieg, warum gibst du dann nicht 
ganz einfach das empfangene Byte am PORTD aus? Das geht schnell und 
bringt dir nicht alles durcheinander, weil der Slave die meiste Zeit nur 
Däumchen dreht und in der SPI ein Byte nach dem anderen durchrauscht 
ohne dass der Slave sie auswertet.

Jedes mal, wenn der Master ein Byte wegschickt, gibt der Slave das Byte 
aus.

Im übrigen musst du dir noch eine Systematik überlegen, wie der Slave 
weiss, ob du nun das Highbyte oder das Lowbyte deines unsigned int 
kriegt.

> das Senden einzelner Bytes habe ich ja auch schon hinbekommen.
Na, dann passt es doch.
n Bytes zu übertragen ist nichts anderes als n mal 1 Byte zu übertragen.
Die Schwierigkeit besteht darin, dass der Empfänger weiss, welches der n 
Bytes er nun bekommen hat. Dafür musst du dir was ausdenken. 
Üblicherweise gibt es dann noch eine Leitung zum 'synchronisieren'. Das 
kann zb die SS Leitung sein (oder irgendeine andere, die du als Chip 
Select benutzt). Solange die auf inaktiv ist, ignoriert der Slave alle 
eingehenden Bytes. Kommt der Chip Select auf 'aktiv', dann zählt der 
Slave mit einem Zähler mit und weiss damit das wievielte Byte er 
bekommen hat. D.h. der Master kann damit dem Slave mitteilen: jetzt 
beginnt eine neue Nachricht aus n Bytes, setz deinen Zähler auf 0 und 
danach schick ich dir genau diese n Bytes.
(was auch immer dieses n war. WEnn das n nicht programmweit fix ist, 
dann kann der Master zb als erstes Byte übertragen, wieviele weitere 
Bytes noch kommen werden).

Du bist gerade drauf und drann zu entdecken, was ein Protokoll ist und 
warum man eines bei der Übertragung von Nachrichten, die aus >1 Bytes 
bestehen braucht und dass dich die Hardware dabei nicht unterstützt 
sondern du selbst etwas erfinden muss.
Wobei du dich vom Empfänger leiten lassen musst. Wie kann ein Empfänger 
bei einer n-Byte Nachricht rausfinden, das wievielte Byte er gerade 
bekommen hat? Das ist die Frage, die du dir stellen musst und für die du 
eine deiner Aufgabenstellung angemessene Lösung brauchst. Wenn du die 
Lösung hast, dann muss sich der Sender nach dieser gefundenen 
Lösungsvereinbarung richten. Hier hat der Empfänger erst mal das Sagen.

Karl Heinz schrieb:

> Wenn du wissen willst, was der Slave krieg, warum gibst du dann nicht
> ganz einfach das empfangene Byte am PORTD aus? Das geht schnell und
> bringt dir nicht alles durcheinander, weil der Slave die meiste Zeit nur
> Däumchen dreht und in der SPI ein Byte nach dem anderen durchrauscht
> ohne dass der Slave sie auswertet.

Um es ganz klar zu sagen:
Der Übeltäter sind die delays hier!
Das ist so, wie wenn du in ein Konzert gehst und jedesmal, wenn die 
Violinen einen bestimmten Ton spielen, haltest du dir für 10 Minuten die 
Ohren zu. Dass du dann vom Konzert nur wenig mitkriegst, dürfte auf der 
Hand liegen.

Man kann es nicht oft genug betonen:
delay_ms ist selten die Lösung aber oft genug das Problem.