SPI Fehlererkennung/-korrektur

Persönliche Seite #873899
Lesenswert?

Habe einen Master und drei Slaves, alle sind AVRs. Der Master überträg 
jeweils 3 Byte an jeden Slave und erledigt dann andere Aufgaben, bis er 
wieder senden muss. In den Bytes sind Helligkeitswerte für LEDs kodiert. 
Die letzten zwei Bit jedes Bytes geben an, ob es sich um einen R-, G- 
oder B-Wert handelt. Die restlichen 6 Bit enthalten die Helligkeit (64 
Stufen).

Nun schleichen sich aber Fehler in die Übertragung ein, wenn ich am 
Drehencoder rumdrehe oder die Taster betätige. Das ist komisch, da auf 
der selben Platine noch viel stärkere Ströme fließen, nämlich die neun 
PWM-Tranistoren. Naja, jedenfalls brauche ich eine Fehlererkennung, 
sodass ein falsch angekommenes Byte erkannt und nicht übernommen wird. 
Eine Fehlerkorrektur wäre auch toll, wenn es nicht zu kompliziert und 
ressourcenlastig ist.

Ich habe schon versucht, das Byte immer doppelt zu senden, sodass der 
Slave das ankommende Byte mit dem letzten vergleicht und bei 
Übereinstimmung als richtig erkennt. Nur habe ich das wahrscheinlich 
schlecht umgesetzt, die LEDs haben nur noch geflackert. Jetzt suche ich 
nach einem guten Ansatz.

Was ist mir AVRs sinnvoll? Habe noch nicht viel Erfahrung mit SPI und 
serieller Datenübertragung allgemein. CRC wäre hier wohl zu viel des 
Guten, oder?

Es besteht die Möglichkeit, dass die Slaves dem Master antworten.
Gast #873911
Lesenswert?

Bei SPI brauchst du eigentlich keine Fehlererkennung.
Der Master sendet und empfängt die Daten synchron.

Entweder du hast einen ganz schlechten Hardwareaufbau,
oder du überrennst die Slaves mit einer zu hohen
SPI Taktrate.
#873923
Lesenswert?

Maxim S. wrote:

> Nun schleichen sich aber Fehler in die Übertragung ein, wenn ich am
> Drehencoder rumdrehe oder die Taster betätige.

Sieht eher nach SW-Fehler aus.


> Ich habe schon versucht, das Byte immer doppelt zu senden, sodass der
> Slave das ankommende Byte mit dem letzten vergleicht und bei
> Übereinstimmung als richtig erkennt. Nur habe ich das wahrscheinlich
> schlecht umgesetzt, die LEDs haben nur noch geflackert.

Ja, dann isses wohl ein SW-Fehler.


Peter
Persönliche Seite #873951
Lesenswert?

Hm, danke für den Hinweis, dann mach ich mich auf die suche.

Das ganze Programm ist in Assemlber hgeschrieben und befindet sich im 
Anhang.

Kann es daran liegen, dass die Übertragung durch INT0 und INT1 (das sind 
die Eingänge des Encoders, der vorher allerdings durch einen ATiny12 
ausgewertet wird) unterbrochen wird und dadurch irgendwelche Fehler 
entstehen?

Das erklärt aber noch nicht, warum die LEDs auch bei normalen Tastern ab 
und zu flackern. Na wie gesagt, ich schau mal, wo es hacken könnte.
Angehängte Dateien:
#874272
Lesenswert?

Maxim S. wrote:
> Kann es daran liegen, dass die Übertragung durch INT0 und INT1 (das sind
> die Eingänge des Encoders, der vorher allerdings durch einen ATiny12
> ausgewertet wird) unterbrochen wird und dadurch irgendwelche Fehler
> entstehen?

Ja, Du zerstörst in den Interrupts fleißig die Register.

Du mußt das SREG und alle auch im Main benutzten Register sichern, bevor 
Du sie verwendest.

Und vor der Benutzung des IJMP sollte man immer prüfern, ob man nicht 
nach außerhalb der Sprungtabelle springt, d.h. ob der Sprungindex zu 
hoch ist.


Peter

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren