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