SPI an ATmega8515L funktionier nicht

hallo.

vielleicht hilft dir das weiter (datenblatt seite 131):

"If SS is configured as an input, it must be held high to ensure Master 
SPI operation. If the SS pin is driven low by peripheral circuitry when 
the SPI is configured as a Master with the SS pin defined as an input, 
the SPI system interprets this as another Master selecting the SPI as a 
Slave and starting to send data to it. To avoid bus contention, the SPI 
system takes the following actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. 
As a
result of the SPI becoming a Slave, the MOSI and SCK pins become 
inputs."

es wäre evtl. sinnvoll, SS auch noch ans oszi zu hängen.

gruß

michael

danke für den tip - ss is bei mir ein output und auf +3.3V. am oszi sehe 
ich da auch keine änderung.
Ich hätte da noch eine andere frage:
ich möchte aus einem slave daten lesen. dazu sende ich vorher ien 
command byte. aber wie bringe ich meinen controller dazu noch 8 takte zu 
senden, um die daten aus dem slave zu clocken un zu empfangen?

Wie groß hast du die zu übertragende Datenlänge eingestellt ?
SPI kann auch eine Datenlänge von 1 (BIT) bis zu 16 (Bit), hängt vom µC 
ab was geht.

Wenn du ein Byte übertragen willst muss die Datenlänge auf 8 stehen.

Soll nach dem Commandbyte eine antwort kommen, dann musst du vom Master 
ein Dummybyte senden. Nur der Master taktet den SPI Bus.

ich glaub der uc kann nur 8 bit.
das mit dem dummybyte hab ich versucht - also ich hab einfach nochmal 
0x00 in das SPDR geschrieben - am oszi sehe ich auch die takte, aber vom 
slave kommt nichts...

Hat der Slave denn schon sein Datenbyte ins Schieberegister gelegt , 
wenn du das Dummybyte sendest ?

sollte er - laut datenblatt sollte das lesen der daten immerhin mit 
50MHz funktionieren - mein takt liegt bei 125kHz. oder sehe ich das 
falsch?

Du bekommst auf dem Slave den Datenempfangen IRQ; dann musst du dort das 
Commandobyte auswerten und das entsprechende Antwortbyte ins 
Schieberegister legen, das dauert seine Zeit.
Was machst du auf dem Master ?  Dort schickst du das Dummybyte direkt 
nach dem Commandobyte, stimmts ?

Um das zu lösen brauchst du eine Synchronisation zwischen den beiden 
Micros.

dazu gibt es zwei Möglichkeiten.
1. der Master wartet nach de, senden des 1. Bytes eine gewisse Zeit, in 
der sichergestellt ist, das der Slavemicro den IRQ abgearbeitet hat und 
das Datenbyte im Sendebuffer liegt.

2. Du verwendest eine zusätzliche Hardwareverbindung zwischen den beiden 
Micros. Das Busy signal. Mit diesem Signal kann der Slave den Master 
anhalten bis er fertig ist, und gibt dann den Master frei, der darauf 
hin den Dummy sendet.

Ein SPI Bus besteht aus mindestend 3 Signalen ; Clock, MISO,MOSI; und 
aus zwei optionalen Signalen ; Chipselect CS und Busy.
direktion    Master   Slave
Clock        Output   Input
MOSI         Output   Input
MISO         Input    Output
CS           Output   Input
Busy         Input    Output

Sollte dein µC die optionalen Signale nicht per Hardware unterstützen , 
musst du das in SOftware mit IO PIN's erledigen.

also der slave ist kein controller sondern ein serielles flash.
es gibt noch die leitungen CS Hold(zum anhalten der verbindung) und WP 
(writeprotect)
es sieht im moment so aus:
egal was ich aus dem slave lesen möchte (statusbyte, hersteller id, 
usw..)
die MISO leitung bleibt solange high, bis vom slave die antwort kommen 
sollte. dann wird sie auf low gezogen (allerdings alle 8 takte lang) 
d.h. ich lese immer 8 nullen, obwohl zumindest bei der hersteller id 
eine zahl (20h) zu lesen sein müsste.

kann das am spi bus liegen oder liegt es eher am slave?

so ich hab jetzt was rausgefunden: wenn ich die MISO leitung vom 
ontroller trenne, und den takt reinschicke, kommen die daten raus.
sobald ich die leitung am controller wieder anschließe, bekomm ich immer 
ein high, außer da wo die daten kommen sollten bekomm ich 8 nullen.
woran kann das noch liegen?

Bist du sicher das du MISO am µC als Input configuriert hast ?
Ist ein Pullup/Pulldown in der Leitung, externer oder interner im µC ?

danke - ich hab das problem gefunden - die masseleitung zum testboard 
war gebrochen.