Hallo!
Ich hab folgendes Problem: Ich möchte ein kleines Programm im Atmel
Studio simulieren. So dass die Ports an den Ausgängen mir das anzeigen,
was der mc in echt auch machen würde.
Hab vorher mal mit ´nem Motorola MC68HC11 was gemacht (allerdings in
Asembler). Dazu gab´s einen Simulator, der mir dann auch tatsächlich
angezeigt hat, was der mc machen würde. Ich konnte dort auch Eingänge
setzen und so nach und nach mein Programm entsprechend erweitern.
Mit dem Atmel Studio 6 krieg ich das bei keinem Beispielprogramm hin
grrrmpf
Ich kann mich nur mit Break und Continue und Setzen von Breakpoints
durchklickern und sehe dann zufällig auch mal einen Ausgang, der an ist
oder an war (rot eingerahmt).
Aber was muss ich machen, um dieses kleine Programm tatsächlich im
Simulator zu sehen (also Ports an - aus - an - aus ...)?
Was mache ich falsch?
Meine Vorgehensweise ist wie folgt:
1. New Project: GCC Cexecutable project (Name unten eingeben)
2. ATtiny2313 wählen
3. Unter Tool simulator einstellen
4. Beispielprogramm (z.B. das unten abgedruckte) hinein kopieren
5. Build solution
5. Start debugging and break?
6. Continue?
7. Wo ist die "PLAY"-Taste?
Danke im Voraus für eine Antwort!
1
// --------------------------------------
2
// Blinken einer LED an PIN 4 (PA1)
3
// für ATTINY 2313
4
// --------------------------------------
5
6
// 1MHz ist Default-Takt (Fuse-Bits nicht manipuliert)
7
#define F_CPU 1000000UL
8
9
#include<avr/io.h>
10
#include<util/delay.h>
11
12
13
intmain(void)
14
{
15
// Pin 1 von Port A (PA1) als Ausgang schalten
16
DDRA=(1<<PA1);
17
18
// Endlosschleife
19
for(;;){
20
PORTA|=(1<<PA1);// bit im Portregister auf 1 setzen => LED leuchtet
21
_delay_ms(500);// eine halbe Sekunde warten
22
PORTA&=~(1<<PA1);// bit im Portregister auf 0 setzen => LED aus
Es gibt viele Hilfswindows, Register, Memory, usw .. die man offen haben
muss. dort kann man auch gleich IO's setzen. Ich glaube mich zu
erinnern, dass man die IO Zustaende auch per File anlegen kann. Und bei
jedem IO-Read wird eine Zeile eingelesen.
Dirk H. schrieb:> Aber was muss ich machen, um dieses kleine Programm tatsächlich im> Simulator zu sehen (also Ports an - aus - an - aus ...)?
Das geht m.W.n so nicht.
Der Simulator macht den update in der simulierten I/O View nur, wenn das
Programm steht. d.h. du musst dich da mit Breakpoints oder im Single
Step Betrieb durchhangeln.
> 6. Continue?> 7. Wo ist die "PLAY"-Taste?
Im Debug Menü findest du alle Menüpunkte und Kommandos, mit denen du mit
dem Simulator interagieren kannst.
Dirk H. schrieb:> Aber was muss ich machen, um dieses kleine Programm tatsächlich im> Simulator zu sehen (also Ports an - aus - an - aus ...)?>> Was mache ich falsch?
Du verstehst das ganze Prinzip des Simulators nicht. Der liefert dir
kein Livebild der Vorgänge in seinem Inneren. Das konnte er nie und
wollte er nie.
Nur dann, wenn du (oder ein Breakpoint) ihn anhält, liefert er mit
seinen Ausgaben einen Snapshot das im Moment der Unterbrechung aktuellen
Status.
Er funktioniert also im Prinzip ganz genau so wie ein Hardware-Debugger.
Früher(tm), zu Zeiten des AVR-Studio 4.x gab es zusätzliches Spielzeug
wie "hapsim". Das hat teilweise das geleistet, was du erwartest (und den
Kram sogar recht hypsch grafisch aufbereitet). Allerdings funktioniert
hapsim nur in Kombination mit dem AVR-Simulator V1. Und den gibts schon
so lange nicht mehr, wie das AVR-Studio Atmel-Studio heißt, also seit
V5.x.
Wenn dir einer abgeht, wenn du fiktive LEDs durch simulierte MCUs
steuern kannst, dann benutze einfach das Studio 4 und hapsim...
Der Sinn von µC ist allerdings eher, die Sache "in echt" laufen zu
lassen. Simulatoren sind sehr nützlich beim Debugging, aber einfach
nicht dazu gedacht, den Effekt eines funktionierenden Programms virtuell
vorweg zu nehmen.
Ich empfehle ein anderes Vorgehen:
Nimm für die Entwicklung einen größeren Controller, und zwei einen, der
JTAG hat. Zb Mega644p. Als Debugger nimmst Du einen Atmel-ICE oder
JTAGIce3. Damit brauchst Du keinen Simulator mehr, sondern kannst direkt
in der realen Hardware nachschauen, was da passiert. Wenn alles läuft,
sollte die Portierung auf den endgültigen Controller kein Problem sein.
PIC-User haben es da besser. Die können alle Controller einfach so
debuggen, auch die kleinen.
fchk
Wenn Du Dich entschließt, statt C mit Bascom zu programmieren, dann
stünde Dir dort ein Simulator zu Verfügung, bei dem man zusehen kann,
wie sich die Zustände der Ports verändern.
MfG Paul
Frank K. schrieb:> Die können alle Controller einfach so debuggen, auch die kleinen.
Auch einen 16F84? Würde mich wundern.
Microchip selbst schreibt was von:
1
An on-chip debugger is special hardware and software that works with
2
specific PICmicro® devices to give developers a low cost method for
3
debugging their code. These PICmicro MCU's must (1) contain special on-
4
chip logic supporting debugging functionality and (2) provide In-Circuit Serial
5
ProgrammingTM (ICSPTM) capabilities.
Anyway, einen ATtiny2313 kann man auch live debuggen, wenn man das
möchte.
Die mir bekannten Studio-Versionen haben die Stati nur bei einem Halt
(Break) aktualisiert.
Mir erscheint dieses Verhalten auch sinnvoll.
Zum einen stellt sich nämlich die Frage: Was nutzt die Info "Ausgang ist
An", wenn nicht feststeht warum bzw. wann. Übrigens: Ein für wenige
Taktzyklen gesetzter Ausgang ist praktisch unsichtbar. Es sei denn, Du
kannst Deine Pupille beliebig beschleunigen.
Zum anderen stellt sich auch die Frage: Wie hoch soll die Auflösung
werden. An dieser Stelle kommen auch moderne Rechner schnell ins
Hächeln.
Die bedingten Haltepunkte sind zwar nicht der große Bringer, aber das
Feature ist nutzbar.
An dieser Stelle merkt man auch schnell, wie stark dies den
Simulationsrechner belastet.
Danke für die vielen Antworten und Infos. Bin jetzt ein Stück weiter.
Hab jetzt verstanden, dass ich den Simulator so nicht nutzen kann.
Ich versuch´s mal mit Breakpoints und Single Step. Das Studio 4 lade ich
mir auch mal drauf.
