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" .equ takt=16000000 .equ lcdpen=portb .equ lcden=pb2 .equ lcdprs=portb .equ lcdrs=pb3 .equ lcdpdat=portd .equ lcdbus='1' .def curpos=r23 .def acku=r16 .cseg rjmp start ;.org $13 start: ldi acku,low(ramend) [\avrasm]
Angehängte Dateien:
:
Bearbeitet durch User
Peter B. schrieb: > Hat sonst noch jemand so erlebt? Nein, habe ich nicht. > .def acku=r16 Entweder accu oder akku. acku sieht so richtig Scheiße aus. Wahrscheinlich so Scheiße, dass sich sogar der Simulator mit Grausen abwendet.
Ob S. schrieb: > Peter B. schrieb: > >> Hat sonst noch jemand so erlebt? > > Nein, habe ich nicht. > >> .def acku=r16 > > 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.)
Peter B. schrieb: > Aber es wäre schön, wenn > man mir statt mit spöttischen Kommentaren mit inhaltlichen Tipps weiter > helfen würde. Das habe ich getan.
Peter B. schrieb: > Dann startet der Debugger (im Simulator) 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? Ob S. schrieb: > 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.
:
Bearbeitet durch User
Gerhard H. schrieb: > Hast Du keinen Debugger an echter Hardware dran? 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.
Gerhard H. schrieb: > 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...
Ob S. schrieb: > Das ist doch für das Problem des TO völlig Wurscht, ob Simulator oder > Debugger. Ja das mag sein, mich würde die Frage trotzdem interessieren. Das Microchip Studio hat hier und da so seine kontextabhängigen Macken... Ob S. schrieb: > 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).
:
Bearbeitet durch User
Gerhard H. schrieb: > 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.
Ob S. schrieb: > Nein, das ist durchaus nicht immer der Fall. Man kann schließlich die > Lage des Resetvektors über die Fuses verändern Stimmt. Kann man. I.d.R. bleibts aber bei der Voreinstellung. Ob S. schrieb: > 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.
Ob S. schrieb: > bei > jedem neuzeitlichen AVR8 (incl. der Tinys) Das war Quatsch. Bei denen liegt der Resetvektor immer auf 0.
Gerhard H. schrieb: > 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.
Ob S. schrieb: > 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!
Gerhard H. schrieb: > 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...
Ob S. schrieb: > 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 :) Peter! Dranbleiben!
:
Bearbeitet durch User
Gerhard H. schrieb: > 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...
Ob S. schrieb: > 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).
:
Bearbeitet durch User
Erst mal Danke für die Beiträge. Ich habe es jetzt hinbekommen. Folgende Änderungen waren nötig: - Korrektur von "Acku" nach "Akku" - Platzhalter für Interrupt Vektoren freihalten : .ORG $13 - Aufruf der Include Dateien nach .ORG $13 sonst gab es den Fehler :Overlap in .cseg: addr=0x13 conflicts with 0x0:0x63 Der Code sieht dann so aus: [avrasm] .include "m8def.inc" .equ takt=16000000 .equ lcdpen=portb .equ lcden=pb2 .equ lcdprs=portb .equ lcdrs=pb3 .equ lcdpdat=portd .equ lcdbus='1' .def curpos=r23 .def akku=r16 .CSEG rjmp start .ORG $13 .include "lcd4puts.inc" .include "lcd4put.inc" .include "lcd4ini.inc" .include "warte1ms.inc" .include "lcd4com.inc" .include "lcd4cur.inc" start: ldi akku,low(ramend) out spl,akku ldi akku,high(ramend) out sph,akku ... [\avrasm] der Debugger startet wieder bei "Start". Jetzt kann ich die inhaltlichen Fehler suchen. Danke an alle.
Peter B. schrieb: > Der Code sieht dann so aus: [...] > .ORG $13 [...] Das schreibt man dann sinnvoller so: .ORG INT_VECTORS_SIZE Dann passt es automatisch auch dann, wenn du statt Mega8 z.B. einen Mega644 als Target wählst. Das Symbol wird nämlich in den device-spezifischen Includes deklariert. Genau dazu, es z.B. für diesen Zweck zu verwenden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.