wie könnte man den Speicherbereich (konkret 24C04) unter C zugänglich machen? Lesen und Schreiben ist ja an sich kein Problem. Ich hätte aber gern Variablen (verschiedene Typen, zur Not würde ich sie aber auch für alle unsigned long benutzen) dort abgelegt und unter ihrem Namen angesprochen (Lesen und Schreiben). Irgendwelche Ideen?
Das wird so ohne weiteres nicht gehen. Dazu müsste der C-Compiler dazu gebracht werden, beim Zugriff auf Variablen im EEPROM völlig anderen Code zu produzieren als beim Zugriff auf Variablen im RAM. Ohne daß Du einen Compiler dafür selber (um)baust, wird das Ziel nicht zu erreichen sein.
Das geht möglicherweise mit einer Struktur, ich habe nur leider gerade
nicht die nötige Zeit, mir da etwas auszudenken.
In etwa so:
typedef struct
memEEPROM_s
{
int val;
char c;
/* ... */
} memEEPROM_t;
Das kostet allerdings bei jedem Zugriff auch wieder RAM.
Wenn ich nachher etwas Zeit habe, könnte ich bei dem Ansatz
weiterhelfen, falls erwünscht.
Wie soll da eine Struktur helfen? Auch die Elemente einer Struktur liegen einfach so im RAM 'rum, und der Zugriff auf die Elemente erfolgt auf exakt die gleiche Art und Weise wie der Zugriff auf andere Variablen auch. Eine eher theoretische Möglichkeit wäre die Implementierung einer Klasse in C++, die benötigte Zugriffsfunktionen (Operator=, Operator& etc.) auf EEPROM-Zugriffe umbiegt - eine Instanz dieser Klasse belegt aber immer noch Speicher im normalen RAM - irgendwo muss ja die Speicheradresse gespeichert werden, unter der die Nutzdaten im EEPROM abgelegt sind. So etwas ist aber nur mit C++ realisierbar; C selbst kennt keine Möglichkeit, Zugriffsoperatoren zu überladen.
Ich hab keine Ahnung ob es hilft, aber ich hatte mal ein ähnliches Problem mit Speicher und Variablen, weil das Array, dass den Wert einer reinkommenden Variablen speichern sollte den RAM zum überlaufen brachte. Ich habe dann einfach die 8 Bit pro Speicheradresse direkt in einer Variablen addiert. Man brauchte damit zwar immer noch eine Variable im RAM und eine um die Speicherbereiche anzusprechen, aber eben nur eine double statt 20. Man musste eben nur ein bisschen aufpassen, was zu welchem Zeitpunkt wo drinsteht. Vieleicht hilfts Dir.
Was natürlich nicht geht (so wie ich das beim zweiten mal lesen jetzt verstehe): eeIntVar = 123; eeChrVar = 'A'; IntVar = eeIntVar; ChrVar = eeChrVar; Das ist natürlich nicht möglich... Ich dachte eher an eine das EEPROM Katalogisierende Struktur.
Hm, sieht ja noch nicht so gut aus.... Ich werde mir erst mal insofern weiterhelfen, dass ich den Speicherbereich für den internen EEPROM benutze und die Routinen für diese Zugriffe umschreibe, das sollte gehen. Sinn der Sache: es wird ein FM24C04 angeschlossen, da weder der interne EEPROM noch ein "normaler" I2C-EEPROM die geforderte Schreibzyklenzahl/Schreibzeitanforderungen erfüllen. Sicher noch nicht die ultimative Lösung, aber ich habe nicht mehr allzuviel Zeit, nächste Woche ist Termin....
Hmm... Hast Du denn vielleicht noch so viel Platz im RAM, daß Du den Inhalt dort spiegeln kannst? Bei Modifikation im RAM dann halt nach einer bestimmten Zeit das EEPROM updaten. Dadurch reduzierst Du die Zugriffe aufs EEPROM und hast das Problem des Schreib-/Lesezugriffs weitestgehend gelöst.
Das 2404 hat doch nur 512 Byte, richtig? Ich benutze zur Zeit ein EEPROM mit 10.000.000 Schreib- Löschzyklen. Wenn du so ein Teil nimmst, die Zugriffe mitprotokollierst, müstest du fertig sein. Der Typ heißt 24LC65 von Mikrochip. Wenn du das Datenblatt nicht findest, schicke ich es dir zu. Die 10.000.000 beziehen sich aber nicht auf den gesamten Speicherbereich, sondern nur auf einen Block. Dieser High Endurance-Block ist genau so groß wie dein jetziges EEPROM. Sollte also funktionieren. MW
Geht nicht,Daten müssen spätestens jede Sekunde gesichert werden, pro Sekunde trudeln auf 12 Kanälen je max. 20 Impulse (Verbrauchsmessungen) ein, alle von mir vorgeschlagenen Lösungen (Backup-Batterie wegen Wartungsbedarf verworfen, Netzausfall-Früherkennung mit Sicherungs ins EEPROM bei Bedarf nur als letztmögliche Lösung akzeptiert). Naja, und wenn man jede Sekunde schreibt, sind normale EEPROMs schnell am Ende. Die FRAMS sind schon die optimale Lösung. Die restlichen (Parametrierungs-)Daten könnten schon ins interne EEPROM, aber wenn schon, dennschon, dann lege ich alles ins externe FRAM.
Wie hoch ist denn das Datenaufkommen pro Sekunde? 20bit? "Viel" kann da ja gar nicht gespeichert werden...
10 Mio s sind auch nur 115 Tage, das reicht nicht. Wie gesagt, das Speichermedium steht fest, jetzt will ich es nur noch komfortabel verwalten...
@ crazy horse, überschlagen hast du doch 12 Produktionslinien, die du überwachen willst. Also, angenommen 12 x unsigned long, entspricht 48 Byte. Nach 100 Tagen wechselst du auf den nächsten 48'er Block. So bekommst du in den High-Endurance Block 10 x 48 Byte, also 10 x 115 Tage. Danach stehen dir noch 7,5KByte mit 1.000.000 Schreib- Löschzyklen zur Verfügung. Das sind etwas über 150 48'er Blöcke. Das sind 150 x 10 Tage. Über 2500 Tage. So, und jetzt ballerst du 8 Stück in die Schaltung. Soviele kannst du adressieren. 20.000 Tage. Danach erfolgt ein Hardware-Update (in ca 55 Jahren). Muster hätte ich da. MW
Hallo Crazy horse, was spricht eigentlich gegen eine MMC / SD Karte? Ziwschen Eprom und SD ist in der Ansteuerung doch nicht der große Unterschied und zwischenspeichern mußt Du das eh, da wie bereist oben beschrieben die Lösung mit den Variablen umbiegen nicht in C existiert. Gruß Marcus
Effektiv gehts wirklich nur um 12 long-Zahlen, aber die müssen sicher gespeichert sein. Und das kann ich mit einem FRAM perfekt erledigen, wird sogar 3fach abgelegt. Dafür baue ich keine 8 Stk andere I2C-EEPROMs oder gar eine SD-Karte ein, da hätte ich ohne weiteren Nutzen nur mehr Aufwand (Verschiebung der jeweils aktiven Bereiche) und zusätzliche Fehlerquellen, Layout ist ja auch schon fertig. Ich möchte nur den I2C-Speicherbereich genauso nutzen können, wie andere auch. Werde noch drüber nachdenken, vielleicht fällt mir noch was ein, könnte auch für andere Anwendungen interessant sein. Ich wollte nur sichergehen, dass ich nicht was offensichtlich einfaches übersehen habe. Danke für die rege Beteiligung.
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.