> 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: :-)
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;
}
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.
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 - 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)