Tag liebes Forum,
ich habe mal im Anhang ein kleines .ASM Listing gelegt, welches folgende
Aufgaben erfüllen soll:
1. Initialisierung 8515
Stack, Ports, SREG -> Interrupts zulassen
2. Initialisierung des SPI
Teilung Phi/128 (SPR0 = 1, SPR1 = 1)
Datenübernahme durch steigende Flanke (CPHA = 0, CPOL = 0)
Betrieb als Master (MSTR = 1)
Datenfluß MSB -> LSB (DORD = 0)
SPI aus (Bit SPE = 0)
Interrupt ein (SPIE = 1)
3. SPI Enable (Bit 6 -> SPCR auf 1), Reset Slave durch String $01
4. Adresse an Slave $30
5. Warten bis Flag SPIE in SPSR gesetzt ist
6. Flag SPIE löschen
7. Daten an Slave
8. Warten bis Flag SPIE in SPSR gesetzt ist
9. Flag SPIE löschen
usw.
Nachdem die Übertragung beendet ist, wird das SPI abgeschaltet und
verbleibt in einer Schleife = späteres Hauptprogramm.
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.
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 ich einen Fehler im Listing habe.........
Life austesten kann ich es noch nicht, da der Slave (CMX813)noch nicht
vollständig aufgebaut werden kann - Quarz fehlt noch.
Danke schon mal,
Günter
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
Eine eigene Frage?
Dieser Thread ist über 24 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
