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!
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... :-)
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
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.
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.
Achso, wenn Du das Bitweise machen willst: (a UND b) ODER (b UND c) ODER (c UND a)
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.
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
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...
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.
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...
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.
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.
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!
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
@ 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: 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
:-) 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?
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?
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: 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
@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?
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.