Hi, ich versuche gerade eine SPI Verbindung zwischen einem K60N512 und einem Gs1500M aufzubauen. Es ist das erste mal das ich mich mit sowas beschaeftige. Den SPI habe ich auf 1,2 MHZ mit CPOL = 0 und CPHA = 0 konfiguriert. Auf dem angehaengten Bild sind MISO (Gruen) und der MOSI (Gelb) zu sehen. Mir ist aufgefallen, das der Slave immer nur auf das erste byte antwortet und dann nichts mehr macht ausser rauschen. Ausserdem bin ich ein wenig verwirrt, warum der MOSI von low zu high wechselt und der MISO von high zu low. Ist das normal oder ist es eine Einstellungssache? Ist es ueberhaupt wichtig? Ich bin dankbar fuer jede Hilfe, die ich kriegen kann!
Plotte mal CS! Dein MISO zeigt nicht selektierten Slave, d.h. MISO ist nach dem 1. Byte hochohmig und MOSI koppelt kapazitiv/induktiv während der weiteren Übertragung ein. Man sieht schön den langsam ansteigenden MISO, der von irgendeinem weak Pullup gezogen wird.
Hol Dir mal die Clock-Leitung mit dazu - so sieht man ja gar nicht, wo das Protokoll anfängt. Und bischen breiter in der Auflösung wäre auch gut. Die Clock-Polarität ist schon entscheidend. Sie muss so sein, wie der Slave sie braucht (steht im Datenblatt), damit der Slave die Mosi auf der richtigen Clock-Flanke liest. Wenn Du Dir also sicher bist, dass Dein gesendetes Protokoll stimmt, dann kannst Du die Antwort auswerten. Das "Rauschen" ist wahrscheinlich nur "übersprechen" von der Mosi.
Paul schrieb: > Mir ist aufgefallen, das der Slave immer nur auf das erste byte > antwortet und dann nichts mehr macht ausser rauschen. Schalte auf deinem Oszi mal den Roman weg ;-) Und zieh MISO mal z.B. mit einen (hochohmigen) Spannungsteiler auf VDD/2. Dann siehst du klarer, wann jemand die Leitung irgendwo hin zieht und wann die Leitung im Tri-State in der Luft hängt.
Danke fuer die Hinweise, hat mir schon sehr geholfen. Ich hab jetzt mal noch den CS und den Clock abgebildet. Ausserdem hab ich auch noch ein Beispieldiagramm gefunden, wenn ich das richtig sehe, dann sind mein CS und mein Clock in Ordnung. Im Datenblatt bin ich auf folgenden Satz gestossen. "SPI chip select (MPSISI_CS0 or MPSI_CS1) signals frame each data word. If the chip select is required to remain asserted for multiple data words, then a GPIO pin should be used for the chip select instead of the SPI chip select signals" Heisst das, ich muss bei jedem byte den CS an und wieder aus machen? Mike schrieb: > Und zieh MISO mal z.B. mit einen (hochohmigen) Spannungsteiler auf > VDD/2. Dann siehst du klarer, wann jemand die Leitung irgendwo hin zieht > und wann die Leitung im Tri-State in der Luft hängt. Ich bin leider nur ein doofer Informatikstudent und weiss nicht wie das geht :-D
Paul schrieb: > Ich bin leider nur ein doofer Informatikstudent und weiss nicht wie das > geht :-D Ganz einfach mit zwei Widerständen (z.B. 100kΩ)
1 | VDD -- 100k --+-- 100k -- Gnd |
2 | | |
3 | MISO/Oszi |
Hi, das Datenblatt würde ich so interpretieren: das heisst du musst im Datenblatt des Slaves schauen ob dein Slave bei einem Transfer von mehreren Bytes das Chip Select die ganze Zeit über aktiv haben will oder ob er nach jedem Byte wieder inaktiv werden soll. Im ersten Fall musst du den Chip select des Slaves an einen GPIO des Masters hängen und per Software steuern, im 2. Fall dierekt vom CS Ausgang des Masters. LG Karl
Irgendwie verschluckt sich die CLK Leitung und genau dann rastet der MISO aus. Wie sieht denn der Code vom Takt erzeugenden Przessor aus und welcher ist es? Schalteste ausversehen die Clockpolarity vom SPI um während der Übertragung?
Auf clockZoom.jpeg sieht man ja deutlich, dass du die Constraints bzgl. der Clock nicht einhältst. Das heißt das Problem liegt bei der CLK-Erzeugung in deinem Controller.
Vielen Dank fuer die Hinweise! Ich habe die Verbindung nun hinbekommen. Es lag am Chipselect, dieser muss naemlich alle 8bits einmal kurz aktiv werden.
Sicher nicht, durch das CS Umschalten verhinderst du sicher nur den Clockskew. Guck also nochmal nach was beim Takerzeiugen des Prozessors schiefgeht.
Hmm also so sieht es jetzt aus. Am Clock hab ich auch was geandert, aber das war noch vor dem CS . Deswegen hab ich das jetzt nich als Ursache erkannt. Den Code fuer den CLK habe ich von SPI2_BASE_PTR->CTAR[0] = (SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(4) | SPI_CTAR_PBR(2) | SPI_CTAR_DBR_MASK ); zu SPI2_BASE_PTR->CTAR[0] = (SPI_CTAR_FMSZ(7) | SPI_CTAR_BR(4) | SPI_CTAR_PBR(2) | SPI_CTAR_DBR_MASK | SPI_CTAR_CSSCK(3) |SPI_CTAR_PASC(2) ); geaendert. Eine Beschreibung des Register kannst du hier nachlesen http://www.freescale.com/files/32bit/doc/ref_manual/K60P144M100SF2RM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation (Seite 1408)
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.