Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

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: