SPI Clock Rate Select

[Stefan H. (stefan0985)]

Hallo

ich hab folgendes Timing Diagram einer SPI schnittstlelle (siehe anhang) 
und bin gerade dabei in einem uC (atmega128) diese zu implementieren.
habe aber noch relativ wenig erfahrung sowohl mit uC als auch mit der 
SPI schnittstelle.
deshalb nur um sicher zu gehen. sehe ich das richtig, dass ich die Clock 
Rate Select auf fosc/8 stellen muss (im SPI controll register spcr das 
register spr auf fosc/8)? da während einem SCK cycle 8 CLK cycles sind?
oder bin ich komplett auf dem holzweg?

vielen dank

[Rainer U. (r-u)]

Wenn man mal annimmt, daß nSCS das ChipSelect (SlaveSelect) ist, hast Du 
für SPI irgendwie eine Leitung zuviel (was ist SCK?)

Bei SPI gibt es meist nur eine maximale Geschwindigkeit, ob Du also 
fosc/8 einstellst oder langsamer, spielt keine Rolle - solange Dein 
Slave fosc/8 kann.

[Stefan H. (stefan0985)]

Danke schon mal Rainer.
aber warum hab ich 1 leitung zu viel?

SDI und SDO klar
nSCS-SlaveSelect
SCK ist Shift Clock-Schiebetakt

CLK ist halt der takt mit dem der uController betrieben wird und der IC 
der über SPI gesteuert wird.
Und fosc teilt doch dann diesen takt. in dem Diagram welches ich 
hochgeladen hab wäre dies doch dann fosc/8?!?!?!?!

[Rainer U. (r-u)]

Ach so. Normalerweise hat man den Systemtakt nicht im SPI-Diagramm, da 
nicht relevant.

Soll Dein uC SPI-Master oder SPI-Slave sein?

[Stefan H. (stefan0985)]

uC ist SPI-Master

[Stefan H. (stefan0985)]

jetzt ist mir grad nochmal was aufgefallen und zwar warum werden in 
anderen SPI timing diagrammen sdo und sdi gleichzeitig eingelesen? z.B.

http://en.wikipedia.org/wiki/File:SPI_timing_diagram.svg

aber in dem diagramm von mir sind die bits auf SDO um ein halbes 
SCK-Intervall versetzt, gegenber SDI? was meiner meinung nach auch sinn 
macht, weil wenn ich CPHA=1 setzte werden die Daten bei fallender 
Taktflanke eingelesen, bei steigender ausgegeben

kann mir das jemand sagen? danke schön

[Rainer U. (r-u)]

SDI wird (vom Master aus gesehen) nicht eingelesen, sondern ausgegeben. 
Beides kann man gleichzeitig oder eine Flanke versetzt, kommt auf den zu 
steuernden SPI-Chip an (Bei Deinem ist es halt versetzt).

Wenn das da oben Dein Systemtakt ist, dann wird es nicht leicht, 
insbesondere nach 8 gesendeten Bits, so schnell (innerhalb von 8 
Taktzyklen, kein Eingangspuffer) das SPDR zu lesen und nachzuladen. In 
Assembler und ohne Interrupt-Nutzung aber evtl. möglich.

fosc/8 würde passen.

[Stefan H. (stefan0985)]

Hallo Rainer

ich bin echt super dankbar, dass du mich hierbei ein bisschen 
unterstüzt, aber ich verstehe nicht ganz was du meinst mit "innerhalb 
von 8 Taktzyklen  das SPDR zu lesen und nachzuladen". (du meinst 8 SCK 
taktzyklen?; lass uns CLK einfach mal ignorieren weil es wie du ja schon 
gesagt hast im prinzip nicht relevant ist)
ich versuch mal möglichst einfach zu erklären was ich glaube  wie die 
übertragung abläuft wenn ich ein Datagramm lesen möchte.
nachdem SPI initialisiert ist, sende ich: SPDR=(Bit39-Bit32 (SDI)) dann 
warte ich bis übertragung beendet ist (while(!(SPSR & (1<<SPIF)));)dann 
les ich SPDR: (bit39-bit32(SDO))=SPDR was währenddesen passiert (wieviel 
taktzyklen ins land streichen) müsste doch egal sein?! weil SCK auf high 
steht (also in ruhe) und als nächstes sende ich: SPDR=(Bit31-bit24(SDI)) 
warte wieder bis übertragung beendet ist und lese dann SPDR: 
(bit31-bit24(SDO))=SPDR usw. bis bit7-bit0 gesendet empfangen ist.

wo brauche ich da einen eingangspuffer? wo denkst du könnte ich da 
schwierigkeiten bekommen. oder beachte ich dabei nicht, dass die SDI und 
SDO bits versetzt sind?


Nochmals

VIELEN VIELEN DANK

[Rainer U. (r-u)]

Also wenn Du nicht exakt 8 Systemtakte einhalten mußt, sondern 
mindestens 8 Systemtakte, dann kannst Du das so machen. dann ist es aber 
acuh irrelevant, ob Du nun fosc/8 oder langsamer einstellst.

Versuche es und fang mit einem langsamen SPI-Takt an und steigere das 
Tempo dann - Du wirst ja sehen, wie schnell Dein Programm mit SPDR lesen 
/ schreiben hinterherkommt.

[Stefan H. (stefan0985)]

so werd ich's machen
habe glaube einiges verstanden durch diesen kleinen dialog

also nochmals viel dank

[Werner B. (werner-b)]

>Wenn das da oben Dein Systemtakt ist, dann wird es nicht leicht,
>insbesondere nach 8 gesendeten Bits, so schnell (innerhalb von 8
>Taktzyklen, kein Eingangspuffer) das SPDR zu lesen und nachzuladen. In
>Assembler und ohne Interrupt-Nutzung aber evtl. möglich.

Nicht ganz. Wenn der uC der Master ist, dann gibt dieser den Arbeitstakt 
vor. Nachdem das alles synchron zu SCL ist, hat der Master per 
Definition "NIE" timing Probleme, da er SCL erzeugt. Hat er gerade etwas 
anderes zu tun (z.B. Daten weg- bzw. heranschaffen) dann hält er SCL 
eben an. Anders ist es mit dem in den AVRs implementierten SPI Interface 
auch gar nicht möglich, da dieses ungepuffert ist. Zwischen zwei Bytes 
wird es immer eine kleine Pause geben wenn ein neues Byte in das SPDR 
Register geladen wird. Das stört aber den Slave überhaupt nicht ob die 5 
Bytes (40 Bit) als zeitlich kontinuierlicher Datenstrom eintreffen, oder 
ob jedes 8te Bit mal ein kleine Pause ist. In einem anderen Fred habe 
ich gar gelesen, dass das Hardware-SPI nicht funktioniert wenn man keine 
Pause lässt (etwa indem man in Assembler die Taktzyklen exakt anpasst 
und das neue Byte exakt dann in SPDR schreibt, wenn dieses nach dem 
Timing wieder frei sein muss).

Sich Sorgen um den den Systemtakt des uC im Master SPI Modus zu machen 
weil dieser "zu langsam" sein könnte ist absolut unnötig. Das SPI 
Interface (Master) wird immer langsamer sein. Probleme kann nur der 
Slave machen, indem der SPI Takt zu schnell ist. Ich mache mir ja auch 
keine Sorgen dass ich zu langsam Kaue und Schlucke und darum am Essen 
ersticke, solange ich mir dieses selbst in den Mund schiebe.