  INFO - FAQ - CC2-Forum - CCPro-Forum |
|
> Hi Die Hard > > Ich gehe davon aus, das wir über die Beispiele "Datenspeicherung_3x.BAS" sprechen? > Das erinnert mich daran, wie ich mit 13 auf nem VC20 versuchte den Schnittpunkt zweier Linien durch ständiges Rauf- und Runterzählen der Pixel zu finden... Da geht soooooo viel Zeit verloren! > Ich bin ja ehrlich, den eigentlichen Code habe ich mir zuerst nicht angesehen, die in den Remarks angedrohten Laufzeiten waren abschreckend genug.... jetzt habe ich aber auch den Code gelesen und die Sache verstanden. Leider ist es unmöglich, einen derart grossen Buffer einzurichten... wäre das möglich, wäre genug RAM da, um das sich mein Problem gar nicht stellen würde... > > Ich vermute, das die Löschung des gesamten Blocks beim Schreiben des ersten Bytes oder eines anderen Bytes innerhalb des Blocks derart Systembedingt ist, das da selbst ein SYS-Treiber nichts ausrichten kann?! Richtig? > > Das setzen des DateiPointers müsste sich in Assembler aber DEUTLICH komfortabler realisieren lassen (die 2 Byte RAM die das zur korrekten Berechnung des Offsets braucht hätte ich auch über) . Mittelfristig wäre ein SYS-Treiber, mit dem der DateiPointer gesetzt werden kann ne super Sache, da mir das in meiner aktuellen Anwendung ermöglichen würde Datensätze zu überspringen ohne alle Werte erst in Dummy´s laden zu müssen. > > Die Anwendung, der die 48 Byte "ab und zu" RAM fehlen, verpasse ich wahrscheinlich doch ne RTC (PCF8583), da wären 240 Bytes über... > > > Pit > > > > > > > > > > Auf www.c-control-support.de liegen bei den Updates die Beispiele zur M 2.0 > > > > Darunter ist auch eines, das dein Problem lösen sollte. > > > > Das File heisst: m20samples_jan05.zip > > > > ciao.. > > > > > > Ist ja super, das Du so schnell reagierst, bisher verstehe ich den Wirbel um angeblich schlechten Service durch Conrad nicht! > > > Trotzdem ist diese Lösung ist viel zu langsam, die konkrete Anwendung müsste alle 60sec. 48 Bytes lesen und wieder zurückschreiben. Der Lesevorgang sollte eigentlich nicht viel mehr als 0,1 sec. benötigen, bei der Schreibroutine könnt ich mich noch mit 1sec für die 48 Bytes anfreunden. > > > > > > Pit > > > > Hallo... > > Das geht schon, wenn du das Beispiel modifizierst und den Schreibbuffer grösser machst. > > Fraglich ist natürlich wie viele Bytes du sonst noch brauchst. > > ciao.. > > Hallo... Ein SYS-Treiber bringt nicht wirklich viel, weil die Programmlaufzeiten (in BASIC) gegenüber dem Zeitbedarf beim Schreiben auf das Flash nicht ins Gewicht fallen. Ich war selbst etwas enttäuscht, dass so eine Anwendung nicht schneller zu realisieren ist, aber ohne entsprechend grossen Buffer geht das leider nicht. Aber damit wir uns richtig verstehen.... Das Zeitproblem existiert nur wenn wirklich "wild" auf die Speicherbänke zugegriffen wird, also einzelne Byte-Manipulationen durchgeführt werden. Bei einem streng sequentiellen Zugriff sollten es nicht mehr als 5ms je Byte sein. Noch eine Info am Rande: Der Hersteller gibt min 10.000 und zyp. 100.000 Schreibzyklen als Lebensdauer für das Flash an. Ich habe mehrere getestet und es war keines dabei, das nicht mindestens 600.000 Zyklen hatte. Ciao..... |
| Antwort schreiben |
Re: TabellenWerte während der Laufzeit "patchen" (von Pit Demmer - 29.01.2005 16:59)Re: TabellenWerte während der Laufzeit "patchen" (von DIE HARD - 30.01.2005 17:59)Re: TabellenWerte während der Laufzeit "patchen" (von Pit Demmer - 30.01.2005 19:01)Re: TabellenWerte während der Laufzeit "patchen" (von DIE HARD - 1.02.2005 14:34)