Hallo,
neuerdings bekomme ich ein Problem wenn ich im Microchip Studio ein Projekt debuggen will. Dann startet der Debugger (im Simulator) nicht bei "Start" in der main.asm wo auch ein Breakpoint ist, sondern in der ersten includierten *.inc Datei.
Auch Neustart des Studions, Neuanmeldung und Erstellen eines neuen Projektes brachten keine Besserung.
Hat sonst noch jemand so erlebt?
[avrasm]
.include "m8def.inc"
.include "lcd4puts.inc"
.include "lcd4put.inc"
.include "lcd4ini.inc"
.include "warte1ms.inc"
.include "lcd4com.inc"
.include "lcd4cur.inc"
Entweder accu oder akku. acku sieht so richtig Scheiße aus.
Wahrscheinlich so Scheiße, dass sich sogar der Simulator mit Grausen
abwendet.
Ach übrigens:
Wenn die Includes blöderweise Code/Daten erzeugen (was sie nicht sollten), dann kann es gut passieren, das der Entrypunkt mitten darin zu liegen kommt.
Es fehlt die Reservierung für die Vektortabelle (oder zumindest den Reset-Vektor). Das muß immer passieren, bevor irgendwelcher sonstiger Code erzeugt wird.
Sprich: wenn Includes Code/Daten erzeugen (was sie, wie gesagt, nicht sollten) dürfen sie erst nach "rjmp start" included werden.
Gut "Acku" ist keine richte Rechtschreibung. Aber es wäre schön, wenn man mir statt mit spöttischen Kommentaren mit inhaltlichen Tipps weiter helfen würde.
Ich möchte mein Programm zum Laufen bekommen. (ATMEGA8 zur Ansteuerung einer LCD Anzeige in Assembler.)
Hast Du keinen Debugger an echter Hardware dran? Warum ist die main.asm im Fenster doppelt? Wie schaut Dein Projekt im Solution-Explorer aus, wo ist da der Entry-Point? Gibt es besondere Meldungen im Build-Prozess?
Sprich: wenn Includes Code/Daten erzeugen (was sie, wie gesagt, nicht
sollten) dürfen sie erst nach "rjmp start" included werden.
Genau. Doch sollte da schon ein Build Probleme machen.
Also: Los gehts in der Code Section immer mit Reset-Vektor und Interrupttabelle. Ein .org xx sollte man sich dort sparen und die Vektoren vollständig hinschreiben. Selbst wenn sie vorerst nicht gebraucht werden. Das kann sich schon bei Updates, spätestens aber im nächstbesseren Projekt ändern. Ohne Interrupts verzichtet man ja auf einen großen Teil Controller-Funktionalität.
Das ist doch für das Problem des TO völlig Wurscht, ob Simulator oder Debugger. Auch der Debugger würde in dem Code landen, der von der lcd4puts.inc ab Adresse 0 erzeugt wird.
Genau. Doch sollte da schon ein Build Probleme machen.
Nein. Solange kein explizites ".ORG 0" vor dem "rjmp start" steht, wird es keine Fehlermeldng geben. Das ist gültiger Code und er wird halt nach dem includierten Code in den Flash geschrieben. Das Problem ist nur: der Reset-Vektor ist nicht dort, wo dann das "rjmp start" steht...
Das Problem ist nur: der Reset-Vektor ist nicht dort, wo dann das "rjmp
start" steht...
Ja, das stimmt natürlich.
Vermutlich kam meinereiner nie zu solchen denkwürdigen Problemen weil der Reset-Vektor /natürlich/ immer der erste Code ist und sein muß. Also Peter: Die .inc Code-Files erst irgendwann nach start inkludieren. Probleme könnten sich trotzdem ergeben wenn darin noch weitere Daten (.equ) deklariert werden. Das besser alles am Anfang, vor dem Code (inkludieren).
Vermutlich kam meinereiner nie zu solchen denkwürdigen Problemen weil
der Reset-Vektor /natürlich/ immer der erste Code ist und sein muß.
Nein, das ist durchaus nicht immer der Fall. Man kann schließlich die Lage des Resetvektors über die Fuses verändern. Bei jedem ATmega, bei jedem neuzeitlichen AVR8 (incl. der Tinys) und sogar bei einem klassischen Tiny (der wohl nur aus Marketinggründen Tiny geworden ist, von der Architektur her aber eigentlich ein Mega ist).
Also
Peter: Die .inc Code-Files erst irgendwann nach start inkludieren.
Besser: Alles, was Code/Daten erzeugt, einfach *.asm nennen. Man kann nämlich auch *.asm includen.
Dann wird es deutlich einfacher, den Überblick zu behalten, um sie an der richtigen Stelle zu includen. Solange die Fuses auf "Standard" sind, also frühestens nach dem Resetvektor.
Und damit man Fehler beim Speicher-Layout tatsächlich mitbekommt, ist es immer eine sehr gute Idee, Code, der an einer bestimmten Stelle liegen muss, mit dem entsprechenden ".ORG" auch an diese Stelle zu zwingen. Dann gibt's halt wenigstens eine Fehlermeldung beim Assemblieren, wenn anderer Code oder Daten überlappen.
Und damit man Fehler beim Speicher-Layout tatsächlich mitbekommt, ist es
immer eine sehr gute Idee, Code, der an einer bestimmten Stelle liegen
muss, mit dem entsprechenden ".ORG" auch an diese Stelle zu zwingen.
Warum sollte Code an bestimmter Stelle liegen müssen (von der Interrupttabelle abgesehen)? Solche Extravaganzen sollte man tunlichst vermeiden, das verkompliziert unnötig.
Warum sollte Code an bestimmter Stelle liegen müssen (von der
Interrupttabelle abgesehen)?
Es gibt keine "Interrupttabelle". Es gibt eine Vektortabelle. Und die enthält halt u.a. auch den Reset-Vektor. Und genau der ist halt hier das Problem.
Soweit sind wir uns einig.
Ansonsten: .org hat in der Code(Flash)-Section für Code nichts verloren. Man kann damit höchstens mal ein paar Daten im Flash positionieren aber meist ist selbst das entbehrlich.
Es gibt keine "Interrupttabelle". Es gibt eine Vektortabelle
Jetzt werde mal nicht zu kleinlich.
Einigen wir uns auf Interruptvektortabelle!
Ansonsten: .org hat in der Code(Flash)-Section für Code nichts verloren.
Unsinn. Hätte er ein ".ORG 0" vor "rjmp start" hingeschrieben (und damit die korrekte Lokalisierung für den Code des Resetvektors erzwungen), dann hätte er zumindest eine Fehlermeldung erhalten.
Das ist der Sinn von Fehlermeldungen: auf Programmierfehler (hier die falsche Reihenfolge der Code-Erzeugung) hinzuweisen. Leider steht aber natürlich in der Fehlermldung nicht "du Honk hast den Code in der falschen Reihenfolge erzeugt". Das herauszufinden, bleibt dem Programmierer überlassen. Aber so ein Hinweis kann trotzdem hilfreich sein. Wenn man halt programmieren kann, also wirklich versteht, was man da tut...
Unsinn. Hätte er ein ".ORG 0" vor "rjmp start" hingeschrieben (und damit
die korrekte Lokalisierung für den Code des Resetvektors erzwungen),
dann hätte er zumindest eine Fehlermeldung erhalten.
Sicherlich.
Wer so "dumm" ist Code vor den Reset-Vektor zu setzen hätte wenigstens das .org 0 gebrauchen können. Entschuldige Peter, jeder hat mal klein angefangen.
Das ist der Sinn von Fehlermeldungen
Das Microchip-Studio kann damit durchaus recht verwirrend und unlogisch werden wenn gewisse stillschweigende Voraussetzungen nicht erfüllt werden. Mir fällt zwar gerade keiner dieser Fälle spontan ein (wieder länger her) aber da gibts über die Jahre durchaus einiges zu erleben.
Wenn man halt programmieren kann, also wirklich versteht, was man da
tut...
Das lernt man /genau so/ , durch die dümmsten Fehler, am besten :)
Das Microchip-Studio kann damit durchaus recht verwirrend und unlogisch
werden wenn gewisse stillschweigende Voraussetzungen nicht erfüllt
werden.
Ähem, nein. Das hat mit dem Studio garnix zu schaffen. Das ist einfach der avrasm2. Der einzige Bestandteil der ASM-Toolchain. Und das Ding ist doch ziemlich gut dokumentiert (außer einigen Teilen des Asm-Präprozessors und dessen Wechselwirkungen mit dem ebenfalls eingebauten C-Style Präprozessor).
Das allerdings sind Feinheiten, die der TO voraussichtlich niemals brauchen oder bemerken wird...
Der einzige wirkliche Beitrag der IDE bei Asm-Projekten ist, das passende Target-Device-Include automatisch an den avrasm2 zu übermitteln. D.h.: das ".include m8def.inc" im Quelltext kann man sich in der IDE-Umgebung sparen. Es stört aber auch nicht, wenn es stehen bleibt. Zumindest nicht, solangem man wirklich beim Mega8 bleibt...
Das hat mit dem Studio garnix zu schaffen. Das ist einfach der avrasm2
Genaugenommen schon.
Für mich sind die halt mit Studiomeldungen identisch weil drin nur der Assembler lebt.
solangem man wirklich beim Mega8 bleibt...
Hier kann ich Peter wiederum nur raten baldmöglichst auf einen aktuellen AVR umzusteigen. Gerade wenn man erst beginnt, in Asm zu programmieren (und dabei bleiben möchte).
Screenshot_2024-04-12_175403.png
(29 KB)
