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, > > > 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). > > Gut, gegen einen zweiten, also alternativen, Treiber habe ich nichts. :-) > Allerdings sollte dieser nicht auch eeprom.c2 heißen, da es sonst zu vielen Verwechslungen > kommen wird. Suche Dir einen Namen für das Mosul aus.(z.B. eepromv.c2 etc.) > > > 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. > > Ehrlich gesagt, hab' ich von Linux leider keine Ahnung. :-) > Schade, daß man sich, auch nur zum Lesen, bei Deinem Forum anmelden/registrieren muß. :-) > Soetwas habe ich hier absichtlich nicht eingeführt. Eine Registrierung verschreckt > nämlich oft viele "Newbies". > Das einzige, was es hier gibt, ist eine Namensreservierung. Dafür ist nämlich das > Feld UserID, bei dem sich sicher schon meherere gewundert haben, für was dieses > da ist. :-) (Ich muß endlich etwas Text dazuschreiben.... :-) ) > > > > 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. > > Naja, dokumentiert ist dieses Capture. (siehe i2c.html in der ZIP des Moduls i2c.c2) > Das neue Capture habe ich gleichzeitig mit dem neuem Modul cap.c2 eingeführt, > welches verschachtelte Captures zulässt.(Max. 16) > > > 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.) > > Richtig Geld verdienen kann ich damit noch nicht, aber es soll jetzt im Sommer einiges > dazukommen. Dann schon eher. :-) > Mein Hauptstandbein bleibt die Solartechnik. :-) > > > 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. > > :-) :-) :-) > > Tja, Ich als Betreiber einer Heitzngsregelung(nicht Steuerung) hab' keineswegs graue Haare > bekommen. (Hab' extra in den Spiegel geschaut *grins*) > Aber das liegt wohl daran, daß ich z.Zt. die wichtigsten Konfigurationsdaten > im Uhrenbaustein meines CC2-ReglerBoards ablege. :-) > (Ich war einfach noch zu faul ein EEProm aufzustecken.) > > > Das Low-Voltage EEprom hat sogar 20 ms... (ist aber für uns nicht relevant) > Stimmt, aber nur, wenn es mit low-Voltage betrieben wird. :-) > > > Ist das wirklich immer so? > Ob das für alle Adressbereiche gilt, muß ich noch testen, jedoch > war das EEProm nach einem geschriebenen Byte immer sofort, ohne Pause, > wieder ansprechbar. > > > 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. > > Gut, die Anzahl der VM-Operationen hängt von der Art der OPs ab. > Aber was, ASM angeht, meinte ich nur, daß durch die "Langsamkeit" des OS > zwischen den I²C-Befehlen, also z.B. zw. Start und write, eine Pause entsteht, > die in ASM so gut wie nicht vorhanden ist. > Ein gutes Bsp. wäre hier der Baustein I2C-COM die RS232 m I²C-Bus. > Der alte Treiber arbeitette nur mit C2-Code. Der neue fast nur mit ASM. > Der Geschwindigkeitsgewinn ist enorm, und der I²C-Bus besser ausgenutzt. > > > 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. > > Das kommt auf die Priorität an. > Ein Thread mit Standard-Prio(=32) Arbeitet 32 VM-OPs ab, bevor es zu einem Threadwechsel > kommt. Setzt man die Prio für einen Thread höher, z.B. 100, werden 100 VM-OPs > ausgeführt. Das Maximum wären 255 VM-OPs an einem Stück. > Hier wäre der Overhead verhältnismäßig gering, jedoch dauert es einige Zeit, bis > 255 VM-Operationen abgearbeitet sind.(Je nach Art der OPs.) > > > Nur gibt das eine Mördertrafic auf dem i2c-Bus.... unschön. Das dürfte unter asm nicht anders sein. > > Mit ASM-Routinen wäre die Zeit kürzer, in der der I²C-Bus blockiert wird. > Vorrausgesetzt, es wird bei einem nicht bereitem EEProm das Capture aufgehoben, > und die Rechenzeit abgegeben. > > > > 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. > > Ich glaube, darüber könnten wir ewig streiten, was nun besser wäre. :-) > Wenn jedoch jemand z.B. 40 einzelne Byte oder Integer-Variablen ins > EEProm schreiben will, ist die 1ms klar im Vorteil. > Gut, ich könnte, genauso, wie die Konstante für Pagewrite, eine für > "WaitTime" im Modul vorsehen, damit jeder für sich dies sehr einfach > festlegen kann. :-) > > > Nun ja.. da unterscheiden sich Linux und CC2 dann doch schon ein bischen... :-) > > Das ist fast so wie der Vergleich zwischen CC1 und CC2. :-) > > > > Ähh, ein klares Jain. :-) > > > > Suuuuper Antwort! > > Int a; > > a=0.5; //Oder wie? Oder ... > > a=vielleicht; > > a=mal_gucken; > > ??? > Du wirst lachen, das geht. (Ich sag' aber nicht, wie *grins*) > > > 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. > Ja, so ungefähr (int a=0.9 *g*) > Die Startbedingung bekommt das EEProm anscheinend immer mit, darum kann man > es mit Starts bombardieren, ohne vorher ein Stop zu senden. > Es wird nurch kein ACK zurückgegeben. Das das EEProm die weiteren Starts > dann als Repeatet-Starts mit schreib-absicht erkennt geht es ohne Stop dazwischen. > Das geht verständlicherweise natürlich nur, wenn in dieser Zeit nur das EEProm angesprochen wird. > > > 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. > > Nicht ganz. > Hier muß man zwischen explizitem und implizitem Capture unterscheiden. > Hier geht es aber nur um das Explizite. Dieses Capture ist Global anwendbar. > Es wird hier ein definiertes flag angegeben (hier i2c.flag). > Es werden alle Funktionen "blockiert", die für das Capture dasselbe flag benutzen. > > Ein guter Erklärungsversuch findet sich im Archiv das alten C-Control-Center-Forum: > "Probleme mit der Synchronisation von Threads - Sprotto 04.1.2001 17:12" (siehe "Foren") > > > 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. > > Unnötig sind diese nicht, da hier dann, wie in der alten Version von eeprom.c2, der Bus > solange blockiert wird, bis der Zugriff auf das EEProm abgeschlossen wurde. > > > Dann wären wir jetzt bei dieser Fassung: > > Ich finde diese Fassung besser: :-) > <font face="courier new" size=2>function write(byte eepromaddr,int addr) returns int > {byte i; > i=0; > eepromaddr= 160 or (eepromaddr shl 1); > loop > { > if i2c.cstart(eepromaddr) break; > i2c.stop(); > if i>=100 return 0; > i=i+1; > sleep 1; > } > i2c.write(addr shr 8); > i2c.write(addr); > return -1; > }</font> > Hier ist das neue Capture bereits implementiert. Siehst du es ? :-) > > Um ehrlich zu sein, habe ich eeprom.c2 bereits gestern Vormittag umgeschrieben. > Auch haben jetzt alle Module, außer readbyte,-int, -long, jetzt auswertbare > Rückgabewerte. Bei den Array-Schreib-Funktionen wird sogar die Anzahl der > geschriebenen Bytes zurückgegeben, falls zwischendrin etwas schiefgeht. > Ich sende Dir das Modul per Mail zu. > Veröffentlichen werde ich es frühestens, wenn ich die html-Hilfe-Datei dazu geschrieben habe. > Ich veröffentliche nämlich keine Module mehr, zumindest keine, an denen ich geschrieben > habe, bei denen keine Dukumentation dabei ist. > Und eeprom.c2 hatte bisher, außer einer kleinen Txt, keine ausreichende Doku. > > > 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. > > Das können wir gerne testen. > Wahrscheinlich kommt raus, daß der Mittelweg die Lösung sein wird. *grins* > Ich habe zwar auch schon viele Timing-Tests gemacht, aber noch nicht mit Multithreading. > Das konnte ich eigentlich immer gut abschätzen. > Aber Dein Tool kann ich gerne auch unter "Programme C2" setzen. > Das wäre sicher für ein paar Anwender nützlich. > > MfG André H.
