ATmega8 SPI für 74HC595 funktioniert nicht. Code?

[Stammgast (Gast)]

Hi!

Beschäftige mich noch nicht so lange mit den "nackten" AVRs, habe aber 
davor etwas mit Arduino gemacht.

Nun steht das Ansteuern eines 74HC595 Schieberegisters an, dies 
funktioniert aber nicht, hoffentlich kann mir einer von euch 
weiterhelfen.

Ich denke, dass es am Code liegt.
Diesen habe ich aus dem Datenblatt bzw. aus dem Roboternetzartikel und 
die Befehle zum setzen eines Bits angepasst.

Am 74HC595 hängen an den Ausgängen a bis h LEDs mit Vorwiderständen.
Verbindung mit dem AVR ist genau wie im AVR-Tutorial unter "Ansteuerung 
per SPI-Modul".

Komisch ist auch, dass ich den ATmega nicht per ISP Flashen kann, wenn 
das Schieberegister verbunden ist. Normal?

So sieht der Code aus, es soll an den LEDs binär hochgezählt werden...

#include <avr/io.h>
#define F_CPU 1000000UL
#include <util/delay.h>

int data = 0x00;

void SPI_MasterInit (void)
{
  //Komplett aus dem Datenblatt übernommen
  DDRB = (1 << PB3);
  DDRB = (1 << PB5);
  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);
}

int main(void)
{
  while(1)
  {
    // SPDR schreiben startet Uebertragung
    SPDR = data;

    // warten auf Ende der Uebertragung für dieses Byte
    while (!(SPSR & (1 << SPIF)));
    
    
    // Strobe an RCK bringt die Daten von den Schieberegistern in die Latches
    PORTD = (0 << PB2);
    PORTD = (1 << PB2);
    
    data++;
    _delay_ms(1000);
  }
}

Liebe Grüße und schonmal danke für die Hilfe!

[Stefan (Gast)]

Schaltplan fehlt

[Eumel (Gast)]

Stammgast schrieb:
> PORTD = (0 << PB2);
>     PORTD = (1 << PB2);

Ist nicht als Ausgang gesetzt.

[Thomas E. (thomase)]

Stammgast schrieb:
> Komisch ist auch, dass ich den ATmega nicht per ISP Flashen kann, wenn
> das Schieberegister verbunden ist. Normal?
>
Nicht normal. Überprüf mal deine Hardware.

Stammgast schrieb:
>> PORTD = (0 << PB2);
>>     PORTD = (1 << PB2);

> Ist nicht als Ausgang gesetzt.

Vor allen Dingen muss /SS als Ausgang geschaltet werden.

mfg.

[Stammgast (Gast)]

Hi!

Thomas Eckmann schrieb:
> Vor allen Dingen muss /SS als Ausgang geschaltet werden.

Gute Idee ;-) Habe die Zeile

DDRD = (1 << PB2); //SS als Ausgang

hinzugefügt.

Dass man die Funktion "SPI_MasterInit()" dann auch noch aufrufen muss 
hab' ich natürlich auch verplant. Zum Glück studier' ich das nicht, aber 
ein Semester C war wohl bisher zu wenig :D

Habe jetzt nochmal folgendes ausprobiert:
Eine Led samt Vorwiderstand gegen GND hängt an PD6. Diese soll am Anfang 
der Übertragung eingeschaltet werden und danach wieder ausgeschaltet 
werden, damit man sieht, ob der Controller nicht irgendwo hängt.

Dabei sind mir mehrere Dinge aufgefallen:
Sobald ich die Zeile

DDRD = (1 << PB2); //SS als Ausgang

auskommentiere, wird die SPI_MasterInit() problemlos durchlaufen.
Wenn nicht, bleibt die LED aus.

Wenn folgende Codezeilen mit drinnen sind, geht die LED an, aber nicht 
aus. Der Controller bleibt dort irgendwie hängen?

// warten auf Ende der Uebertragung für dieses Byte
while (!(SPSR & (1 << SPIF)));
     
// Strobe an RCK bringt die Daten von den Schieberegistern in die Latches
PORTD = (0 << PB2);
PORTD = (1 << PB2);

Grüße!

[Stammgast (Gast)]

Hatte ich vorhin vergessen - Flashen mit dem AVR ISP MKII über die ISP 
Schnittstelle funktioniert jetzt, keine Ahnung was da nicht gepasst hat.

Hat sonst noch einer eine Idee, woran das liegen könnte?

Grüße!

[Karl H. (kbuchegg)]

Zeig halt mal deinen kompletten Code, so wie er jetzt aussieht.
Es ist immer ein wenig fehleranfällig, wenn man hier von einem 
fehlerhaften Programm ausgehend, gedanklich alle textuell beschriebenen 
Änderungen einsetzen soll und dann auch noch rausfinden soll was noch 
übersehen wurde.

[Karl H. (kbuchegg)]

> DDRD = (1 << PB2); //SS als Ausgang

DDRD?
Wieso DDRD?

SS ist doch nicht am Port D


> PORTD = (0 << PB2);
> PORTD = (1 << PB2);

so macht man das aber nicht.
die erste Operation ist gleichwertig zu
PORTD = 0
die zweite Operation beeinflusst alle anderen Bits an diesem Port 
ebenso.

[katastrophenheinz (Gast)]

>// Strobe an RCK bringt die Daten von den Schieberegistern in die Latches
>PORTD = (0 << PB2);
>PORTD = (1 << PB2);
Sieht komisch aus:
 PORTD = (0 << PB2); Diese Anweisung setzt alle Bits auf 0
 PORTD = (1 << PB2); Setzt Bit2, alle andere werden auf Null gesetzt

Setzen/Rücksetzen von einzelnen Bits ohne Verändern der restlichen geht 
so:

PORTD &= ~( 1 << PD2 ); <- Setzt nur Bit2 auf 0
PORTD |=  ( 1 << PD2 ); <- Setzt nur Bit2 auf 1

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

DDRB = (1 << PB3);
  DDRB = (1 << PB5);
Wie soll DAS denn auch funktionieren?
Die zwete Operation überschreibt das Register wieder.

Bei SPCR hastes dann wieder richtig gemacht oder nur von irgendwo 
zusammenkopiert.

Also schreibe:
  DDRB |= (1 << PB3);
  DDRB |= (1 << PB5);

Weiteres hier:
http://www.mikrocontroller.net/articles/Bitmanipulation


@karl:
An PORTD hat er den RCK des 595 angeschlossen und der RCK hängt wohl ned 
an SS

[Karl H. (kbuchegg)]

Martin Wende schrieb:

> @karl:
> An PORTD hat er den RCK des 595 angeschlossen und der RCK hängt wohl ned
> an SS

Mag sein.
Trotzdem sollte er PB2 auf Ausgang schalten. Sonst macht die SPI 
Hardware alles mögliche, nur nicht als Master arbeiten.

[Stammgast (Gast)]

Servus!

Erstmal danke vorneweg für eure Antworten.

Wie gesagt dies sind meine ersten Versuche (Nach LED blinken, etc..) mit 
den AVRs, davor nur Arduino, das hat mich wahrscheinlich verdorben...

Karl Heinz Buchegger schrieb:
> Zeig halt mal deinen kompletten Code, so wie er jetzt aussieht.
Gerne!

Ich habe versucht, alle angesprochenen Fehler zu verbessern:

#include <avr/io.h>
#define F_CPU 1000000UL
#include <util/delay.h>

int data = 0x00;

void SPI_MasterInit (void)
{
  //aus dem Datenblatt übernommen
  DDRB |= (1 << PB3); //MOSI als Ausgang
  DDRB |= (1 << PB5); //SCK als Ausgang
  DDRD |= (1 << PD6); //LED an PD6
  DDRB |= (1 << PB2); //SS als Ausgang
  SPCR |= (1 << SPE) | (1 << MSTR) | (1 << SPR0);
}

int main(void)
{  
  SPI_MasterInit();
  while(1)
  {
    //LED an
    PORTD |= (1 << PD6);
    //SPDR schreiben startet Uebertragung
    SPDR = data;

    //warten auf Ende der Uebertragung für dieses Byte
    while (!(SPSR & (1 << SPIF)));
    
    //Strobe an RCK bringt die Daten von den Schieberegistern in die Latches
    PORTB &= ~( 1 << PB2 );
    PORTB |=  ( 1 << PB2 );
    
    data++;
    
    _delay_ms(50);
    PORTD &= ~(1 << PD6);
    _delay_ms(500);
  }
}

RCK vom Schieberegister ist schon an SS/PB2 angeschlossen. Hatte das nur 
irgendwie falsch :-/

Funktioniert leider immer noch nicht. Ich kann nur sagen, dass der Code 
zumindest schonmal durchläuft, die LED blinkt.
Ist dies eigentlich eine passende Art, zu prüfen ob das Programm 
einigermaßen tut was es soll? Oder gibt es da intelligentere Methoden?

Grüße!

[Johann L. (gjlayde)]

http://www.rn-wissen.de/index.php/Portexpander_am_AVR

[Karl H. (kbuchegg)]

    //Strobe an RCK bringt die Daten von den Schieberegistern in die Latches
    PORTB |=  ( 1 << PB2 );   <----------------
    PORTB &= ~( 1 << PB2 );

Der Übergang Low-High sorgt dafür, dass die Daten ins Latch übernommen 
werden.

Was hast du eigentlich mit dem G Pin bzw. den restlichen Pins vom 595 
gemacht?

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:
>

>     //Strobe an RCK bringt die Daten von den Schieberegistern in die 
> Latches
>     PORTB |=  ( 1 << PB2 );   <----------------
>     PORTB &= ~( 1 << PB2 );
>

>
> Der Übergang Low-High sorgt dafür, dass die Daten ins Latch übernommen
> werden.

Wobei:
Das sollte eigentlich egal sein. Bei dir ist dann eben RCLK auf High 
während Daten reingetaktet werden.

> Was hast du eigentlich mit dem G Pin bzw. den restlichen Pins vom 595
> gemacht?

D.h. das Programm sieht soweit gut aus.
Jetzt sollte man sich mal die Hardware ansehen.

[Stammgast (Gast)]

Hi!

Sorry, dass ich mich so spät erst wieder zurückmelde, hatte sehr viel um 
die Ohren.

Habe nun den gesamten Aufbau nochmal neu aufgebaut.
Nun funktioniert auch alles ohne Probleme. Keine Ahnung was da genau der 
Fehler war, eventuell OE auf VCC oder so.

Trotzdem danke für eure Hilfe, weil im Code gab es ja auch einige 
Ungereimtheiten...


Grüße