>
> > > > 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. :-) )
Stimmt.. da stehts drin... ich hatte das mal quer gelesen.. mir war diese Passage aber nicht
im Gedächtnis hängen geblieben... oder vieleicht doch... die i2c.stop hatte ich ja auch erwogen.
Dann hat die i2c.stop das Capture gelöst was die ganze Zeit nicht benutzt wurde... deswegen
auch kein neues i2c.cstop...
> > 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.
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. Ausserdem wäre so ein Modul ein prima
Verkaufsarument für Dein Watchdog-Modul... :-)
> > 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 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..
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.
> > 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.
Ich verstehe was Du meinst aber das schaue ich mir noch mal genau an.
> > 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.
hm..das wäre dann sowas wie eine imlizite len-Funktion in readstr...
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.
> > 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.
Ok.. ich denke auch, das es schnell geht.
> > 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.
Uh... das muÃ? aber dringend gefixt werden...!
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.
Schickst Du mir wieder die Version, wenn Du die Fixes gemacht hast?
Ich schau dann wieder rein. Danke.
GruÃ? Rolf
Antwort schreiben
Antworten:
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)