Hallo, mein Atmega64 bekommt über SPI im Slavebetrieb von einer Komponente im Roboter 4 Init Bytes gesendet. Wenn diese 4 Bytes gesendet werden, zieht sie die Handshakeleitung runter. Dies symbolisiert dem Atmel, dass er nun Daten empfangen muss. Diese Leitung liegt bei mir auf INT6 (Interrupt wird ausgelöst, MCU ist im Slave). Ich rufe die Daten solange ab, bis sie stimmen. Doch leider werden diese erst beim 10 Interrupt-Aufruf richtig erkannt. Die Einstellungen CPOL und CPHA stimmen. Der SS Pin ist auch die ganze Zeit auf Low. Woran könnte das liegen? Ich habe schon alles ausprobiert. Wenn die Interrupts ausgeführt werden, passiert in der Warteschleife (siehe Code) nichts, sprich anscheinend springt er nie richtig zurück in die Main. Wär echt klasse, wenn ihr mir kurz helfen könnt. Ist natürlich wie immer sehr wichtig:) danke Alex
Gast
#474413
> Wenn diese 4 Bytes gesendet werden, zieht sie die Handshakeleitung >runter. ja, so funktioniert SPI. >Diese Leitung liegt bei mir auf INT6 (Interrupt wird >ausgelöst, MCU ist im Slave Die Slaveselect-Leitung liegt auf INT6? Warum? Wenn die SPI im Slave-Mode initialisiert wurde, wird der ganze Spaß über /SS (PB0) gesteuert. Solbald ein komplettes Byte empfangen wurde, wird das SPIF im SPSR gesetzt. Das löst entweder einen Interrupt aus und verzeigt in die entsprechende ISR, oder kann einfach abgefragt (Polling-Betrieb) werden. Man braucht also keine extra Interrupt-Leitungen dafür. Da ich ein grundsätzliches Verständnisproblem deinerseits sehe, hab ich keinen genaueren Blick auf dein Code geworfen. für dich sollten die Seite 162ff im Datenblatt interessant sein...
Guck dir auch mal das Timing komplett an. Wir haben hier auch mal mit einem AVR als Slave experimentiert, da merkt man richtig, dass SPI-Slave nicht für Controller gemacht ist, sondern für Hardware- Schieberegister. Mit vollem Takt kannst du das praktisch komplett vergessen, es sei denn, du weißt ganz genau, wann dein Master dir den SPI-Transfer aufdrängeln wird (und kannst da entsprechend darauf warten). Anders als z. B. bei I²C hat der Slave bei SPI keine Möglichkeit, dem Master zu signalisieren, dass er jetzt gerade noch nicht bereit ist.
Jörg hat recht, SPI-Slave möchte man nicht wirklich benutzen. Du brauchst schon ne Handshakeleitung, allerdings in umgekehrter Richtung. Der Master setzt /SS = 0 und schickt das erste Byte. Dann macht der Slave ne Flanke auf der Handshakeleitung, daß er bereit fürs nächste Byte ist. Und erst dann darf der Master weiter senden - warten - senden - warten - ... Alles andere ist Käse. Peter