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è, > > > > > 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. > > > > Na gut. Das ist ein Argument. :-) > > Aber so eine schöne Achterbahnfahrt im Aufzug wär' auch etwas neues. *grins* > > Nee, im Ernst. Ein Aufzug ist eindeutig eine sicherheitsrelevante Einrichtung. > > Hier wäre es auf jeden Fall erforderlich durch Rücklesen der geschriebenen Daten > > zu prüfen, ob diese korrekt geschrieben wurden. > > Jedoch glaube ich kaum, daß jemand eine CC2 in einer Aufzugsteuerung einsetzt, oder doch ? > > Da keiner weis, wozu sie eingesetzt wird, kann man da wohl auch kaum spekulieren... > Die Frage ist letztlich doch, zwischen Sicherheit und Komplexität und Geschwindigkeit abzuwägen... > das sollte man den User entscheiden lassen und nicht durch Vorgaben des Betriebssystems/Treiber einschränken. > Deshalb mein Vorschlag als Alternative zu den vorhandenen Treibern des eeprom.c2 ein Satz funktionsgleicher > Befehle mit Verify anzubieten... der User soll sich aussuchen können ob er es lieber schnell oder sicher haben will... > Und so viel Aufwand wäre das nicht.. ich hab ja angeboten, das zu übernemen. (zumindest für den c2. Teil). > Es geht mir dabei nicht um "Meine" oder "Deine" Funktionen.. Du kannst Sie von mir aus sogar in Deinem > Namen veröffentlichen.... nur damit klar ist, das ich keine Ansprüche stelle! > > > > 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... > > > > Sorry, aber bei eeprom.c2 bin ich irgendwie etwas eitel. Das liegt wohl daran, daß es mein > > erstes Modul war. > > Ob Du's glaubst oder nicht... auch dafür habe ich ein gewisses Verständnis... > Es ist für die CC2 ein sehr wichtiges Modul und deswegen bin ich wohl auch als erstes darüber gestolpert. > Das Modul soll weiterhin "Dein Kind" bleiben.. auch wenn ich mich da jetzt einmische. > > > > 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,... > > > > Es ist nicht meine Absicht, Dich zu provozieren. Das Problem ist, daß ich bei allen > > Modulen, die den I²C-Bus betreffen, schon genaue "Pläne" der Änderungen gemacht habe, > > und nur noch nicht zeitl. dazugekommen bin, alles umzusetzen. > > Das sehe ich ein. So wie ich das hier im Forum überblicke, bist Du bisher auch der Einzige, der sich > ernsthaft engagiert. Ich hab selbst auch ein Forum (Anderes Thema) und kann Dir da nachfühlen. > www.loch-im-netz.de falls es Dich interessiert... es geht um Linux. Du must Dich anmelden. > > > Das nächste Problem ist, daß ich ein komplett neues Capture für den I²C-Bus > > am Einführen bin, und deshalb alle Module einheitlich ausehen sollen, damit > > es später nicht zu wirklich massiven Problemen kommt. (Ähnliches ist nämlich schon woanders passiert) > > Das hat aber zur Folge, das kaum einer in der Lage sein wird, dann noch den Code nachzuvollziehen.. > Das schreckt auch ab.. ich hoffe, Du hast Dir das gut überlegt. Ich weis aber auch, das es aus > Performancgründen sinnvoll sein kann... von da her hab ich nicht mal was dagegen. Aber Du solltest es gut > dokumentieren... sonst hast Du ganz schnell das MS-Image ;-) Aber ich denke, das ist Dir klar. > > > > ... prophezeihe ich Dir den Tag, wo du mit > > > der CC2 und "Deinen" Treibern alleine stehst. > > > > Tja, da sieht die Resonanz der User aber anders aus. > > Ehrlich gesagt, stell Dir einmal vor, CC2Net.de würde es nicht geben. > > Die einzige wirkliche andere CC2-Site ist durch mehrere unglückliche Ereignisse "verstorben". > > Ich glaube kaum, daß sich irgendjemand anderes die Arbeit gemacht hätte, > > eine Site wie CC2Net.de aufzubauen. > > (Oder besseres Beispiel: Schaue Dir einmal die offizielle C-Control Site an, oder > > den Support von Conrad) > > > > > Linux und open source ist das beste Beispiel! > > > Dort wird auch zusammen entwickelt.. und nicht gegeeinander! > > > > Naja, Linux ist, glaube ich, ein klein wenig komplexer. :-) > > Das ist wohl so... aber dort schreiben die Leute im Prinzip den gleichen Kram wie hier... > und kloppen sich auf die gleiche Art wie wir jetzt ... :-) > Und was Deine Site angeht - ich weis das die CC2 schlecht supportet wird und finde das schade. > Ich sehe, das Du Dir die Mühe machst und ich finde auch ok wenn Du damit Geld verdienst (cctools). > (Ich überleg mir selbst grade, bei Dir zu bestellen.) > Aber wenn ich als Freund einer Heizungssteuerung den Thread hier lese, würde ich graue Haare kriegen. > Und das - finde ich - muß nicht sein. Auch Heizungssteuerungen haben ein Anrecht auf korrekte Funktion. > :-) :-) :-) > > > > 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. > > > > Da muß ich Dir leider widersprechen: > > Lt. allen Datenblättern heißt es meistens max. 10ms. (Manche Typen auch 5ms) > > Das Low-Voltage EEprom hat sogar 20 ms... (ist aber für uns nicht relevant) > Aber Du hast recht... es wird von max. gesprochen. > > > Fakt ist, das Schreiben eines einzelnen Bytes benötigt weniger als eine Millisekunde, > > bis das EEProm wieder ansprechbar ist. > > Ist das wirklich immer so? > > > Das haben auch ettliche Versuche ergeben. > > Es dauert max. 10ms bei einer ganzen Page. > > Bei weniger Daten auch entsprechend weniger. > > Es gibt aber auch ein weiteres "Phänomen", daß bei manchen EEProms, je > > weiter man in den hinteren Adressbereich kommt, länger zum Schreiben > > gebraucht wird. > > Na schon deswegen wäre ja nicht unbedingt immer von 1ms auszugehen. > Aber ich verstehe was Du meinst. > > > > > > 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. > > > > Der Sinn einer ASM-Routine läge eher da, die "Langsamkeit" des Betriebssystems auszugleichen und > > den I²C-Bus selbst besser zu nützen. > > Die geänderten Routinen machen im Fehlerfall jetzt schon weniger Traffic auf dem Bus als vorher. > Die bausteinbedingten Zwangswartezeiten lassen sich aber auch durch asm kaum verkürzen. > Ausser beim Burstmode. Das Betriebssystem schafft offensichtlich nur etwa 1000 bis 3000 Zeilen > pro Sek. c2-Code. Das habe ich messen können. Ein sleep-wert von 1 reicht gerade um eine einzige > int-Addition in einem Fremden Thread auszuführen. Das ist für fremde Treads zu wenig und kostet > nur enorme Treadwechselzeiten. Da wäre es evtl. sogar besser, mit einer loop ohne sleep den Baustein > mit der Adressierung zu bombardieren so das sofort geschrieben werden kann wenn der Baustein frei ist. > Nur gibt das eine Mördertrafic auf dem i2c-Bus.... unschön. Das dürfte unter asm nicht anders sein. > > > Das einige Funktionen schneller ausgeführt würden, wäre ein angenehmer Nebeneffekt. :-) > > Jedoch wäre jede Funktion durch ASM ein wenig schneller, da zwischen den > > einzelnen I²C-Kommandos weniger "Pausen" wären. > > > > > 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 > > > > Klar wird der Overhead kleiner, jedoch sind es eben keine festen 10ms. > > Deswegen hab ich ja auch 5 ms genommen die in 99% aller Fälle ja nicht mal genutzt werden. > Siehe auch letzten Kommentar. > > > Es hängt eben, wie oben beschrieben, von der Datenmenge ab, wann ein EEProm wieder bereit ist. > > Darum macht "meine" 1ms auch Sinn. Werden jedoch meistens Arrays geschrieben, > > würden natürlich die 5ms mehr Sinn machen. > > GE-NAU! > Es gibt eben kein Pauschaloptimum... :-) > > > Ich sehe es eben so: > > Sollen Daten in ein EEProm geschrieben werden, soll dies wahrscheinlich so > > schnell wie möglich passieren. > > > > > 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 > > > > Das eben nur, wenn man ganze Pages schreibt.(Rest s.o.) > > hm... > > > > 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è! > > > > Klar ist, daß Du recht hast, wenn "größere" Datenmengen (Arrays/Strings) geschrieben > > werden. Jedoch bei einzelnen Bytes sieht es wieder anders aus. > > > > Dein Kompetenz zweifle ich keinesfalls an. > > Ich weiß zwar nicht, wie bei Linux prioritäten gesetzt werden, jedoch kann man > > bei der CC2 auch bei den Threads Prioritäten setzen. > > Nun ja.. da unterscheiden sich Linux und CC2 dann doch schon ein bischen... :-) > > > > 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. > > > > Gut, das war eine unglückliche Formulierung von mir. > > Ich meinte eben damit, wenn das EEProm z.B. nach 1ms schon wieder bereit ist, > > wird unnötig 4ms gewartet. > > > > > 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. > > > > Ähh, ein klares Jain. :-) > > Suuuuper Antwort! > Int a; > a=0.5; //Oder wie? Oder ... > a=vielleicht; > a=mal_gucken; > ??? > > Ich vermute, Du meinst: > Das Eprom braucht keine Stopkondition da es vom Start nichts mitbekommen hat. > Andere Devices brauchen es sehr wohl damit sie wissen, das der Bus wieder frei ist. > Ist das so richtig? Wenn ja, dann hab ich es ja richtig gemacht. > > > Bis jetzt hat mein Modul den ganzen Bus aufgehalten, bis das EEprom bereit war. > > GE-NAU! > > > > 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!!! > > > > Natürlich gibt es Threadwechsel innerhalb von Captures. > > Ein Capture ist schließlich keine Funktion, die die anderen Threads anhält. > > Nur die Threads, die das gleiche Capture benutzen, warten eben an der Stelle > > mit dem Capture-Befehl, bis das flag wieder freigegeben wurde. > > Hm.... hm.... das bedeutet, das mit sleep durchaus auch in einem Captureblock andere Threads > Rechenzeit kriegen.. nur der Aufruf einer aktiven Funktion wird für den Zeitraum des Capture > blockiert... das Capture verhindert also, das die Funktionen mehrfach zeitgleich aufgerufen werden. > Da liegt allerdings bei mir ein Mißverständnis vor. Ich dachte, das Capture wäre sowas wie das sperren > aller Interuptquellen. Kennst Du ja bestimmt auch... dann sind die Captures sowas wie die Spinlocks > unter Linux.... damit sind die von mir eingefügten release/Captureaufrufe tatsächlich unnötig. > Ich werd's gleich korrigieren. > > > > 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... > > > > Gut, ich hab mich wieder unglüklich ausgedrückt. > > Gemeint war, daß die Rechenzeit an den nächsten Thread weitergegeben wird, und nicht der > > Thread selbst freigegeben wird. > > Fakt ist, daß bei z.B. 20 Threads genügend Zeit vergeht, bis der > > "EEProm-Thread" wieder Rechenzeit bekommt, daß ein Sleep nicht notwendig wäre. > > Bei zwei Threads enstünde jedoch wirklich unnötiger Overhead. Da u.U. weniger Zeit > > vergeht als nötig wäre. > > (Kann sein, daß ich mich wieder etwas unglücklich ausdrücke, sorry) > > > > > 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. > > > > Ich fände es eigenlich besser, wenn Du die Reihenfolge wie geplant einhältst. > > > Schon damit Du Deinen Arbeitsablauf nicht wegen mir ändern must. > > Ich denke mal, das war sarkastisch gemeint. :-) > > NEIN, war es nicht! > Wenn ich sarkastisch werde, wirst Du es wissen :-) > > Dann wären wir jetzt bei dieser Fassung: > > /**Schreibzugriff einleiten****************************************/ > function write(byte eepromaddr,int addr) returns int > { > byte i; > i=0; > eepromaddr= 160 or (eepromaddr shl 1); > loop > { > if i2c.start(eepromaddr) break; > i2c.stop(); //--RD./AH. stop nach Fehlschlag > if i>=100 return 0; > i=i+5; > sleep 5; > } > i2c.write(addr shr 8); > i2c.write(addr); > return -1; > } > > Irgendwie finde ich es müssig, dauernd über die Performance zu diskutieren ohne mit > konkreten Zahlen zu arbeiten. Ich hab mir ein kleines Benchmarktool geschrieben. > Ich fange dafür aber einen neuen Thread an. (Programmieren) > > Ggf. ist es auch für Dich interssant. Ich werde damit die Eeprom-Funktionen auf Herz und Nieren > und "Deine" gegen "meine" testen. Evtl. kriegen wir das dann auch mit den 5 ms noch geregelt. > > Gruß Rolf

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

max. 256kB

max. 256kB