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.
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
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.
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.
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!
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!
Zitieren
Lesezeichen