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, > > > > Welche Fehlfunktion ??! > > > > Na zum Beispiel fehlerhaft arbeitende Eeproms. Oder ein Fehler auf dem i2c-Bus. Oder ein fehlendes i=0; > > > Ich hatte die "Fehlfunktiunen" auf Dein Testproggie bezogen. :-) > Ein fehlerhaft arbeitendes EEProm ist ein defektes EEProm. Da kann man nicht > viel machen (außer austauschen). Fehler auf dem Bus werden erst nach 10m, > wenn man z.B. ohne Extender arbeitet, möglich. Außer natürlich Kurzschlüsse. > Übrigens habe ich den I²C-Bus schon ohne Treiberbausteine schon auf 90m "getrieben", > ohne daß es zu störungen kam. Jedoch darf man soetwas nur zu Testzwecken machen > Hier gehört auf jeden Fall, wenigstens zum Schutz der CC2-Ports, ein I²C-Bus-Extender > dazwischen > Und das kleine fehlende i=0; ist wohl keine Hardwarefehlfunktion. :-) > > > Nana... einen weiteren hast Du selbst heute noch gefixt. :-) > Kleiner Bug gefixed = erledigt. Darum ist das kein Thema mehr. > > > Aud das zu häufige beschreiben kann ein eeprom plätten..... obwol ich nicht weis, wie es sich dann > > auf dem i2c-Bus verhält. Ggf. würde das nicht mal beim Adressieren auffallen. > > Das fällt überhaupt nicht auf, bis Du einen Wert zurückliest. Das EEProm wird funzt weiterhin funzen, > nur lassen sich die betroffennen Speicherzellen nicht mehr ändern. > > > Ich halte es jedenfalls für ein Unding, das Treibersoftware (und das ist eeprom.c2 nun mal) gnadenlos > > über ein offensichtlichen Fehler des eeprom-i2c-Systems hinwegschaut als wenn nichts gewesen wäre. > > Wenn das EEProm nicht mehr funzt hat das nichts direkt mit I²C zu tun. > > Außderdem mußt Du das Ganze auch einmal anders sehen: > (Fast) jedes Modul ist sozusagen in meiner "Freizeit" entstanden, da ich mit der CC2 selbst, > also Conrad, nichts zu tun habe, sondern auch nur ein "User" bin. > Das gilt auch für CC2Net.de . Im Prinzip ist CC2Net.de eine private Hobby-Seite. > Jedoch hat Sie eher die Funktion der offiziellen Supportseite übernommen. :-) > Das wird wahrscheinlich so ziemlich jeder CC2-User sagen. > Der größte Teil des Supports zur CC2 läuft nachweislich eben über meine > (private) Site CC2Net.de . > Gut, seit einem Jahr habe ich auch geschäftlich mit der CC2 zu tun, als ich CCTools > ins leben gerufen habe, aber das war Ursprünglich nur zur finanzierung von CC2Net.de > gedacht. :-) > > Einige Module sind vielleicht nicht perfekt, aber sie funktionieren. > (im gegensatz zu manchen C. Originaltreibern ...) > Das Entwickeln von Modulen benötigt mit dem Testen eben viel Zeit. > Besonders, wenn immer mehr ASM mit im Spiel ist. > > > Häng Dich doch bitte nicht an dem Wort Katastrophe auf... > Sorry, aber unter Katastrophe verstehe ich nunmal einen GAU. :-) > > > Eine fehlgeschlagene Schreiboperation ist eine fehlgeschlagene Schreiboperation! > > Da diskutiere ich auch nicht länger drüber... wenn PC-Treiber so geschrieben wären, > > würdest Du Dein PC nicht mal booten können. > > Da sag ich nur Windows ab V4.0. *grins* > > > Das sehe ich ein. Nur wenn Ausgaben auf dem i2c laufen und der Bus nicht ok ist, > > könnte es dann nicht doch zu Fehlern in anderen i2c-Bauteilen kommen? > > Dann ist jedoch etwas größeres passiert. Hier müsste dann die Integrität > des Busses selbst geprüft werden. (Das ist etwas schwerer) > Jedoch sind Fehlfunktionen an den Bausteinen selbst durch ungewolltes Adressieren > fast ausgeschlossen, da die Adressierung nach dem START erfolgt. Daten, > mit i2c.wirte geschrieben, können keinen anderen Baustein ansprechen ! > Wird am Bus ein START signalisiert, "hören" alle Baustein am Bus zu. > nach dem Start wird das Adressbyte gesendet. Stimmt dieses nicht mit > der eigenen Adresse überein, "klinken" sich die Baustein wieder aus, bis > Das nächste START gesendet wird; dafür muß zuvor jedoch ein STOP gesendet > werden. > Als kleine "Lektüre" zum I²C-Bus empfehle ich Dir das Modul i2cext.c2 . > Hier kannst Du erkennen, wie der Bus funzt. > > > Na das worüber wir die ganze Zeit sprechen... ich denke mir, das aber auch andere Module solche Probleme haben. > > > Tja, man darf nicht alles so eng sehen. :-) > Die CC2 wird mittlerweile in vielen Kleinserienprojekten eingesetzt, ohne > daß es zu größeren Problemen kommt. > Wenn letztendlich für eine Anwendung spezielle Routinen benötigt, muß man > eben selbst ran. Es gibt eben kein "für alle Fälle das passendes Modul". > Die CC2 ist eben kein PC, sondern ein Mikrocontroller. > Würde man Treiber schreiben, die alles berücksichtigen, wären von den 128kB > wahrscheinlich nurnoch 10kB frei, und die CC2 seeeeeeehr langsam. :-) > > > Ich will Dir Deine Erfahrung auch nicht absprechen... ich würde mich selbst eher als Laie bezeichnen. > > Zumindest was den I2C und die CC2 angeht. > > Darum sage ich immer: Probieren geht über Studieren :-) > > > Wie gesagt, wenn der Bus nicht ok ist, kann das im Extremfall doch zu Fehlern führen. > > Behaupte ich einfach mal so.... sonst dürfte es tatsächlich keinen Einfluß haben. > Der einzige Fehler, der passieren kann, ist, daß der die Daten den angesprochenen > Baustein nicht oder nur teilw. erreichen, und u.U. dieser nicht ganz das macht, was > man will. > > > Die Wahrscheinlichkeit führ Fehler steigt mit der Leitungslänge des Busses.... > > mehr brauche ich dazu doch nicht zu sagen oder? > Deshalb muß man bei langen Bussen mit Treiberbausteinen, wie dem P82B715, > arbeiten, um solche Fehler auszuschließen. > Darum ist auf meinem CC2-Reglerboard auch ein I²C-Bus-Extender vorgesehen, > bevor der Bus von der Platine wegführt. > > > Ich sag Dir auch was.. ich programmiere schon seit Jahren auf Linux in C und ich weis auch > > wovon ich rede.. so von wegen Multithreading, Multitasking, Seiteneffekte. > > Tja, ein PC ist eben keine CC2. Und man kann das Multithreading auch nicht mit > dem eines PCs vergleichen. (Besonders, da hier mehr Multitasking vorkommt, was die > CC2 wiederum nicht kann) > > > Ich kenne zwar den i2c-Bus > > nicht so genau aber wenn Dir einer helfen will, dann hau dem nicht auf die Finger. > Ich klopfe niemanden auf die Finger. Ich vertrete nur meinen Standpunkt bei dieser > Diskussion. :-) > > > So... und damit tun wir jetzt mal Butter bei die Fische! Hier kommt das von mir eben überarbeitete > > Listing von eeprom.c2 Sehe es bitte als Vorschlag. Ich denke mir, das Du noch eigene Ideen dazu hast. > > Sorry, aber mit diesem Listing schießt Du bei einem Fehler (return 0) den Bus, sodaß > garnichts mehr geht, bis ein STOP gesendet wird. > Nehmen wir mal eine Funktion. Da ganze Modul brauchen wir zum erläutern nicht. > > <font face="courier new" size=2> /**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; > if i>=100 return FALSE; > i=i+1; > sleep 1; > } > i2c.write(addr shr 8); > i2c.write(addr); > return TRUE; > } > > /**einzelnes byte schreiben****************************************/ > function writebyte(byte eepromaddr,int addr, byte data) returns int > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > i2c.write(data); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > }</font> > > Hier passiert im Fehlerfall folgendes:(=EEProm reagiert nicht) > > Versuch der Adressierung: senden von START + Adresse > => I²C-Bus ist aktiv, Bausteine mit anderer Adresse "klinken sich aus" > Versuch schlägt fehl. > Durch das If wird das Schreiben mit anschließendem Stop übergangen. > => I²C-Bus bleibt aktiv > Funktion wird mit return 0 beendet. > Jedes weitere START am Bus wird u.U. ab jetzt ignoriert, bis wenisgtens > einmal ein STOP gesendet wird. > => das nenne ich schon eher einen GAU :-) (aber nicht wirklich) > > Die Funktiun müsste dann eher so lauten: > <font face="courier new" size=2> capture i2c.flag; > if write(eepromaddr,addr) > { > i2c.write(data); > i2c.stop(); > release; > return -1; > } > i2c.stop(); > release; > return 0;</font> > > Nebenbei wird diese Funktion um einiges schneller ausgeführt. > Außerdem geht es bei mir bei Modulen immer um Geschwindigkeit. > Darum muß man in C2 aufpassen wie man schreibt. > z.B. if Abfragen auf TRUE sollten so kurz wie möglich sein: > if Wert==TRUE Anweisung; // das dauert zu lange > besser ist: > if Wert Anweisung; > Nebenbei ist letzteres besser, da alles ungleich 0 True ist. > Festzulegen, daß True immer -1, als alle Bits high, ist, habe > ich mir schon längst abgewöhnt. > Gerade im hardwarenahem Programmieren ist diese Vorgehesweise sinnvoller. :-) > Auch das zwischenspeichern eines schon bestehenden Status sollte vermieden > werden.(Rechenzeit) > > Übrigens, um wirklich jeden Fehler beim schreiben zu erkennen, müsste > man nach jedem geschriebenen Byte das ACK prüfen und mit > in die Rückgabe setzen. > Aber das benötigt wirklich zu viel Zeit. Wie gesagt, mir geht es mehr um Geschwindigkeit. > > Ich werde mal sehen, ob ich eeprom.c2 irgendwie mir schon früher vornehme. > Jedoch müssen zwei Module unbedingt vorher überarbeitet werden: ram.c2 und ram_hs.c2 . > Vielleicht mache ich vorher noch den i=0 Patch. > > Das Problem ist nämlich: Ich muß von "Groß" nach "Klein" arbeiten, damit in kurzen > Intervallen alle I²C-zugreifenden Module fertig werden, da das Arbeiten mit zwei unterschiedlichen > Captures zwangsläufig zu Übergangslösungen beim Programmieren führen muß. > Außerdem sind die Module zum CC2Net-RAM-Device mittlerweile schon fast > hoffnungslos veraltet. (zumindest aus meinem Standpunkt) > Darum haben diese nun die Top Priorität. > Es wäre schön, wenn ich den ganzen Tag nur programmieren könnte. Jedoch muß > ich immerhin quasi zwei Firmen am Laufen halten. > > MfG André H.
