Hallo, ich möchte ein Messwertkurve digital ablegen. Das heißt, zu 1000 möglichen Messwerten benötige ich einen entsprechenden Datenwert. Dieser liegt zwischen 0 und 5000. Nun reicht dafür leider der interen Speicher eines Atmega32 nicht. Ich habe keine Erfahrung mit EEProms, so wie ich das sehe benötige ich optimalerweise 16k ( 1024x16) Dann können meine 1000 möglichen Messwerte die zwischen 0,0 und 100,0 liegen die Adresse bilden und ich habe 16bit für meinen Datenwert. Stimmt das so? Ist das herangehen ok? Dann hätte ich gerne Serielle oder SPI / I²C Ansteuerung. Und 5V Versorgung. Bei Reichelt gibts den ST 93C86 BN , bin ich mit dem richtig? Danke, Pö
Nimm lieber einen I2C FRAM, da man die EEPROMs nur begrenzt oft beschreiben kann. Hier z.B.: FM24CL64-G (64Kbit). Außerdem ist beim EEPROM Page-Write Mode nicht unbedingt eine angenehme Sache. Beim FRAM kannst drauf los schreiben Byte für Byte.
>Nimm lieber einen I2C FRAM, da man die EEPROMs nur begrenzt oft >beschreiben kann. So ein Käse. 1 Million Schreibzyklen sollten wohl reichen.
> ich möchte ein Messwertkurve digital ablegen. Das heißt, zu 1000 > möglichen Messwerten benötige ich einen entsprechenden Datenwert. Dieser > liegt zwischen 0 und 5000. Also möchtest du 1000 Messwerte á 16 Bit in einen nichtflüchtigem Speicher ablegen. Damit haben wir einen Speicherbedarf von 16000 Bytes oder etwas weniger als 16kB. > Stimmt das so? Ist das herangehen ok? Kommt drauf an, wie schnell die Messwerte herein gepurzelt kommen. So ein EEPROM benötigt schon seine Zeit um einen Wert weg zu schreiben. 10 Werte pro Sekunde sind locker drin, 3000 eher unmöglich. > Dann hätte ich gerne Serielle oder SPI / I²C Ansteuerung. > Und 5V Versorgung. Da gibt es viele, die für dich passen. > Bei Reichelt gibts den ST 93C86 BN , bin ich mit dem richtig? Naja, die EEPROM-Speichergrößen sind meistens in Bits angegeben. Deiner ist mit 2kx8, also 2 kB bei Reichelt angegeben. Schau mal nach den 24C512 (=64kByte) oder 24C256(=32kByte) oder 24C128(=16kByte). Das sind I2C EEPROMs in die deine Daten passen. Und dran denken das EEPROMS eine begrenzte Anzahl an Schreibzyklen haben. Eine Million Schreibzyklen sind wenn man mehrfach pro Minute auf die selbe Speicherzelle schreibt doch schneller erreicht als man denkt ;)
>Außerdem ist beim >EEPROM Page-Write Mode nicht unbedingt eine angenehme Sache. Und was soll das den bedeuten??
Es ist nicht nötig den oft zu beschreiben, normalerweise reicht sogar einmalig :-). Allerdings wäre ein Modell schön was gut an den Hardware - SPI passt. So wie ich das sehe müßte ich für diesen Microwire Bus das ganze Timing in Software realisieren. Schreiben ist ein guter Stichpunkt. Ich frag mich gerade wie ich es eigentlich einrichte den EEProm zu beschreiben. Wie kommt die Tabelle aus Excel in den EEprom.....? Muss ich da ein extra Programm schreiben, die 1000 Datenwerte als .dw in Assembler und dann den EEProm schreiben...? Boah...
>Naja, die EEPROM-Speichergrößen sind meistens in Bits angegeben. Deiner >ist mit 2kx8, also 2 kB bei Reichelt angegeben. Schau ins Datenblatt. Dieses Eeprom kann über den ORG-Eingang als 16bit Speicher organisiert werden.
> Nimm lieber einen I2C FRAM, da man die EEPROMs nur begrenzt oft > beschreiben kann. Ok, rechnen wir mal nach: 1 Schreibvorgang pro Minute macht am Tag 60*24=1440 Schreibzyklen. Dann ist die Million nach 694 Tagen oder knapp 2 Jahren erreicht. Allerdings auch nur, wenn man immer auf die selbe Zelle hämmert. Wenn man die Schreibzugriffe auf alle 16k Zellen gleichmässig verteilt wird der EEPROM dich sicher überleben ;) Wenn allerdings dauerhaft(!) 2x pro Sekunde auf das EEPROM geschrieben wird haben wir 24*60*60*2=172800 Schreibzugriffe am Tag. Nach knapp 6 Tagen sind die Anzahl der garantierten(!) Schreibzyklen erreicht. Kaputt geht die Zelle in einem heutigem EEPROM allerdings dann wahrscheinlich noch lange nicht, es wird halt nur nicht mehr vom Hersteller garantiert. Deshalb sollte man halt beim SW-Entwurf darauf achten nicht über lange Zeiträum immer auf die selbe Zelle zu schreiben. Wenn man das beachtet ist ein EEPROM ein sehr preiswerter und bequemer Weg. Ausserdem sind das Standard-Bauteile die es seit langem von mehreren Herstellern gibt, man muss also nicht damit rechen das nächstes Jahr keine 24Cxxx mehr hergestellt werden.
> Schreiben ist ein guter Stichpunkt. Ich frag mich gerade wie ich es > eigentlich einrichte den EEProm zu beschreiben. Wie kommt die Tabelle > aus Excel in den EEprom.....? Muss ich da ein extra Programm schreiben, > die 1000 Datenwerte als .dw in Assembler und dann den EEProm > schreiben...? Boah.. Wenn du eh für jeden Schreibvorgang einen Assembler+Programmer bemühen willst, dann pack es lieber als Konstanten in den Flash (falls noch frei). Der Vorteil des EEPROMS ist es ja gerade, dass du auch im Feld neue Daten mit dem Mikrocontroller hineinschreiben kannst. Wenn du noch eine RS232-Schnittstelle in deinem System hast, kannst du ja einen "Service-Modus" in deiner Software vorsehen, in dem du die Daten z.B. per XModem empfangen kannst. Das kann dann von Windows aus sogar mit Bordmitteln (HyperTerminal) versendet werden.
>So ein Käse. 1 Million Schreibzyklen sollten wohl reichen. Mein kSüßer, stand was davon in seinem Beitrag? -> NÖ! > 07.01.2009 12:26 Von da wird einem erst klar, dass es sich anscheinend um Kalibrationsdaten o.ä. handelt. >>Außerdem ist beim >>EEPROM Page-Write Mode nicht unbedingt eine angenehme Sache. >Und was soll das den bedeuten?? Bedeutet, dass man die Werte nicht Byte für Byte runterbratzen kann. Je nach Anwendung, kann es störend sein, da zw. Pages gewartet werden muss.
>Bedeutet, dass man die Werte nicht Byte für Byte runterbratzen kann. Je >nach Anwendung, kann es störend sein, da zw. Pages gewartet werden muss. Das ist nichts anderes als Gefasel, schau ins DB des ST 93C86 BN.
Hallo, erst mal vielen Dank für die zahlreichen Antworten, und bitte seit lieb und streitet nicht :-). Ähm, ja, es handelt sich im Prinzip um eine Art Kalibrationsdaten. einem Transmissionswert muss ein Konzentrationswert zugeordnet werden. Das könnte man auch ausrechnen, allerdings ist da ne Menge mul, div, und e Funktion im Spiel. Daher ist es im Endeffekt einfacher aller möglichen Ergebnisse sauber in Excel zu ermitteln und die Daten als Zuordnungstabelle abzulegen. Daher interessieren mich Schreibgeschwindigkeiten und Häufigkeiten überhaupt nicht. Im schlimmsten Fall wird der Speicher 10x beschrieben. Ein Lesezugriff 1x / Sekunde ist angedacht, es gibt keine zeitkritischen Vorgänge. Aus der Ecke auch alles problemlos. Momentan fasziniert mich die Option "pack es als Kontanten in den Flash". Weil das kostet nix extra und ich bräuchte keine neue Platine.., Hm. Wenn ich den Messbereich einschränke könnte ich mit weniger als 16k für die Datenwerte auskommen. Auf jeden Fall bräuchte ich dann einen Atmega mit mindestens 16k Flash. Da steht mein Atmega32 doch ganz gut da. Muss ich mal nachsehen wie die groß mein Programm ist. Erst mal Danke, ich meld mich... Pö
@Sirko Pöhlmann (poehli) >Momentan fasziniert mich die Option "pack es als Kontanten in den >Flash". Wäre sinnvoll. > Weil das kostet nix extra und ich bräuchte keine neue Platine.., >Hm. Wenn ich den Messbereich einschränke könnte ich mit weniger als 16k Was denn? 16 kBit oder 16 kByte? Wenn du 1000 Werte a 16 Bit hast sind das 16kBit=2kByte!! >für die Datenwerte auskommen. Auf jeden Fall bräuchte ich dann einen >Atmega mit mindestens 16k Flash. Klär erstmal deine Einheit! MfG Falk
> > Weil das kostet nix extra und ich bräuchte keine neue Platine.., > >Hm. Wenn ich den Messbereich einschränke könnte ich mit weniger als 16k > > Was denn? 16 kBit oder 16 kByte? > > Wenn du 1000 Werte a 16 Bit hast sind das 16kBit=2kByte!! Ähm..sorry, da hab ich vorhin einen kleinen Verdreher drin gehabt. 1000 16-Bit (=2 Byte) Werte ergeben natürlich (wie von Falk schon gesagt) 2kByte. Und die können, wenn sie denn wirklich konstant sind und niemals nicht geändert werdem, am besten im Flash als Konstante im C-Programm angelegt werden. Und ein Tool was aus CSV-Dateien von Excel compilierbaren C-Code macht sollte auch schnell geschrieben sein.
vielen Dank für die Hilfe, insbesondere auch an Falk. Tatsächlich hab ich das mit den Einheiten etwas verpatzt. Das ganze hat als adressierter Table im Flash ganz ausgezeichnet funktioniert. Der Zugriff über Z-pointer und lpm ist da ja ein Klacks! Pö
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.