SPI - Schnittstelle

Hm,
also im Datenblatt steht, das WCOL gesetzt wird wenn wärend einer 
Übertragung in das SPI Dataregister geschrieben wird (Collision). Was 
aber die Ursache ist hab ich jetzt nicht genau analysiert.
Aber mir ist eins aufgefallen: Du willst Interrupts verwenden hast aber 
keine IRQ Sprungtabelle angelegt. Das ist normal tödlich. Oder hast Du 
in einer anderen Dateri die Definition dafür? Das solltest Du in jedem 
Fall machen.

Gruß
Markus
http://www.elektronik-projekt.de/

Hi Markus,

Sprungtabelle ist vorhanden, steht an anderer Stelle. Dies hier ist nur 
nur der Versuch, einen Slave über SPI anzusprechen. Den Interrupt muss 
ich aber freigenen, weil sonst das SPIF nicht abgefragt werden kann 
(glaube ich jedenfalls).

Gruß und Dank
Günter

Hi,
also wenn ich das dem Datenblatt richtig entnehme wird das SPIF auch 
dann gesetzt wenn der IRQ nicht eingeschaltet ist. Man muß ihn nur 
einschalten wenn man mit IRQ arbeiten will.
Das andere von Dir beschriebene Verhalten könnte aber auch ein Bug im 
Studio sein.

Gruß
Markus
http://www.elektronik-projekt.de/

Jawoll Markus,

es ist für diese Routine unerheblich, ob Bit 7 im SREG gesetzt ist oder 
nicht. Ich hab das nochmal  ausprobiert.

Wenn ich die SPI Pins mal mit dem Oszilloskop anfahre, scheint es auch 
alles zu funktionieren. Aber eben sind auch per Post die fehlenden Teile 
eingetroffen (von Reichelt, gestern Mittag geordert) und nun wollen mal 
sehen obs hinhaut.

so denn,
Günter

Hi Günter wie wars beim bock ?

#Nun ist mir beim Testen im "AVR Studio 4" aufgefallen, das bereits nach 
#dem Senden des ersten Bytes das Bit WCOL im SPSR gesetzt wird und #auch 
bleibt.

Wenn du den SPI interrupt freigibst erwartet der uC eigentlich das er 
von aussen gerufen wird.
Für den normal MASTER modus brauch man kein IRQ
Da reicht die SPIF Abfrage
SPIF ist übrigens auch ein flag kein IRQ

#Das ist mir nicht ganz klar.
#Ebenso kann ich im "AVR Studio 4" nicht erkennen, ob das Register SPDR 
#mit dem korrektem Byte gesetzt wird. Es steht immer nur $00 drin
#Kann mir das vielleicht mal jemand erklären? Kann natürlich auch sein, 
das i#ch einen Fehler im Listing habe.........

Nö das ist korrekt.
Du solltest das einschreiben ins SPDR sehen können.
Ein takt später ist alles 00
Was auch klar ist weil der Slave ja nichts zurückliefert.
Man  ein IO file an den MISO Port " anschließen"
( Ich verwende da ein RAND generiertes monsterfile )

Das SPDR ist ein Ringregister
Während der Master zb Bit1 rausschiebt kommt vom slave Bit 7 rein
Dh nach der SPI übertragung hast du die Slave Daten im SPDR

Nur so als Tipp
Wenn der Slave Zeit zum Arbeiten braucht ist besser den
Auftrag n a c h der SPI übertragung abzugeben.
Sonst muss der uC immer auf den Slave warten.

Somit können beide Slave und Master parallel weiterarbeiten



Phagsae
CMMR ist lätürnich false -> CMRR =!flase

Holla Phagsae,

also der Bock war gut, ich war gut drauf am nächsten Tag gabs keine 
Brummstörungen. Alles somit im grünen Bereich.

Gut denn, das mit dem Interrupt ist eigentlich logisch. Die Software 
funktioniert im Atmel und nachdem ich jetzt den Quarz beim Slave 
eingesetzt habe funktioniert das auch. Ich initialisiere jetzt den Slave 
und wenn der ein externes NF-Signal erhält, löst der einen Interrupt an 
Int1 aus. Das soll er auch und nun geht es weiter mit der Hardware...

Was mir aber immer noch nicht einleuchtet, ist die Geschichte mit der 
Word-Collosion. Hängt das etwa damit zusammen, das er kein Feedback vom 
Slave bekommt? Das kann der nämlich nicht. Der kann nur Befehle und 
Daten bekommen und bestenfalls nach aufforderung Daten senden, sonst 
nix. Und wenn ich das richtig geschnallt habe, braucht der Master auch 
kein Feedback vom Slave.

Djambo,
Günter

Hallo Leute,

ich hab ein Problem mit meiner SPI-Schnittstelle:

Meine Aufgabe ist es, die Daten, die von einer SPI-Schnittstelle
gesendet werden mit dem Microcontroller PIC 16F873 einzulesen. Dabei
verwende ich die hardwarmäßige SPI-Schnittstelle des Controllers.
Dieser arbeitet mit dem externen Takt und somit als Slave.

Zum Testen habe ich die Takteingangsleitung des PIC an einen
entprellten Taster angeschlossen, um im Debugmodus den Takt selbst
erzeugen zu können.
Leider funktioniert das Ganze nicht richtig. Nur ab und zu wird in den
Empfangsbuffer etwas reingeschrieben.

Die Register für den SPI-Betrieb habe ich folgendermaßen konfiguriert:

SSPSTAT = 0100 0000 (clock edge select = steigende Flanke)
SSPCON  = 0010 0100 (enables serial port;SPI slave mode;clock=SCK-PIN)

Die Konfiguration müsste so eigentlich stimmen.

Für eure Hilfe wäre ich sehr dankbar.

Gruß, Markus