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 André, > > > > Hallo Andrè, > > Jetzt merk ich's erst. :-) > > Das heißt André nicht Andrè ! > > Kompromißvorschlag: " Andrê " *grins* > ...aber ich halt mich demnächst dran :-) > > > > 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 :-) > > > > 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; > > > } > > Hier gibt es jedoch ein kleines Problem: > > Um da wieder rauszukommen hilft nur folgendes: > > Entweder ein Neustart des Programms oder ein Zurücksetzen des betreffenden Threads > > mit der Anweisung "reset" . > > 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. > > 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. > > 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 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. > > 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. > > 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... > > Gruß Rolf > > >
