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
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.
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?!?!?!?!
Ach so. Normalerweise hat man den Systemtakt nicht im SPI-Diagramm, da nicht relevant. Soll Dein uC SPI-Master oder SPI-Slave sein?
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
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.
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
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.
so werd ich's machen habe glaube einiges verstanden durch diesen kleinen dialog also nochmals viel dank
>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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.