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, > > Jetzt wird der Thread langsam richtig lang. :-) > > > Hm.. so weit ich weis, funktionieren Aufzüge so... sie machen vieleicht keine Notbremsung sondern > > nur eine einfache Motorbremsung... Aber vom Prinzip her stimmt das schon so. > > Man könnte den Watchdog aber z.B. auch auf ein Interupt-Port oder dem NMI legen. Damit hab > > ich mich bei der CC2 noch nicht auseinader gesetzt. > > Das wäre viel zu kompliziert. Einfacher wäre es, mit normalen Timeouts zu arbeiten. > (Bsp: receive-Funktion in hwcom.c2, swcom.c2, i2ccom.c2 und i2ckop.c2) > > > Ausserdem wäre so ein Modul ein prima > > Verkaufsarument für Dein Watchdog-Modul... :-) > > Glaub' mir, das PCF-UHR-WD benötigt keine weiteren Verkaufsargumente. > Das ist nämlich die nächste Platine, die mir ausgehen wird. > (Ich muß dringenst meine neuen Hardwareentwicklungen fertig machen, damit > ich wieder Platinen herstellen kann.) > > > > Gut, daß hab' ich schlicht vergessen einzufügen. Jedoch schlimm ist dies nicht. > > > Es wird nur ein wenig Traffic am Bus erzeugt, jedoch zu Fehlfunktionen kann es nicht kommen. > > > > Das stimmt aber im Fehlerfall gibt die Funktion ohne if len < 1 return 0; den falschen Wert zurück. > > Das aufrufende Programm meint dann, es wäre alles ok. Auf der i2c-Seite ist es das auch. > > Ähh, return 0 heißt hier immer, daß nichts OK ist bzw. daß 0 Werte geschrieben wurden. > > > Entweder man macht es bei allen array-Funktionen rein und der Treiber prüft len oder man macht es bei > > allen raus und sagt, der Treiber ist nicht für Fehlaufrufe zuständig. Das ist eine Definitionssache... > > komfortabeler wäre mit Prüfung.. ein bischen schneller ohne. > > Es ist jetzt in allen Array-Funktionen drin. > Die Array-Schreib-Funktionen geben immer zurück, wieviele Werte(nicht Bytes) geschrieben wurden. > > > hm..das wäre dann sowas wie eine imlizite len-Funktion in readstr... > Ist es, ja. Ich hatte hier aber auch return -1 zurück schreiben können. > Aber die Definition von "True" ist nunmal: x!=0 :-) > Das einzige Problem tritt auf, wenn man einen String mit der Länge 0 aus dem EEProm liest. :-) > (seeeeeehr unwahrscheinlich) > > > Macht es dann nicht Sinn, in writestr ein return len s; statt dem return i; zu machen? > > Weil wie gesagt.. i ist immer 31 und dann nicht die tatsächliche Stringlänge. > > Ausserdem... len s und s[31] müsten ja dann immer das gleiche Ergebnis haben... ist das so? > > Dann könnte man ja auch in writestr ein return s[31]; statt len einsetzen... macht die Funktionen konsistenter. > > Nein, es mach Sinn. Es wird die Länge der tatsächlich geschriebenen Bytes zurückgegeben. > Ist diese nicht 32, gab's einen Fehler. Dieser könnte z.B. beim Pagewrite passieren, > wenn das EEProm beim Adressieren für die nächste Page nicht mehr reagiert. > Genauso ist der Rückgabewert für alle anderen Array-Schreib-Funktionen wichtig. > Bsp.: String schreiben ab Addr. 60 > Es werden 4 Byte geschrieben, dann wg. Pagewechsel neu adressiert. > EEProm reagiert nicht. Ergo: es wird nicht 32, sondern 4 zurückgegeben. > > > Ok.. ich denke auch, das es schnell geht. > > Die Long-Array-Funktionen sind drin. > > > > Stimmt. Das hab' ich dort schlicht vergessen. > > > Übrigens, z.B. beim 24C64 passiert folgendes, wenn einfach über die Pagegrenze geschrieben wird: > > > Die nachfolgenden Bytes werden ab Begin der Page eingefügt. > > > Somit würden sich zwei Bytes, sequentiell geschrieben ab Addr.63, danach an Addr. 63 und 0 befinden. > > > > Uh... das muß aber dringend gefixt werden...! > > Ist gefixed. > (Jetzt muß ich langsam aufpassen, daß ichnicht mit dem neuem CC2Net-RAM-Device-Treiber > durcheinanderkomme. :-) ) > > > Mir ist noch was für Deine Version 3.0 eingefallen... es kommen scheinbar neue Versionen der eeproms > > mit 128 KByte raus.. die wären nur zu adressieren wenn Long als Adresse und nicht Int verwendet wird. > > Für die aktuelle Version mach das noch keinen Sinn aber für die 3er würde ich mir das auf die ToDo setzen. > > Diese 1MBit EEProms gibt es bereits. Jedoch ist die Adressierung wieder völlig anders. > Darum wäre es hierfür besser, wie für die 2kBit EEProms (eeprom2k), ein eigenes Modul > zuschreiben.(z.B. eeprom1M.c2) > Jedoch wird das 1Mbit-EEprom nicht so leicht erhätlilich sein. Auch der Preis wird höher sein. > Außerdem gibt's ja noch das CC2Net-RAM-Device mit bis zu 4 MBit. :-) > (Und evtl. auch irgendwann ein CC2Net-Flash od. RAM-Device mit 8MBit.) > > > MfG André H.
