> 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.
Ok..
> 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.
Na gut.. dann denke Dir doch einfach, die CC2 läuft als Steuerung für ein Aufzugsystem
und im EEprom sollen selbstlernende lastabhängige Beschleunigungskurven gespeichert werden...
Falsche Daten im EEprom hätten sehr wohl einen deutlichen Effekt.
> > > 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.
Ich habe ausdrücklich geschrieben, das ich anbiete, den c2-Code zu schreiben. Nicht den asm-code und nicht
die Verwendung des I²C-Capture. Nebenbei.... ich hab schon vor 20 Jahren auf dem Z80 in asm programmiert...
> 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.
Lieber Andrè, Du provozierst so nur, das ich irgendwann stinkesauer bin. Vieleicht überdenkst Du mal Dein
Verhalten. Wenn Du nur ein "normaler User" bist, solltest Du froh sein wenn es Leute gibt, die Dich tatkräftig
unterstützen. Wenn Du statt dessen die Arbeit an der CC2 und Treibern als "alleinverantwortlich" betrachtest
und Vorschlägen und Angeboten nur Abweisend gegenüber stehst, prophezeihe ich Dir den Tag, wo du mit
der CC2 und "Deinen" Treibern alleine stehst. Linux und open source ist das beste Beispiel!
Dort wird auch zusammen entwickelt.. und nicht gegeeinander!
> > 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.
Also... Diesmal habe ich die besseren Argumente.
1. Laut Datenblatt für das Atmel 24c512 müssen zwischen dem letzen Stop-Zyklus und dem nächsten
Start-Zyklus min. 10 ms vergehen. Das wird bei anderen Typen nicht viel anders sein.
Schreibe ich 32 mal ein Byte mit writebyte, vergehen damit zwangsläufig immer min. 320 ms.
Dabei ist egal ob in der gleichen Page oder in verschiedenen Pages gearbeitet wird.
Nur wenn Strings oder Arrays ohne start/stop-kondition (Page writing) geschrieben werden, sieht das
Warte/Arbeitsverhältnis besser aus. Das wäre auch der einzige Bereich, von dem eine asm-Routine
profitieren evtl. würde da man eine Art Burst-Mode verwenden würde. Geht der Schreibvorgang über
Pagegrenzen hinweg, muÃ? vermutlich pro Pagegrenze wieder gewartet werden.
Der "Burst-Mode" wäre damit nur max. 32-128 Byte je nach Baustein lang und geht nicht
über den ganzen Speicher. Es macht also nur Sinn, Funktionen mit "Burst-Mode" in asm zu optimieren.
Diese Fakten sind durch die Bausteine so vorgegeben.
2. Vom Ablauf her macht meine 1.ste Funktionsänderung folgendes:
Sie versucht das Eprom zu Adressieren und wenn es klappt, wird normal geschrieben. (so wie bei Dir)
Klappt es nicht, muÃ? kurz vorher eine Stop-Kondition auf dem Bus gewesen sein... warten! (so wie bei Dir)
Bei mir wird aber 5 ms gewartet da der Baustein min. 10 ms nach einem Stop nichts annimmt.
Beispielrechnung mit verschiednenen Ausgangssituationen:
Der Baustein ist (typisch) ab dem Schreibversuch 2 ms lang belegt.
Bei mir 1 Schleifendurchlauf, und 3 ms Verlust, 1 mal 5 ms Threadzeit freigegeben.
Bei Dir 3 Schreibversuche und 3 mal 1 ms freigegeben pus 10 % Overhead für 3 Schleifen
Der Baustein ist (typisch) ab dem Schreibversuch 8 ms lang belegt.
Bei mir 2 Schleifendurchläufe, und 2 ms Verlust, 2 mal 5 ms Threadzeit freigegeben.
Bei Dir 9 Schreibversuche und 9 mal 1 ms freigegeben pus 10 % Overhead für 9 Schleifen
Der Baustein ist (worst case) ab dem Schreibversuch 22 ms lang belegt.
Bei mir max 5 Schleifendurchläufe, und 3 ms Verlust, 5 mal 5 ms Threadzeit freigegeben.
Bei Dir 23 Schreibversuche und 23 mal 1 ms freigegeben pus 10 % Overhead für 23 Schleifen
Der Baustein ist (Busproblem, Einstreuung) ab dem Schreibversuch 85 ms lang belegt.
Bei mir max 18 Schleifendurchläufe, und 5 ms Verlust, 18 mal 5 ms Threadzeit freigegeben.
Bei Dir 86 Schreibversuche und 86 mal 1 ms freigegeben pus 10 % Overhead für 86 Schleifen
Dies zeigt, das meine Funktion zwar geringfügig langsamer ist, anderen Threads aber mehr
zusammenhängende Rechenzeit zur Verfügung stellt. Und das ist nun mal das A un O eines
Threading-Systems. Da die CC2 nicht wie Unix ein Taskprioritätensystem hat sondern erher mit
dem Tasking unter Win9x zu vergleichen ist, mu� auf die "Gutmütigkeit" der Tasks gesetzt werden.
Sonst hebelt man das Threading aus. Ich weis wovon ich rede, Andrè!
3. Ausserdem unterbreche ich nicht den Schreibvorgang wie Du sagst, ich unterbreche das Warten
auf das EEprom bis zu dem Zeitpunkt, wo das schreiben funktioniert. Das ist ein riesen Unterschied.
Deine Routine führt nach einem fehlgeschagenen Adressierungsversuch kein Stop ein und
deshalb habe ich dies auch nicht gemacht. Nach dem was Du jetzt sagst, muÃ? da aber einer rein.
So etwa...
> > loop
> > {
> > if i2c.start(eepromaddr) break;
i2c.stop(); // Stop nach fehlgeschlagenem Adressierungsversuch <---------- Neu
> > release; //--------------------------- Ã?nderung, gibt Thread frei
> > yield //--------------------------- Evtl. sleep statt yield... ist noch nicht raus...
> > capture i2c.flag; //--------------------------- Ã?nderung, Thread ist gesperrt
> > }
Es werden durch meine Funktion letztlich max 4 ms gegenüber Deiner Variante zusätzlich verwendet,
und auch nur dann, wenn das EEprom vorher nicht bereit war..
Es werden bei mir viele unnütze Schleifenzyklen (10-20% Overhead nach Deinen Angaben)
eingespart und zusammenhängende Rechenzeit in 5ms Blöcken freigegeben.
4. Ich möchte von Dir eine klare Aussage, ob nach einem capture i2c.flag; ein Threadwechsel durch sleep
möglich ist oder ob der Thread erst nach dem release; wieder gewechselt werden kann. Wenn ein Threadwechsel
INNERHALB eines capture i2c.flag; - release; Bereichs NICHT möglich ist, sieht Deine Funktion bezüglich
Threadperformance nämlich noch wesentlich bescheidener aus als in den Beispielen gezeigt!
Das Handbuch zur CC2 ist dazu eigentlich sehr eindeutig!!!
5. Ich kann auch programmieren....
> > ...
> >
> > 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.
Mit dem Argument schiest Du Dir selbst ins Knie... eignetlich sollte ich das unkommentiert stehen lassen!
Schlie�lich ist die CC2 Threadfähig und das macht die Leistungsfähigkeit erst aus. Man kann jedes
Threading-Betriebsystem durch lineares denken blockieren.... selbst Unix...
> Bei Programmen mit zwei bis drei Threads, wird hier u.U. zuviel Rechenzeit investiert.
Das habe ich bereits widerlegt.
> 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".
Ich habe die CC1 und kenne mich auch mit dem System aus. Ich weigere mich aber, die CC1 und
die CC2 in einen Topf zu schmeiÃ?en. Die CC1 ist nur der Beleg, das schlecht geschriebene
i2c-Funktionen zu fehlerhaften Gesamtsystemen führen und Grund genug, das in der CC2 zu verbessern.
>
> AuÃ?erdem haben beide Funktionen dasselbe Problem:
> Sie geben zwar das Capture frei, blockieren aber dennoch den Bus,
> da kein STOP gesendet wurde.
Das habe ich korrigert, es bezog sich auf DEIN Fehler wie bereits geschrieben.
> Aber das erledigt sich mit dem neuem I²C-Capture sowieso.
Sowieso? Sowieso.... naja...
> 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".
Ich fände es eigenlich besser, wenn Du die Reihenfolge wie geplant einhältst.
Schon damit Du Deinen Arbeitsablauf nicht wegen mir ändern must.
Aber Du bist immer noch nicht bereit, meine Hilfe anzunehmen... und das...
das finde ich wirklich schade!
GruÃ? Rolf
Antwort schreiben
Antworten:
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)