ASM für SPI .. ist das richtig so?

[Magnetus]

Hallo

Mein CAN Controller (Slave) will einfach nicht funktionieren.
Vielleicht ist das SPI falsch konfiguriert. Wäre echt schön wenn jemand
helfen könnte. Das ganze ist auf nem Steckbrett aufgebaut. Hier der Code der im Mega8515 (Master) abgelegt ist:

; -------------------------- KONFIGURIEREN -------------------
ldi temp, 0b10100000 ; Output = SCK & MOSI
out DDRB, temp

ldi temp, 0b01010001 ; SPIEnabled, MasterMode, SPI Clock Rate=
; OSC/16 = 250kHz @ 4MHz OSC
out SPCR, temp

; ---------------------- per SPI was senden ------------------
cbi PortB, 4 ; /CS pull down
ldi temp, 0b00000010 ; WRITE-Instruction
rcall spiout
sbi PortB, 4 ; release /CS



; -------------------- SUBFUNKTION FÜR SENDEN ------------
spiout:
out SPDR, temp
wait_spi:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi

ret ; back...



Ich bin schon am verzweifeln, ich weis echt nicht wo ich den Fehler
suchen soll. Mein restliches Programm bin ich schon hundertmal
durchgegangen. Leider programmieren das alle bis auch mich in C.
Deshalb krieg ich auch von nirgendwo Hilfe. Ist doch zum heulen.

[SprinterSB]

Du musst das SPIF zurücksetzen.


SPDR = data;

// wait for xmission to complete
while (!(SPSR & (1 << SPIF)));

// clear SPIF
data = SPDR;


Ist zwar C, aber das raffst du schon ;-)

[Magnetus]

und ich dachte schon das wärs gewesen... ich habs so gemacht:

spiout:

out SPDR, temp
wait_spi:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi
; SPIF is set

in temp2, SPSR
in temp2, SPDR ; release SPIF by reading Register

ret ; back to programm..


leider nicht geholfen, aber ich denke dass es einer von vielen Fehlern ist.

Dank Dir!

[SprinterSB]

CS wird nicht als OUT geschaltet. Zumindest passt's nicht zu deinem Kommentar...

[Magnetus]

Du meinst diese Zeile?
ldi temp, 0b10100000 ; Output = SCK & MOSI

SCK ist bit 7 und MOSI bit 5
beide = 1 = output

Oder hab ich was übersehen?

[SprinterSB]

Port B.4 schaltet ein CS-Signal, momentan zwischen high-Z und Pullup. Mag sein, daß es ok ist. Sieht aber etwas wunderlich aus...

[Magnetus]

ach so wenn du das meinst, dass VOR
cbi PortB, 4 ; /CS pull down

eigentlich noch stehen müsste:
sbi PortB, 4 ; /CS up

dann hast du recht. Das habe ich auch gerade bemerkt. Erst hoch , dann tief, am Ende wieder hoch. So muss es.

[Magnetus]

Ein weiterer schwerer Fehler ist:
Ich habe /SS auf Input gehabt.

Es muss aber Output sein. (Laut Datenblatt unlogisch)

Jetzt geht die CAN Verbindung. Nur ist wieder etwas komisch:

Das gesendete Byte wird ca. 12 mal übertragen (eben warens 15 Mal) danach steht die Übertragung still. Weis jemand Rat?

[Magnetus]

Wenn ich das Sendeintervall halbiere (halb so lange Pause zwischen dem Senden) werden doppelt so viele Bytes übertragen.... also etwa 24. Danach scheint die Verbindung wie unterbrochen...

[SprinterSB]

Kann sein daß der CAN-Controller abschmiert? (Puffer voll, ...)

[Bernhard.Erfurt]

Hab mir gerade mal diesen ASS-Code angeschaut,
sieht sehr vernünftig aus, vielleicht findest Du so scheller die Ursache:

http://www.mikrocontroller.net/forum/read-4-21765.html


Wenn Dein Programm dann vernünftig läuft, könntest Du es ja auch veröffentlichen ...viele würden sich darüber freuen, nicht nur meiner einer ;)

Gruß

Bernhard


PS: es ist immer günstiger, wenn der komplette Code veröffentlicht wird, manchmal ist die Ursache für ein Fehlverhalten an einer ganz anderen Stelle zu suchen (Bsp: reti, Stack, Interrupt, Timing-Probleme)

Auch der Code für den Slave ist hier nicht ganz unbedeutend.

[MarkusG]

Hi,

also ich hab vor kurzem auch ne routine in ASM geschrieben zur CAN übertragung. Ich werd aber nicht so ganz schlau aus deinem Thread:

Wie genau sieht denn deine Schaltung aus, was genau versuchst du zu senden, welchen CAN Controller verwendest du ( 2515 ? ) und hast du die Möglichkeit zur Kontrolle mit dem Oszi oder Logic Analyzer ? Oder woher weißt Du wie oft was übertragen wird ?

Wie ist dein CAN Controller konfiguriert, welchen Bustreiber hast Du, passt das Bit Timing , ...


Also für mich hört sich das stark danach an, dass deine gesendete CAN Nachricht nicht von der Gegenseite verstanden wird, kein ACK gesendet wird und somit der CAN-Controller die Nachricht so oft sendet, bis sie verstanden wird (ausser Du arbeitest in OSM ?)

Oder sendest du die Nachricht schon öfters, sie wird auch verstanden, Du kannst sie auslesen aber beim n-ten mal dann eben nichtmehr ??

Gib uns doch einfach nochmal ein bisschen mehr Informationen - wie schon gesagt eventuell auch den kompletten relevanten Code - dann kann man dir bestimmt helfen


Mfg Markus

[Magnetus]

>> Oder sendest du die Nachricht schon öfters, sie wird auch verstanden, Du >> kannst sie auslesen aber beim n-ten mal dann eben nichtmehr ??

Genau so ist es. Innerhalb der ersten paar Sekunden kommt alles an (nur im OSM).

Hier mein Thread:
http://www.mikrocontroller.net/forum/read-1-325202.html#new
Dort hab ich mich schon exakter gefasst.


Im Moment glaube ich sogar dass ein mcp2515 nicht ganz sauber läuft, denn ich habe beide mal getauscht und es zeigt sich ein anderes Verhalten als vorher. Hab schon neue mcp's bestellt...

Hat niemand einen funktionierenden Code in ASM? Wenn es dann mal irgendwann funzt, werd ich den Code natürlich veröffentlichen.

[Bernhard.Erfurt]

>Hat niemand einen funktionierenden Code in ASM? Wenn es dann mal >irgendwann funzt, werd ich den Code natürlich veröffentlichen.

Zeig uns doch mal Deinen, damit wir sachlich mitdiskutieren können, sonst orakeln wir doch nur :(

Scheint wirklich ein Software-Problem zu sein

[Magnetus]

Hallo!

Ich habe die abgespeckte aktuelle Version im Anhang. Am PC kann ich über HTerm sehen, dass 2 Bytes ankommen: 11001100 und 00110011
Danach ist Ruhe. Wenn empfangen wird leuchtet auch kurz die Empfangs-LED (PortA, 0) synchron zur Sende-LED.

Sollte es doch ein SW Problem sein?

Habs eigentlich gut dokumentiert...

[Bernhard.Erfurt]

Mir ist was aufgefallen:

; MESSAGE TRANSMISSION (periodic)
send:
.
.
.
sbi PortB, 4 ; release /CS
; define ID (Std. ID High)
cbi PortB, 4 ; /CS pull down
.
.

Füge doch mal eine kleine Pause zwischen sbi... und cbi... ein, denn die Impulslänge beträgt nur wenige µs und das kann zu Hardware-Problemen führen

[Magnetus]

Stimmt. Ist ne gute Idee. Ich habs mal mit mehreren NOPs versucht. Gebracht hats allerdings nichts. Werds aber drin lassen. Und wieder ein Fehler weniger... Danke!

[Bernhard.Erfurt]

Ich weiß, bei solchen Fehlern kann man leicht verzweifeln und an den

Rand des Wahnsinns getrieben werden ;)

Das Hauptproblem ist bei Dir, dass Du es gleich mit 2 µC zu tun hast, also gleich mit 2 Fehlerquellen.

Versuche doch mal den Fehler etwas einzugrenzen.


Leider habe ich mich noch nie tiefgreifend mit SPI beschäftigt,

wenn Du mir/uns mal ganz kurz den Grundmechanismus der SPI-

Übertragung erklären könntest, dann finden wir vielleicht den Fehler

schneller?


Bernhard

[Bernhard.Erfurt]

http://www.mikrocontroller.net/forum/read-4-21765.html

[Magnetus]

Hi Bernhard

Bin aber auch Neuling mit SPI. Das angefügte Blatt aus dem Datasheet des mcp veranschaulicht das ganz gut.
Grundsätzlich wird der Slave immer mit auf Low-gehaltener /SS Leitung aktiviert. Danach legt man irgendein Byte in das Register SPDR:
out SPDR, temp
Sobald das Register gefüllt ist, gibt der AVR automatisch das Byte raus, mit gleichzeitiger Taktschaltung am SCK-Pin. Sobald das letzte der 8 Bit raus ist, hört auch der Takt wieder auf zu schlagen. SPDR ist nun wieder frei. Dabei wird auch das SPIF-Flag gesetzt. Wenn man es also nach dem Beschreiben von SPDR zyklisch abfragt, weis man wann SPDR wieder frei ist:
wait_spi:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi

Damit man wieder etwas in SPDR schreiben kann muss das Bit vorher wieder von Hand gelöscht werden. Das geht z.B. durch Auslesen des SPDR:
in temp2, SPDR ; release SPIF by reading Register

Der SPI ist ein Ringpuffer. Bei rausgehen eines Bytes kommt eins "von draussen" gleichzeitig rein. Es ist ein Kreis. Meist hat das reinkommende aber keine Bedeutung (z.B. wenn man nur was senden will).
Will man was von "draussen" holen, muss man irgendetwas senden um danach das empfangene Byte nur noch zu lesen.

Das ist das grobe Geschehen.Wenn noch Fragen, oder mehr Details. Bitte, ich bin hier!

viele Grüße

[Magnetus]

Ach ja und am Ende muss /SS wieder High gesetzt werden.

PS: Den Thread den du reingelinkt hast kenne ich, habe auch diese dumme Frage dort gestellt... Aber mir antwortet ja keiner.... *heul ... :-)

[Bernhard.Erfurt]

@Magnetus

Danke für Deine sehr fleißige Zuarbeit ;)

Ich habe mich in den letzten Stunden etwas reingelesen in diese interessante Materie.

Grundsätzlich muss man ersteinmal festlegen, in welcher Bertriebsart der Master und der Slave arbeiten soll.

Ich denke, für die meisten Anwendungsfälle (1Master 1Slave) genügt es wenn man ohne Chip-Selct arbeitet.


SS-PIN beim Master und beim Slave.

MASTER:
Wird als Ausgang konfiguriert.
Wird LOW, wenn Master was senden möchte.

SLAVE:
SS ist als Eingang definiert.
Slave bleibt so lange inaktiv, bis SS low wird

Diese Betriebsart wird im
"SPI Control Register – SPCR" festgelegt.

Bei der Grund -Initialisierung des Masters und des Slaves sind / können o.g. Einstellungen vorzunehmen. s.Datenblatt:

SPI_MasterInit:
; Set MOSI and SCK output, all others input
ldi r17,(1<<DD_MOSI)|(1<<DD_SCK)
out DDR_SPI,r17
; Enable SPI, Master, set clock rate fck/16
ldi r17,(1<<SPE)|(1<<MSTR)|(1<<SPR0)
out SPCR,r17
ret

SPI_SlaveInit:
; Set MISO output, all others input
ldi r17,(1<<DD_MISO)
out DDR_SPI,r17
; Enable SPI
ldi r17,(1<<SPE)
out SPCR,r17
ret



Überprüfe mal bitte Dein Programmcode, ob die Initialisierung genauso vorgenommen wurde? Ob die gleichen Bits in dem Register SPCR gesetzt wurden sind?

Wenn ich alles jetzt richtig vertstanden habe, dann kein ein Master immer Daten senden !!!, auch wenn kein Slave vorhanden ist, d.h. werden pausenlos Daten vom Master gesendet, dann hat man immer Pegeländerungen an: SCK MOSI und SS oder?


>Grundsätzlich wird der Slave immer mit auf Low-gehaltener /SS Leitung >aktiviert.

Ja das sehe ich auch so, dass der Slave immer mit einem LOW an SS aktiviert wird.


Ich habe etwas im Internet dazu gefunden, ich stell es Dir / Euch mal zur Verfügung.

Ich werde mir als nächstes einen MASTER programmieren,

ich denke, wir bekommen SPI schon zum laufen ;)


PS:

in Deinem Programm steht:

ldi temp, 0b01010001 ; SPIEnabled, MasterMode, SPI .....
out SPCR, temp


besser wäre:

ldi temp, ,(1<<SPE)|(1<<MSTR)|(1<<SPR0); SPIEnabled.....
out SPCR, temp

Denn Durch die Schreibweise "0b01010001" muss man erst auwändig im Datenblatt nachschauen, welches Bit gesetzt ist.

und

durch "0b01010001" kann man sich schnell mal verzählen, oder vertippen, gel ? ;)



Gruß

Bernhard

[Bernhard.Erfurt]

@Magnetus

jetzt muss ich nochmal fragen, sendet Dein Master Pausenlos Zeichen, oder bleibt er "stecken" ?

Mit einer einfachen LED an SCK MOSI oder SS kann man das ja prüfen ;)

Bernhard

[Magnetus]

Servus!

Dank dir für deine Unterstützung.

Also als erstes: ich habe heute die bestellten neuen mcp2515 Tranceiver bekommen und gleich eingesetzt. Das wars aber nicht... Also weitersuchen :-(

Die von dir übernommene Initialisierung für MASTER habe ich auch schon im Datanblatt gefunden. Die ist meiner Meinung aber falsch, denn es wurden 2 Dinge vergessen:

/SS wird dort nicht auf OUT geschaltet,
Am Ende wird SPIF nicht zurückgesetzt

Du hast ja selbst oben geschrieben, dass /SS Ausgang sein muss.


Was sagst du?

Ich werde jetzt mal das Steckbrett und die Quarze austauschen und neue ATMELS versuchen zu bekommen, vieleicht haben dir einen SPI-Fehler.

Das alles schreit nach diesem Murphy-Gesetz:
"Alles, was Du in Ordnung zu bringen versuchst, wird länger dauern und Dich mehr kosten, als Du dachtest."

[Magnetus]

Das mit den LEDs geht leider nicht. Die Frequenz am SPI ist viel zu hoch als das man was sehen könnte. Man würde ein Flackern garnicht wahr nehmen. Aber ich kanns trotzdem mal machen, vielleicht geht die LED ja irgendwann aus und dann weis man ob SPI abschaltet... Wahrscheinl. meinst du auch genau das :-)
Was natürlich hier gut wäre: ein Oszi !

[Bernhard.Erfurt]

@Magnetus

Konntest Du mal eine / einige LEDs anschließen?

>Was natürlich hier gut wäre: ein Oszi !

Naja, nicht immer, weistens genügen zwei LEDs pro PIN

Eine von Avcc gegen PIN
und eine von GND gegen PIN ;)


Wie ist Deine Verdrahtung?

GND => GND
SCK => SCK
MISO => MISO
MOSI => MOSI
SS => SS

und alles ohen Pull-Ups ?


Bernhard

[Magnetus]

Wie meinst du denn das:
>> Eine von Avcc gegen PIN
>> und eine von GND gegen PIN

?
Ich habe normal die SPI-Leitungen angezapft mit je einem R und ner LED nach Masse.
Beim Senden an den Slave ist nun folgendes zu beobachten:
/SS leuchtet immer, halbe Leuchtkraft
MISO leuchtet nicht
MOSI leuchtet immer, sehr hell
SCK blinkt intervallmäßig kurz auf (alle 2 sek, wie programmiert)

Die 2 zu übertragenden Bytes werden ca. 3 mal übertragen, danach 2 Bytes Nullen und alles steht still...nur die Sende-LED blitzt normal weiter alle 2 Sek. Also muss das Problem Empfängerseitig liegen.

Hast du bei dir eine ähliche Schaltung, dass du das mal dort testen kannst?
Ich weis nicht woran es noch liegen könnte. Habe den ASM Code nochmal freundlicher gestaltet. Schaue ihn doch mal durch. Vor allem interssiert mich ob ich unten die Unterprogramme (Senden, Lesen,..) richtig habe. Eine C-Datei ist dabei, die funzt auf jeden Fall. Man müsste nur prüfen ob ich daraus den richtigen ASM Code generiert habe.

[Bernhard.Erfurt]

>>Wie meinst du denn das:
>> Eine von Avcc gegen PIN
>> und eine von GND gegen PIN

eine LED von +5V gegen MOSI (natürlich mit einem Widerstand)
eine LED von Masse gegen MOSI (natürlich mit einem Widerstand)

Und so könnte man das für jeden AUSGANGS-PIN machen, um festzustellen, ob Impulse anliegen, ein OSZI würde auch nicht viel weiter helfen ;)

>Hast du bei dir eine ähliche Schaltung, dass du das mal dort testen >kannst?

Hab hier zwei ATmega8 vor mir auf einem Experimentierboard

>SS leuchtet immer, halbe Leuchtkraft
SS leuchtet auch bei mir, d.h. SS-PIN ist LOW

>MISO leuchtet nicht
bei mir auch nicht, denn ich habe noch kein SLAVE angeschlossen

>MOSI leuchtet immer, sehr hell
zuckt kurz auf, wenn daten gesendet werden

>SCK blinkt intervallmäßig kurz auf (alle 2 sek, wie programmiert)
zuckt kurz auf, wenn daten gesendet werden

> Man müsste nur prüfen ob ich daraus den richtigen ASM Code >generiert habe.

ich kann momentan bei Deinem Master kein Problem finden

>Habe den ASM Code nochmal freundlicher gestaltet.

Dann zeige ihn doch mal (haste vergessen mit zuzusenden) ;)

>Also muss das Problem Empfängerseitig liegen.

vielleicht, so weit bin ich noch nicht



Habe mal eine kleine MASTER-Routine geschrieben (ganz einfach)

jede Sekunde wird ein DUMMY gesendet, ich lege es mal mit bei.




Bin momentan noch am überlegen, ob beim senden das

"SPIF: SPI Interrupt Flag" beachtet werden muss, nach meiner Meinung nach nicht ?

Wie lange bist Du heute noch fleißig?

Bernhard

[Magnetus]

>> Dann zeige ihn doch mal (haste vergessen mit zuzusenden)

In der can_.zip sind alle Dateien

Der Code ist je eine pdf-Datei.

gefunden? wenn nicht sag bescheid!

[Magnetus]

ich mach noch bis 3 Uhr.... ich habe echt keine Ruhe vorher!

[Bernhard.Erfurt]

>Der Code ist je eine pdf-Datei.

ja habe ihn gefunden

>ich mach noch bis 3 Uhr.... ich habe echt keine Ruhe vorher!

geht mir genauso ;)

[Bernhard.Erfurt]

könntest Du mir direkt auf meine e-mail-adresse schreiben, sonst wird dieses Forum zu lang?

Bernhard.Erfurt@gmx.de

[Magnetus]

>> "SPIF: SPI Interrupt Flag" beachtet werden muss, nach meiner Meinung nach nicht ?

Ganz oben im Beitrag hat jemand gesagt dass es so sein muss. DIe C-Codes von 2 Leuten weisen da saber auch auf. Ich denke es stimmt. Steht auch im Datenblatt "... SPIF is cleared by first reading SPSR with SPIF is set and then acessing SPDR..."

[Magnetus]

gibt es eine Begrenzung in dem Forum? Ich kann natürlich auch mails senden, aber dann haben andere nichts davon... was meinst du?

[Bernhard.Erfurt]

>aber dann haben andere nichts davon... was meinst du?

wir bleiben hier im Forum

[Magnetus]

Hab jetzt pro SPI Port 8 LEDs dran:
LEDs nach Vdd: _______ LEDs nach Masse:
/SS zuckt wenn sendet _______ leuchtet konstant
MISO leuchtet konstant _______ leuchtet konstant
MOSI zuckt wenn sendet _______ leuchtet konstant
SCK leuchtet konstant _______ zuckt wenn sendet

Aber so richtig schlau werd ich nicht draus..

[Magnetus]

Dass MOSI konstant leuchtet (nach GND) ist mir unlogisch. Die müsste doch im Ruhezustand aus sein und wenn was gesendet wird (je nach einsen und nullen) mehr oder weniger schwach aufblitzen.

[Bernhard.Erfurt]

>Hab jetzt pro SPI Port 8 LEDs dran:
GROSSES LOB ;) ich habe 9 angeschlossen :)

>LEDs nach Vdd: _______ LEDs nach Masse:
>/SS zuckt wenn sendet _______ leuchtet konstant
OK, bei mir auch

>MISO leuchtet konstant _______ leuchtet konstant
d.h es werden keine DATEN vom SLAVE gesendet, oder nurdas
ZEICHEN "NULL" (alle 8 Bits vom SLAVE sind 0)

>MOSI zuckt wenn sendet _______ leuchtet konstant
OK, bei mir auch


>SCK leuchtet konstant _______ zuckt wenn sendet
OK, bei mir auch


>Aber so richtig schlau werd ich nicht draus..

Das menschliche Auge ist zu träge, dass es schnelle Helligkeitsunterschiede von Hell auf Dunkel erfasst (siehe Fernseher)
(Einbrenn-Effekt bei der menschlichen Netzhaut)

Aber Helligkeitsunterschiede von dunkel auf hell das erkennt man besser.

Mein MASTER ist soweit fertig,

- er sendet pausenlos ein BYTE (welches aber nach jedem senden um eins erhöt wird)

- er liest das Empfangsbyte aus, welches vom SLAVE gesendet wurde
und zeigt es an 8 LEDs an

Habe mal, weil ich noch kein SLAVE habe, die PINS MISO und MOSI miteinander verbunden,
der MASTER hat sich also "selber" etwas zugesendet.
UNd das was der MASTER empfängt sieht ganz vernünftig aus.
(Die abwechselnd leuchtenden LEDs sehen gut aus) ;)

Ich lege mal den ASSEMBLER-CODE mit bei.

Und gehe jetzt mal zum SLAVE über, AUSBAUSTUFE 2 :)

[Magnetus]

leider kann ich kein C
sonst hätt ich es mal damit probiert. Zumindest getestet ob es am ASM liegt.

[Bernhard.Erfurt]

>Dass MOSI konstant leuchtet (nach GND) ist mir unlogisch.

dh MOSI ist HIGH und das ist ok

> Die müsste doch im Ruhezustand aus sein und wenn was gesendet
> wird (je nach einsen und nullen) mehr oder weniger schwach >aufblitzen.

Einer der beiden LEDs an einem PIN muss immer kurz blitzen

[Magnetus]

>>MISO leuchtet konstant _______ leuchtet konstant
>d.h es werden keine DATEN vom SLAVE gesendet, oder nurdas
>ZEICHEN "NULL" (alle 8 Bits vom SLAVE sind 0)

Müsste da nicht die LED nach GND aus sein?
Werden nur Nullen gesendet, ist praktisch die ganzen 8 Bit Low auf der Leitung. also nach Masse geschaltet.

[Bernhard.Erfurt]

>Müsste da nicht die LED nach GND aus sein?
>Werden nur Nullen gesendet, ist praktisch die ganzen 8 Bit Low auf der >Leitung. also nach Masse geschaltet.

kann ich Dir momentan auch noch nicht erklären.

Nur was mich sehr wundert:

Irgendwas stimmt mit DEINER "empfanger.asm" nicht,

das ist ein Programm für einen MASTER



; ========================= SPI Transmit =================================
spiout:

out SPDR, temp
wait_spi:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi
; SPIF is set
in temp2, SPSR
in temp2, SPDR ; release SPIF by reading Register

ret ; back to programm..
; ================================================== ======================


Das sind alles MASTER-Routinen ?????????

was ist da los?

Erklär mir mal ganz kurz was es machen soll

[Magnetus]

das ist ja alt...
aber das neue ist kaum anders:

Byte an Slave senden:
out SPDR, temp
wait_spi:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi
; SPIF is set
; Lesen des SPSR (wegen rücksetzen des SPIF)
in temp2, SPSR
; Lesen des SPDR (wegen rücksetzen des SPIF)
in temp2, SPDR ; release SPIF by reading Register

Das ist der SPI-Transfer-Prozess. Hast du doch bei dir auch drin... bis auf das SPIF-Rücksetzen

[Bernhard.Erfurt]

Mein SLAVE ist fertig..... und läuft..... ;)
(allerdings etwas seltsam noch...)

[Magnetus]

Bist du Student oder sowas.. ich ja und kann nämlich über meine UNI-Email überall erfolgreich Samples bestellen. Hab schon 2 mal bei Microchip diese CAN-Chips geordert.
Du hast nicht solche ICs ? Ich könnt sie dir zukommen lassen...

[Bernhard.Erfurt]

>Bist du Student oder sowas.. ich ja und kann nämlich über meine UNI->Email überall erfolgreich Samples bestellen. Hab schon 2 mal bei >Microchip diese CAN-Chips geordert.
>Du hast nicht solche ICs ? Ich könnt sie dir zukommen lassen...

ich kenn diese ICs nicht, habe auch noch nicht gegoogelt ;)



So Magnetus, was machen wir jetzt,

mein MASTER sendet pausenlos ZEICHEN an den SLAVE und dieser sendet diese wieder EFOLGREICH zurück ;)

[Bernhard.Erfurt]

Hab' gerade etwas gespielt :)

Neue Erkenntnis:

Wenn Ein SLAVE nicht sendet, warum auch immer,

ist MISO ===> HIGH

[Magnetus]

Hallo Bernard
Wenn ich einen 8MHz Quarz statt des 4er bei den CAN-Transceivern nehme, wird etwa 3mal soviel korrekt übertragen wie vorher. Danach stoppt es dann wieder... Aber du kannst das wohl schlecht nachvollziehen ohne diese ICs..
Die Übertragung sollte normalerweise bis heute fertig sein... so ein Mist.

[Bernhard.Erfurt]

>Wenn ich einen 8MHz Quarz statt des 4er bei den CAN-Transceivern >nehme, wird etwa 3mal soviel korrekt übertragen wie vorher

...hab jetzt mal einige Minuten auf die Schaltpläne gestarrt, so langsam verstehe ich dieses gesamte-Prinzip, denn Du hattes mir ja auch nicht auf meine Fragen so richtig geantwortet :)

Mein Tipp, so auf die schnelle:

- füge mal längere Pausen ein, bermutlich gibt es TIMING-Probleme im CAN-IC

BSP:

; WRITE COMMAND
ldi temp,WRITE
out SPDR,temp
wait_spi_w1:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi_w1
in temp,SPDR ; release SPIF here
; SET ADDRESS
out SPDR,address
wait_spi_w2:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi_w2
in temp,SPDR


ändern in:

; WRITE COMMAND
ldi temp,WRITE
out SPDR,temp
wait_spi_w1:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi_w1
in temp,SPDR ; release SPIF here
;-----------------

rcall PAUSE_100ms

; -----------------
; SET ADDRESS
out SPDR,address
wait_spi_w2:
sbis SPSR,SPIF ; Transmission complete?
rjmp wait_spi_w2
in temp,SPDR

Gib den CAN-IC genügend Zeit, seine Daten zu verarbeiten,
bremse mal alles etwas, nicht, dass er total überfordert wird ;)



Bernhard

[Bernhard.Erfurt]

noch was:

diese kurzen Pausen nach jedem "SENDEN" einlegen

Vielleicht hilft es ?

[Bernhard.Erfurt]

noch was, Du merkst, es gibt immer wieder Ideen:

ldi temp,0b01010001 ; SPIEnabled, MasterMode, SPI Clo
out SPCR,temp

setze mal einen ganz langsamen SCK-TAKT:

; Enable SPI, Master, set clock rate fck/128
ldi temp,(0<<SPIE)|(1<<SPE)|(0<<DORD)|(1<<MSTR)|(0<<CPOL)|(0<<CPHA)|(1<<SPR1)|(1<<SPR0)
out SPCR,temp


also: SPR1=1 SPR0=1

[Bernhard.Erfurt]

noch was:

ldi temp,0b10111000 ; Output = SCK & MOSI & /SS & LED
out DDRB,temp
ldi temp,0b01010001 ; SPIEnabled, MasterMode, SPI Clo
out SPCR,temp
sbi PortB,4 ; /CS High
nop


ändern in:

ldi temp,0b10111000 ; Output = SCK & MOSI & /SS & LED
out DDRB,temp

sbi PortB,4 ; /CS High

ldi temp,0b01010001 ; SPIEnabled, MasterMode, SPI Clo
out SPCR,temp



gleich diesen sehr wichtigen PIN auf HIGH legen, nicht dass der SLAVE auf dumme geanken kommt ;)

[Bernhard.Erfurt]

noch was:


Du kannst von bei Deinen 8515 µC den MOSI und MISO miteinander Verbinden

Damit sendet der µC sich zwar selber DATEN zu, aber man könnte so seine SOFTWARE prüfen

[Bernhard.Erfurt]

noch was:

Du könntest das SLAVE-Programm von mir auf Deinen µC umschreiben, ist ja schnell getan und somit Deinen CAN-IC simulieren ;)

Gruß

Bernhard

[Magnetus]

>Du kannst von bei Deinen 8515 µC den MOSI und MISO miteinander Verbinden

>Damit sendet der µC sich zwar selber DATEN zu, aber man könnte so seine SOFTWARE prüfen

Werd ich jetzt mal probieren. Die Pausen hatte ich vorher eingesetzt, half aber auch nichts. Auch das SS auf High vor dem SPCR konfigurieren war ohne Wirkung.

Aber gute Einfälle waren das! Danke!

[Bernhard.Erfurt]

>Aber gute Einfälle waren das! Danke!

Gern geschehen ;)

Somit wurde ich "gezwungen", mich endlich mal mit SPI zu beschäftigen.

Ich habe unsere Erkenntnisse mal etwas zusammengefasst:

http://www.mikrocontroller.net/forum/read-4-328073.html


Gruß


Bernhard

[Magnetus]

Schönes Ding. Habe auch gleich ne Frage beim ersten Durchgehen:

Warum sicherst du das SREG bevor du
rcall SPI_EMPFANGEN ; SPI EMPFANGEN OUT: TEMP
rcall SPI_SPSR_AUSWERTEN ; Fehlerprüfung
ausführst?

Wird das SREG dort verändert?

(Datei:Slave-Interrupt.asm)

[Bernhard.Erfurt]

>Warum sicherst du das SREG bevor du
>rcall SPI_EMPFANGEN ; SPI EMPFANGEN OUT: TEMP
>rcall SPI_SPSR_AUSWERTEN ; Fehlerprüfung
>ausführst?

>Wird das SREG dort verändert?

>(Datei:Slave-Interrupt.asm)

SREG und alle Register, die im Interrupt verwendet werden müssen dringend gesichert werden,
denn man weiss ja nie, wann ein Interrupt "zuschlägt".

Wenn ein interrupt bei einem Rechenvorgang "adc" z.B. ausgelöst wird
kann kann es sein, dass das Rechenergebnis total falsch ist, weil SREG (Überlauf) verändert wurde.

Die Programme verhalten sich dann sehr eigenartig und man(n) sucht stundenlang verzweifelt ;)

[SprinterSB]

Du kannst von bei Deinen 8515 µC den MOSI und MISO miteinander Verbinden

Damit sendet der µC sich zwar selber DATEN zu, aber man könnte so seine SOFTWARE prüfen

Noch effektiver geht dieses Testen durch einen "Loopback", indem man ein 8-Bit-Schieberegister wie CD4094 oder 74595 zwischen MOSI und MISO hängt, denn bei normalem SPI-Betrieb werden ja auch das 8-Bit Shift-Register des Masters mit dem des Slaves zu einem 16-Bit Schieberegister zusammengestöpselt. Die Datenübertragung Master <--> Slave ist nicht anderes als ein Rotieren um 8 Positionen im entstandenen zyklischen 16-Bit Schieberegister.

[Bernhard.Erfurt]

@Georg-Johann

>Noch effektiver geht dieses Testen durch einen "Loopback", indem man >ein 8-Bit-Schieberegister wie CD4094 oder 74595 zwischen MOSI und >MISO hängt

Stimmt, manchmal gubt es ganz einfache Lösungen ;)

Gruß

Bernhard

[Magnetus]

Hallo Bernard

Ich habe 2 Fragen zu deinem MASTER.asm Code

1.

Du hast eine Fehlerprüfung, die guckt ob WCOL gesetzt wurde (SPDR wird geschrieben wenn gerade Datatransfer stattfindet)
SPI_SPSR_AUSWERTEN:
in temp, SPSR ; einlesen
andi temp, 0b01000000 ; BITMUSTER
tst temp
brne SPI_SPSR_AUSWERTEN_ERROR
sbi PORTB, B_LED ; LED aus
ret
SPI_SPSR_AUSWERTEN_ERROR:
cbi PORTB, B_LED ; LED an

Dort hast du aber keine "Problemlösung" als Abhilfe, sondern nur eine LED.
Ist der Fall schonmal vorgekommen dass diese geleuchtet hat?
Bin am überlegen das bei mir auch zu implementieren.

2.
Das alte Problem mit dem SPIF:

SPI_SENDEN:
; MASTER SS auf LOW
cbi PORTB, 2
; Start transmission of data
out SPDR,temp
; Wait for transmission complete
SPI_SENDEN_w:
sbis SPSR,SPIF
rjmp SPI_SENDEN_w
; MASTER SS auf HIGH
sbi PORTB, 2

Dort setzt du SPIF nicht zurück. Und es funktioniert trotzdem??

[Bernhard.Erfurt]

@Magnetus


>Dort hast du aber keine "Problemlösung" als Abhilfe, sondern nur eine >LED. Ist der Fall schonmal vorgekommen dass diese geleuchtet hat?
>Bin am überlegen das bei mir auch zu implementieren.

Kommt im "Normalbetrieb nicht vor, dass ein "Fehler" auftritt,
wollte nur zur Veranschaulichung dieses wichtige Register auswerten.


>Dort setzt du SPIF nicht zurück. Und es funktioniert trotzdem??

ja, wird automatisch mit der OUT-Anweisung gelöscht ;)