> 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 max. 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:
i2c.cstart(addr);
i2c.write(cmd);
i2c.start(addr or 1);
i2c.stop();
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.
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 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)