Hi Leute.
Ich brauche unbedingt etwas Struktur in meinem Durcheinander, vielleicht
könnt ihr mir ja ein paar Tips geben.
Ich verliere total die Übersicht, wenn es um die Keil IDE und den
STM32F100, verbaut auf dem Discovery Board geht.
Bei ST direkt gibt es eine große Library mit vielen Beispielen. Wenn ich
dort die Projekte öffne funzt auch alles. Aber ich kann mir die
Peripherie Register des µC beim Debugging nicht angucken. Das Dropdown
Menü ist einfach leer.
Kennt das jemand?
Jedenfalls benötige ich die Register, weil ich sonst noch weniger mit
dem Teil klarkomme (ich möchte z.B. einfach mal gucken, ob ne Interrupt
Flag gesetzt wird, oder nicht ec.)
Dann gibt es noch was von Keil, aber die config Files sind teils von
2008 und ich finde keine aktuellen.
Überhaupt blicke ich durch die vielen verschiedenen Start/Config files
nicht durch.
Die IDE z.B. included IMMER noch eigene Libfiles aus c:\Keil\ARM\INC ,
wobei diese wohl erst benutzt werden, wenn in den anderen Includepfaden
nichts zu finden ist.
Ganz lustig ist auch, dass anscheinend die einen z.B. uint8_t und die
"anderen" u8 als Typdefinition verwenden. Einmal aus stdint.h und einmal
aus stm32f10x_types.h
Nur um mal welche zu nennen: stm32f10x_config, system_stm32f10x, dann
die von uVision erzeugten *.s Dateien, dann gibt es noch andere startup
und ini files.
Mir würde es doch vollkommen genügen, wenn eine Sache zuverlässig
funktionieren würde. Bitte mit den Registern :D
Gerne höre ich mir an, wie ihr das gelöst habt :)
Danke schön,
db
Benutze einfach die "Nutzlast" vom Keil, also den Compiler, Assembler,
Linker, Fromelf und die Lib's von ner Batchdatei aus und laß die ganze
uVision beiseite. Nen brauchbaren Editor wirst du ja wohl haben.
Ich mach's schon jahrelang so und hab all diese tollen IDE's bislang nur
sehr selten vermißt. Der Hauptärger bei allen IDE's, die ich kenne,
besteht darin, daß sie einen bevormunden wollen. Ehe man z.B. seinen
eigenen Startup-Code hineingelinkt kriegt und nicht den Kram, den die
IDE gern möchte, kriegt man überall graue Haare. Ein Gleiches gilt für
unerwünschten Bibliothekskram. Sowas muß man teilweise dadurch abwürgen,
daß man sowas wie __start oder __main oder _init, __init oder _setup im
Startupcode definiert und exportiert. Ist mir bei Keil, IAR, Raisonance
(GNU) schon passiert.
Und nochwas: Mach dir für dein Projekt besser ne eigene Headerdatei für
die Hardware und laß möglichst den ganzen Sumpf vom Hersteller weg.
Gerade bei ST kriegst du sonst kübelweise unnützen Kram in dein Projekt
herein, der nur Probleme macht.
W.S.
Zum debuggen benutzt du Keil aber noch?
Ich finde den Editor der Keil IDE ziemlich Mist...keinerlei Komfort wie
heutzutage üblich. Wenn man gleichzeitig noch mit den VisualStudio IDEs
arbeit, könnte ich bei Keil jedesmal heulen
Das Problem ist, wenn ich jetzt anfange und auch noch unterschiedliche
Tools getrennt voneinander benutzen und diese abschließend verheiraten
möchte, wird es noch komplizierter.
funky schrieb:> Zum debuggen benutzt du Keil aber noch?
Nö.
Ich hatte mir im bastlerischen Übermut mal nen Segger-JTAG-Adapter
zugelegt, aber das Teil fristet sein Dasein in der Schublade. Ich
debugge nicht, sondern schreibe meinen Kram so, daß er auch ohne
Debugger läuft. Bei NXP und ST benutze ich die eingebauten Bootlader und
nur bei Nuvoton nehme ich den JTAG-Programmer-Stick von Nuvoton.
Ich brauch für meinen Kram also wirklich nur die eigentlichen
Übersetzungstools und meinen Editor. Wenn man beim Schreiben sich ein
bißchen Mühe gibt und nicht gedankenlos daherschreibt, dann geht das
richtig gut.
Allerdings muß ich dazusagen, daß ich mittlerweile so einiges an Quellen
und Codestücken im Repertoire habe, die ich vor Ewigkeiten geschrieben,
ausprobiert, schon x mal verwendet und von Prozessor zu Prozessor
mitgenommen habe und die ich immer wieder verwende.
W.S.
naja gut...ist für mich nicht wirklich ne alternative. einen
funktionierenden debugger möchte ich eigentlich nicht mehr missen.
bei der neuen keil version haben sie anscheinend ne andere editor engine
benutzt, aber das gelbe vom ei scheints auch noch nicht zu sein(habs
noch nicht ausprobiert)
Hallo,
schau Dir doch mal diese Seite an, hier wird sehr schoen ein "Vorgehen"
fuer das discovery board beschrieben. Die verwendeten header Files,...
kannst Du auch weglassen (nach entsprechenden Apassungen).
http://en.radzio.dxp.pl/
Keil mag sein wie es ist, ich arbeite damit sehr gerne, da die
Entwicklungsumgebung verlaesslich funktioniert (immer die neueste
Version installieren) und vor allem einen sehr gut integrierten Debugger
hat.
Zum effizienten Arbeiten (Programmieren / Testen) gehoert der Debugger,
Hilfskonstrukte wie das Einfuegen von "printf´s" (oder entsprechende
Ausgaben auf LEDs,...) sind wie der Namen sagt Hilfskonstrukte (und
damit zweite Wal).
Viele Gruesse
Winfried
Winfried Speidel schrieb:> Zum effizienten Arbeiten (Programmieren / Testen) gehoert der Debugger
ähem...
Mal ne bescheidene Frage: Was für Bugs findest du denn üblicherweise mit
dem Debugger in deinen Programmen?
Mich würde mal interessieren, was für Fehler all diejenigen so machen,
die zum effizienten Arbeiten einen Debugger brauchen.
W.S.
Hallo,
ich hatte in meinem Projekt die STM32 Firmware Library im Keil-Ordner
umbenannt, so dass die IDE die Dateien nicht mehr finden konnte. Dann
habe ich die neuere Version der Firmware Lib ganz normal ins Projekt
eingefügt und damit gearbeitet.
Dann hatte ich zwar den Keil Editor+Debugger, aber eben auch nicht mehr.
Die ganzen Einstellungen (Taktfrequenz etc.) fehlten entsprechend.
Gruß,
Svenska
... welche "Fehler" findet ein Arzt mit einem Roentgengeraet? Natuerlich
kann ich einen Knochenbruch auch ohne Roentgen erkennen, ich muss nur
lange genug "biegen",...
... wozu mit einer IDE arbeiten? Es geht doch genauso aus der
"Kommandozeile" heraus,...
... wozu einen Assembler (oder gar Compiler), es gibt doch Tabellen zum
uebersetzen,...
Bitte nicht missverstehen alle diejenigen deren Programme von Beginn an
fehlerfrei sind, bzw. die ihre Fehler auf den ersten Blick erkennen
benoetigen natuerlich keine solchen Hilfsmittel.
Manch andere allerdings sind froh, ob der Moeglichkeiten die ein
Debugger bietet. Aus meiner Sicht gestaltet sich damit eine
systematische Fehlersuche (voellig egal um welche Art von Fehler es sich
handelt) einfacher (und sinnvoller).
Das Erlernen einer Programmiersprache / Einarbeiten in eine neue
Architektur gestaltet sich meiner Erfahrung nach einfacher, wenn
Programme mittels Debugger getestet werden.
- Single Step Modus
- Haltepunkte (auch komplexer Art)
- Betrachten und Aendern von Speicherinhalten Speicherbereichen
Register Variablen ...
- Erkennen von "nicht gewollten" Speicherzugriffen
- Die Moeglichkeit Hardware zu simulieren
- Betrachten und Abarbeiten der "ursprünglichen Hochsprachenanweisungen"
in Assembler
- Code Coverage, Timing Analysen, Statistiken
... sind exemplarisceh Punkte fuer Moeglichkeiten die ein Debugger
bietet.
Wieso soll ich darauf verzichten? Ich messe meine Spannungen / Signale
doch auch mit einem Messgeraet / Oszilloskop - nichts anderes ist ein
Debugger.
Viele Gruesse
Winfried
und vieles mehr sind Dinge die ein Debugger ermoeglicht
