|
Anzeige
|
Fragen zu debuggen etc.
Gast
#2745932
hallo ich kann mir vorstellen, dass ihr die fragen schon tausende male gehört habt, aber was bedeutet eigentlich debuggen, programmer, brennen? braucht man das alles um ein µC zu programmieren? Ist denn debuggen und programmieren nicht, dass gleiche? und was ist eigentlich mit dem brennen. programmiere ich nicht ein µC, oder heißt das brennen, dass ich den Code irgendwo im µC brenne, wie eine CD. irgendwie bin ich benebelt. danke im voraus. MFG Tim
Gast
#2745946
Tim schrieb: > aber was bedeutet eigentlich debuggen, programmer, brennen? Der Begriff "debuggen" stammt aus der Zeit der Relaisrechner und heißt so viel wie "Käfer entfernen", weil die lieben Tierchen gerne die Kontaktzungen von Relais blockierten und damit die korrekte Programmausführung behindern. Im übertragenen Sinne wird der Begriff heute für jegliche Fehlerbeseitigung in Programmen verwendet.
Gast
#2746089
Aha...also debuggen überprüft den Code nach Fehlern. und der code, den man nun geschrieben hat, wie kommt auf den mikrocontroller? Indem man ihn brennt oder mit einem programmer oder mit Compiler? Falls es brennt kann man es wieder löschen? MfG Tim
Gast
#2746103
Eine von Menschen geschrieben Textdatei in eine Binärdatei (exe) für den Mikrocontroller umwandeln: Compilieren. Die Binärdatei dann auf den Mikrocontroller programmieren: Flashen oder brennen. (Nur wenn man möchte:) Den Mikrocontroller im Betrieb anhalten und Register und Speicherzellen auslesen oder manipulieren: Debuggen
Gast
#2746106
cccc schrieb: > Eine von Menschen geschrieben Textdatei in eine Binärdatei (exe) für den > Mikrocontroller umwandeln: Compilieren. Die Binärdatei für den µC erstellt erst der Linker. Mit exe hat das leider nichts zu tun - die wäre für den PC. Der Programmer braucht allerdings meist eine Hex-Datei, die er vor dem Schreiben in den Flash-Speicher in die entsprechenden Binärdaten umwandelt, nachdem er die Schreibadresse aus der Datei entnommen hat. Viele Mikrocontroller können sich auch selbst den Flash-Speicher brennen, wenn sie einen Boot-Loader besitzen. Ach ist das alles kompliziert ...
Gast
#2746455
>(Nur wenn man möchte:) >Den Mikrocontroller im Betrieb anhalten und Register und Speicherzellen >auslesen oder manipulieren: Debuggen Was bringt es denn wenn ich mein eigenen Code auf dem µC debugge? dann schreibe ich den Code gleich so hin, wie ich ihn habe möchte.
Gast
#2746460
Tim schrieb: > Was bringt es denn wenn ich mein eigenen Code auf dem µC debugge? dann > schreibe ich den Code gleich so hin, wie ich ihn habe möchte. Der ist gut! Irren ist nun mal menschlich, man macht Fehler beim Programmieren und muss letztere dann beim Debuggen entfernen. Es kann ja auch sein dass man das Datenblatt falsch verstanden hat oder irgendeine Peripherie nicht ganz so funktioniert wie es im Datenblatt steht.
Gast
#2746461
Du siehst dann, ob der Controller das macht was du dir gedacht hast ;) Was oft nicht der Fall ist. Kann sehr hilfreich sein um Fehler im Programm zu finden. Tim schrieb: >>(Nur wenn man möchte:) >>Den Mikrocontroller im Betrieb anhalten und Register und Speicherzellen >>auslesen oder manipulieren: Debuggen > > Was bringt es denn wenn ich mein eigenen Code auf dem µC debugge? dann > schreibe ich den Code gleich so hin, wie ich ihn habe möchte. Das "Problem" ist: Man programmiert meist in einer höheren Programmiersprache. Diese höheren Programmiersprachen wie z.B. "C" sind Interpretersprachen, d.h. der C-Compiler übersetzt den von dir geschriebenen Code erst in Maschinencode. Fehlerquellen sind logische Fehler bei der Programmeingabe oder unerwartetes Verhalten des vom Compiler generierten Maschinencodes(lernen, sich dem Compiler mitzuteilen, was man denn eigentlich will). Auch kann z.B. der Compiler fehlerhaft sein(das ist aber in seeeehr seltenen Fällen von Belang). Auch beim Assemblerprogrammieren gibt es manchmal logische Fehler, die zu einem vom Programmierer so nicht erwarteten Verhalten führen. Dann gibt es i.A. auch noch Fehler, die erst zur Laufzeit und/oder im Zusammenspiel des Controllers mit externen Bausteinen auftreten und manchmal auch nur bei bestimmter Stimulierung des zu testenden Systems auftreten. Um die Quelle dieser aller genannten Fehler zu entdecken, kann man natürlich -wie von dir vorgeschlagen- weitere Stunden seinen Code durchsehen und den Fehler nicht finden. Oder "herumstochern" und mit der Zeit alles kaputtfrickeln. Beim debuggen kann man sich alle Einzelschritte des Programms, Register, Variablen usw. ansehen und verändern. Damit findet man die genannten Fehlerquellen gezielt, schnell und reproduzierbar. Eine Möglichkeit des Debuggens "für Arme" ist eine simple serielle Schnittstelle. Darüber kann man logging-Daten zu Funktionsaufrufen und bei Bedarf Werte ausgeben und per Einlesen auch manipulieren. Dies ist aber mit Vorsicht zu genießen: Viele Systeme funktionieren mit logging-Ausgaben erstmal prima, ohne logging(nicht mit eincompiliert, "auslieferbare Version der Software") treten wildeste Fehlerszenarien auf, die wegen fehlenden Loggings nun nicht entschlüsselt werden können. So, ne Menge Text, aber ich hoff es ist jetzt etwas klarer. mfg mf
Gast
#2746611
vielen dank erst mal für die zahlreichen Erklärungen. >Beim debuggen kann man sich alle Einzelschritte des Programms, Register, >Variablen usw. ansehen und verändern. Damit findet man die genannten >Fehlerquellen gezielt, schnell und reproduzierbar. das klingt logisch...also kann man doch sagen, das debuggen so eine Art Simulation ist? MFG Tim
Gast
#2746688
Hi >das klingt logisch...also kann man doch sagen, das debuggen so eine Art >Simulation ist? Kann eine sein. Aber es gibt auch die Möglichkeit über eine Debugschnittstelle, z.B. JTAG, direkt im Contoller zu debuggen. MfG Spess
Gast
#2747907
>Kann eine sein. Aber es gibt auch die Möglichkeit über eine >Debugschnittstelle, z.B. JTAG, direkt im Contoller zu debuggen. ist das nicht bisschen riskant? man könnte doch µC zerstören, wenn man irgendwelche falschen befehle eingibt oder? gruß Tim schrieb: >>Kann eine sein. Aber es gibt auch die Möglichkeit über eine >>Debugschnittstelle, z.B. JTAG, direkt im Contoller zu debuggen. > > ist das nicht bisschen riskant? man könnte doch µC zerstören, wenn man > irgendwelche falschen befehle eingibt oder? Nein, kannst du nicht. Mit einem Programm kann man einen µC nicht zerstören (im Regelfall). Die Dinge, die du in Kinos siehst, dass jemand ein Programm in einen Computer eingibt und daraufhin steigt irgendwo Rauch auf und der Computer röchelt noch vor sich hin, ehe dann seine Stimme ganz langsam und matt wird - das sind Märchen, die Hollywood erfunden hat um etwas Dramatik in den Film zu bringen. Ein Computer arbeitet deine Befehle ab. Und zwar die Befehle, die du hingeschrieben hast. Ob diese hingeschriebenen Befehle dann auch tatsächlich das Verhalten ergeben, welches du dir vorgestellt und welches du erreichen willst, das steht auf einem ganz anderen Blatt. Ein Debugger ermöglicht dir, deinem Progamm bei der Arbeit zuzusehen. Und zwar während es arbeitet. Dies wird benötigt, sofern man das nicht alles am Papier macht, um festzustellen wo man seine Denkfehler gemacht hat und wo sich die gegebenen Befehle nicht mit dem decken, was man eigentlich erreichen möchte. Manchmal ist aus so einer Diskrepanz das Problem ziemlich offensichtlich, manchmal muss man auch etwas um die Ecke denken und manchmal muss man eben auch die genaue Befehlsreihenfole während der Verarbeitung studieren um Hinweise dafür zu erhalten, wo man sich geirrt hat.
Gast
#2749518
danke für die antworten. sehr hilfsbereit :) ich habe mir das AVR Studio 6 zugelegt. Benötige ich denn noch eine andere Software, um dem µC zu flashen bzw. zu brennen? und was ist denn mit "built" gemeint? So viele Wörter nur um ein µC zu "steuern". gruß Tim
Gast
#2749560
Nein AVR Studio 6 sollte genuegen. Debuggen wurde bisher etwas unrichtig erklaert, und bezog sich eher auf den PC, in einem controller kann man nicht den code anhalten und Register anschauen. Dh es gibt schone limitierte Moeglichkeiten. zB AVR DRagon, der aber auf 32k limitiert ist. Und das AVR Studio enthaelt auch einen Simulator fuer die trivialen Faelle. Aber meist ist der Prozess eh kaputt wenn man anhalten wuerde. Das bedeutet, dass meist die externe Umgebung das Timing vorgibt uns man sich daran halten muss. Je nachdem kann etwas zerstoert werden. Wenn zB eine Seilbahn gesteuert wird, darf man nicht einfach anhalten. Deswegen muss man meist im Betrieb debuggen. Die geschieht zB indem man uber das UART kommuniziert, und Zustaende ausliest, resp. setzt. Mein Tip, lass die kleine AVR sein, Unter einem Mega32 macht's keinen Sinn. Die Tinies und der Mega8 sind fuer extreme Kostensparer, die mit 1000er stueckzahlen arbeiten, und jeden Cent sparen muessen. Du machst dir keinen Gefallen mit einem Kleinen. Oha Tatsaechlich schrieb: > Aber meist ist der Prozess eh kaputt wenn man anhalten wuerde. Das > bedeutet, dass meist die externe Umgebung das Timing vorgibt uns man > sich daran halten muss. Da hast du recht. Das macht die Sache dann noch einen Tick schwieriger. Daher lautet die Empfehlung auch meistens, sich erst mal auf dem PC mit allgemeiner C-Programmierung sich die ersten Hörner abzustossen und erst dann in die µC-Programmierung einzusteigen. Allgemeine Programmierung und grundlegende Basisalgorithmen lernen sich auf dem PC einfach wesentlich besser als auf einem µC, auf dem man meistens erst mal sich selbst um Ausgabekanäle kümmern muss, damit man da überhaupt zur Laufzeit Werte ausgeben kann. Das sind Dinge, die auf dem PC aus dem Stand heraus funktionieren. Ganz abgesehen davon, dass man auf dem PC mit so ziemlich jedem C-Lehrbuch anfangen kann. Die IDE mag unterschiedlich sein, aber die Beispiele funktionieren genau so, wie sie im Buch abgedruckt sind.
Gast
#2749574
Hi >Dh es gibt schone limitierte Moeglichkeiten. zB AVR >DRagon, der aber auf 32k limitiert ist. Hast du ein paar Jahre geschlafen? Das stimmt schon lange nicht mehr. >Mein Tip, lass die kleine AVR sein, Unter einem Mega32 macht's keinen >Sinn. Die Tinies und der Mega8 sind fuer extreme Kostensparer, die mit >1000er stueckzahlen arbeiten, und jeden Cent sparen muessen. Mein Tip: Vergiss diese Dinosaurier. Aktuelle sind ATMega48/88/168/328P/PA oder ATMega164/324/644/1284A/P/PA. MfG Spess
Gast
#2749590
ok wenn ich mir jetzt einen AVR Dragon zulegen möchte und z.B. einen µC von mehr als 32KB Flash. Wäre der AVR Dragon micht in der Lage den µC zu debuggen, flashen wie auch immer? >...zB AVR DRagon, der aber auf 32k limitiert ist.... bist du dir sicher? ich habe hier was ganz anderes gelesen http://www.mikrocontroller.net/articles/AVR-Dragon >Ursprünglich hatte Atmel die Debugmöglichkeiten künstlich auf AVRs mit bis >zu 32 KB Flash-Speicher begrenzt. Mit einer mit AVR Studio 4.18 >mitgelieferten Dragon-Firmware wurde diese künstliche Einschränkung fallen >gelassen. Ist das nun machtbar oder nicht? gruß
Gast
#2749595
OK. spess53 kam mir zuvor :D
Gast
#2749601
Hi >wenn ich mir jetzt einen AVR Dragon zulegen möchte und z.B. einen µC von >mehr als 32KB Flash. Wäre der AVR Dragon micht in der Lage den µC zu >debuggen, flashen wie auch immer? Die Aussage von Oha Tatsaechlich (Gast) ist total veraltet. Der Dragon kann mit allen üblichen AVRs umgehen. Ausnahme sind einige ATTinys die TPI benötigen. >Ist das nun machtbar oder nicht? Ja. MfG Spess Oha Tatsaechlich schrieb: > Debuggen wurde bisher etwas unrichtig erklaert, und bezog sich eher auf > den PC, in einem controller kann man nicht den code anhalten und > Register anschauen. dann lies nochmal den Wikipedia-Eintrag zu JTAG Tim schrieb: > Ist das nun machtbar oder nicht? es ist machbar
Gast
#2750324
JTAG ist in vielen Faellen nicht brauchbar, denn es liegt oft auf der benoetigten Peripherie. Beim Mega32 lags auf portc, welches man als parallelen Bus verwendet. Anderswo liegt's auf dem ADC. Daher hab ich's noch nie verwendet. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
