Grundsätzlich eine Frage ans Forum: Ausgangslage: Es werden zu Unterweisende (die niemals zuvor eine Programmiersprache, geschweige denn C oder C++ angefasst) in die einfachsten Grundlagen von AVR Programmierung mit C eingeführt. Nun habe ich relative Schwierigkeiten, am Anfang den Zusammenhang zwischen Präprozessor, Compiler und Linker zu erklären. Wird der Präprozessor noch mit dem Erklärungsmodell eines "suchen und ersetzens" verstanden ist das mit dem Linker schon etwas "schwieriger" und grundsätzlich wird hinterfragt warum man ÜBERHAUPT etwas aus seinem Quellprogramm "auslagert". Damit die ersten Schritte auch mit Lernerfolgen gekrönt werden können, laß ich beim Erklären (mit dem Hinweis darauf, dass diese Methode bei größeren Programmen auf ihre Grenzen und Schwierigkeiten stößt) den Linker einfach weg (bzw. das Erklären desselbigen und die zu Unterweisenden verwenden nur ein Script bei dem durch ein Menü gesagt werden kann, ob es Gleitkommazahlen und printf für Gleitkommazahlen hinzufügen soll). Ein Aufteilen (und ich weiß dass das eigentlich eine Todsünde in C ist) von Funktionalitäten geschieht dann "einfach" dadurch, dass eine Datei (immerhin schön unterteilt in Defines, Prototypen und danach die Funktionen) erstellt wird die mittels eines: #include "meinefunktion.c" eingebunden wird. Hier ist "meinefunktion.c" KEINE kompilierbare Datei, sondern schlicht so angeordnet, als wäre sie in der Hauptdatei geschrieben. Das hat beim Erklären den Vorteil, dass ich anfänglich nur minimal mit einem Programmgerüst anfangen muß, erste Dinge in der "main" zeigen kann und um die vielen Dinge drumherum erst später eingehen werde. Es sei noch mal angemerkt, dass das Zusammenspiel zwischen Compilevorgang und Linkvorgang zu einem späteren Zeitpunkt gezeigt wird. Ist sowas legitim oder sträuben sich da dann doch zu arg die Haare ? Gruß, Ralph
Ralph S. schrieb: > Ist sowas legitim oder sträuben sich da dann doch zu arg die Haare ? warum sollte man dann überhaupt mit dem Aufteilen anfangen? Lass doch am Anfang alles in einer Datei. Dann braucht man den linker auch nicht wirklich aufzurufen sondern kann direkt das binary erzeugen. Wenn es dann an der Zeit ist, das das Projekt größer wird dann erklärt man es gleich richtig.
Ralph S. schrieb: > Ist sowas legitim oder sträuben sich da dann doch zu arg die Haare ? man tut was man muss.... im AVR Studio ist es ein leiches die meinefunktion.c ins Projekt zu legen. in der Arduino IDE 1,05 geht das nicht so leicht, ich nutze eben #include "meinefunktion.c"
Mach dir doch nicht so einen Kopf und fange klein an. Also das ganze C-Programm kommt in eine Datei und oben sind die notwendigen Systemlib mit Include eingebunden. Dann kannst du ihnen für den Anfang ein Makefile bereits stellen oder du lässt sie gcc zum compilieren und linken von Hand ausführen. Mögen deine Teilnehmer lästig finden, aber das übt und lässt sie sich später mit Freude auf eigene Makefiles stürzen. Eigene Libs oder aufgeteilten Code würde ich da erst einführen, wenn du Arbeitsgruppen bilden möchtest, um die Aufgaben in den Arbeitsgruppen schön aufzuteilen. Aber ich denke, mit den Grundlagen von C und der Bedienung des AVR sind die in den ersten Tagen gut ausgelastet.
mir sträuben sich nicht nur die haare, mir steigt die zornesröte ins gesicht!!! erkläre die funktion des präprozessors korrekt, oder unterlasse das "unterrichten" ganz. einen bullshit wie 'include "bla.c" zu verzapfen ist sträflich. mit so einem müll muss man sich hier im forum schon genug rumärgern.
Marek Walther schrieb: > Dann kannst du ihnen für den Anfang ein Makefile bereits Im Moment mach ich das auch so ... Marek Walther schrieb: > Aber ich denke, mit den Grundlagen von C und der > Bedienung des AVR sind die in den ersten Tagen gut ausgelastet ... genau das ist der Grund, warum ich den Linkvorgang erst einmal weglassen mag ! Joe F. schrieb: > mir sträuben sich nicht nur die haare, mir steigt die zornesröte ins > gesicht!!! smile, mir sträuben sich nur die Haare (ohne Zornesröte) und genau deshalb frag ich hier ja auch nach. Die ersten Versuche, den Linker zu erklären schlug fehl, weil die Gruppe schlicht erst einmal zuhören muß und die relativ schnell "abschalten". Die Vorgänge haben da schlicht noch nichts mit dem AVR zu tun (und leider kommt immer die Frage, wann man etwas sehen kann. Es reicht ihnen scheinbar nicht, wenn man ihnen einfach ein Programm vorführt, welches funktioniert). --------------------------------- Nur mal so: bisher hab ich den Linker erklärt, aber es dauerte immer, bis die selbst etwas zustande gebracht haben. Meine Vorgehensweise bisher war: - zeigen eines Programms wie es auf dem AVR läuft - zeigen der Dateinamen welche daran beteiligt sind - erklären dass ein compilieren KEIN lauffähiges Programm erzeugt, sondern eine linkbare Datei - (das schwierige jetzt): Kommandozeilenparameter von AVR-GCC - kompilieren aller einzelnen Dateien - linken - elf2hex - upload ---------------------------------- jetzt ... bin ich eben auf der Suche nach einem besseren Konzept um eben schneller ein Erfolgserlebnis vermitteln zu können !
Ralph S. schrieb: > #include "meinefunktion.c" Es geht doch nicht um einen Ritus zur Verehrung des C-Gottes. Wenn das Bedürfnis nach Änderungen besteht, kann man ein Computerprogramm anpassen. Wenn du die Konventionen einhalten willst, definier dir einen neuen Dateityp, z.B.: > #include "meine_unterfunktion.sub" wenn nicht, nimm > #include "meinefunktion.h" Grotten-C, vereinfacht aber den Umgang mit C erheblich, da der Programmaufbau hierarchisch ist. schlecht ist nur: > #include "meinefunktion.c" weil damit die Datei - bei manchen Compilern - selbständig und unkotrolliert - compiliert wird. Das führt bei der Verwendung von globalen Variablen zu völlig unnötigen Problemen, die Anfänger weder verstehen noch interessieren.
Ich denke nicht, dass #include nur dazu genutzt werden darf, Header Dateien einzubinden. Das ist lediglich der gewöhnliche Anwendungfall. Ich habe zum Beispiel einen Codegenerator, der Binärrdateien einliest und daraus Ketten von hexadezimalzahlen generiert und als Plain-Text Datei ablegt. Diese binde ich mitten im Source Code mit #include ein, um daraus Arrays zu machen. Klappt prima und ich sehe keinen grund, warum man das nicht machen sollte. Ich habe nichts gegen Ausnahmen, solange der Programmcode gut lesbar bleibt. Man sollte es nur nicht übertreiben.
Include von .c Dateien hat nur wirklich nichts mit C-Programmierung zu tun. Wie wäre es, Dein Halbwissen mit der Lektüre eines guten Buches zu ergänzen: http://www.amazon.de/Programmieren-C-Reference-Manual-deutscher-Sprache/dp/3446154973 Das Geld sollte es Dir Wert sein.
Ralph S. schrieb: > Damit die ersten Schritte auch mit Lernerfolgen gekrönt werden können, > laß ich beim Erklären (mit dem Hinweis darauf, dass diese Methode bei > größeren Programmen auf ihre Grenzen und Schwierigkeiten stößt) den > Linker einfach weg Das ist, wie wenn du beim Erklären der Funktionsweise eines KFZ-Antriebs einfach das Getriebe weglässt. Man kann sich zwar schon vorstellen, dass das geht, aber man kommt schnell drauf, dass "irgendwas fehlt". > Nun habe ich relative Schwierigkeiten, am Anfang den Zusammenhang > zwischen Präprozessor, Compiler und Linker zu erklären. Mir fehlt hier der wichtige und oft unsichtbare Zwischenschritt "Assembler". Denn man kann sich den vom Compiler erzeugten Code ja durchaus mal anzeigen lassen und bewerten... > Es sei noch mal angemerkt, dass das Zusammenspiel zwischen > Compilevorgang und Linkvorgang zu einem späteren Zeitpunkt gezeigt wird. > > Ist sowas legitim oder sträuben sich da dann doch zu arg die Haare ? Es ist ein unnötiger umständlicher Umweg. Warum machst du nicht zu Beginn einfach nur solche Projekte, die ein "Aufteilen" oder "Einbinden" überhaupt nicht brauchen?
grundschüler schrieb: > Ralph S. schrieb: >> #include "meinefunktion.c" > > Es geht doch nicht um einen Ritus zur Verehrung des C-Gottes. Wenn das > Bedürfnis nach Änderungen besteht, kann man ein Computerprogramm > anpassen. Nein es geht um die Vermittlung einer elementaren Grundlage: Trennung von Interface und Implementierung. Das ist kein sinnloser Ritus, sondern solche grundlegenden Konzepte sind meist das einzige was noch zwischen uns und der (Code-)Hölle steht. Anfängern etwas anderes beizubringen ist töricht.
Ralph S. schrieb: > Nur mal so: bisher hab ich den Linker erklärt, aber es dauerte immer, > bis die selbst etwas zustande gebracht haben. es reicht für den Anfang völlig, wenn sie wissen, dass es ihn gibt. Mehr brauchen sie bei den ersten Projekten nicht wissen. Den Linker braucht man, damit all die vorgefertigten Funktionen mit zum Programm dazukommen, die in der sog. Runtime Library zusammengefasst werden. Also die Implementierungen für Sinus; die String Funktionen; die ganzen Funktionen, die Arithmetik abhandlen; printf; ..... der Vorgang
1 | Source Code (zb a.c) Source Code (zb b.c) |
2 | | | |
3 | v v |
4 | +--------------+ +--------------+ |
5 | | Preprozessor | | Preprozessor | <---- Header Files (zb. a.h) |
6 | +--------------+ +--------------+ |
7 | | | |
8 | v v |
9 | Zwischencode Zwischencode |
10 | | | |
11 | v v |
12 | +--------------+ +--------------+ |
13 | | eigentlicher | | eigentlicher | |
14 | | Compiler | | Compiler | |
15 | +--------------+ +--------------+ |
16 | | | |
17 | v v |
18 | Object Code Object Code |
19 | | | |
20 | +----------+ +-------------+ |
21 | | | |
22 | v v |
23 | +---------------+ |
24 | | Linker | <------ System Libraries (zb. fertige Implementierung |
25 | +---------------+ für sqrt oder printf |
26 | | |
27 | v |
28 | fertiges Program |
sollte so schwer nicht zu erklären sein bzw. nicht viel Zeit in der Durchbesprechung verschlingen. Mehr brauchen sie am Anfang nicht wissen. Insbesondere alle Aufrufparameter braucht man am Anfang wirklich nicht kennen. Die wichtisten reichen völlig. Wichtig ist, dass sie das Konzept verstanden haben. Wenn sie am Anfang mit von dir vorgegebenen makefiles arbeiten, dann ist das völlig ok. Gerade am Anfang hat man in der AVR Programmierung Programme, die kleiner als 1, maximal 2 Bildschirmseiten sind. Dazu braucht man nicht mehrere Compile-Pfade. Aber den Linker einfach wegzulassen ist keine gute Idee. Zumindest konzeptionell sollte man schon wissen, dass es diesen Schritt gibt und was dort passiert. Wenn sie wissen, dass dort die unabhängig voneinander compilierten Einzelteile, zusammen mit den bereits fertig übersetzen Teilen aus der Runtime-Library zusammengeführt werden, dann genügt das völlig. Schreib in dem Diagramm noch die typisch benutzten Command Line Argumente dazu, und dann sollte eigentlich jeder in der Lage sein, mit einem Ausdruck dieses Diagramms an der Seite ein einzelnes C-File korrekt bis zum fertig Programm durch den Prozess durchzuschleusen.
:
Bearbeitet durch User
Man sollte Anfängern nicht erklären, was technisch alles geht. Aus meiner Sicht sollte man von Anfang an auf das übliche Vorgehen beschränken und so von Anfang an auf ein ordentlichen Programmierstil hinarbeiten. Immerhin schauen Anfänger häufig in fremden Code und sollen sich dort auch zurechtfinden.
Wenn es Code für sehr kleine Maschinen (sagen wir PIC16 oder 8051) ist macht es doch durchaus Sinn alles aus dem Präprozessor rauszuholen, nicht nur über #include sondern vor allem auch über #define/#ifdef- wenn man da mit Bibliotheken arbeitet stopft man sich nur den Programmspeicher und viele Zyklen mit totem Code von Funktionen zu bei denen bestimmte Parameter eigentlich IMMER letztendlich aus einer Konstanten übergeben werden und daher eigentlich Konfiguration und keine Parameter sind. Vorsicht ist aber geboten wenn man mit Makros Makros definiert ... da benehmen sich zB ein älterer sdcc-Präprozessor oder der gnu-cpp in Details sehr unterschiedlich.... Rausfinden ob irgendwas "selbständig und unkontrolliert" kompiliert wird ist sehr einfach - einfach dafür sorgen dass der Inhalt der inkludierten Datei ohne den Kontext des #include-Statements syntaktisch ungültig ist, zB in dem man eine Kontrollstruktur über beide Dateien aufteilt ;) Oder aber man schreibt sein Makefile oder Buildskript so dass die Quelldatei auf jeden Fall erstmal durch den cpp gedreht wird!
Steffen Rose schrieb: > Immerhin schauen Anfänger häufig in fremden Code Jeder Programmierer schaut häufig in fremdem Code.
>Es werden zu Unterweisende (die niemals zuvor eine Programmiersprache, >geschweige denn C oder C++ angefasst) in die einfachsten Grundlagen von >AVR Programmierung mit C eingeführt. Meiner Meinung nach geht es am Anfang darum, Hürden abzubauen. Stichwort ist "implizites" und "explizites" Lernen. Den Ablauf von Editor, Präprozessor, Make, Linker etc. zu erklären ist ganz klar explitites lernen und führt auf den ersten Metern bei den Zuhörern nur zu der Frage "Und wozu?" Sie können nicht einordnen, was sie hören und so verschwindet es bei vielen gleich im Nirvana. Ich würde es für besser halten ein paar einfache "Hands-On" Beispiele zu machen. DDR'n' und PORT'n' setzten und leuchten lassen. Vielleicht was fertiges nur verändern. Dann blinken lassen. Dann mal von nem einfachen 8 Bit Timer Datenblatt lesen lassen. Dann mittels Timer blinken lassen. Wenn dann ein erster aha Effekt da ist, würde ich hinter die Kulissen schauen. Das Gehirn lernt bei völlig neuen Bereichen erstmal besser Implizit. Jedes Sprachbuch fängt mit "Ich bin..." "Ich komme aus..." an, ohne gleich Grammatik zu erklären.
Wissensvermittlung oder Abschreckung und Verunsicherung? Falls letzteres das Ziel ist, dann ist es sinnvoll mit den ganzen Details anzufangen, vorzugsweise noch alles auf Händen und Knien auf der Kommandozeile erledigen lassen. Sonst reicht für den Anfang das Wissen, das es das alles gibt aber momentan die Standardeinstellungen und eine einzige C-Datei reichen. Lieber zuerst einige einfache Aufgaben durcharbeiten lassen und dabei auf einen sauberen Stil (Lesbarkeit, vernünftige Kommentierung usw.) achten.
"Man sollte Anfängern nicht erklären, was technisch alles geht." Doch. Zumindest sollte man niemals sagen "es geht nicht" wenn es technisch geht, das ist dann Unwissensvermittlung.
Ähhmmm, ihr wisst aber, dass der Linker mehr macht, als nur die OBJ zusammen zu packen? Wie kommen wohl die absoluten Adressen in das Maschinen Programm? Ohne Linker geht es nicht!
Wenn das Ziel ist irgendwann man schlechte Programmierer zu haben, dann ist #include "meincode.c" eine richtig gute Idee. Aber sowas von richtig gut ... Alternativ, wenn einem sonst nichts einfällt, und man nicht weiß was man da eigentlich unterrichtet, kann man einfach die ersten Abschnitte aus dem ersten Kapitel aus dem K&R präsentieren. Die sind einfach gehalten, dass sollte auch den Lehrenden nicht überfordern.
@Jay ein guter C-Programmierer wird einsehen dass manche in einer "void main()"-Umgebung sehr sinnvolle Vorgehensweise in einem portablen Programm das oberhalb eines Betriebssystems laufen soll nichts zu suchen hat und vice versa.
Präprozessor? Compiler? Linker? AVR? Im Studio nen leeres Projekt anlegen und auf den Build Knopf drücken und unten kommt das Compilat raus. Klingt irgendwie dumm aber wir haben 2015 und nicht 1995. Klar kann man erklären, was es mit den #include Zeilen auf sich hat die per Default mit eingefügt werden. Aber interessant ist das nur am Rande - für den Einstieg. Wichtig ist doch erstmal, dass das "Hello World" klappt und man vermittelt, was man mit dem neuen Spielzeug alles so anstellen kann. Und schrittweise wie man das geschickter macht. GCC habe ich zuletzt von der Kommandozeile auf meinem Amiga benutzt, zwar OS4 und PPC aber dennoch Jahre her, da bestand meine Anwendung auch aus 18 Modulen mit zusammen über 20k Zeilen Quelltext und nem Haufen .h Dateien dazu. Da machte es dann auch noch ein wenig "Sinn", in welcher Reihenfolge man im Makefile die Objekte zusammengepuzzelt hat um die resultierende Binär-Datei zu optimieren. Für die AVRs habe ich noch nie ein Makefile schreiben müssen und normalerweise habe ich auch nur eine Objekt-Datei, vielleicht mal zwei. Auf dem Weg zum Techniker hatte ich nen Kurs Software-Entwicklung, soweit ich mich erinnern kann hat der Dozent nichtmal erwähnt, dass es sowas wie einen Linker gibt und auch der Prä-Prozessor war eher nicht interessant. Wichtiger war ihm die Elemente der Sprache C richtig rüber zu bringen und was man damit anfangen kann.
Rudolph schrieb: > Im Studio nen leeres Projekt anlegen und auf den Build Knopf drücken und > unten kommt das Compilat raus. und dann stehen die Leute dumm da wenn es eine Fehlermeldung gibt (Symbol nicht gefunden) und verstehen nicht was sie falsch gemacht haben. Jeder C Entwickler sollte von Hand ein Programm bauen können, wenn er das verstanden hat darf er es auch mit der IDE machen.
Besonders "spaßig" ist das Debuggen bzw. Verändern von Programmen mit solchen #include "xxx.c" Konstrukten. Wenn man da mal 20 und mehr Quelldateien hat, wird das Ganze zum unentwirrbaren Mikado. Ich durfte mich vor einiger Zeit mal mit so etwas herumschlagen, solch ein Paket fasse ich nicht mal mehr mit der Kneifzange an.
Hallo, ich halte das Einbinden von *.c-Dateien per Include auch für sinnlos, besonders um die Elemente des Compilers, Linkers, ... zu erklären. Peter II schrieb: > und dann stehen die Leute dumm da wenn es eine Fehlermeldung gibt > (Symbol nicht gefunden) und verstehen nicht was sie falsch gemacht > haben. > > Jeder C Entwickler sollte von Hand ein Programm bauen können, wenn er > das verstanden hat darf er es auch mit der IDE machen. Jop, das sollte evtl. so sein, jedoch nicht als erster Schritt. Erstmal die Sprache selber mit ihren Fallstricken, dann der Weg über Hand. Wenn überhaupt. Soll heißen die Standard-Includes werden eben angesprochen als "hier wird eins zu eins der Code aus dem File übernommen, den braucht das Programm um die verwendeten Funktionen und Variablen zu definieren", ansonsten geht es ans "Hello world" und wen interessiert hier erstmal der Linker? Besonders weil einmal gelerntes schwer wieder zu verlernen ist. Die machen das dann weiterhin so, auch wenn du später dann sagst: "das ist aber eigentlich schlechter Stil, hier werden nur Header-Files eingebunden" Fazit: Lass es!
Michael schrieb: > Besonders weil einmal gelerntes schwer wieder zu verlernen ist. Genau so ist es. Das und die Unterscheidung welche Fehlermeldungen vom Compiler und welche vom Linker kommen und warum. So ganz kommt man also um die Funktionsweise eines Linkers nicht rum, auch wenn am Anfang eine ganz einfache simple Erklärung reicht. Sonst kann man eine Fehlermeldung "undefined reference" einfach nicht richtig deuten. Hat man nur ein Source Code File, dann kann man sich noch retten. Aber spätestens wenn dann irgendwann doch mehrere C-Files im Spiel sind, muss man zumindest prinzipiell wissen, wo so eine Fehlermeldung aus welchem Grund entsteht.
Karl Heinz schrieb: > Aber spätestens wenn dann irgendwann doch mehrere C-Files im > Spiel sind, muss man zumindest prinzipiell wissen, wo so eine > Fehlermeldung aus welchem Grund entsteht. Das ist richtig, aber wenn man an dem Punkt ankommt ist es ja nicht zu spät noch was neues zu lernen. Und auch eine neue Fehler-Meldung schraubt den Kopf nicht ab. Komisch, in meinem alten Kernighan/Ritchie steht "Linker" nicht mal im Inhaltsverzeichnis. Und der C-Preprozessor taucht in Kapitel 4.11 ab Seite 86 auf.
Rudolph schrieb: > Karl Heinz schrieb: >> Aber spätestens wenn dann irgendwann doch mehrere C-Files im >> Spiel sind, muss man zumindest prinzipiell wissen, wo so eine >> Fehlermeldung aus welchem Grund entsteht. > > Das ist richtig, aber wenn man an dem Punkt ankommt ist es ja nicht zu > spät noch was neues zu lernen. > > Und auch eine neue Fehler-Meldung schraubt den Kopf nicht ab. > > Komisch, in meinem alten Kernighan/Ritchie steht "Linker" nicht mal im > Inhaltsverzeichnis. > Und der C-Preprozessor taucht in Kapitel 4.11 ab Seite 86 auf. Weil man bis dahin locker ohne Präprozessor und noch viel viel länger ohne Wissen über einen Linker auskommt. Und "was neues" zu lernen ist das eine, was "umzulernen" das andere - wenn ich mich zurückerinnere, wie das war, als wir das gelernt hatten... Etwas falsches wird auch zu Demo- oder Vereinfachungszwecken nicht richtiger, auch wenn es vielleicht funktioniert. Ich denke dass die meisten Programme bis hin übers Tutorial hinaus (und ein Unterricht mit den Grundlagen wird ws. nur ein ähnliches Stoffgebiet abdecken?), kommt ohne den Linker aus und sollte sich mit den wesentlichen Dingen bei der Programmierung selber beschäftigen, nicht mit dem Weg, der dahintersteht. (Kommandozeile höchstens in einem Aufbaukurs!!!) AVR Studio auf, Projekt aufsetzen und "Übertragen" drücken kann auch schwer genug für einen Anfänger sein, siehe diverse Threads dazu) LG
Rudolph schrieb: > Komisch, in meinem alten Kernighan/Ritchie steht "Linker" nicht mal im > Inhaltsverzeichnis. Die Jungs beschreiben ja auch die Sprache C mit ihren Syntaxelementen. Sie sagen aber nicht, wie man den Code compiliert und aus dem Compilat eine irgendwie irgendworauf ausführbare Datei machen könnte...
Angehängte Dateien:
-
avride1.jpg
110 KB -
avride2.jpg
130 KB
Guten Morgen, ich hatte gestern eine Unterrichtseinheit gehalten und den "richtigen" Weg mit Compilieren UND linken am Beispiel einer (vorgefertigten) seriellen Minilibrary, Header und bedingter Compilierung durch Präprozessor (Auswahl der Registernamen in Abhängigkeit des gewählten Controllers). Es hat die ganze Einheit benötigt bis das gesessen hat. Aaaaaber, ich werde eure Kommentare und Anmerkungen beherzigen und bei der Einführung es eben doch MIT Präprozessor und Linker machen. By the way: Das ganze geschieht NICHT mit dem Atmelstudio, es läuft unter Linux, noch mit Geany und damit die Vorgänge "deutlich" werden, wird der Aufruf von AVR-GCC auf der Konsole von Hand eingegeben (mit einer Liste, welche Parameter AVR-GCC besitzt). Auch die zu Unterweisenden waren der Meinung, dass, wenn man schon mal etwas nach einer bestimmten Methode hinbekommen hat, es so sein kann, dass man zu faul ist, es anschließend "richtig" zu machen. Am zweiten Beispiel war der Vorteil der "richtigen" Methode deutlich geworden: - Hauptprogramm bindet Library "coldisplay" zum Ansprechen eines Farbdisplays ein - eine weitere Library kann eine PCX Grafik darstellen und benötigt hierfür eine Funktion "putpixel" die auch in "coldisplay" vorhanden ist. Hier konnte sehr gut demonstriert werden, WARUM im Header KEINE Variablen deklariert werden dürfen, was ein extern uint16_t rgb565; ist und was passiert, wenn man bspw "coldisplay" nicht hinzulinkt, und dass ein "undefined reference" letztlich ein fehlender Code oder fehlende Variable ist und der Linker deswegen keine Adresse zu selbigem hat. Die zur Unterrichtung entstehende TUI - IDE ist hierfür nun geändert (siehe Bilder). Es kann nun ein einzelner Übersetzungsvorgang gestartet werden oder ein "Compile & Link". Die Linkeroptionen bietet die Möglichkeit, Dateien, die dazugelinkt werden sollen anzugeben. Hier wird es dann so sein: ist eine C-Datei angegeben wird diese logischerweise vor dem Linken übersetzt, ist eine o-Datei angegeben wird diese "einfach nur" hinzugelinkt ! --------------------------------------------------------------- An vorherige (bisweilen auch höchst bissige und abfällige) Kommentare: Mir ist sehr bewußt, dass ich bestimmt nicht ALLES weiß, aber ich denke schon dass ich genug weiß um jemand anderem C-Programmierung beizubringen. Ob man das nun Halbwissen nennen soll weiß ich nicht. "Witzig" finde ich, dass es von einigen Forumsmitgliedern schon mal grundsätzlich "abfällige" und vor allen Dingen beleidigende und persönlich beleidigende Kommentare gibt (von Mitgliedern, die wenn man liest, wohl fachlich extrem qualifiziert sind, menschlich aber absolut versagen). Ich finde so etwas unglaublich (und vor allem extrem unhöflich). Deshalb gilt hier mein besonderer Dank denen, die hier sachlich Kommentare angebracht haben und die vor allen Dingen verstanden haben, dass es in der Frage darum ging, wie man dieses Thema rüberbringt und nicht, wie etwas "RICHTIG" gemacht wird. Für mich ist die Frage, ob man aus didaktischen Gründen ein "#include blafasel.c" verwenden darf mit einem klaren "NEIN" beantwortet und ich werde das so auch nicht unterrichten, sondern eben weiterhin MIT einer normalen und richtigen "#include dateiname.h" Dieses wird hierfür in Zukunft sogar als aller erstes gezeigt werden, noch bevor eine einzige Zeile codiert wird, um Aufzuzeigen aus welchen Teilen ein fertiges Programm besteht. Beim Kapitel "call by reference" und dem Umgang mit den Pointern erhoffe ich mir, dass dort das Erklären einfacher sein (in Bezug auf übergeben einer Adresse)! --------------------------------------------------------------- Smile, mir ist bewußt, dass auch dieses Vorgehen manchen aufstoßen wird. Einfach nur irgendwo "klicken" und dann kommt der "Code" heraus finde ich im übrigen nicht richtig und deswegen wird die Kommandozeile auch noch eine Weile bestehen bleiben. Grundsätzlich wird es darauf hinauslaufen, das ganze prinzipiell OHNE X-Unterstützung zu bewerkstelligen und eine speziell zum Unterricht passende IDE verwendet werden wird.
Hallo, mich interessiert aus Neugier welcher "Art" deine zu Unterweisenden sind. Habe nicht vor, dir Tips zu geben. Ich frage mit dem Hintergrund, wie ich es im Studium erlebt habe. Da war Der Sprung für einige wohl recht weit, dass da ein schwarzes Ding mit Pins liegt wo ein Programm drauf läuft. Mir war das nicht neu, weil ich schon vor dem Studium in Eigenregie mit C-Control und dann mit Atmel Megas hantiert habe. Da dann ganz klassisch, wie der Bastler das macht. Blink-Blink und was juckt mich der Linker...
Die zu unterweisenden sind Auszubildende im Beruf: - Elektroniker für Geräte und Systeme - Physiklaborant und aus privater Initiative Real- und Gymnasialschüler 10. Klasse (die sich für Elektronik interessieren) ... in einer Art "AG". Kennzeichnend ist, dass alle niemals irgendetwas getan haben in Richtung Microprozessoren. Die Azubis Elektroniker wissen, was Widerstände, Kondensatoren und Transistoren sind, sie kennen Wechselstromwiderstände und Zeigerdiagramme. Außerdem kennen sie Grundwissen Operationsverstärker und logische digitale Verknüpfungen. --------------------------------- Aber wie bereits erwähnt werde ich nun die grundsätzlichen Zusammenhänge und das Zusammenspiel von Präprozessor, Compiler und Linker als allererstes machen !
PS: als "Spielzeug" (nach dem Steckbrett) gibt es das hier auf dem ihre Programme und Versuche laufen: http://www.mikrocontroller.net/attachment/244662/atmelboard_kl.jpg
Andy D. schrieb: > > "Man sollte Anfängern nicht erklären, was technisch alles geht." > > Doch. Zumindest sollte man niemals sagen "es geht nicht" wenn es > technisch geht, das ist dann Unwissensvermittlung. Einen Anfänger nicht mit Details zu überfrachten, die er mangels Zusammenhang noch garnicht versteht ist etwas anderes als etwas falsches zu vermitteln. Auf entsprechende Rückfrage kann man schon sagen, das vieles geht, aber die Erklärung erst später folgt.
Smile, ich hab mich ja bekehren lassen und werde das nicht tun ... und habe eigens dafür in der zu verwendenden Entwicklungsumgebung die Linkeroptionen doch eingefügt. Sie bekommen gesagt: - niemals Definitionen im Header außerdem: #infdef inmyheader #define inmyheader // Prototypen und bla bla #endif und sie müssen nur noch auf "additional files to link" damit diese Dateien später hinzugelinkt werden (hier werden dann, so es eine Quelldatei ist diese vor dem linken automatisch und immer erst übersetzt. Ist sie bereits übersetzt wird sie nur hinzugelinkt). Wenn das alles dann sitzt, lernen sie die Kommandozeilenparameter. Ich denke, damit werden doch wohl alle auch einverstanden sein !
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.