BASCOM-Projekt (2.0.7.3.001) mit AVR-Studio (5.1.208) reassemblieren

LotadaC

Sehr aktives Mitglied
22. Jan. 2009
3.547
70
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
...........
 

Anhänge

  • BascomOutput.png
    BascomOutput.png
    14,4 KB · Aufrufe: 40
  • debuggenStarten.png
    debuggenStarten.png
    28,1 KB · Aufrufe: 33
  • fertig.png
    fertig.png
    74,2 KB · Aufrufe: 40
  • MCUWaehlen.png
    MCUWaehlen.png
    76,1 KB · Aufrufe: 37
  • ObjektOeffnen.png
    ObjektOeffnen.png
    19,9 KB · Aufrufe: 39
Hallo,

(vorweg: in Dinos FAQ-Sammlung habe ich keine solche Anleitung gefunden, die SuFu hat mich diesbezüglich auch nicht befriedigt - ansonsten warte ich auf einen entsprechenden Verweis.)

desöfteren möchte ich (meist aus Forenanfragen heraus) mit BASCOM erstellte Projekte reassemblieren. Die Gründe sind (u.a.):
  • Verständnis, wie BASCOM irgendeinen (insbesondere über eine externe Bibliothek eingebundenen) Codeabschnitt umsetzt - also was dabei in der Hardware geschieht, auch im Hinblick auf die Timings
  • Verwendung des AVR-Studio-Simulators, welcher (zumindest bei integrierter Hardware) etwas zuverlässigere Ergebnisse liefert (liefern soll), als der von BASCOM (siehe zB Bascom-Online-Hilfe zum Thema Timer/PWM)
Da ich mich irgendwie jedesmal neu in den Ablauf reinwuseln muß (einfach das .hex öffnen reicht mir nicht), hier mal eine bebilderte Abfolge:

Wir benötigen (zumindest) die .hex und die .obj-Dateien - ich lasse Bascom einfach diese hier erzeugen:
Anhang anzeigen 5085
Das erstellte Programm muß natürlich compiliert werden (dann werden diese Dateien erzeugt, klar) -> F7
Danach kopiere ich einfach das gesamte Projektverzeichnis, und starte das AVR-Studio...

Hier ist das "Object File fürs debuggen zu öffnen"...
Anhang anzeigen 5089
Es ist ein Projektname und -verzeichnis zu wählen...
ObjektWaehlen.png
"Next"

Die verwendete MCU wird ausgewählt...
Anhang anzeigen 5088
Dann (geduldig) laden lassen

Als nächstes kann man das Debuggen starten lassen...
Anhang anzeigen 5086
Es wird nach dem zu verwendenden Simulator gefragt
SimulatorWaehlen.png
hier ist die Wahl einfach -> Wählen und OK

Irgendwann sollte es (mit etwas Geduld) so aussehen:
Anhang anzeigen 5087

Unter "Viewing Options" kann man jetzt die Codeanzeige frisieren (insbesondere in Hinsicht auf Zeilennummern (für Diskussionen im Forum hilfreich), und die Einblendung der Bascom-Befehle als Kommentar).
Die tatsächliche MCU-Frequenz läßt sich (hier) rechts über einen Rechtsklick (Kontextmenu) anpassen, um aus den Zyklen sinnige Angaben zur verstrichenen Zeit zu erhalten (ggf erscheint dieses Fenster auch woanders).

Das wars eigentlich.

Jetzt noch eine Anmerkung/Frage:
Ich habe auf dem (doch schon etwas betagten CoreDuo) unter anderem das Visual-Studio (für VisualBasic) und Eclipse (für Android) am laufen, beide basieren (wie auch das AVR-Studio ab Version 5) auf dem .net-Framework, wenn ich mich nicht irre.
Ob der Rechner das einfach nicht mehr ordentlich schafft, oder ob's (bei mir) ein Softwareproblem ist, weiß ich nicht - jedenfalls wird das Debuggen damit so langsam unzumutbar: jeder Einzelschritt kann durchaus Sekunden (im zweistelligen Bereich) bis Minuten (Rekord bisher knapp 5) in Anspruch nehmen.
(interessant daran ist übrigens, daß es keine Rolle zu spielen scheint, ob man einen einzelnen Schritt, oder einen größeren Abschnitt (Run to) simulieren läßt - dauert beides gefühlt gleich lange)

Unter dem AVR-Studio 4.18.684 hab ich diese Probleme nicht - hier läuft alles (noch) flüssig. Allerdings bekomme ich es hier nicht hin, ein BASCOM-Projekt fürs Debuggen zu öffnen. Ich kann mir das .bas-File anzeigen lassen, ich kann das .hex (als ASM) anzeigen lassen und simulieren, aber dann fehlen mir die eingeblendeten Bascom-Befehle. Ich bin eigentlich sicher, daß das schon mal geklappt hat - hat jemand dafür ein HowTo?
 
Hey,

ich kann dir bei deinem Problem leider nicht helfen, aber ich kann dir sagen dass du mit dem Konflikt AVR Studio 5 (vllt auch 6) was auf der Visual Studio 2010 Shell basiert nicht der Einzige bist wo es Probleme gibt mit bereits installierten VS Versionen. Genau aus diesem Grund bin ich zu dem altem AVR Studio 4 zurück gewechselt (ich musste dafür neu installieren <_<). Debuggen ging bei mir nirgendswo mehr vernünftig, eher garnicht (weder im AVR Studio via debugWire noch im VS).

Ich hab mir die Mühe gemacht aktuelle Projekte umzuschreiben von Bascom in ASM. Nett dass Bascom inline Assembler erlaubt, so kann man Routine für Routine übersetzen und wenn man das Gröbste hat gleich in Assembler umsetzen. Ja, kostet Zeit, aber ich bereue den "Absprung" nicht :)
Aber meine Projekte waren auch immer relativ klein.

Und wenn ich so sehe was die anderen Programmiersprachen (VB.NET, C#, ...) sich da so zusammen klatschen mit zig tausend unnötigen Typ Umwandlungen, Aufrufen etc, da bin ich ganz froh dass ich auf den kleinen Dingern ASM einigermaßen beherrsche. Und bin froh dass Dirk (wie zuletzt) aber auch die anderen Member hier fleißig helfen :)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)