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, > > > 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 ? > > > 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. > > > 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 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) > > > ... 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. :-) > > > 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) > Fakt ist, das Schreiben eines einzelnen Bytes benötigt weniger als eine Millisekunde, > bis das EEProm wieder ansprechbar ist. > 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. > > > 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. > 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. > 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. > 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.) > > > 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 > > Das ist eben nicht so. (write cycle <b>max.</b> 10ms) > > > 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. > > > 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. :-) > > Bis jetzt hat mein Modul den ganzen Bus aufgehalten, bis das EEprom bereit war. > Es ist nämlich zulässig das EEProm zu adressieren, ohne nach jedem erfolglosem Adressieren > ein Stop zu senden. > Wird der Bus jedoch zwischen jedem Adressierungsversuch wieder freigegeben, muß natürlich > ein i2c.stop() rein. > > > 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. > > > 5. Ich kann auch programmieren.... > > Das habe ich nie angezweifelt. :-) > > > 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 werfe die CC1 nicht in den selben Topf. > Es sollte nur eine leichte Analogie zwischen der Endlosschleife und der CC1 i2c-Start-Routine werden. > > > > > Aber das erledigt sich mit dem neuem I²C-Capture sowieso. > > > > Sowieso? Sowieso.... naja... > > Ganz einfach, es wird anders aufgerufen. > Als Beispiel: > <font face="courier new" size=2>i2c.cstart(addr); > i2c.write(cmd); > i2c.start(addr or 1); > i2c.stop();</font> > > So sieht z.B. das neue Capture aus. :-) > > > 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. :-) > > > Aber Du bist immer noch nicht bereit, meine Hilfe anzunehmen... und das... > > das finde ich wirklich schade! > > Wie gesagt, eigentlich habe ich schon bei allen vorhin genannten Module > schon angefangen zu überarbeiten. > > MfG André H.
