SPI hängt im while (!(SPSR & (1<<SPIF)))

[Schorsch (Gast)]

Hi,

wiedermal ein SPI Problem:

muß über SPI 16bit übertragen. Klappt auch alles, hab der Logic Analyser 
nachgesehen. Wenn ich den Befehl eine Sekunde später nochmal 
rausschicke, bleibt er im while (!(SPSR & (1<<SPIF))) {} hängen. Ich 
sehe, dass nicht geclockt wird. Was mache ich falsch?

Hier meine Init-Routine:

SPI_init(void) {
  DDRB = _BV(PB1) | _BV(PB2) | _BV(PB4) | _BV(PB5) | _BV(PB6) | _BV(PB7);
  DDRB &= ~_BV(PB3);
  PORTB = _BV(PB4) | _BV(PB5) | _BV(PB6) | _BV(PB7);
  SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPR0) | _BV(SPR1);
  spi_status = SPSR;  
}

hier der Teil meine Senderoutine, der SPI anspricht

    PORTB &= ~_BV(PB4);
    SPI_send(highByte);
    SPI_send(lowByte);
    PORTB |= _BV(PB4);

was highByte und lowByte ist, ist erstmal egal, wie gesagt es wird gar 
nicht geclocked...



und hier der SPI_send command

void SPI_send (unsigned char data) {
  uart_puts("sending SPI\n\r");
  SPDR = data;              
  uart_puts("before while...\n\r");
  while (!(SPSR & (1<<SPIF))) {}
  uart_puts("ready!\n\r"); ///< Wird nicht mehr angezeigt
}

Ah ja, ich benutze eine atmega64

Gruß und Danke für alle tips

Schorsch

[Stefan E. (sternst)]

Schorsch schrieb:
> Was mache ich falsch?

SS ist nicht auf Ausgang geschaltet.

[Schorsch (Gast)]

Stefan Ernst schrieb:
> SS ist nicht auf Ausgang geschaltet.

Hallo,

wie gesagt, einmals gehts, das zweite mal nicht....

und er würde auch SCK senden, wenn CS nicht Ausgang wäre.

Dennoch Danke

Schorsch

[Karl H. (kbuchegg)]

Schorsch schrieb:
> Stefan Ernst schrieb:
>> SS ist nicht auf Ausgang geschaltet.
>
> Hallo,
>
> wie gesagt, einmals gehts, das zweite mal nicht....


Schalte den SS-Pin (PB0) einfach mal auf Ausgang. OK?

> und er würde auch SCK senden, wenn CS nicht Ausgang wäre.
>

Und wo soll das passieren (auf Ausgang schalten)?
Hier
SPI_init(void) {
  DDRB = _BV(PB1) | _BV(PB2) | _BV(PB4) | _BV(PB5) | _BV(PB6) | 
_BV(PB7);
jedenfalls nicht.
Du fummelst zwar an jeder Menge Pins rum, die nichts mit SPI zu tun 
haben, aber am entscheidenden SS Pin (PB0) tust du nichts.

[Stefan E. (sternst)]

Schorsch schrieb:
> und er würde auch SCK senden, wenn CS nicht Ausgang wäre.

Ich meine nicht den Pin, den du als CS benutzt, sondern den SS-Pin des 
SPI-Moduls des Controllers (PB0).

[Schorsch (Gast)]

Karl Heinz Buchegger schrieb:
> Schalte den SS-Pin (PB0) einfach mal auf Ausgang. OK?

Hallo,


erstaunlich.....

...in der Tat ich hatte im Datenblatt nur diesen Satz gelesen

> When the SPI is configured as a Master (MSTR in SPCR is set), the user
> can determine the direction of the SS pin

damit war die Sache für mich gegessen und SS spielte keine Rolle mehr, 
wenn ich aber drei Zeilen weiter gelsen hätte

> If SS is configured as an input, it must be held high to ensure Master
> SPI operation.

wäre das nicht passiert

schäme mich :(



Ihr seid super,
Vielen Dank


Schorsch

[Purzel H. (hacky)]

So ganz nebenbei, pollen in dieser Form, blockierend, ist beliebig 
schlechter Stil

[Knut B. (Firma: TravelRec.) (travelrec)]

Wenn das SPI sehr schnell ist, geht das gar nicht anders, da die 
Interruptbearbeitungszeit u.U. länger als eine Bytelaufzeit ist. Es 
kommt auf den Verwendungszweck an ;-)

[Schorsch (Gast)]

Siebzehn und Fuenfzehn schrieb:
> So ganz nebenbei, pollen in dieser Form, blockierend, ist beliebig
> schlechter Stil

Hallo,

für konstruktive Kritik bin ich jederzeit offen.

Wie würdest Du es vorschlagen?

Schorsch