Hallo Zusammen,
hänge grad ein einem echten Anfängerproblem.
Ich versuche über die SPI-Schnittstelle eines ATmegas16 Daten zu senden
und zu empfangen. Die Funktionen liefen ohne Probleme auf einem Atmega8.
Nun ist es aber so das das Programm an
1
while(!(SPSR&(1<<SPIF)));
hängen bleibt. Ich weis nicht warum.
Wäre toll wenn ihr mir einen kleinen Denkanstoss geben könntet.
Hallo,
wenn du den SPI als Master betreibst musst du SS (PB4) auf Ausgang
setzen, da sich der SPI sonst bei LOW-Pegel auf Slave umschaltet.
Beim M8 war SS an PB2 und das hattest du richtig eingestellt.
Sascha
Bei SPI (zumindest im Mode Master) ist es so,
dass Du zuerst was senden musst, bevor Du was empfangen kannst,
auch wenn es nur ein Dummy-Byte ist.
Also wenn ein Byte gesendet wird, dann wird das Byte nach aussen
übertragen, und zugleich ein Byte empfangen
(ganz egal, ob das angesprochene Gerät etwas zu senden hatte oder nicht)
Möglicherweise brauchst Du etwas in dieser Art:
(Senden und Empfangen vertauscht)
while(1)
{
PORTB |= (1<<PB2);
spi_senden(0x55);
data_received=spi_empfangen();
_delay_ms(50);
PORTB &=~ (1<<PB2);
}
Hans schrieb:>> wenn du den SPI als Master betreibst musst du SS (PB4) auf Ausgang>> setzen, da sich der SPI sonst bei LOW-Pegel auf Slave umschaltet.>> Wo steht das?
RTFM
Hallo,
die SPI-Schnittstelle liegt beim Mega8 an den Pins PB2 bis PB5, beim
Mega16 an den Pins PB4 bis PB7.
Ausserdem ist es keine gute Idee, den SPI-Interrupt freizugeben, ohne
eine Interrupt-Routine zu haben (und für dein Progrämmchen ist die
Freigabe auch überflüssig).
Normalerweise führt der Aufruf einer nicht deklarierten ISR zu einem
Reset des Controllers ...
>> wenn du den SPI als Master betreibst musst du SS (PB4) auf Ausgang>> setzen, da sich der SPI sonst bei LOW-Pegel auf Slave umschaltet.> Wo steht das?
Im Datenblatt des Controllers unter "/SS Pin Functionality".
Samuel K. schrieb:> Hans schrieb:>>> wenn du den SPI als Master betreibst musst du SS (PB4) auf Ausgang>>> setzen, da sich der SPI sonst bei LOW-Pegel auf Slave umschaltet.>>>> Wo steht das?>> RTFM
Wieso ist doch intressant?! Damit könnte man dann auch zwei Master
miteinander Kommunizieren lassen (nagut, wobei sich dann der eine in den
Slavemodus begibt.)
Die Routine ist mehr oder weniger aus dem Datenblatt übernommen.
Selbst wenn PB4 auf Ausgang geschalten ist hängt der Controller bei
while(!(SPSR & (1<<SPIF)));.
Auch wenn ich den SPIE heraus nehme läuft es nicht.
Das seltsame ist das ich das mehr oder weniger gleiche Progamm auf einem
ATmega zum laufen bring. Sowhol auf dem Controller wie auch in der
Simulation.
Siehe Beitrag von SPI-Master:
SPI-Master schrieb:> Ausserdem ist es keine gute Idee, den SPI-Interrupt freizugeben, ohne> eine Interrupt-Routine zu haben (und für dein Progrämmchen ist die> Freigabe auch überflüssig).Marcus K. schrieb:> Die Routine ist mehr oder weniger aus dem Datenblatt übernommen.> Selbst wenn PB4 auf Ausgang geschalten ist hängt der Controller bei> while(!(SPSR & (1<<SPIF)));.> Auch wenn ich den SPIE heraus nehme läuft es nicht.>> Das seltsame ist das ich das mehr oder weniger gleiche Progamm auf einem> ATmega zum laufen bring. Sowhol auf dem Controller wie auch in der> Simulation.
Und solange du keine ISR hast wird er sich auch immer wieder aufhängen.
Lies dir noch mal alles hier durch!
Zum Empfangen eines Bytes durch den Busmaster, also den ATmega, must du
erst senden, denn nur so gnerierst du einen Takt für die
SPI-Schnittstelle. Wenn aber keine Übertragung statt fand, dann ist das
Flag auch nicht gesetzt.
S.T schrieb:> Samuel K. schrieb:>> Hans schrieb:>>>> wenn du den SPI als Master betreibst musst du SS (PB4) auf Ausgang>>>> setzen, da sich der SPI sonst bei LOW-Pegel auf Slave umschaltet.>>>>>> Wo steht das?>>>> RTFM>> Wieso ist doch intressant?! Damit könnte man dann auch zwei Master> miteinander Kommunizieren lassen (nagut, wobei sich dann der eine in den> Slavemodus begibt.)
Ich hab ja nicht gesagt, dass es unintressant ist. Es steht halt im
Datenblatt. Kommunikation zwischen 2 Mastern würde aber heißen, dass
immer einer im Slavemodus sein muss. Sonst gäbe es unter Umständen ein
paar Kurzschlüsse auf den Datenleitungen.
Hans schrieb:> Danke für die Info(außer Samuel natürlich).
Wobei meine Antwort die erste und dazu noch richtig war.
http://lmgtfy/?q=rtfm
