Variablen können nicht ins Eeprom gespeichert werden

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Variablen können nicht ins Eeprom gespeichert werden

      Hallo,

      bisher hatte ich immer mit Readeeprom und Writeeeprom gearbeitet. Nun nutze ich die Eram Variablen.

      BASCOM-Quellcode

      1. Dim Gs_(38) As Eram Byte
      2. Dim Grad_servo_(38) As Byte
      3. Locate 1 , 1 : Lcd "Eeprom Daten laden"
      4. Waitms 200
      5. For F = 1 To 38
      6. Grad_servo_(f) = Gs_(f)
      7. Next
      8. If Grad_servo_(1) = &HFF Then
      9. Locate 2 , 1 : Lcd "Standartwerte laden"
      10. Waitms 200
      11. For F = 1 To 38
      12. Grad_servo_(f) = Lookup(f , Dta_grad)
      13. Next
      14. Locate 3 , 1 : Lcd "Eeprom Daten speichern"
      15. Waitms 200
      16. For F = 1 To 38
      17. Gs_(f) = Grad_servo_(f)
      18. Next
      19. End If
      20. Dta_grad:
      21. Data 0 , 135 , 75 , 50 , 135 , 75 , 155 , 130 , 75 , 50 , 50 , 25 , 25 , 240 , 180 , 140 , 130 , 100 , 75 , 50 , 90 , 0 , 25 , 70 , 50 , 40 , 0 , 20 , 185 , 165 , 140 , 135 , 115 , 100 , 90 , 75 , 60 , 50 , 40
      Alles anzeigen

      Es sollen Servopositionen für bestimmte Frequenzen geladen werden, siehe "Eeprom Daten laden".
      Ist das Eeprom aber leer (z.B. das erste Array), dann sollen Standartwerte geladen werden und dann zugleich ins Eeprom abgespeichert werden. Die geladenen Standartwerte kann ich mir am LCD anschauen, da stimmen alle 38 Werte.

      Resete ich aber den µC, dann lädt er die zuvor gespeicherten Werte aus dem Eeprom und sollte sie anzeigen. Er zeigt mir aber nur das erste Array, die 135 korrekt an. Die restlichen Werte sind nicht wie in der Datentabelle, siehe unten.

      328.PNG

      Selbst wenn ich die Werte mit z.B. Gs_(3) = Grad_servo_(3) manuell abspeichere und dann beim nächsten Start wieder lade, wird mir was anderes angezeigt.

      Ich hatte mich an folgenden Beispiel orientiert:


      BASCOM-Quellcode

      1. $regfile = "m8def.dat"
      2. $crystal = 16000000
      3. $baud = 9600
      4. Dim B As Single
      5. Dim Ee_v As Eram Single
      6. Do
      7. 'Wert aus EEPROM in normale Variable laden und anzeigen
      8. B = Ee_v
      9. Print "Alter Wert: ";
      10. Print B
      11. 'Neuen Wert eingeben und abspeichern im EEPROM
      12. Input "Neuer Wert: " , B
      13. Ee_v = B
      14. Print "Wert ist im EEPROM gespeichert"
      15. Print "und bleibt beim Ausschalten erhalten"
      16. Wait 2
      17. Loop
      Alles anzeigen


      Danke für eure Hilfe.
    • Hast du auch mal stackangaben? Evtl. (ich weiß es nicht) werden framesize verwendet. Schreib für die stacks und framesize mal ordentlich Werte in's Programm und probier es nochmal.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • oscar schrieb:

      EEprom-Zugriffe sind vergleichsweise langsam und du willst da ein ganzes Feld mit voller Geschwindigkeit (gar 16MHz) lesen und schreiben? Lass dem EEprom mal mehr Zeit.
      Da hätte ich mich aber jetzt auch auf die bascoms Befehle verlassen, dass die das zeitmäßig entsprechend machen.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Noch was: Hast du den brownout-detektor (fusebit) aktiviert? Sonst kann es bei unzureichender VCC (z.B. nach Reset) zu EEPROM-Datenverfälschungen kommen (der EEprom reagiert empfindlich bei zu geringer Versorgungsspannung). Wenn du das Array aus dem EEPROm gelesen hast solltest du später nur die geänderten Daten im EEPROM wieder abspeichern, das schont den selben, 100000 garantierte Schreibzyklen sind nicht sooo viel. ;)
    • tschoeatsch schrieb:

      Hast du auch mal stackangaben? Evtl. (ich weiß es nicht) werden framesize verwendet. Schreib für die stacks und framesize mal ordentlich Werte in's Programm und probier es nochmal.
      Die Stackangaben lauten jetzt:

      BASCOM-Quellcode

      1. $hwstack = 200
      2. $swstack = 200
      3. $framesize = 200
      Erhöhe ich die Werte noch weiter bekomme ich Fehlermeldungen, dass bestimmte Variablen nicht mehr in den SRAM passen. Das ganze Programm füllt gut 71% vom 328P.

      oscar schrieb:

      EEprom-Zugriffe sind vergleichsweise langsam und du willst da ein ganzes Feld mit voller Geschwindigkeit (gar 16MHz) lesen und schreiben? Lass dem EEprom mal mehr Zeit.
      Ich habe jetzt mal bei Lesen und Schreiben eine großzügige Wartezeit von 20ms eingefügt. Soweit ich weiß braucht das Schreiben 9ms, hoffe aber das Bascom das selbstständig optimiert.

      oscar schrieb:

      Noch was: Hast du den brownout-detektor (fusebit) aktiviert? Sonst kann es bei unzureichender VCC (z.B. nach Reset) zu EEPROM-Datenverfälschungen kommen (der EEprom reagiert empfindlich bei zu geringer Versorgungsspannung). Wenn du das Array aus dem EEPROm gelesen hast solltest du später nur die geänderten Daten im EEPROM wieder abspeichern, das schont den selben, 100000 garantierte Schreibzyklen sind nicht sooo viel. ;)

      Der war deaktiviert. Habe ihn jetzt auf 4,3V gestellt. Später werde ich dann auch nur die geänderten Werte speichern, vorab wollte ich nur testen ob es grundsätzlich überhaupt funktioniert.


      Durch die ganzen Änderungen ändert sich aber am Verhalten nichts. Das Problem ist nach wie vor wie oben.

      Update:
      Habe nun mal das Programm auf den Laden/Speichern Teil reduziert und es funktioniert ohne Problem. In dem Fall liegt der Fehler an einem anderen Teil des Programms.
      Den jetzt schreibt er auch nur bis 020/05, beim oberen Screenshot füllt er viel mehr Felder.

      Dann werde ich mich mal auf die Suche nach dem eigentlichen Fehler begeben, trotzdem Danke bis hier her.
    • @Simon1234 hast du einen interrupt am werkeln, wenn du das eram bedienst? Bei writeeeprom wird von bascom zumindest der interrupt abgeschaltet, avrhelp.mcselec.com/writeeeprom.htm
      ( When data is written to the EEPROM, all interrupts are disabled, and after the EEPROM has been written, the interrupts are re-enabled ), wenn du das bei deinem Programm auch mal berücksichtigst und evtl interrupts erst nach der Schleife mit der Schreiberei der Werte aktivierst.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Ich hab's jetzt mal probiert, es geht bei mir einwandfrei
      Eram-ohne-Pause.PNG
      Für das Schreiben braucht die Schleife gemäß Simulator 1,052ms.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo,

      ich habe noch irgendwo ganz weit im Hinterkopf eine Erinnerung, dass sich bei größeren Programmen (leider weis ich nicht mehr bei wie viel kB der Fehler auftrat) ein Problem bzw.
      ein seltsames Verhalten ergab.
      Ob dieser Bug in der Zwischenzeit bereinigt wurde, entzieht sich meiner Kenntnis.

      Wenn es möglich ist, kannst Du ja mal verschiedene Programmteile auskommentieren, um dieses Speichergrenzenproblem (falls es eins ist) zu erkennen.

      Oder anders herum implemetiere in das lauffähige einfache EE-Prom Programm einfach ein paar Bitmaps, die den Seicher füllen.

      Viel Erfolg

      Sepp
    • Hallo zusammen,

      ich wollte hiermit noch den Fehler mitteilen an was es lag. Ich nutze ein Programm, mit dem man ein Menü erstellen kann. Diesen Bascom Quellcode habe ich in mein Programm eingebunden.
      Das Menü speichert bei der Initialisierung vorab alle geladenen Werte im Eeprom auf festen Adressen (siehe rot umrahmtes Feld) ab. Da das erste Feld im Eeprom von dem Menü nicht benutzt wird, hat sich auch die erste Zahl nie geändert.

      Demnach kann ich keine Eram Variablen nutzen und muss die Array Variablen von oben auch mit festen Adressen abspeichern.

      328P.png
    • Riedleweg schrieb:

      Das Programm für die Menü-Erstellung würde mich interessieren. Gibts das wo?
      mat.midlight.eu/index.php/Simple_LCD_Menu_Main_Page

      Als ich die Software anfangs genutzt hatte ging die Hälfte nicht und ich musste mit dem Entwickler zusammen die Fehler ausbügeln.
      Zusätzlich wurde auf Nachfrage dann noch die Speicheroption für Variablen integriert, die man je nach Wunsch aktivieren kann.

      Für größere Menüs ist das ganz praktisch, aber es braucht auch einiges an Speicher.

      Version 1.5 (21.11.2017)
      Enhancements:
      • Added option to preserve editable values in EEPROM
      • Changed file extensions from .bas to .inc
      • Added menu entry move up/down buttons
      Bug fixes:
      • Exported wrong count of values of type Long
      • Exported wrong data for Dword data types
      • Minor bug fixes
    • Hallo,

      (wie bereits per Mail geschrieben, aber hier nochmal der Vollständigkeit wegen)

      Der vom Menü benutzte EEPROM-Speicherbereich lässt sich durch setzen der Konstante Menu_eeprom_start verschieben:

      BASCOM-Quellcode

      1. Const Menu_eeprom_start = xyz
      2. $include "menu.inc"
      Der von Bascom-Eram-Variablen reservierte Speicher und damit die Startadresse des freien Speichers kann zB. aus dem Compiler-Report oder mit einer Simulation ermittelt werden.

      Lg