Bascom 2.0.8.5

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • bitlogger wrote:

      Wozu sollte das Programm veröffentlicht werden?
      Darum geht es gar nicht. Niemand will deine Betriebsgeheimnisse wissen.

      Es geht darum, den Fehler nachvollziehen zu können. Man kann ja auch ein Programm zeigen, mit dem sich der Fehler reproduzieren lässt.


      bitlogger wrote:

      Das $Cristal fehlt nicht!. Ist in obigem Auszug nur nicht vorhanden, folgt unmittelbar dem Abschnitt.
      $Crystal gehört an den Anfang zu diesen Angaben:

      $regfile = "m1284pdef.dat" '"m644def.dat"
      $hwstack = 80
      $swstack = 80
      $framesize = 60
      $Crystal = 123456

      Grund ist einfach. Der Compiler muss z.B. den Takt wissen, bevor er einen Teiler für ein I2C-Register berechnen kann.

      Vielleicht ist das der Fehler.
      Warum das mit vorherigen Programmen keinen Fehler ergab könnte daran liegen, dass sich durch das Update auch am Compiler oder Parser was geändert hat.
    • bitlogger wrote:

      Wozu sollte das Programm veröffentlicht werden?
      Na ja ;( .
      Ich stelle mir jetzt mal vor, du findest einen möglichen Fehler in BasCom und wendest dich deswegen an den Support.
      Der kann deine Beobachtung aber auch nur dann nachvollziehen wenn er das entsprechend analysieren kann und braucht dazu eben ein entsprechendes Programm wo der Fehler dann eben auch auftritt und nachvollziehbar ist.
      Wenn nun dein Programm so super-duper-maximal-geheim ist, liegt es dennoch an dir, zumindest ein entsprechend kompilierbares Programmfragment zu liefern und dann nicht zu sagen "dies und das" steht ja eh da du musst es dir halt dazu denken.
      Das ist auf keinen Fall "die feine englische Art" und wird potentiell helfende nur vergrämen.

      Wenn du "Pech" hast tritt der Fehler aber nur in deinem (langen) Programm auf in einer gekürzten Form aber nicht mehr weil da allfällige Sprungziele plötzlich viel näher sind (so etwas hatte ich z.B. in der Vorgängerversion von BasCom mit den WS2812-LEDs welche in deren Vorversion noch einwandfrei liefen).

      Solche Äußerungen erinnern mich immer an "die gute alte Zeit" wo in der Elektronikwerkstätte Geräte einlangten mit der Bitte um Reparatur und dem vielsagenden Beipacktext "geht nicht". Die gingen dann immer unrepariert zurück wenn die im Kurztest soweit doch korrekt funktionierten.
      So wurde dann auch "Hilfspersonal" (die die Geräte halt verbauten und im Störungsfall einfach nur austauschten aber von Technik einfach keine Ahnung hatten) dazu erzogen, einen Fehler in ein oder zwei sinnvollen Sätzen zu beschreiben.
    • @Zitronenfalter hat es gut auf den Punkt gebracht.

      Ich möchte aber noch folgendes ergänzen.

      Ich habe Verständnis, dass man sein "Programm-Werk" bei einem Fehler und halb fertig nicht gerne öffentlich macht. Oder weil man im Programm eine Idee verfolgt und man die nicht verraten will. Es gibt da viele Gründe. Ich kenne die Situation zu gut.

      Um aus dem Dilemma zu kommen gibt es aber nur 2 Wege:
      • Man wendet sich an ein Forum und muss unter Umständen zumindest einen Teil des Codes preisgeben, um den Fehler zu finden bzw. Hilfe zu bekommen. Oder
      • Man sucht eben selber nach der Problem-Ursache was dauern kann. Dafür bleibt es geheim.
      Aber es gibt noch einen dritten weg.
      Du vertraust dich einem Helfer im Forum an und gibst nur dem den Code via PN oder nach Maulaustausch per PN.
      So bekommst du Hilfe und dein Code bleibt auf Vertrauensbasis auch geheim.

      Ich konnte am Simulator bisher keine Macke an Version 2.0.8.5 feststellen. Und ich kann dir versichern, dass in den die letzten Tage sehr intensiv genutzt habe.
    • Mitch64 wrote:

      $Crystal gehört an den Anfang zu diesen Angaben:
      ...
      Der Compiler muss z.B. den Takt wissen,
      Der Compiler weiß den Takt auch ohne das er im Code erwähnt wird. Nur wir dann nicht. Da er ohne Angabe im Programm bei jedem anders sein kann.

      Mitch64 wrote:

      dass in den die letzten Tage sehr intensiv genutzt habe.
      Schon versucht ob der Neue die Timer vollständig(er) unterstützt. Die Vorgänger "vergaßen" einige Interrupts und Pwm-Pins.. ?
    • Es scheint in diesem Forum einige zu geben, die ähnlich wie ich sind. ;) Sinngemäß ein Helfersyndrom haben.
      Ich verstehe leider immer noch nicht, wieso ich ein Programm vermitteln sollte, das in vorherigen Bascom-Versionen "einwandfrei und umfangreich funktioniert"!
      Es gibt darin keinen Fehler, somit dürfte auch nichts zu finden sein.
      Nochmal, ich habe zum ausprobieren (aufgrund euerer Hinweise des Simulators 2.0.8.5) ein funktionsfähiges Programm mit dem "neuen" Simulator testen wollen, damit ich die Gestaltung usw des neuen Simulators testen kann.

      Hatte dabei zuerst vergessen den "Auftrag" $sim einzufügen, diesen Eintrag an die erste Zeile dann eingetragen und dann kam diese Meldung etc.
      $sim stand also diesmal weit vor den üblichen Anweisungen, dachte, das müsste egal sein, Compiler händeln können.
      Nachdem dieser sinngemäße Fehler, bzw Hinweis auftauchte, wollte ich darauf aufmerksam machen! Nebenbei fragen, ob dieses $sim hinter den Hauptanweisungen stehen muss, und ob jemand etwas mit dem Meldungshinweis anfangen kann.

      Ich habe somit gar nicht um Hilfe gebeten, sondern nur aufmerksam machen wollen, was mir mit einem fehlerfrei übersetzten, lauffähigen Programm, einzig im Zusammenhang mit diesem Simulator 2.0.8.5 "aufgefallen" ist.
      Nochmal, genau dieses Programm wird in den Versionen 2.0.8.3 und 2.0.8.4 einwandfrei bedient, liefert im Simulator dieser Versionen keinen Fehler, macht dort keine Probleme! Das wollte ich aufzeigen, sonst nichts.
    • bitlogger wrote:

      Es gibt darin keinen Fehler, somit dürfte auch nichts zu finden sein.
      Was nur bis zur Version 2.0.8.4 gilt da es in der Version 2.0.8.5 ja offenbar nicht mehr das tut was es eben vorher getan hatte.

      Auch ich hatte ein Programm welches in der "alten" Compilerversion fehlerfrei funktionierte und das aber in der neuen Compilerversion (hier dann 2.0.8.4) eine Fehlermeldung des Compilers lieferte. Dieser Fehler ist nun wohl in der aktuellen Version beseitigt wenn ich die Hinweise richtig deute
      .

      Source Code

      1. - rainbow libs rolled back. the automatic platform code had the disadvantage of requiring a call instead of rcall

      Erschwerend kam dabei hinzu, dass dieser Fehler aber nur deswegen aufgetreten ist weil sich zwischen Aufruf einer Funktion und dem vom Compiler zugewiesenen Platz im Compilat zuviel Flash-Speicher befand weil das Programm eben sehr umfangreich war.
      Der Grund war wohl, dass der neue Compiler das Compilat wohl anders zusammensetzte und somit der Rücksprungbefehl einer Funktion nicht mehr ausreichend weit genug wirken konnte.

      In einem kürzeren Programm tritt der Fehler gar nicht auf in einem langen schon also muss man zur Analyse des Fehlers eben das große ganze Programm zur Verfügung stellen oder der Fehler kann nicht (oder nur mit mehr Aufwand) gefunden werden.

      Es hilft also eigentlich gar nicht hier hinzuweisen dass da irgend was bei deinem "funktionierenden" Programm nicht funktioniert ohne dann nicht weiter darauf eingehen zu wollen.
    • OK

      Fassen wir zusammen.

      Dein Programm funktioniert, ist tippi-toppi und scheidet als Ursache aus.
      Das kann ich also ein beliebiges Programm laden und der Fehler müsste auftreten, wenn ich nach dem Compilieren den Simulator starte.

      Habe ich geprüft. Simulator funktioniert.
      Also liegst am Simulator auch nicht.

      Logische Schlussfolgerung: Der Fehler existiert nicht.

      Spaß bei Seite.

      Sag doch mal schritt für Schritt was man machen muss, dass der Fehler auftritt.
      Tritt der Fehler bei dir auch mit einem anderen Programm auf? Dürfte ja nicht sein, weil deine Programme funktionieren ja.
    • Seit dem Update auf Bascom 2085 ist die Splitlinie (markiert im Bild mit rotem Pfeil) bei mir nicht ganz an der Oberkante des Editorfensters. Dadurch erscheint immer ein Teil der ersten Zeile oberhalb der Splitlinie (markiert im Bild mit grünen Pfeilen).
      Man kann sie zwar hochziehen, allerdings ist sie beim nächsten Start von Bascom wieder die 1-2 mm nach unten verschoben. Unter Bascom 2084 war alles in Ordnung.
      Habt Ihr das Problem auch? Bekommt man das irgendwie weg?
      Benutze Windows 10, Bildschirmauflösung 1920x1080 an einem Flatron IPS235

      Splitlinie_2084_vs_2085.jpg
    • Rollo Robert
      Man sieht's auch an der Linie am linken Rand des Editor-Fensters. Die ragt nach oben über die Splitline hinaus.
      Ich kann das auch nachvollziehen.
      Aber Teile von Buchstaben erscheinen bei mir trotzdem nicht über der Splitline.
      Das liegt vielleicht daran, dass ich im Editor einen anderen Font verwende.
      Ich verwende "Courier New" mit 12er Schriftgröße. Habe aber zusätzlich noch "Use Monofont" angehakt.

      Mir ist das bisher nicht aufgefallen (Buchstabenteile über der Splitline), weil ich in der ersten Zeile nie anfange zu Coden. Das sieht so gequetscht aus.
      Gleiches gilt für den linken Rand. Ich rücke hier auch immer eine Tab-Größe ein.

      Was mit aber aufgefallen ist, dass dieses Fenster oberhalb der Splitline beim Scrollen des Editorfensters auffällig zuckt.