Hallo! Ich habe grade ein Problem, das ich nicht selber lösen kann. Ich habe eine Lüftersteuerung mit Menuesteuerung über Display programmiert. Nun möchte ich während des Betriebes gemachte Einstellungen, wie Solltemperatur und Max-Drehzahl auch nach dem Aus- und Einschalten der Betriebsspannung wieder zur Verfügung haben. Mein Controllerboard besitzt einen Flash-Speicher für das Code-Memory und ein sRam für die Daten. Jetzt legt er aber die gemessenen Werte im Datemmemory über "movx @dptr,a" ab, und das ist flüchtig. Deshalb muss ich beim Neustart die Speicherplätze initialisieren, wenn ich definierte Werte haben will, will heissen ich kann die Werte nur im Quellcode vorfestlegen, dann während des Betriebes ändern, beim Abschalten gehen sie verloren. Gibt es da vielleicht einen Trick, wie ich die Speicherplätze im Code-Memory unterbringen kann, damit sie erhalten bleiben? Der Befehlssatz hilft mit nicht so recht weiter, da finde ich nur Befehle um Programmspeicherzellen auszulesen, z.B.: movc a,@a+dptr Danke im Voraus, Timo
Um den Flash zu beschreiben, mußt Du Dir dessen Datenblatt ansehen, wie das geht und den Schaltplan Deines Boards, um zu sehen, wie man ihn zum Schreiben freigibt. Oder in der Dokumentation des Monitorprogramms ist eine Funktion beschrieben, die man dazu aufrufen kann. Aber aufpassen, daß Du Dir nicht das ganze Programm zerschießt !!! Alternativ kann man auch einen seriellen EEPROM (24C16) ranhängen und dort alle Daten ablegen, die man sich merken muß. Kostet 2 Portpins des C509. Peter
Hi! Na wenn das so ist :-( Könnt ich kotzen.... Das lässt sich also nur über eine Hardwarelösung machen. Das mit dem EEprom wär ja noch recht leicht zu lösen. Ansonsten könnte ich den Flash vielleicht über einen freien Chipselect ansteuern, dem ist bei mir nämlich auch ein ausreichender Adressbereich zugeordnet. Ich hatte gehofft, dass es eine Softwarelösung dafür gibt. Timo
Ich hatte auch mal ein lustiges Erlebnis mit einem C505 Entwicklungsboard. Ich habe in den freien SRAM-Sockel einen 2. Flash reingesteckt und an diesen ein Full-Erase Kommando geschickt. Ich hatte mir aber vorher nicht den Schaltplan des Boards angeschaut. Der war nämlich so blöd, daß der /WE des 1. Flash garnicht disabled werden konnte. D.h. der hat immer mitgelauscht auch wenn ich in nem völlig anderen Adreßbereich geschrieben habe und so auch an sich selbst das Full-Erase geschickt und dann auch selber ausgeführt. Danach mußte ich den SMD-Chip runterlöten und neu programmieren. Peter
Was hältst Du davon, das SRAM mit einer Batterie zu puffern? Die meisten SRAMs haben einen Standby-Modus, in dem sie nicht viel Strom verbrauchen. (Um diesen sicher zu erreichen, mußt die vielleicht noch einen FET in die -CS-Leitung hängen. Schau unbedingt ins Datenblatt, welche Bedingungen für den Standby-Modus erfüllt sein müssen. Diese variieren durchaus von Hersteller zu Hersteller, ebenso die dann erzielte Stromaufnahme). Mit "Batterie" meinte ich oben den Oberbegriff für irgendeine Dauerstromquelle. Ich nehme für so etwas gerne einen Gold-CAP. Gruß, Markus_8051
na ja, die sinnvollste Lösung ist schon ein I2C oder SPI EEPROM, der kleinste für wenige Cent reicht ja. Ich habs mir mittlerweile angewöhnt, prinzipiell einen ext. EEPROM mit vorzusehen, kostet mich 1 min bei Schaltung und Layout. Wird dann nicht bestückt und auch in der Software nicht berücksichtigt. Irgendwelche Änderungswünsche kommen oft, und schon mehrere Male hat das ein Redesign der Platine erspart. Fehlerspeicher, irgendwelche Grenzwerte, Kalibrierungsdaten..., irgendwas fällt den Kunden oft ein, was sie ursprünglich vergessen/nicht bedacht haben.
Hallo und vielen Dank schonmal für die Tips! Ich halte beide Ideen für sinvoll. Die Idee mit dem Batteriepuffer, weils ne einfache Lösung ist und weil ich weiter ganz normal übers SRAM arbeiten kann. Die Idee mit dem EEPROM, weil es die sicherste Lösung ist, aber dafür umständlicher, weil ich das Tranferprotokol erstmal schreiben müsste und das schon bestehende Programm an JEDER Stelle umschreiben müsste, wo die entspr. Speicherplätze benutzt werden. Die Speicher"organisation" vom 8051 is ja eh schon ein Chaos und dann auch noch das:-( Da hätten früher mal die Jungs von Intel oder wenigstens die Nachmacher von Siemens um die Ecke denken können.... Ist das bei den AVRs genauso behämmert? Gruß, Timo
Jammer nicht rum, sondern freu´ Dich, daß Du einen 8051 programmieren darfst. Auf dem PIC ist das schlimmer. Falls Du Dich für die EEPROM-Variante entscheidest, denk daran, daß EEPROMs nicht beliebig viele WRITE-Zyklen aushalten. Also die Werte nur schreiben, wenn es unbedingt nötig ist, also wenn sie sich geändert haben. Ich habe mir da mal einen EEPROM gekillt, weil ich in einer Schleife ständig neue Werte da reingeschrieben habe. Beim RAM hast Du natürlich den Nachteil, daß Batterie (und speziell GoldCAP) nicht ewig halten. Die Batterie muß irgendwann gewechselt, der GoldCAP wieder geladen werden. Mit einem GoldCAP sind nach meinen Versuchen Überbrückungszeiten von einigen Wochen bis zu wenigen Monaten (unter einem halben Jahr) zu erreichen. Viel Erfolg, Markus_8051
Ich benutze einen 89C51 von Philips, dessen Flash Speicher in 4 16Kb Blöcke aufgeteilt ist. Auf der Philips Seite gibt es einen Beispielprogramm, um Daten im Flash Speicher abzulegen. Dabei muss dann ein Block "geopfert" werden, um darin Daten zu speichern. Die Daten werden dann quasi wie eine Tabelle darin abgelegt und der Block nach und nach vollgeschrieben. Wenn der Block dann voll ist, wird der komplette Block gelöscht und wieder neu beschrieben. Anscheinend hängt die Lebensdauer des Flash nicht von den Schreib- sondern Löschzyklen ab. Insgesamt ein recht komplexer Programmteil, da auch noch überwacht wird, wenn bei der Reorganisation des Blockes der Strom ausfällt usw. Für mein Motorradtacho bin ich jetzt aberzu der Lösung übergegangen, den Controller einfach schlafen zu legen, da eine halbwegs leistungsstarke Batterie ja im Hintergrund ist und die Daten auch nicht soo wichtig sind. MfG Thomas
Eine Batterie hat gerade bei Experimentieren den Nachteil, daß jegliches Metallteil, was einem in die Schaltung fällt großes Unheil anrichten kann und nach Murphies Gesetz dies auch tun wird. Seit mir mal eine ausgelaufene Batterie ein PC-Motherboard zerstört hat, hasse ich jegliche Stützbatterien. Die Goldcaps haben deshalb einen internen Schutzwiderstand von etwa 50 Ohm. Daß Dir der Speicher zu klein vorkommt, liegt warscheinlich daran, daß Du unglücklicher Weise das Large-Modell benutzt. Benutze lieber das Small-Modell und definiere nur große Variablenfelder als XDATA. Dann benutze noch lokale Variablen wenn immer es möglich ist und Du wirst Dich wundern, wie viel in die internen 256 Byte reinpaßt und wie sauschnell Dein Programm und wie klein der Code dadurch wird. Es sollte zur Pflicht für alle 8051-Programmierer gehören, erstmal den C51-Primer zu lesen. In Assembler muß man das zwar selber machen, aber auch da gilt, erst die Register benutzen, dann RAM, dann IRAM und erst wenn das alles voll ist, PRAM bzw. XRAM. Im IRAM muß man natürlich immer etwas Platz übrig lassen für den Stack, nach meinen Erfahrungen reichen da 16 Byte dicke. Peter
> Die Goldcaps haben deshalb einen internen Schutzwiderstand > von etwa 50 Ohm. Naja, so ist das ja nun nicht. Nein, die Dinger haben "einfach nur so" einen verflucht hohen Innenwiderstand, und der ist nicht gezielt so hoch gewählt worden, sondern aufgrund des Aufbaus bislang nicht weiter zu reduzieren gewesen. Davon abgesehen hast Du, was Stützbatterien betrifft, natürlich recht; andererseits hindert Dich niemand, in Reihe mit der Batterie eben jenen erwähnten Schutzwiderstand zu schalten ... EEPROMs und FLASH-ROMs haben SRAM gegenüber das Problem der endlichen Haltbarkeit; einige hunderttausend Schreibzugriffe und die Dinger sind breit - da ist batteriegepuffertes SRAM doch deutlich besser.
N Abend! Die eingeschränkte Haltbarkeit eines EEPROMS ist natürlich auch ein Argument. Da würde ich spontan mal die Lösung mit dem GoldCap bevorzugen. Die Möglichkeit, das Board so umzubauen, dass ich auf den Flash per movx-Anweisung zugreifen kann, behagt mir nicht so, weil ich mir das Board nicht verbasteln will. Das wäre dann ne Lösung, wenn ich in Zukunft ein neues Layout mache. @Peter: Ich habe keine Probleme mit der Größe des Speichers, im Gegenteil. Ich möchte nur die erfassten Daten auch nach Abschalten der Versorgungsspannung weiter zur Verfügung haben. Und ich programmiere ausschl. in Assembler aber trotzdem Danke für die Tips. Werde mich in Zukunft mal mehr mit C beschäftigen.... THX, Timo
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.