> > 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.
/**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;
}
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:
capture i2c.flag;
if write(eepromaddr,addr)
{
i2c.write(data);
i2c.stop();
release;
return -1;
}
i2c.stop();
release;
return 0;
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.
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 - 12.07.2003 23:01)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 10:10)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 13:44)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 20:02)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 23:40)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 9:15)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)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 0:29)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:16)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:12)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:08)