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 Andrè, > > > 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

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB