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.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 13:44)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 20:02)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 23:40)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 9:15)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 12:54)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 15:48)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 15.07.2003 2:57)Re: Modul eeprom.c2 (von André H. - 15.07.2003 8:25)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 10:47)Re: Modul eeprom.c2 (von 89984984/8 - 7.04.2005 10:32)Re: Modul eeprom.c2 (von André H. - 15.07.2003 11:50)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 19:31)Re: Modul eeprom.c2 (von André H. - 15.07.2003 20:26)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 22:48)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 0:43)Re: Modul eeprom.c2 (von André H. - 18.07.2003 18:19)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 18:35)Re: Modul eeprom.c2 (von André H. - 18.07.2003 19:24)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 21:38)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:53)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:55)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 1:36)Re: Modul eeprom.c2 (von André H. - 19.07.2003 8:41)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 13:02)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:18)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 14:04)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:42)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 16:39)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:24)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 11:26)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:13)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 15:04)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:42)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 21:28)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 12:16)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:28)Re: Modul eeprom.c2 (von André H. - 18.07.2003 22:43)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 0:29)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:16)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:12)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:08)