SPI - Kommunikation überwachen

Hero_123

Mitglied
17. Sep. 2010
183
3
18
Sprachen
  1. ANSI C
Hallo!

Bei meinen "Entwicklungsbord" tauschen 2 ATMega8 (3.68 MHz) per SPI Daten aus - der Master gepollt, der Slave per SPI-Interrupt.
Es werden jeweils 8 Byte gesendet und empfangen (Master sendet und empfängt 8 Byte, der Slave dito).

Der Master schreibt erst dann neue Daten ins SPDR (= wartet), wenn er vom Slave eine Freigabe erhält (wenn Slave seinerseits das SPDR gefüllt hat)

Gibt es einen (sinnvollen) Algorithmus, mit dem man feststellen kann, dass die empfangenen Daten wirklich den gesendeten entsprechen?
Es kann - manchmal, wenn der Slave oder der Master neu geflasht wurden - vorkommen, dass die Daten, die beim Master (oder Slave) im "Empfangsbuffer" stehen nicht denen entsprechen, die im "Sendebuffer" des Slaves (oder Master) stehen (sollten) => der Master und der Slave senden derzeit immer die gleichen Daten (Master und Slave natürlich unterschiedliche), damit ich per USART checken kann, ob die Daten korrekt übertragen wurden - und diesen Check soll der Controller selbst machen (können).

Nach einem Neustart bzw wenn ich die Spannungsversorgung (eine für beide ATMega8) abziehe und wieder aufstecke ist die Übertragung aber immer korrekt.

Ich könnte natürlich die Summe aus den übertragenen Bytes errechnen und mit einem Wert vergleichen um bei Unterschied LEDs anzusteuern (mache ich derzeit auch), das ist aber nur bei sich nicht ändernden Daten sinnvoll - wenn ich die Werte eines ADC / Motordrehzahl übertragen ändern die sich zwangsläufig...

mfg

Hero_123
 
Wie wäre es wenn Du dir ein Protokoll ausdenkst? So habe ich das gelöst und in diesem Protokoll hängst Du noch eine Checksumme mit hinten dran.. Das klappt bei mir wunderbar
 
Und wirst Du es mal probieren?

Was denn?????

In Deinem obigen und dem von mir zitierten Beitrag steht ja .... herzlich wenig bis nix verwertbares ;)

Aber das Internet bietet ja genügend Info bezgl CRC und Checksummenbildung.

Ich habe mir einen Check geschrieben, dennoch kann man nie sicher sein, dass die Übertragung wirklich zu 100% funktioniert hat - es können zwar die übertragenen Daten korrekt sein, aber die Checksumme /CRC inkorrekt bzw verfälscht sein oder visa versa.
Man könnte nun die empfangenen Daten spiegeln und da checken, aber auch da ... wie auch immer...

Dennoch vielen Dank für Deine Unterstützung :good3:

mfg

Hero_123
 
Ich denke schon das Du dich darauf verlassen kannst.
Dafür ist diese Berechnungen erfunden worden. Du bildest den CRC auf den Datensatz den Du empfangen hast und vergleichst dann die CRC mit der CRC die Du empfangen hast. Sollte das nicht gleich sein, wurde der Datensatz nicht korrekt empfangen.
 
100% sicher sein kannst du dir nie. Es bietet aber einen ausreichenden Schutz.
Aber viel häufiger liegt der Fehler entweder in zu hohen Übertragungsraten (eher UART als SPI) oder verbuggter Software ;)

Protokoll kommt immer drauf an was du brauchst. Sendest du nur Statuswerte, sonst nichts, reicht eigentlich schon Start- und/oder Endbytes damit du erkennen kannst wo ein Paket anfängt und aufhört. Häufig wird der Zeilenumbruch (Windows, CrLf) genutzt, also 0x0D0A am Ende. Auch gängig ist 0xA0 als Start- und 0xA1 als Endbyte. Wird eine komplexere Kommunikation vorausgesetzt, eignet sich TLV. Das ist auch auf Microcontrollern leicht umzusetzen.
 
Dein Problem ist eher nicht die Daten bzw. CRC oder sonstwas, sondern, dass Du ein Bussystem verwendest, welches für so einen UseCase nicht gedacht war....
Muss es denn SPI sein? Bzw. Warum hast Du Dich anfänglich für SPI entschieden?
 
Hallo TommyB, hallo Hemi

Vielen Dank für Eure Tipps / Hinweise!

Protokoll kommt immer drauf an was du brauchst. Sendest du nur Statuswerte, sonst nichts, reicht eigentlich schon Start- und/oder Endbytes damit du erkennen kannst wo ein Paket anfängt und aufhört. Häufig wird der Zeilenumbruch (Windows, CrLf) genutzt, also 0x0D0A am Ende. Auch gängig ist 0xA0 als Start- und 0xA1 als Endbyte. Wird eine komplexere Kommunikation vorausgesetzt, eignet sich TLV. Das ist auch auf Microcontrollern leicht umzusetzen.


Ja, Start- und/oder Endbytes + CRC / Checksum dürften reichen; es ist (derzeit) keine komplexe Kommunikation ;).

Dein Problem ist eher nicht die Daten bzw. CRC oder sonstwas, sondern, dass Du ein Bussystem verwendest, welches für so einen UseCase nicht gedacht war....
Muss es denn SPI sein? Bzw. Warum hast Du Dich anfänglich für SPI entschieden?

Ich habe mich deshalb für SPI entschieden, weil ich mich bislang noch nie mit der Kommunikation zwischen 2 ATMega8 beschäftigt hatte, und ich wollte wissen, ob ich die Kommunikation "zum Laufen bringe" (ja, der Datentransfer Master <-> Slave fkt); erst jetzt, wo sie läuft, beschäftige ich mich mit der Absicherung der Daten.
Man wächst mit der Aufgabe ;) und bevor man rennen kann, muss man erst das Laufen lernen ;).

mfg

Hero_123
 
Zeig doch mal deinen Code her..
 
Und warum sollte ich das tun?
 
Und warum sollte ich das tun?
Du meintest das du ein Problem hast mit dem empfangen nach dem Einschalten, wenn ich mich recht erinnere. Vielleicht hätte man Dir so helfen können bei deinem Problem. Aber Okay
 
Du meintest das du ein Problem hast mit dem empfangen nach dem Einschalten, wenn ich mich recht erinnere. Vielleicht hätte man Dir so helfen können bei deinem Problem. Aber Okay

Dieses "Problem" war nicht meine Frage, und ich weiß, warum / wann dies passiert und wie ich darauf zu reagieren habe.

Und - mit allem nötigen Respekt - ich denke nicht, dass Du mir da eine große Hilfe gewesen wärest ;).

mfg

Hero_123
 
ein Bussystem verwendest, welches für so einen UseCase nicht gedacht war....
Wiso das? Es ging doch darum, zwei Controller miteinander kommunizieren zu lassen:
tauschen 2 ATMega8 (3.68 MHz) per SPI Daten aus
Genau auf demselben Weg werden die Controller doch i.a. geflasht (auf/im STK500, AVRisp mkII und diversen Nachbauten sitzt irgend'n Mega, der das Target per I/O in den Reset zwingt, und dann per SPI kommuniziert.

Ähnlich Thomas's TLV wird hier dann ein Protokoll verwendet.

Bei der Kommunikation zwischen Computer und Programmer (via UART) bin ich auf ein ähnliches Protokoll gestoßen - Jedes Telegramm beginnt mit einem bestimmten Kopf, enthält eine Telegrammnummer, dann ein Kommandobyte/word, und ggf die Anzahl der zu übertragenden Parameterbytes und dann die Bytes. Abgeschlossen mit'ner byteweisen XOR-Checksumme. Das Ziel muß dann innerhalb eines Timeouts antworten, auch mit dem Kopf und der Telegrammnummer, der Anzahl der Bytes usw.

Zum CRC: Dabei handelt es sich ja vereinfacht gesagt um 'ne Bitweise(?) Polynomendivision. Die Bits sind binär, also müßte man eher von Subtraktionen sprechen. Der beste Weg wäre also, bereits beim bitweisen Empfang (Bit für Bit) die CRC-Prüfung mitlaufen zu lassen - Aber das unterstützt Hardware-SPI natürlich nicht... also würde man erst auf den Empfang des ganzen Telegrammes warten müssen, und danach alle Bytes (Bits) hin und herschieben und subtrahieren.

Ich habe das meiner Erinnerung nach hier irgendwo im Forum mal mit 1wire (da gibts ja keine Hardware-Schnittstelle) durchgespielt. Im Zusammenhang mit den Temperatursensoren. Während die Bits bitweise eingelesen werden läuft die CRC im hintergrund mit (sind ja nur wenige Instruktionen mehr pro Bit)...

(Hab leider keine Zeit, die beiden Sachen hier im Forum rauszusuchen, sorry)
 
Hi Hero_123

Du hast es ja schon angesprochen, die gesendeten Daten spiegeln. Wenn du da einen Fehler haben solltest, dann hast du ein Problem mit der Software und nicht mit der Übertragung. Also, Datensatz und Prüfbit senden. Gegenseite prüft das Bit, setzt das Spiegeltelegramm zusammen und bildet davon ein neues Prüfbit. Das geht zurück zum Sender. Spiegeltelegramm und Prüfbit müssen gleich sein. Wenn du nicht grad zeitkritisch arbeiten mußt, dann sollte das eine mögliche Lösung sein. Ich habe mal eine Kommunikation zwischen PC und einer Maschine so aufgebaut. Hat über viele Jahre sicher funktioniert.
Gruß oldmax
 
Hallo LotadaC, hallo oldmax

Vielen Dank für Eure Hinweise /Tipps :good3:

Ich werde diese bei der Kommunikationsüberwachung mit umsetzen bzw. testen, was am sinnvollsten für mein Lernprojekt ist (aber ausprobieren werde ich sie alle - schon um dabei zu lernen).

(Hab leider keine Zeit, die beiden Sachen hier im Forum rauszusuchen, sorry)

Kein Problem, Du hast mir eh' schon sehr viel geholfen ;)
mfg

Hero_123
 
Du könntest dich, wenn du wirklich so weit gehen willst, natürlich auch an das wohl erprobte TCP anlehnen. Aber ob man jetzt nicht mit Kanonen auf Spatzen schießt...
Aber (das ist jetzt nur ein Ideeansatz!):
SPI hat ja Sende- und Empfangsleitung. Wenn Daten gesendet werden ist es häufig so dass ohnehin die gesendeten Daten 1 Byte später wieder empfangen werden, könnten also vom Sender überprüft werden. Und es hat Slave Select Leitungen. Bei Fehler Slave vor Stoppbyte deaktivieren ... hmm... Hab leider grade kein Equipment hier um selber zu testen (von Zeit mal ganz abgesehen)
 
Hallo TommyB

Vielen Dank für Deinen Tipp ;)

Werde ich auch ausprobieren - habe ja Zeit, da es kein Kundenprojekt ist :).

Als ich begann, mich mit SPI zu beschäftigen, wollte ich "nur" Daten zwischen Master & Slave austauschen und ich war - was das Thema SPI und Sicherheit der zu übertragenden Daten angeht - völlig unbedarft (hatte keine Ahnung).
Je mehr ich damit befasse umso mehr erkenne ich, wie komplex das Thema ist - von der HW bis zur SW.
Aber nur durch Herausforderungen lernt und wächst man ;).

mfg
Hero_123
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)