Problem EEPROM-HEX-Format

    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!

    • Problem EEPROM-HEX-Format

      Hallo

      Wenn man in einem Programm erreichen möchte, dass das EEPROM eines Controllers direkt mit Daten beaufschlagt wird, verwendet man ja die Direktive $EEPROM und gibt danach die gewünschten Daten in Data-Zeilen ein.
      Soweit so gut, nur wenn man auch noch die Direktive $EEPROMHEX verwendet erzeugt BasCom erwartungsgemäß auch eine Datei welche den HEX-Code der Daten enthält.
      Wenn man dann aber die so erstellten Daten auch zum Chip übertragen möchte hat man ein Problem (oder ich übersehe da etwas).
      Im Bufferfenster des EEPROMs wird nämlich der Inhalt der so erzeugten HEX-Datei übernommen und nicht die HEX-Datei vorher konvertiert und dann erst in den Buffer übernommen
      Dies dürfte deswegen passieren, weil Bascom auch die EEPROM - HEX-Datei mit der Dateiendung *.EPP anlegt und das Einlesen an dieser Dateiendung "aufhängt" und wohl gar nicht erwartet, dass das nun aber eine HEX-Datei ist.

      Wie bereits gesagt, entweder übersehe ich da was (ein Häckchen irgendwo z.B.).
      Meiner Meinung nach müsste da irgendwas im Dateimanagement passieren und die EEPROM-HEX-Datei zusätzlich als HEX-Datei angelegt werden weil BasCom strickt zwischen EPP und HEX-Dateien unterscheidet.

      Kann da wer Licht ins Dunkel bringen?

      BASCOM-Quellcode

      1. $regfile = "m328pdef.dat"
      2. $crystal = 11059200
      3. $hwstack = 100
      4. $swstack = 100
      5. $framesize = 100
      6. Do
      7. Loop
      8. End
      9. $EEPROM ' Entsprechend DIM - ERAM
      10. $EEPROMHEX
      11. Data "TASTATURKALIBRIERUNG"
      12. Data "Taste [-] bet{225}tigen!"
      13. Data "Kalibrierungsfehler!"
      14. Data "Kalibrierung OK "
      15. Data "OK, Box neu starten!"
      16. LEDcolors: ' Farbdefinition
      17. Data 255 , 0 , 0 ' rt
      18. Data 0 , 255 , 0 ' gn
      19. Data 0 , 0 , 255 ' bl
      20. Data 255 , 127 , 0 ' or
      21. Data 255 , 255 , 0 ' ge
      22. Data 255 , 0 , 255 ' mg
      23. Data 255 , 255 , 255 ' ws
      24. Data 0 , 0 , 0 ' sw
      Alles anzeigen
    • Hast du dir dazu mal die Bascom-Hilfe durchgelesen


      Remarks
      The AVR has build in EEPROM. With the WRITEEEPROM and READEEPROM statements, you can write and read to the EEPROM.
      To store information in the EEPROM, you can add DATA lines to your program that hold the data that must be stored in the EEPROM. $EEPROM must be used to create a EEP file that holds the data.
      The EEP file is by default a binary file. When you use the STK500 you need an Intel HEX file. Use $EEPROMHEX to create an Intel Hex EEP file.
      :!: $EEPROMHEX must be used together with $EEPROM.

      Die DATA-Zeilen müssen auch noch mit einem $DATA abgeschlossen werden.
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • djmsc schrieb:

      Die DATA-Zeilen müssen auch noch mit einem $DATA abgeschlossen werden.
      Soweit ich das verstehe sagt die Direktive $DATA dem Compiler aber nur, dass die dann folgenden Datazeilen im Flash landen sollen.

      BasCom-Hilfe schrieb:

      Instruct the compiler to store the data in the DATA lines following the $DATA directive, in code memory.

      Nichtsdestotrotz habe ich das aber nun auch noch versucht und es ändert nichts im bereits oben beschriebenen Verhalten von Bascom.
      Das erzeugte EPP-File ist zwar im HEX-Format wird aber auch genauso in den Buffer geladen (eben ohne Umwandlung in die dort notwendigen binären Daten) was dann ein direktes Brennen des Chips verunmöglicht.
      Aktuell muss man die Dateinamenserweiterung der so erzeugten HEX-Datei erst um ".HEX" erweitern, dann kann man diese auch erwartungsgemäß in den Buffer laden und brennen weil die Laderoutine offenbar nur durch die Erweiterung unterschieden wird.

      Und bevor die Frage kommt warum braucht es beide Dateien?
      Ich brauche halt in einem aktuellen Projekt beide und ich finde es auch unpraktisch, dass zwei vom Inhalt und Funktion verschiedene Dateien offenbar den gleichen Namen tragen.
      Aktuell muss man einmal mit und einmal ohne der Direktive $EEPROMHEX compilieren und vor dem zweiten compilieren die zuerst erstellte Datei händisch umbenennen und "retten".
      Das ist zumindest unpraktisch ;) .
    • Hi @Zitronenfalter

      Ich denke der Entwickler dachte daran, dass man die Dateien auch als Hex-Datei bereitstellen sollte. Denn es gibt ja Nutzer, die haben kein Bascom, und der Compiler versteht nur HEX-Files.

      Wenn du natürlich beides brauchst und die Namen beißen sich, ist das ein Fall für den Entwickler.
      Ticket schreiben und Verbesserungsvorschlag machen.

      Wenn du aber z.B. mit der Option $EEPROMHEX compilierst, und du dieses File brennen willst, dann geht das auch.
      Dazu hängst du einfach an die eep-Datei noch ein ".hex" dran.
      Die heißt dann z.B. Projekt.eep.hex.

      Dann gehst du in Manuell programmieren und wählst den Reiter EEPROM aus.
      Dann im Menü "Buffer" den Eintrag "Load from File" auswählen.
      Es öffnet sich eine Dateiauswahlbox. Dort dann unten rechts den Typ "*.hex" auswählen und die Datei Projekt.eep.hex laden.
      Das hex-File wird konvertiert und korrekt in den Buffer geladen und kann jetzt mit Write Buffer gebrannt werden.

      Bascom erkennt anhand der Dateierweiterung, ob die Datei hex ist oder bin.
      Die Option EEPROM hex speichert hex, aber die Extension sagt Bascom, es sei eine Bin-Datei und lädt diese dann 1:1 in den Buffer.

      Daher vorher einfach ".hex" an das EEProm-File anhängen und manuell öffnen.
    • Genau so habe ich das ja auch gemacht.
      Ich fand das halt etwas unpraktisch und hoffte auf einen versteckten "Schalter" den es aber wohl nicht gibt.
      Bisher brauchte ich das nicht, daher fiel es mir auch nicht auf.
      In meinem aktuellen Projekt musste ich aber Flash frei bekommen und habe daher Daten direkt ins EPROM ausgelagert wo ich dann ganz normal mit Variablen zugreifen kann.
      Ich habe das aber heute auch im Originalforum mit einem Lösungsvorschlag gepostet.
      Mal sehen.