| Re: Modul eeprom.c2 Kategorie: I²C-Bus (von 89984984/8 - 7.04.2005 10:32) | |
|
Als Antwort auf Re: Modul eeprom.c2 von Rolf - 15.07.2003 10:47
| |
|
> > 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. :-) ) > > 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: | |