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
Entschuldigt, ich habe oben zwei Absätze vertauscht. Bitte den 4. Absatz von unten zwei Absätze nach oben schieben ;) Danke
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
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.