Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Rolf, > > Zuerst: Poste bitte nicht komplette Module ins Forum. > Ab einer bestimmten Länge kann es u.U. zu Problemen mit dem Script kommen. > Einzelne Funktionen reichen völlig, da jede Funktion im Prinzip gleich aufgebaut ist. > > > Wenn ich als Programm z.b. bei einem Fehler des Eeproms eine Meldung wie "Service" aus dem Display > > darstellen will/kann, muß ich natürlich auch als Programm erfahren wenn was schief geht. Mir ist klar, das > > man in einer Steuerung wie der CC2 dies nicht bis Ultimo durchziehen kann. Aber wo es leicht Möglich ist, > > sollte es passieren, und sei es nur um den Ruf der CC2 als sicheres System zu verbessern. > > Was hat das wiederum mit dem Ruf der CC2 zu tun ? > Das wäre jetzt so, als wenn man z.B. den Ruf von einem Rechner mit Linux an Hand > der Software, die darauf läuft, bestimmt. > > > Das sehe ich auch so. Es wäre also ggf. darüber nachzudenken, ob man nicht sogar einen zweiten Satz > > Funktionen baut, die genau das beim schreiben schon prüfen oder die vorhandenen Funktionen um eine > > "Verify-Option" erweitert. Für Anwendungen bei denen es auf die 100%tige Datensicherheit ankommt. > > Man darf ja nicht vergessen, das Eeproms relativ langsam sind und rum um den Schreibvorgang jede Menge > > Zeit bleibt, um weitere Operationen durchzuführen. Dazu komme ich aber gleich noch mal. > > Ich überlege mir, ob ich das nicht evtl. sogar mit dem Verify machen soll. > > Eines muß ich auf jeden Fall einmal klarstellen: :-) > Wenn jemand Sicherheit bis ins kleinste Detail braucht, muß man eben selbst Hand > anlegen und Systemressourcen dafür verwenden. (Das Ganze wird dann sehr langsam ...) > Fakt ist, daß es in eeprom.c2 und eeprom2k.c2 kein "Verify" geben wird. > Als kleines Beispiel sei hier mal die CC1 genannt: > Hier wird das gesamte Programm in einem EEProm abgelegt. Es wird lediglich > geprüft, ob dieses ein Ackknowledge sendet, jedoch nicht, ob die Daten auch wirklich > geschrieben wurden. Auch bei anderen Mikrocontrollern wird das nicht gemacht, da > es natürlich sehr unwahrscheinlich ist, daß es zu einem Fehler kommt. > > > > Das sehe ich immer noch anders... wenn die CC2 steuertechnisch Mist baut weil das i2c-Eprom falsche/veraltete > > Daten hat (z.B. auf Grund einer fehlgeschlagenen Schreiboperation), ist es sehr wohl ein Problem des > > Gesamtsystems und damit auch der CC2, dem I2C und den Treibern. > > Tja, wie gesagt. Mit dem Bus selbst hat das kaum etwas zu tun. Eher mit der Software > oder dem EEProm selbst. > > > Natürlich liegt die Ursache nicht in der CC2 oder den Treibern aber das Problem wurde durch sie auch nicht > > verhindert. Die CC2 ist zwar kein Flugzeugboardcomputer aber würdest Du dort auch so agumentieren? > > Und wenn nicht, was unterscheidet die CC2 abgesehen vom Preis dann von einem Boardrechner? > > Wenn Du mir "Zuverlässigkeit" als Grund nennst, haben wir eine gemeinsame Linie gefunden. > > Das ist kein Vergleich. Warum, meinst Du, sind Boardrechner immer mehrfach vorhanden !? > Ganz einfach: weil es keine absolute Sicherheit gibt. : -) > > Um auf falsche Daten zurück zu kommen: > Ist es so schlimm, wenn bei einer Heizungsregelung einmal ein Byte nicht gespeichert wird. > was kann schlimmstenfalls passieren? > - Die Schaltuhr funzt noch nach den alten Daten > - Die geänderte Solltemperatur wird nicht übernommen > - Die geänderte Heizkurve wird nicht gespeichert > - usw. > Also nichts sicherheitrelevantes. Hier kommt nieman und nichts zu Schaden. > Vielleicht wird es ein wenig zu warm, oder nicht warm genug. Aberso wild wäre > das auch nicht. Außerdem sollten sich die Werte auch im RAM befinden, > da es keinen Sinn macht, diese jedesmal aus dem EEProm zu lesen. > > Etwas anders könnte man dies bei einer Datenerfassung sehen. > Hier gibt es eben schlimmstenfalls einen Datenverlust. > > > > Sehe ich auch so... war aber auch eigentlich nur sozusagen meine Arbeitsversion... > > Ich optimiere eigentlich erst, wenn alles zur zufriedenheit läuft. > > Ok, ich optimiere immer während dem Programmieren. :-) > > > > Ich werde mal sehen, ob ich eeprom.c2 irgendwie mir schon früher vornehme. > > > > Lass mich das doch machen... zumindest was den c2-Teil angeht... wenn der sauber ist, kannst > > Du ihn evtl. auch leichter in asm umschreiben. Wenn wir weiter in kontakt bleiben, klapt das doch prima. > > Ehrlich gesagt, weiß ich nicht, ob Du schon mit dem neuen I²C-Capture zurechtkommst. > Außerdem bin ich am Überlegen, ob ich den Treiber in ASM schreiben werde. > Das hätte beim Lesen von Daten enorme Vorteile. Auch würde der I²C-Bus besser > ausgenützt. > Jedoch spricht auch einiges dagegen, wenn jemand, z.B. wg. einer Verify-Funktion, > eigene Routinen schreiben möchte. :-) > Ich glaub' ich lasse hier ASM weg. > > > Apropos.... > > in den Funktionen read und write wird ja max. 120 ms auf das eeprom gewartet. 100 ms durch Timer, > > ca. 20 ms durch die Laufzeit... ich würde das mal als "schnelles warten" bezeichnen. > > Was hältst Du von folgender Konstruktion? > > ... > > loop > > { > > if i2c.start(eepromaddr) break; > > if i>=100 return FALSE; > > release; //--------------------------- Änderung, gibt Thread frei > > i=i+5; > > sleep 5; > > capture i2c.flag; //--------------------------- Änderung, Thread ist gesperrt > > } > > ... > > Die Loopschleife wir ja durch break verlassen wenn der Versuch erfolgreich war. > > Ist das Eprom nicht bereit, muß gewartet werden. In der Zeit könnten aber andere Threads laufen. > > Das erreiche ich, in dem das Capture vor dem sleep freigegeben und nach dem sleep wieder gesetzt wird. > > wärend des sleep hätte die CC2 Zeit, andere Treads zu bedienen da in der Zeit effektiv nichts auf dem i2c passiert. > > Durch das setzen von 5 ms lohnt sich der Treadwechsel auch und es dürfte kaum zu verzögerungen kommen. > > Das ganze nutzt also vor allem anderen Treads, die wärend des Schreibens des eeproms Rechenzeit benötigen. > > Das erledigt sich durch das neue Capture von selbst ... > Da bei sleep automatisch ein Threadwechsel zustandekommt, > sollte es bei 1ms bleiben. Denn zum schreiben einer Page von 32Byte > werden max. 10ms benötigt. Bei weniger Daten entsprechen kürzer. > Es wäre es nicht klug, den Schreibvorgang für 5ms zu unterbrechen, > wenn das EEProm vielleicht nur 1 bis 2ms zum Schreiben von Daten > benötigt. Hier würde das Schreiben unnötig aufgehalten werden. > > > Eine Variante schnellere dazu ist folgende Konstruktion. > > ... > > loop > > { > > if i2c.start(eepromaddr) break; > > release; //--------------------------- Änderung, gibt Thread frei > > yield > > capture i2c.flag; //--------------------------- Änderung, Thread ist gesperrt > > } > > ... > > > > Bei dieser Version wird nicht mehr auf die Zeit von 100 ms geprüft sondern nur der Thread sofort abgegeben. > > Das ist wohl das schnellste was man sich denken kann, leider würde ein defektes Eprom jedoch zu einer > > dauerhaften und vorerst unentdeckten Threadschleife führen da die loop nicht verlassen werden kann. > > Das widerum könte durch eine Verify-Funktion nach einer gewissen Zeit (wie oben schon angesprochen) > > entdeckt und geprüft werden. (Da ja nun der Thread freigegeben wird(yield)). > > Diese Art der Konstruktion hätte nur bei Anwendungen mit sehr vielen Threads einen Sinn. > Bei Programmen mit zwei bis drei Threads, wird hier u.U. zuviel Rechenzeit investiert. > Auch das evtl. Endlos-Loop führt, wie Du schon erkannt hast zu Problemen. > Auf diese weise funzt nämlich das Lesen am CC1-I²C-Bus. Und dort gibt es deswegen > "Abstürze". > > Außerdem haben beide Funktionen dasselbe Problem: > Sie geben zwar das Capture frei, blockieren aber dennoch den Bus, > da kein STOP gesendet wurde. > Aber das erledigt sich mit dem neuem I²C-Capture sowieso. > > Jetzt werde ich vielleicht doch eeprom.c2 mir als nächstes vornehmen. > Die Ursprüngliche Reihenfolge war: > ram.c2 - komplett Neu schreiben > ram_hs.c2 - komplett Neu schreiben > eeprom.c2 - Anpassung auf neues I²C-Capture / Rückgabewerte / evtl. ASM > eeprom_2k.c2 - Anpassung auf I²C-Capture / Rückgabewerte / evtl. ASM > pcflcd.c2 - Anpassung neues auf I²C-Capture > pcf.c2 - Anpassung auf neues I²C-Capture / Überarbeitung > pcf8583.c2 - Anpassung auf neues I²C-Capture > i2ckop.c2 - Anpassung auf neues I²C-Capture > pcfkeyb.c2 - Anpassung auf neues I²C-Capture > > Bereits auf neues Capture angepasst und veröffentlicht: > i2ccom.c2 > > Bereits auf neues Capture angepasst, aber noch nicht veröffentlicht: > ds1621.c2 > ds1631.c2 > > Ich hatte ursprünglich vor, die Module möglichst zeitgleich zu veröffentlichen, > da es ansonsten zu Problemen kommt, wenn zwei verschiedene Captures > verwendet werden. Es müsste dann jeder User übergangsweise > die neuen Modulversionen zusätzlich mit capture i2c.flag "einbetten". > > MfG André H.
