>
> > 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
Antwort schreiben
Antworten:
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)