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, > > > > > Ja... > > > > if i2c.cstart(eepromaddr) break; > > > > ^ da... wenn die Proportionalschrift mir da nicht den Satz zerbröselt... > > > Hier wird nichts "rebröselt". Dafür werden automatisch erstellt. > > > Außerdem, für was habe ich eine Vorschau im Forum ? :-) > > > Übrigens, nächste Frage: Mal sehen, ob Du es findest. *g* > > > Wo ist das Release beim neuem Capture ? :-) > > > > Ich bin mir nicht sicher... entweder schraubst Du in asm am Stack rum, der vom return; > > aufgeräumt wird oder das normale release; übernimmt dies. ich denke eher zweites. > > Innerhalb des i2c.stop wäre es auch noch möglich... dann hättest Du aber sowas wie > > i2c.cstop einführen müssen. ich müste mir dazu den asm-Code ansehen.. > > dazu hab ich aber jetzt keine Zeit. (soll keine Ausflucht sein... wenn Du willst, > > verschieben wir das nur. Dann kannste auch ne genaue Antwort kriegen) > > cstart ruft ja nur wait capture auf und macht dann das altbekannte start. > > Wobei "nur" ist relativ... ich hab noch nicht nachgesehen was Capture macht.. ausser > > ein paar VM-Instruktionen.. das dürfte dann in Capture.hex versteckt sein... und cap.c2 hab > > ich mir auch noch nicht angesehen... da werde ich wohl schlauer werden :-) > > Soweit gehe ich jetzt nicht. Ich wollte nur prüfen, ob die html zu den Modulen > gelesen wird. in der i2c.html zu i2c.c2 steht nämlich drin, wie das I²C-Capture funzt. :-) > (Wenn Du den ASM Code oder i2c.c2 durchsuchst, wirst du nämlich nicht fündig. :-) ) > > > > Das hab ich auch überlegt.. gehen wir mal zum Beispiel mit der Steuerung für den Aufzug. > > Ich würde nie so eine Steuerung ohne HW-watchdog betreiben. Wenn ich aber nen > > HW-watchdog habe, kann ich den auch zum überwachen des Schreibvorgangs benutzen. > > Beim Starten könnte die CC2 z.b. die Lastkurven im eeprom mit crc überprüfen und so feststellen, > > ob vor dem letzten Reset ein Schreibfehler auftauchte. Wenn ja, muß ein Notfallprogramm > > gefahren werden... Bremsen ... Türen auf... SMS an Service... Notbetrieb mit 2.tem eeprom.. > > Ohne crc-Fehler wars nur eine normale Inbetriebname und die CC2 kann das Standartprogramm fahren. > > Das ist noch sicherer als mit Thread reset obwohl man damit evtl. auch was machen könnte. > > Naja, stell Dir mal folgendes vor: > Der Aufzug ist in voller Fahrt. Schreiben ins EEProm funzt nicht. > Watchdog löst aus und startet die Steuerung komplett neu. > Hier gibt es erstmal eine Notbremsung des Aufzugs. Die Folge: Kopfschmerzen, > da sich die, die sich im Aufzug befinden, den Kopf stoßen werden. > Soetwas müsste auf jeden Fall per SW überwacht werden. Daß ein HW-Watchdog > einen Reset auslöst, ist erst nötigt, wenn die SW garnicht mehr will. > > > So.. zum aktuellen.. > > Ich beziehe mich auf Deine Mail. > > > > den vermeintlichen Fehler mit for i=0 ... len-2 in readintarray habe ich nun verstanden. Es ist kein Fehler. > > Du liest einen weniger weil ein abschließendes i2c.read() und i2c.readlast() noch hinterher geschickt wird. > > Im Fall von len=1 wird aus for i=0 ... len-2 aber for i=0 ... -1 , die CC2 geht also nicht in die for-schleife. > > Die CC2 prüft also vor dem entern der for - Schleife die Bedingung... ich meine das auch schon anders > > gesehen zu haben. Gut zu wissen. > > > > Naja... bei readintarray kann noch ein if len < 1 return 0; an den Anfang... ist bei writeintarray schon > > drin gewesen und soll wohl verhindern das len=0 übergeben wird. Bei den Bytearrayfunktionen ebenso. > > 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 Paging wird durch: > > if ((addr+i) % Pagewrite)==0 and i > > {i2c.stop(); > > if not write(eepromaddr,addr+i) return i; > > } > > gehandelt. Die Funktionen, die viele Bytes schreiben können, hast Du auch damit ausgestattet. > > readstring braucht natürlich kein Paging, writestring hat es.. habs wohl überlesen.. sorry. > > Nur warum in if ((addr+i) % Pagewrite)==0 and i > > das "and i" am Ende? Der Term 0 and i dürfte immer 0 ergeben. Die Bedingung "Pagegrenze" ist doch mit > > (addr+i) % Pagewrite)==0 erfüllt, oder? Wenn ja, reicht ja auch ein "if ((addr+i) % Pagewrite)" > > Das i ist wichtig: > Es passiert sonst folgendes: (bei z.B. Pagewrite=64) > Es soll ab Addr.64 geschreiben werden > Der Schreibforgang wird eingeleiteitet. Danach kommt diese if-Abrage. > Lt. dieser wäre hier ohne "and i" hier ein Pagewechsel, also müßte nochmal > ein Start durchgeführt werden. Das "and i" verhindert dies, da der if-Teil erst ab einem > Index >0 ausgeführt wird. Statt dem "and i" könnte man auch "and i>0" schreiben. > > > Das return s[31]; in readstring leuchtet mir aber immer noch nicht ein. > > Auch das return i; in writestr leuchtet mir nicht ein. Es werden ja immer 31 Byte geschrieben. > Dazu mußt Du wissen, wie Strings aufgebaut sind: > Ein String besteht aus 32 Byte. In diesem können bis zu 30 Zeichen stehen (Byte 0 bis 29) > Im 31.Byte (Byte 30) steht immer der Wert 0, Im 32.Byte (Byte 31) steht die Anzahl der > Zeichen, die sich im String befinden. > Kurz: Es wird einfach zurückgegeben, wieviele Zeichen sich im gelesenen String befinden. > > > Was es noch nicht gibt, ist ein Longarray-Funktionspärchen und Floatfunktionen. Float weis ich nicht > > ob das überhaupt gefragt ist aber Longarray fänd ich ja schon ... angebracht. > > Das hatte ich mir gespart. Da ich davon ausging, daß außerst selten soetwas benötigt wird. > Gut, diese Funktion ist aber schnell eingebaut. > > > Wo ich mir noch Sorgen drum mache ist, wenn jemand Pagegrenzen überschreibt.. > > Also so etwa... writelong(eeprom1,30,wert); bei einer Pagesize von 32 > > die ersten 2 Byte des Longwertes müsten dann in der ersten Page, die zweiten zwo Byte in der zweiten > > Page landen. Dem 24c512 mit 128er Pagegrenzen soll das angeblich nichts ausmachen... > > auch wenn man das mit writelong(eeprom1,126,wert); versucht. Ich weis aber nicht wie's bei kleineren > > Bausteinen ist.. 24c64 und so.. evtl müste man daher auch bei writelong und writeint eine Pageprüfung > > einbauen. Oder zumindest müste man solche Schreibversuche abfangen... da sonst wieder Datenverlust > > droht. Bei Int müste man nur einmal den Pagebreak prüfen.... bei Long gleich 3 mal... > > 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. > > MfG André H.
