www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Dreifach-Redundanz und Kreuzparität in C


Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und täglich grüsst das murmeltier...


bin mich gerade am informieren und habe zu den themen direkt nichts im
forum gefunden. hatte vor ein paar wochen schon mal angefragt...

kann vllt. jemand von euch kurz ein paar beispiel zeilen in C zu
folgenden sicherungsmechanismen schreiben, damit ich eine idee bekomme,
wie man diese am besten softwaretechnisch löst:

- dreifach-redundanz oder auch "2aus3 verfahren",
hier sollen bestimmte (wichtige) 128byte blöcke dreifach
(hintereinander) gespeichert werden und beim rücklesen verglichen
werden. weicht ein block ab, wird per mehrheitsentscheid einer der
beiden verbleibenden (übereinstimmenden) genommen und der defekte
wieder mit einem der beiden stimmenden korrigiert.
was aber nun, wenn alle drei unterschiedlich sind? kann man dann noch
versuchen bitweise zu vergleichen, oder wird dies sowieso gemacht? und
wie schreibt man diesen vergleich beim rücklesen am
elegantesten/schnellsten?

- kreuzparität / längs- und querparität,
hier soll mit den 128 byte daten, die gesichert werden sollen, 2mal
eine 8x8 matrix erstellt werden, die zeilen und spaltenweise eine
parität erhält. so werden also zusätzlich 2 byte fällig, anhand derer
man auch noch 1 bit fehler korrigieren könnte.
wie baut man sowas am besten auf? (beim schreiben und
lesen/verifizieren)


hoffe es ist einigermassen klar, was ich meine.
wäre schön, wenn jemand evtl. seine erfahrungen dazu posten könnte oder
ein paar kurze zeilen code schreibt, wie man diese verfahren am besten
in C realisiert.

danke euch im voraus!

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wofür brauchst Du das denn?

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht um speicherung von mehreren ringpuffern in einem EEPROM, die
unterschiedlich wichtige daten beinhalten. bei manchen wird eine
sicherung über parität langen, andere müssen aber zu einem hohen
prozentsatz unbedingt richtig sein, auch wenn während der übertragung
in oder aus dem EEPROM (über I2C) störungen durch hohe ströme oder
sonstwas auftreten.

dadefür brauch ich des... :-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also so weit ich Dich verstehe geht es um fehlerkorrigierenden Code ?
Sie mal hier
http://de.wikipedia.org/wiki/Codierungstheorie
http://de.wikipedia.org/wiki/Kreuzsicherung
http://de.wikipedia.org/wiki/Fehlererkennung
Das Verfahren, was Du meinst ist im militärischen Bereich angesiedelt
und verlangt zusätzlich eine Heuristik für die
Fehlerwahrscheinlichkeit.
Das war der Grund warum in den guten alten Transputern mit mil-spec
eine extra Recheneinheit eingebaut war, der hat Dir gesagt wie
wahrscheinlich die Richtigkeit seiner Berechnung wahr ;)
Aber bevor Du jetzt anfängst tausend Zeilen Code zu produzieren, ließe
sich die Leitung samt EEPROMs nicht schirmen ?
Z.B. HF-Gehäuse für die EEPROM-Platine und CAT-10 Kabel mit extra
Außenschirmung für den I2C-Bus ?
Das dürfte wohl schneller gehen ;)
Nur als Tipp,
Markus

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke Markus, die seiten von wikipedia habe ich schon durch.
das prinzip ist mir auch klar; deswegen habe ich mich ja schon so gut
wie für diese zwei verfahren entschieden.
schirmung und solche maßnahmen werden natürlich beim endprodukt auch
angewandt. zusätzlich kommt auch noch der I2C treiberbaustein P82B96
zum einsatz.
trotzdem wird noch eine zusätzliche datensicherung gefordert :-/

prinzipiell ist diese ja auch nicht allzu schwer zu programmieren. die
dreifach redundanz entspricht ja nur einer dreifachen abspeicherung.
beim rücklesen müssen dann irgendwie alle drei datenblöcke á 128 byte
UND verknüpft werden, damit erkannt werden kann, ob einer abweicht.
und die kreuzparität wäre meiner meinung nach mit einem 2D array
(matrix) am ehesten zu realisiren.
nur leider bin ich mir da halt nicht sicher und wollte mal hören ob
dies jemand schon programmiert hat und mir tipps geben kann, wie man
dies am elegantesten macht.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, Du verrennst Dich da etwas:

a.) Wie lange (Zeit) dauert die Übertragung aller drei Datenblöcke zum
EEPROM? Wie lange kann die elektrischen Störung anhalten? Das Problem
dabei: Hält die Störung zu lange an, sind alle drei Blöcke werlos.

b.) Was versuchst Du überhaupt zu schützen? Einzel-Bit-Fehler? Bursts?
EEPROM-Fehler? EEPROM-Page-Fehler?

Kla, irgendeine Fehlerkorrektur ist schnell programmiert. Doch ob sie
etwas bringt? Das ist meisten eine ganz andere Frage.

Wie man so etwas implementiert? Naja:

  if (block_a == block_b)
    // Verwende block_a oder block_b
  else if (block_b == block_c)
    // Verwende block_b oder block_c
  else if (block_c == block_a)
    // Verwende block_c oder block_a
  else
    // Alle Blöcke unterschiedlich. Explodiere...

Aber vielleicht reicht die einfachste alle Methoden ja schon aus:

1.) Block schreiben
2.) Block lesen
3.) Beide Blöcke vergleichen, wenn nicht gleich, zurück zu 1.

Natürlich sollte die Schleife nicht endlos hängen bleiben, wenn
andauernd irgendwelche Fehler auftreten. Naja, und dann noch den Block
mit Vorwärtsfehlerkorrektur versehen, und die einzelnen Block-Teile in
verschiedenen EEPROM-Pages sichen und gut ist.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, wenn Du das Bitweise machen willst:

   (a UND b) ODER (b UND c) ODER (c UND a)

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke erst mal.

zu a) und b)
das sind alles sachen, die (noch) nicht gesagt werden können.
der normalbetrieb wird so sein, dass die elektronik direkt mit an/in
dem gerät sitzt, um das es hier geht (EEPROM in direkter nähe zum
controller => wenig störungen).
zZt sieht es aber noch so aus, dass die elektronik/controller auch
dafür ausgelegt werden soll, dass dieser bis auf mehrere meter durch
ein kabel vom gerät aufgebaut werden kann.
somit würden über diese meter im selben kabel die I2C kommunikation und
die motorströme, etc. fließen.
deshalb die sicherung; und die dreifach sicherungsdaten sollen auch
dann sicher sein, wenn nach ein paar jahren ein bit im EEPROM kippt. da
hilft mir also das direkte rücklesen beim scheiben nix.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich würde die Kreuzparität folgendermaßen relisieren:
Die Spalten sind einfach, nur alle Bytes nacheinander XOR verknüpfen,
dann hast du am Ende ein Paritätsbyte.
Zu den Zeilen fällt mir nur eine Look-up-table mit 256 Werten ein, wo
immer das zugehörige Pritätsbit drin steht. Das muss dann halt
entprechend nach Links geschoben werden und mit dem Paritätsbyte
ver-odert. Nicht sonderlich elegant, aber sonst fällt mir gerade nix
ein.

Gruss

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, hab aber eben noch etwas gefunden.
und zwar hat der M32C85 ein XY-Conversion Register. das ist eigentlich
schon eine matrix mit der man (so denke ich zumindest) dies sehr
einfach erschlagen kann, da man, nachdem man die 8 byte in
entsprechende register geschrieben hat, die zeilen auch direkt mit den
Y-registern ansprechen kann... sehr praktisch, falls es so klappen
sollte...

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach verrennst Du Dich da total. Du wirst nicht nur ein
Datenproblem auf der langen, gestörten Leitung bekommen, sondern auch
ein Protokollproblem.

Wenn Du über ein längeres Kabel mit heftiger Störeinstrahlung Daten
verschicken willst, musst Du die Datenübetragungsstrecke in erster
Linie durch Hardware schützen, z.B. differentielle Übertragung etc.
Wenn das noch nicht ausreicht, dann brauchst Du ein Layer-1-Protokoll
auf dem Kabel, das durch Fehler nicht durcheinandergebracht wird (i2c
ist kein so ein Protokoll). Und auf diesem Protokoll kannst Du dann
die Datensicherungsschicht aufbauen.

Das was Du da probierst, so zumindest meine Meinung, ist Murks. Du
doktorst an der falschen Stelle rum und stocherst im Nebel. Du weist ja
noch nicht mal, welche Störungen auftreten.

Beim Hausbau wird auch erst das Fundament gelegt und am Schluss das
Dach gebaut, und nicht umgekehrt.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo, nur leider stocher ich da rum, wo ich rumstochern muss...
nochmal: die gegebenheiten sind (wie das wort sagt) vorgegeben und ich
muss damit klar kommen. ich kann nicht ein komplettes projekt neu
entwickeln. das was ich hier dazu entwickel ist ein kleines puzzle-teil
des ganzen systems. der controller hat zwar CAN, doch leider ist keines
der interface mehr frei, weil damit schon andere sachen angestellt
werden.
welche störungen konkret auftreten, können wir erst am prototypen
testen. annehmen kann ich so vieles...

Autor: Dieter Werner (dds5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die I2C Schnittstelle ist so ziemlich das ungeeignetste für diesen Zweck
was man sich vorstellen kann.

Das liegt hauptsächlich daran, dass die Clock / Datenleitungen open
collector mit pullup Widerständen sind; im high Zustand fangen die
ordentlich Dreck ein.

I2C ist als 'on board bus' konzipiert, eine Führung zusammen mit
Power in einem Kabel kommt einem Lotteriespiel gleich.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag ich doch schon andauernd.

Aber nein, "Marcus" will unbedingt mit dem Kopf durch die Wand. Dann
soll er auch, wenn's ihn glücklich macht.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
liest auch einer das was ich schreibe?
der I2C bus ist mir vorgegeben und ich muss damit klar kommen!
der normalfall besteht ja auch zu 99% aus on-board bus. nur im
absoluten einzelfall soll die auslagerung möglich sein.
aber trotzdem danke!

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade das das Forum keinen "Zitat" Knopf hat :?
Naja muß man mit leben.

@Autor: Marcus - heinz.heinzenbach(at)gmx.net
OK,
also so wie ich die Sache nach lesen Deiner Erklärung verstehe geht es
um eine Motoransteuerung mit hohen Strömen und Störungen auf/durch die
Motorleitungen.
Im normalfall ist die Steuerung direkt am Motor und dadurch die Leitung
des I2C zu kurz, um signifikant gestört zu werden.
Es soll optional die Motorsteuerung auch extern untergebracht werden.
Richtig so ?
Zwei Fragen:
1. Muß die Motorleitung über/neben den I2C Bus gehen ?
2. Kann das aktuelle Design getrennt werden µC von Leistungselektronik
entkoppelt ?

Im ersteren Fall solltest Du über die gestörte Leitung des I2C
zusätzlich mit einer Manchester Codierung arbeiten, wie sie z.B. in
Funkmodulen zum Einsatz kommt.
Damit machst Du die Erkennung einfacher.
Zusätzlich dazu würde ich die Datenpakete redundant schicken und jweils
mit einem Hashwert (mdsum5 fällt mir spontan ein, da sollte es aber
besseres und kleineres geben können, mußt mal suchen) versehen, der als
extra pakete einmal vorher und dann hinter den eigentlichen Datenpaketen
übertragen wird.
Nun hast Du die sechsfache Redundanz der Hashwerte und kannst diese
nach dem Auschlußverfahren, wie beschrieben prüfen. Also diejenigen die
am häufigsten auftreten sind die wahrscheinlich richtigsten.
Nun läßt Du erstmal über alle drei Datenpakete den Hashwert berechnen
und vergleichst ihn mit dem zuvor erhaltenen.
Die Pakete die den Hash bestätigen kannst Du dann nehmen.
So würde ich es realisieren, allerdings kenne ich Deine Vorgaben nicht,
denn sobald es in Echtzeit verlangt ist, kommst Du mit einem üblichen µC
nicht weiter !
Kurz zusammengefaßt:
1. Hashwert von originalen Daten erstellen
2. dreimal Hashwert manchestercodiert senden
3. dreimal Datenwert manchestercodiert senden
4. dreimal Hashwert manchestercodiert senden
5. Aus den sechs Hashwerten denjenigen nehmen, der am häufigsten
auftritt
6. Hashwert von empfangenen Datenwert erstellen
7. Datenwert auswählen dessen Hash identisch ist
Wie Du siehst erfordert dieses Vorgehen einen ziemlichen Overhead beim
senden !

Ich würde daher zu zweiter Lösung tendieren und einfach versuchen die
Störquelle zu entfernen/abzuschirmen.
Das ein starker Motor direkt am µC hängt glaube ich nämlich weniger
lol

Oder hab' ich Dich wieder falsch verstanden ?
Hoffe geholfen zu haben,
Markus

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Markus:

danke dir. so halbwegs kams dann ja doch rüber.
geht um eine pumpe. die eigentliche elektronik sitzt direkt aussen
(modular) an der pumpe (u.a. auch die versorgung und der controller).
über eine kurze verbindung in die pumpe (=normalfall) sollen über I2C
sensordaten in einem externen EEPROM über mehrere jahre gespeichert
werden, so dass, wenn die elektronik gewechselt wird, trotzdem alle
gesammelten pumpenspezifischen daten (wichtig für qualitäts- und
garantiesicherung) erhalten bleiben.
angeblich soll es aber auch kunden geben, die aufgrund irgendwelcher
strahlungen die elektronik ein paar meter weiter auslagern wollen, zB
in den nächsten raum.
also müsste der controller die daten über die längere leitung zusammen
mit der versorgung zur pumpe schaffen. die verschiedenen leitungen im
kabel selbst werden natürlich bestmöglich geschirmt werden (+
zusätzlich der schon genannte I2C treiberbaustein).
im normalfall sollten also keine grösseren störungen auftreten
(speicherungen eines 128byte page blocks zum EEPROM dauern bei 100khz
ca. 13ms zZt.).
dein 2ter vorschlag ist leider nicht realisierbar aufgrund des riesigen
overheads und der damit verbundenen arbeit für den controller, da der
mit dem ganzen rest noch genug zu tun hat.

trotzdem danke für deine konstruktive kritik :-)

PS: anbei: erste tests über ein paar meter mit dem treiberbaustein und
einfachem tütteldraht + treiberbaustein in nähe von netzteilen
verliefen zufriedenstellend.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Autor: Marcus - heinz.heinzenbach(at)gmx.net
OK,
dann hab' ich's ja fast alles richtig verstanden gehabt ;)
Also in der Pumpe ist ein Sensor, der über I2C Daten sendet.
Diese Daten sollen in der µC Steuerung dauerhaft gespeichert werden.
Der µC hat direkt nichts mit dem EEPROM zu tun.
Das ist es auf den Punkt gebracht, ja ?
Dann empfehle ich Dir einfach mal nur die Manchester-Codierung zu
nehmen und zu sehen, wie gut die sich verhält. Dazu müßte halt am
Sensor ebenfalls ein µC sitzen, der das übernimmt.
Was die Datensicherung im EEPROM angeht würde ich eines mit
integriertem ECC nehmen, sowas habe ich schonmal irgendwo gesehen
gehabt ;)
BZW. die Daten wie von Dir vorgeschlagen mit Prüfsumme auf voneinander
physikalisch getrennten Bereichen des EEPROMs schreiben.
Wenn Du natürlich nur den Sensor als I2C Datenlieferant hast, sieht es
ganz anders aus, denn dessen Werte ändern sich doch ständig, oder ?
Ich meine folgendes:

+------+
|sensor|
+------+
   | I2C
+-----------------------+
|µC zur Datenübertragung|
+-----------------------+
   |
   | I2C und Power
   |
+-----------------------+
|µC Steuerung+Datenübrtg|
+-----------------------+
   | I2C
+------+
|EEPROM|
+------+

Oder sitzt das EEPROM in der Pumpe ?
Mal mir's mal bitte auf ;)
Markus

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)   ohjee... malen...

nee, also erst mal sind das einige sensoren, bzw. daten, die der
controller aufnimmt, bearbeitet, aufbereitet, berechnet, etc. und im
externen EEPROM speichern soll.
hierbei handelt es sich mind. um ein 512bit EEPROM (nix ECC, zZt der
von Microchip), was die auswahl der verfügbaren bausteine natürlich
schon wieder extrem eingrenzt.
ein zusätzlicher controller kommt auch nicht in frage, da ja zu ü99%
der schon beschriebene normalfall besteht (=> kosten/nutzen).

also grob gemeint isses so:

 +--------+
 |sensoren|    -> in der pumpe
 +--------+
  | |  | |
  | |  | | versch. buse
  | |  | |
+---------+
|µC M32C85|    -> an der pumpe
+---------+
     |
     | I2C
     |
  +------+
  |EEPROM|    -> in der pumpe
  +------+


meinst du es macht unterschiede, ob ich die 3er redundanz daten weit
auseinander getrennt im EEPROM ablege, oder kann ich die auch direkt
hintereinander, in 3 aufeinanderfolgenden blöcken speichern?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh man, hier wird ja richtig gemurkst... Marcus, willst Du oder kannst
Du das Problem mit dem I2C-Bus nicht verstehen?

 a.) Warum gehst Du davon aus, dass nur die Datenleitung
     gestört wird und die Clock-Leitung nie?

 b.) Hast Du Dir schon mal überlegt was passiert wenn die
     Clock-Leitung gestört wird und I2C-Sender und -Empfänger
     nicht mehr syncronsisiert sind?

 c.) Hast Du Dir schon mal überlegt, was passiert wenn die
     Störung auf der Datenleitung ausgerechnet dann auftritt,
     wenn die gerade zu beschreibende EEPROM-Page gesendet
     werdeb und Deine super-wichtigen Daten einer anderen Page
     deshalb überschrieben werden?

 d.) Hast Du überhaupt irgendetwas verstanden?

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu a.) wo hab ich das gesagt?

zu b.) ja

zu c.) auch ja

zu d.) das hoffe ich doch


trotzdem auch dir wieder mal danke...
doch schön das sich menschen gedanken machen...
und ich probiers ja auch gerne noch einmal:
nicht ich habe mir die gegebenheiten ausgedacht.
schön wenn du alles so machen kannst, wie du es für richtig erachtest.
ich kann es (zumindest in diesem fall) nicht.
lass mich ruhig wissen, wenn dich sonst noch etwas bedrückt.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Autor: Marcus - heinz.heinzenbach(at)gmx.net

Tja,
da haste gelitten :(
Da es nur darum geht das Steuermodul weiter weg zu bringen, kannst Du
das mit der geprüften Übertragung voll knicken !
Von den Meßstörungen der Sensordaten will ich erst gar nicht anfangen
!!!
Versuche den verantwortlichen Projektleiter oder besser neudeutsch
"Director" davon zu überzeugen, das ein Bauteil mehr (zweiter µC) mit
größerer Sicherheit und Redundanz verkauft werden kann.
Ansonsten sehe ich bei starken Störungen, die länger anhalten schwarz.
Zu Deiner Frage die Speicherung betreffend:
Es macht mehr Sinn die Daten mit jeweils einem Offset im ungeraden
Bereich versetzt auf dem EEPROM zu speichern, um sie physikalisch
voneinander zu trennen. Das hat den Vorteil, das bei einem Überlauf
zudem nicht gleich zwei identische Datenwörter überschrieben werden ;)
Aber nach der Zeichnung (die Du am besten von Anfang an 'reingestellt
hättest) ist überhaupt die Frage, ob sinnvolle Daten bei längeren
Übertragungswegen ankommen.
Ich würd einfach mal einen Testaufbau mit zwei nicht verdrillten Litzen
für'n I2C Bus machen, z.B. einfach 25m 0,75er Litze zusammengewickelt
lassen, an die Teile anschließen und dann direkt in eine ziemlich
gestörte Umgebung bringen/erzeugen ...
Zumal Du ja nie weißt, ob die ans EEPROM gesendeten Daten auch richtig
angekommen sind, also das ganze ist vom Ansatz her Murks !
Sorry,
Markus

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marcus:

Wenn Du also weißt, dass eine Kugel weder Ecken noch Kanten hat, warum
suchst Du noch immer nach ihnen? Nur weil es Dir jemand gesagt hat,
dass es auf einer Kugel doch irgendwo eine Ecke oder eine Kante geben
müsse?

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, danke euch. werd mal schauen, was sich da machen lässt.
ein weiterer testaufbau wird vermutlich schon mehr zeigen.
und wie gesagt, zu mehr als 99% wird das system dann ja auch so
aufgebaut sein, dass die I2C verbindung nur einige cm beträgt. alles
weitere werde ich dann testen.
ging ja auch eigentlich nur mal um die verfahren der 2
sicherungsmechanismen und wie man diese am besten in C realisiert...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.