Hallo Forum, leider haben sich doch noch einige Merkwürdigkeiten eingestellt: die unten stehende Routine soll Daten von einem Slave abfragen: der erste Schritt hierzu ist der Aufruf des Registers $38 im Slave. Nach der Übertragung des Bytes (funktioniert) soll der Slave Daten an den Master ausgeben (funktioniert nicht). Was mir dabei auffällt ist, das beim Senden des Bytes $38 8 Taktimpulse an SCK auftreten und das Bitmuster über MOSI an den Slave ausgegeben werden während in der Empfangssequenz keine Taktimpulse vorhanden sind. Das Progrämmchen verbleibt in der Schleife "warten1". Müssten nicht auch in der Empfangsroutine 8 Taktimpulse auftreten? Möglicherweise habe ich einen Fehler drin, aber ich sehe den einfach nicht....... Hier die Routine ;------------------------------------------ UP RX ----------------------------------- RX: ldi slave_reg,$38 cbi portb,ss ;enable Slave nop sbi spcr,spe ;SPI einschalten nop out spdr,slave_reg ;register $38 v. Slave wählen und senden rcall warten1 rcall time_1us ;Interbyte Time 1µs sbi spcr,spe ;enable SPI in rx_data,spdr rcall warten1 nop sbi portb,ss ;disable Slave rcall time_100us ;0.1mS warten, dann weiter rcall time_100us ;0.1mS warten, dann weiter rjmp RX ;------------------------------------------- UP Warten ------------------------------ warten1: sbis spsr,spif ;wenn Flag gesetzt, nächstes Byte rjmp warten1 ;sonst noch warten cbi spcr,spe ;SPI abschalten cbi spsr,spif ;spif löschen ret Danke für eure Mühe, es grüßt Günter (Dino)
Moin Günter. Komisch womit ich keinerlei Probleme bislang hatte ist die SPI Ich programmier mit angeschlossen SPI Slave-> keine Probleme Was mir ja nicht ganz klar ist warum schaltest du die SPI denn 2 mal ab ? In jeder Warteschleife. Und warum löscht du das SPIF eigentlich ? Es wird doch nach einem erfolgreichen Transfer gesetzt. Dh wenn du durch einschreiben ins SPDR einen neuen Transfer startest Ist das flag wieder neu gesetzt Was mir auch nicht klar ist Im 2ten Progteil liest du Daten ein das hättest du doch gleich machen können #in rx_data,spdr #rcall warten1 Du schreibst ja nichts in SPDR was soll sich da ändern? BZW das SPIF ist jetzt garantiert 0 ---->kann ja nicht anders ( Da kann die Warteschleife ja nie verlassen werdn ) Hab mal meine Routine hier kommentiert. Schiebt und 16bit in den Slave und liest 16bit vom Slave Das läuft eigentlich so: Durch schreiben ins SPDR schickt der Master dem slave 8bit daten UND empfängt gleichzeitig vom Slave 8bit Ist der Transfer beendet. Sind die Daten vom Slave im SPDR Und können aausgelesen werden Das SPIF zeigt ob die Aktion erfolgreich war. Hab mal ne frühere Assy Routine drangehängt. Die tut ohne probleme. ADC_WRITE: ; Abfrage Busy Status vom SPI Slave ADC_WRITE: sbis PINB,BUSY rjmp ADC_WRITE ;Slave ready? also Daten tausch cbi PORTB,CS ; Dummy zum Slave out SPDR,OUT_HB_R ;Transmission H_Byte finished ?> send low bit else wait AW1: sbis SPSR,SPIF rjmp AW1 ; Daten vom Slave in IN_HB_R,SPDR nop ;Dummy Daten zum Slave out SPDR,OUT_LB_R ;Transmission L_Byte finished ?> send low bit else wait AW2: sbis SPSR,SPIF rjmp AW2 in IN_LB_R,SPDR sbi PORTB,CS Das wars Phagsae
Moin Phagsae, habe mal das Datenblatt von dem CMX813 beigepackt. Vermutlich habe ich mich auch etwas blöd ausgedrückt. Schau es dir mal an, besonders das Timing auf Seite 20. Es drückt wohl mehr aus als 1000 Worte. Mittlerweile habe ich die Aussage, das es mit dem SPI und diesem IC überhaupt nicht funktionieren soll....... Mist!!! Danke dir erstmal und schönen Gruß, Günter
Moin moin Eigentlich schaut das ziemlich gut aus vom timing Wo siehst du denn probleme ? Einer von uns beiden steht auf dem schlauch. Wer solll denn im 2. Programmteil Den Clock lieferfern ?? Der CMX tut da gar nix. Der Clk ist pD immer Input also kann der CMX kein Master werden Wenn du Daten vom Slave haben möchtest musst Richtung Slave schreiben!!!!!!!!!!. Oder der Slave wird zum master Aber das kann der CMX eigentlich nicht Hab allerdings das Datenblatt nur füchtig gelesen. Der SCLK ist n u r Als Eingange definiert Also passiert folgendes Der uC ist eine Slave und wartet auf den SPI Clock ( Da kann er lange warten ) Phagsae
Hi Phagsae, genau das ist das Problem. Der CMX kann den Clock nicht liefern. Er verlangt die Registeradresse z.B. $3f + Clock, was ja auch klappt. Dann aber muss nach einer kurzen Pause der Clock neu starten damit das Register ausgelesen werden kann. Und das geht nicht. Wie gesagt, das initialisieren des CMX geht, er arbeitet auch so wie er soll d.H. er liefert auch einen Interrupt. Funktioniert also. Ich werde aber mal was Hardwaremäßiges probieren: Das Mosi-Signal lasse ich mal über ein UND-Gatter laufen, einen Anschluß an Mosi, den zweiten an einen Port-Pin. Bei der Registeradressierung werde ich den Portpin auf H setzen damit das Mosi-Signal an den CMX gelangt. Bei der Abfrage lege ich den Port-Pin auf L, sende einen Dummy und nur der Clock kommt zum CMX da der Ausgang vom Gatter auf L liegt und das Register kann somit gelesen werden. Schaun mer mal, Dank und Gruß, Günter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.