hallo arbeite mit winavr und möchte gerne zu meiner .c datei noch eine weitere einhängen um ein lcd anzusteuern. doch irgendwie geht das wohl nicht so einfach mit winavr. deshalb habe ich avrstudio4 installiert wo ich die zusätzlich .c datei problemlos einhängen und compilieren kann, allerdings verwende ich ein lpt1 programmierkabel und ich kann in avr studio nur usb und com anschlüsse angeben, warum auch immer? kann ich jetzt rein theoretisch mit avr studio compilieren und die so enstandene .hex datei mit winavr auf den eeprom des boards überspielen, denn dort kann ich lpt1 als schnittstelle angeben. was natürlich noch einfacher wäre, wenn ich alles mit winavr machen könnte, irgendwie muß es doch gehen, dass ich die 2. .c datei und die .h da mit einbinden kann, oder? habe mal gelesen, dass ich dazu das winavr makefile verändern muß, aber wie und an welcher stelle? bitte dringend um hilfe, ist eine projektarbeit, die ich in ein paar tagen abgeben muß.
>bitte dringend um hilfe, ist eine projektarbeit, die ich in ein paar >tagen abgeben muß Ich habe da meine Zweifel, daß du das schaffst, da du offensichtlich schon Probleme hast die Links auf dieser Seite durchzulesen oder die Suchfunktion in diesem Forum zu benutzen. Ganz zu schweigen vom einfachen reinschauen in das Makefile, in ein C-Buch oder in die Hilfe des Avrstudio's.
Deine Shiftatste ist kaputt. Zum Verständnis: AVRStudio hat gar keinen C-Compiler, und weder "WINAVR" noch AVRStudio können per Parallelport einen Prozessor flashen. AVRStudio benutzt den avr-gcc aus dem WinAVR-Paket als C-Compiler, und im WinAvr-Paket gibt es avrdude zum flashen. Ob du also mit AVRStudio oder "WinAVR" kompilierst, ist egal. Benutzt wird immer der selbe Compiler und Linker. Wie das mit dem makefile geht, steht oben links im Tutorial. Oliver
Danke für den Hinweis. Dann können wir das Forum ja schließen und holen alle wieder die Bücher raus und klemmen gleich noch den Netzzugang ab. Ich hoffe du bist jetzt mit der Schreibweise zufrieden, ansonsten schreib mir doch noch mal, dann werde ich versuchen mir noch mehr Mühe zu geben.
"möchte gerne zu meiner .c datei noch eine weitere einhängen um ein lcd anzusteuern." Warum nicht einfach mit #include: #include "myLCD.h" #include "myLCD.c" Das geht immer.
Ist ne Idee, dachte "Include" benutzt man nur bei der Einbindung von Headerdateien, bin noch Neuling in der C-Programmierung.Werds gleich mal versuchen.
tobhu wrote: > Ist ne Idee, dachte "Include" benutzt man nur bei der Einbindung von > Headerdateien, Ja, so ist es auch. > bin noch Neuling in der C-Programmierung. Offenbar noch weniger als Andreas.
Andreas Paulin wrote:
> Das geht immer.
Und meistens schief.
Wenns noch nicht schief geht, dann sind Deine Projekte nur noch nicht
groß genug.
Peter
Danke euch. Hab jetzt noch mal bei dem Makefile nachgesehen, anscheinend muß ich die 2. .c Datei dort nur bekannt geben, hoffe dass es dann geht.
@Peter: ;-) Nicht so neu, wie es scheint, aber ich habe erst über die AVR-Geschichten diese Makefiles kennengelernt. Komme aus der IDE-Ecke. Warum geht das meistens schief?
>Warum geht das meistens schief?
globale Variablen sind als solche erstmal nur auf eine C Datei
beschränkt.
Wenn du include verwendest wird die C-Datei in die andere eingefügt.
Damit kann es bei gleichen Namen zu Überschneidungen kommen.
In C-Dateien sind normalerweise include mit Header-Dateien
Diese würden bei der anderen auch eingebunden. Dabei kann es zu
Überschneidungen kommen.
@Wolfram: Die Funktion von #include ist mir schon bekannt. Klar: Alle globalen Variablen sind dann im ganzen Projekt sichtbar. Getrennt kompilieren und DANN linken ermöglicht separates scope auf Sourcedateiebene für separate Sources. Geht aber doch auch ohne: Muss ich halt Disziplin bei der Namensvergabe halten. DAS muss ich natürlich im Auge behalten. Klar ;-) Ich nutze halt minimal globale Var. in den #includes und wenn, dann ausgiebig Prefixe, z.B. LCD_uiLineptr LCD_uiColptr LCD_ucWasweissich @ Peter: Und ich muss Dir recht geben: Diese flat structure mag wirklich bei echt großen Sachen Probleme machen, weil die Randauswirkungen unübersehbar sein können. Und dass es Chaos gibt, wenn ich mal kurz ne Source vomn Kollege mit einbinden muss, wenn der gleiche VarNamen vergibt - d' accord!! Meine Projekte sind meist nicht sooooooo riesig, dafür habe ich immer mal wieder - Ein neues Display am µC (ständige Änderung) - Eine andere IIC-Busansteuerung (ständige Änderung) - die RS232 muss in Software, weil µC keine HW dafür hat (ständige Änderung).................. Panta rei. Und DAS ist bis dato mein Ressort. Und dafür klappts gut mit direkter Einbindung per #include. Es gab für mich immer 2 Möglichkeiten: Via library oder direkt via #include. Makefiles hatte ich ja nie ;-) Wenn Du aber an einer Source rumfrickelst (hier z.B.: LCD) und der Code sich ständig ändert, ists blöd, da jedesmal eine Library draus zu generieren, um diese dann dazuzulinken. Muss ich ja mit nem Extraprojekt erst die lib generieren und dann im anderen Projekt diese einbindem ächz Aber - tx2all: Gut, das Scope-Thema mal wieder unter neuem Vorzeichen angerissen zu haben... werde mal drüber nachdenken. Via Makefile scheint ein neuer - guter - dritter Weg zu sein............... -> back to thinktank ;-)
Noch einmal vielen Dank, habe das Makefile geändert, mußte nur die .c Datei einbinden unter "SRC = $(TARGET).c lcd.c" und siehe da es läuft. Muß zu meiner Schande gestehen, dass das doch nicht so schwer war und ich wirklich nur im Skript zu WinAVR hätte nach lesen müssen. Sorry für die vielen Mühen.
@tobbu: Ja so ists richtig :D Übrigens: "#include" tut NICHTS anderes, als simpel den Inhalt der inkludierten Datei einzulesen und in die Datei an dem Ort einzufügen, wo das "#include" auftaucht. Quasi Copy+Paste. Und zwar vor dem Kompilieren.
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.