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è, > > > 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.) > > sowas wird's wohl werden... > > > Ehrlich gesagt, hab' ich von Linux leider keine Ahnung. :-) > > Schade, daß man sich, auch nur zum Lesen, bei Deinem Forum anmelden/registrieren muß. :-) > > Das macht Sinn, da es ursprünglich ein Forum für eine Weiterbildungsveranstaltung im Bereich Linux war. > Ich werde das Forum aber demnächst für das Publikum öffnen. > > > > 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.) > > :-) > Mein Onkel verkauft auch als Fachhändler Solaranlagen... ich weis aber nicht mal, welche Steuerungen > er verwendet. Irgend was fertiges.... > > > > 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. > > Das Asm vorteile hat, ist klar. Es wäre nur nicht zweckmässig "schneller zu warten". > Das hatte ich ja schon ausgeführt. Sonst ist das mit dem asm-Code ja ok. > > > > 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. > > Das alles läst sich ja nun mit Bfast wunderbar austesten... :-) evtl... demnächst.. weil..: > > Mir kommt da ein Verdacht... vieleicht kannst Du mich da auch aufklären... > Wenn die VM "nur" abhängig vom "Runlevel" eine bestimte Menge an festgelegten Operationen ausführt, > kann ich in Prinzip eine Int-addition garnicht mit einer long-addition vergleichen da immer beide Testschleifen > gleich oft durchlaufen werden. Richtig? > > Das bedeutet aber, das mein Bfast im prinzip derzeit nicht zu gebrauchen ist weil letzlich nur die Gesamtzahl > an Schleifen eine Aussage zur Leistung enthält. Die Angaben zu den einzelnen Schleifen ist eigentlich nur dann > unterschiedlich, wenn die Schleifen unterschiedliche Mengen an VM-Operationen enthalten. Richtig? > > Die einzigen Faktoren im aktuellen Bfast sind also die Menge der VM-Instruktionen und Operationen > zur Threadsteuerung (run level, yield, wait, halt, usw.) Das bedeutet, ich muß Bfast erst noch mal überarbeiten > bevor Du es richtig online stellen kannst. Ich mache an mein Thread sofort ne Bemerkung. > > Ich denke mal, wir werden da beide noch so die eine oder andere Überraschung erleben den die VM > des CC2 verhält sich offensichtlich nicht so, wie man es von einer CPU vermuten würde. > Z.B. sind die Zeiten für Int-additionen fast gleich wie bei Long-additionen... das würde ich bei einer > 16Bit-CPU so erst mal nicht vermuten. > > > 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. > > Das war ja im Prinzip auch meine Idee. Nur wollte ich es als c2-Code und sozusagen > als Prototyp für die Konvertierung nach asm umsetzen und erst in einem 2.ten Schritt > und nach einer Testphase dann von Dir nach asm konvertieren lassen. > > > > > 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. :-) > > Das wäre sicher eine Möglichkeit. Ich denke aber, wir können auch mit Bfast die Werte ermitteln. > Wenn sich die 1 ms als praktikabel herausstellt, hab ich ja nichts dagegen. > > > > > Ä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. > > So dachte ich mir das nach Deinen Ausführungen auch in etwa. > Für den Fall, das ein Eeprom nicht reagiert oder man den Schreibzyklus abbrechen will, muß dann aber > ein Stop kommen damit die anderen Bausteine sich nicht verschlucken. > > > > 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. > > Hm.. dann war die Idee, das capture aufzuheben wenn der Fall des Wartens eintritt, > also doch nicht so verkehrt. Nur für 1 ms lohnt sich das nicht. Da kommen wir dann wider zu der > 1ms/5ms-Geschichte. mit 1 ms wäre Deine Fassung besser, mit 5 ms die Fassung mit dem freigeben > des i2c-Captures und neues setzen nachdem sleep abgelaufen ist. (hatte ich so schon mal gepostet). > > > > 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 ? :-) > > Ja... > if i2c.cstart(eepromaddr) break; > ^ da... wenn die Proportionalschrift mir da nicht den Satz zerbröselt... > > > 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. > > Das wäre Klasse... rolf(at)diesing.net > Ich teste das und sag Dir Bescheid.. dann kannst Du es nach belieben freigeben. > > > 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. > > Das ist nen guter Vorsatz :-) > > > Und eeprom.c2 hatte bisher, außer einer kleinen Txt, keine ausreichende Doku. > > Och.. man kann sich aber gut reinlesen.... :-) > > > > 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. > > Das wäre schön... wäre vor allem klasse, wenn das Teil als Aufforderung genommen wird, es > zu erweitern... für das wo ich es brauche, reicht mir das erst mal.. ich denke, das sich um > die Möglichkeiten der VM eine Menge Gerüchte halten da kaum jemand wirklich die Abläufe > versteht. Learning by doing... oder so... > > Apropos... > Für den fall, das man ein Hardware-watchdog hätte... (ist ja nachzurüsten) > wären folgende Funktionen noch schneller als alles bisher besprochene.. (ausserevtl. der asm-code) > da kein sleep nötig ist. Ohne Watchdog bleibt die Scheife aber hängen wenn sich ein eeprom tot stellt. > Ich hatte mir das für die Verify-Funktion so überlegt.... denn dieser Zugriff + Verify dürfte genau so schnell > sein wie ein Schreibversuch mit sleep. > > function writeabyte(byte eepromaddr,int addr,byte data) > { > capture i2c.flag; > //evtl. HW-watchdog oder Timer starten.... > wait i2c.start(160 or (eepromaddr shl 1)); > i2c.write(addr shr 8); > i2c.write(addr); > i2c.write(data); > i2c.stop(); > //hier dann noch mal eine Lesefunktion ähnlicher Bauart und vergleich ob Daten identisch sind. > release; > } > > Wäre das evtl. auch mit Deinen Asm-Funktionen zu regeln? > Also wait i2c.cstart(160 or (eepromaddr shl 1)); ? > > Gruß Rolf

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

max. 256kB

max. 256kB