Modifizierete Fonts stoppen das Programm

    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!

    • Modifizierete Fonts stoppen das Programm

      Liebe Bascom-Experten,

      ich baue gerade schrittweise ein Programm auf, welches mir auf einem 128x64-Grafikdisplay verschiedene Informationen in verschiedenen Schriften anzeigen soll. Hierbei verwende ich zunächst zwei unveränderte Fonts (16x12 und 8x6), die auch regulär auf dem Display erscheinen - bis hierhin funktioniert alles.

      Da ich auch "Sonderzeichen" verwenden möchte, wie z.B. verschiedene Akkustands-Symbole oder ein Bluetooth-Symbol, habe ich einen dritten Font mit dem Font-Editor-Plugin generiert, und diesen 9x16_Symbole genannt.

      Das verrückte ist, dass der Controller nach dem Flashen komplett stehenbleibt, sobald ich den dritten Font mittels $include "9x12_Symbole.font" einfüge. Der Compiler kompiliert klaglos, das Flashen funktioniert auch, aber der Controller "steht". Ich habe den Rest des Programmes auf ein simples blinkenlassen einer LED reduziert, um alle anderen Fehlerquellen auszuschließen - und die LED blinkt nicht.

      Entferne ich die Zeile $inculde ""9x12_Symbole.font", blinkt die LED.

      Hier wäre man der komplett reduzierte Code:

      BASCOM-Quellcode

      1. $regfile = "m328pdef.dat"
      2. $crystal = 3686400
      3. $baud = 9600
      4. $hwstack = 32
      5. $swstack = 32
      6. $lib "glcdeadogm128x6.lib"
      7. $lib "glcd.lbx"
      8. $include "16x12.font"
      9. $include "8x6.font"
      10. $include "9x16_Symbole.font"
      11. Config Graphlcd = 128x64eadogm , Cs1 = Portd.5 , A0 = Portd.7 , Si = Portb.1 , Sclk = Portb.0 , Rst = Portd.6
      12. Initlcd
      13. Cls
      14. Glcdcmd &B10101111 '1 Display on
      15. Glcdcmd &B10100000 '8 ADC select: normal
      16. Glcdcmd &B11001000 '15 Common output mode select: reverse direction
      17. Ddrc.3 = 1
      18. Do
      19. Toggle Portc.3
      20. Waitms 500
      21. Loop
      Alles anzeigen

      Der Font ist übrigens korrekt an der gleichen Stelle gespechert wie alle anderen Fonts auch, und im Zustand des "Stillstands" ist eine Kommunikation mit dem Controller per ISP (Auslesen von Signatur-Bytes oder Fusebits) problemlos möglich. Es steht also nur das Programm...

      Hat irgendjemand eine Idee, weshalb ein simpler Font das Programm zum Stillstand bringt??
    • @Einzeller schau doch mal in deinem 'code explorer' (im bascom-editor im linken Fenster, evtl musst du ihn noch sichtbar machen) unter info, was da an framesize angezeigt wird.
      Raum für Notizen

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

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

      erstmal vielen Dank für all die Tips, Framesize hatte ich auch schon versucht, das Problem ist aber selbst bei 128 Bytes immer noch aufgetreten.

      Die Lösung brachte Mitch´s Vorschlag: Mit den includes hinter der Hauptschleife läuft alles wie geschmiert. Warum verstehe ich zwar nicht, wenn ich ehrlich sein soll - aber was soll´s, Hauptsache es funktioniert a_64_3a718cae
    • Das INCLUDE schmeißt die Font-Daten genau an die Stelle, an der diese Anweisung steht. Sofern Du dIE Datei vor dem „offiziellen Programmende“ - gekennzeichnet durch das END nach der Main-LOOP - reinstellst, dann musst Du in der INCLUDE-Datei den Datenblock überspringen, z.B. mit GOTO. Tust Du das nicht, dann wird der Datenblock selbst nach dem kompilieren vom MC diese „Befehle“ versuchen auszuführen.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Hm - das heißt also, der Compiler kompiliert die komplette Datei (also z.b. "8x12.font") inklusive Datenblock, und dabei kommen sinnlose Befehle heraus, die Chaos anrichten, wenn sie in der Do-Loop-Schleife stehen. Das ist einleuchtend.

      In der Include-Datei den Datenblock mit GOTO zu überspringen wäre für mich im Moment eine Nummer zu groß - ich wüsste gar nicht, wie ich diese Datei "aufdröseln" soll, um ein GOTO einzufügen. Macht ja aber auch nichts - hinter dem END machen die Includes ja keine Probleme mehr.

      Das einzige was mich wundert (und hier kommt jetzt mein Ehrgeiz, es richtig zu verstehen) ist die Tatsache, dass die Includes der ersten beiden Schriftarten auch VOR der Do-Loop-Schleife keinerlei Probleme gemacht haben. Das Problem trat erst mit dem dritten (selbst editierten) Font auf...
    • Zufall? Stell die Reihenfolge mal um, ob's dann immer noch nix ausmacht.
      Du kannst das Programm im Simulator mal im Einzelschritt laufen lassen, dann zeigt sich ja gleich, in welcher Zeile 'rumgearbeitet' wird.
      Oder ist in den Originalfonts ein $nocompile drin?
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      Das müsste in der Datei als Klartext lesbar sein.
      Spannend. Ich habe mir die font-Datei mal im Editor angeschaut, und nichts dergleichen gefunden.

      Aber seit ich die includes hinter das eigentliche Programm geschrieben habe, funktioniert es einwandfrei.
      Ich habe schon fleißig jede Menge weiterer Schriftarten dazugenommen, und alle werden tadellos angezeigt.
      Das war wohl des Rätsels Lösung...
    • Einzeller schrieb:

      Ich habe mir die font-Datei mal im Editor angeschaut, und nichts dergleichen gefunden.
      Ich hab' dich wohl auf den Holzweg geschickt, aber nicht mit Absicht. Ein $nocompile würde wohl nicht helfen. Ich hab' mich bisschen schlauer gemacht, ein $nocompile verhindert ein compilieren der Datei direkt. Steht die Datei aber als include in einer 'Hauptdatei' und die wird compiliert, dann wird natürlich die include auch bearbeitet.

      Syntax
      $NOCOMPILE
      Remarks
      This looks like an odd directive. Since you can split your program in multiple files, and you can create configuration files, you might open a file and try to compile it. Only normal project files can be compiled and you will get a number of errors and also unwanted files like error, report, etc.
      To prevent that you compile a file that is intended to be included, you can insert the $NOCOMPILE directive.
      Then the file will only be compiled when it is called from your main file, or other include file.
      A file that is opened as thus the main file, and which includes the $NOCOMP directive, can not be compiled.
      The IDE will see it as a successful compilation. This is important for the Batch Compiler.
      Raum für Notizen

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

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