Moin Leute, Ich habe folgendes Problem ich versuche grad ein Programm abzuändern, beim Compilieren kommt immer wieder der Fehler das GIMSK nicht deklariert ist!Ich habe bei AVR Studio bereits die Includes von WINAVR eingebunden. Includet hab ich die beiden Header <avr/io.h> und <avr/interrupt.h> Kann mir vielleicht einer von euch sagen wo das Problem liegen könnte? Hier der Programmabschnitt samt Fehlermeldung: void init_timer_interrupt (void) { // as tactful source for Timer1: CPU-Frequency // (adapt to time of rotation, column group) // TCCR1B = Timer/Counter Control Register B TCCR1B= (1 << CS00); // as tactful source for Timer0: CPU_Takt/8 (aim: 1ms) // TCCR0 = Timer/Counter Control Register // ClkIO/8 from presacler for Timer 0 TCCR0 = (1 << CS01); // Activate Timer0 and Timer1 as interrupt-source // TIMCK = Timer/Counter Interrupt Mask Register TIMSK = (1 << TOIE0) | (1 << TOIE1); // engaging extern Interrupt0 (sensor-signal) GIMSK = (1 << INT0); // dissolving the interrupts in case of growing shoulder // MCUCR = MCU Control Register // configured for Power Save MCUCR = (1 << ISC01) | (1 << ISC00); // enable interrupts sei(); } ../../../Desktop/Kreisel_080678-11/firmware_v1.0/kreisel.c:183: error: 'GIMSK' undeclared (first use in this function) ../../../Desktop/Kreisel_080678-11/firmware_v1.0/kreisel.c:183: error: (Each undeclared identifier is reported only once ../../../Desktop/Kreisel_080678-11/firmware_v1.0/kreisel.c:183: error: for each function it appears in.)
Jannes Borchers schrieb: > Moin Leute, > > Ich habe folgendes Problem ich versuche grad ein Programm abzuändern, > beim Compilieren kommt immer wieder der Fehler das GIMSK nicht > deklariert ist! was daran liegen könnte, dass der ATmega8 kein so Register besitzt...
JA dies hab ich auch schon gesehen, aber in anderen Beiträgen steht das es trotzdem funktioniert und mit dem GICR der beim Atmega8 das richtige wäre macht genau das gleiche!
Welche Beiträge wären das? Schau dir mal die iom8.h an; da wirst du kein GIMSK finden. Wenn irgendwer behauptet, es geht doch, dann hat er sich das Register an die Adresse eines anderen Registers (GICR o.ä.) selber mit nem #define zusammengeschustert oder nen falschen Controller gewählt.
Jannes Borchers schrieb: > und mit dem GICR der beim Atmega8 das richtige wäre macht genau das gleiche! kannst du das auch auf Deutsch schreiben? > JA dies hab ich auch schon gesehen, aber in anderen Beiträgen steht das > es trotzdem funktioniert Du weisst also, dass der Name falsch ist, setzt ihn aber trotzdem ein, und wunderst dich dann, dass du einen Fehler bekommst. -> Troll, bin weg...
Danke aber hab jetzt das Problem: C:\WinAVR-20090313\avr\include/avr/iom8.h:41:4: error: #error "Include <avr/io.h> instead of this file." C:\WinAVR-20090313\avr\include/avr/iom128.h:51:4: error: #error "Attempt to include more than one <avr/ioXXX.h> file."
1. Nur das <avr/io.h> includen, keine speziellen IO-Headerfiles 2. Schau ins Datenblatt und verwende den richtigen Registernamen für deine gewünschte Funktion.
Also soll heißen GICR wäre das richtige Register, aber es bleibt beim selben Fehler! Und da dies ein bereits fertiges Programm ist, das ich nicht geschrieben habe, wunderte es mich einfach, das ich es nicht Compilieren kann da ich auch vom orginal Programm eine HEX Datei zum programmieren mit diesem Programm habe und das Programm läuft!
Welcher Fehler bleibt? Wenn der Programmierer deines vorliegendes Codes das GIMSK auf den richtigen Namen/Adresse umdefiniert hat - wo auch immer - kann das Programm durchaus funktionieren.
Der vom Anfang mit dem nicht Deklariert. Und GICR müsste der richtige Befehl sein! Lasse mich aber gerne eines besseren belehren!
Na dann musst du halt GIMSK = (1 << INT0); in GICR = (1 << INT0); umändern. oder #define GIMSK GICR am Anfang der Datei schreiben.
Genau das hab ich ja getan und es hat sich nix geändert!
Doch dann muss die Fehlermeldung anders sein. Der Compiler kann kein GIMSK anmeckern, wenn keines da ist.
Dann hast du #include <avr/io.h> vergessen oder vielleicht in den Projektoptionen/Makefile den Atmega nicht richtig gewählt?
Hey danke hatten den Atmega8 nicht ausgewählt bei den Makefile. Erstellt das Programm eigentlich beim Compilieren eine Programmierbare Hex.datei??
Jain... Also unterm Strich hast du eine programmierbare Datei, ja (HEX oder was auch immer). Zu einem Compiler gehört auch immer der Precompiler und der Linker. Wenn das Makefile vollständig ist, werden immer alle drei aufgerufen und am Ende gibts das fertige Programm.
Okay kann es sein das ich damit ich er das Programm erstellt build benutzen muss??
Oh Kerl, schreib doch mal verständliche Sätze!
Also ich will nur das Programm mit VAR studio erstellen und mit einem zweiten Programm die HEX datei auf den Atmega8 spielen. Die Frage ist wie mache ich dies?
Ich drück bei mir im AVR-Studio auf F7 und hab alles was ich brauch; darunter auch die .hex. Müsste halt in den Project Settings auch eingeschaltet sein.
Wenn ich das tue,F7 drücken, bekomme ich 3 Fehlermeldungen: c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Warning: size of symbol `runden_nr' changed from 1 in Kreisel-de.o to 2 in kreisel-de-ct.o c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Hallo.elf section .text will not fit in region text c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: region text overflowed by 626 bytes
Für Fehler 1: Was ist denn runden_nr für ein Typ? Fehler 2 und 3 lesen sich fast, als wäre dein Programm 626 Bytes zu gross für nen ATmega8. Welche Optimierung ist denn drin? Hoffe doch mal schon -Os.
Wie bekomme ich das mit der Optimierung raus?? Und zu Fehler 1 es ist ein unsigned char.
>Wie bekomme ich das mit der Optimierung raus?? Die stellst du in den Projektoptionen ein. Such mal in den Menus. >Und zu Fehler 1 es ist ein unsigned char. In Kreisel-de.c ist die Variable ein Byte groß, in kreisel-de-ct.c gibt es aber eine mit gleichem Namen, aber 2 Byte Größe. Blöd. Oliver
So gut hab jetzt den Fehler behoben ;) Aber eine erneute Fehlermeldung :( gccplug-in: error: objectfile not found on expected location c:/dokumenteundeinstellungen/lehrer/eigenedateien/blub/default/blub.elf
Stimmt der Pfad so tatsächlich? c:/dokumenteundeinstellungen/lehrer/eigenedateien/blub/default/blub.elf Ohne jegliche Leerzeichen drin?
nein sorry hatte mich da vertippt. c:/dokumente und einstellungen/lehrer/eigene dateien/blub/default/blub.elf Das ist jetzt der richtige Pfad^^
@ Jannes Borchers (janpabo) >nein sorry hatte mich da vertippt. Patsch Wer sowas ABTIPPT ist einfach doof. Sorry, musste jetzt raus. Schon mal was von kopieren und einfügen gehört? Geht nicht nur einfacher und schneller, vermeidet vor allem solche Fehler. >c:/dokumente und einstellungen/lehrer/eigene >dateien/blub/default/blub.elf >Das ist jetzt der richtige Pfad^^ Tja, Pech. Einige ältere Programme verschlucken sich an Leerzeichen im Dateinamen. Für diesen Unsinn müsste Billy Boy auch eine Ohrfeige kassieren. MfG Falk
Mit Copy-Paste gestalltet sich schwierig da die Programmierumgebung nicht an diesem PC, sozusagen also nicht am Internet angeschlossen ist. Ich habe bereits einmal den Zielpfad und den Projectpfad auf C:/win_avr/ geändert und bekomme nun den Fehler: "Could not create Directory, bailing out...". Was bedeutet das?
>Einige ältere Programme verschlucken sich an Leerzeichen im >Dateinamen. Wird zwar gerne und häufig kolportiert, gehört aber doch eher in den Bereich der urban legends. Aber zum testen, leg mal ein ganz neues Projekt auf C:\irgendwas an, kopiere alle Sourcedatein da hinein, und probier es nochmal. Und überprüf mal, ob da nicht vor der gccplugin-Meldung noch andere Fehlermekdungen stehen (auch mal in den anderen Ausgabefenstern bzw. -tabs nachschauen) Oliver
Oliver schrieb: >>Einige ältere Programme verschlucken sich an Leerzeichen im >>Dateinamen. > > Wird zwar gerne und häufig kolportiert, gehört aber doch eher in den > Bereich der urban legends. Sicherer fährt man allerdings doch, wenn man auf derartigen Dateinamens-Unsinn, zu dem auch Umlaute und dgl. gehört, verzichtet. Sooo lange ist das noch gar nicht her, dass speziell Programmiertools lediglich auf 7-Bit ASCII, nach Möglichkeit ohne Sonderzeichen, gehört haben. Alles andere war Lotterie. (Auch die ersten CD-Brennprogamme haben sich bei sowas abenteuerlich verhalten :-) Unsere Vertriebsleute haben das auf die harte Tour gelernt :-) > Für diesen Unsinn müsste Billy Boy auch eine Ohrfeige > kassieren. Und die nächste kriegt er, wenn seine Mannen wieder einmal unbedingt meinen sie müssen mir diesen Pfad als Default beim File-Speichern vorschlagen anstatt sich den letzten Pfad, auf dem ich war, zu merken.
> "Could not create Directory, > bailing out...". > > Was bedeutet das? Das irgendein Tool ein Verzeichnis nicht erzeugen konnte. Steht doch da! Blöd nur, dass das Tool nicht hinschreibt welches Verzeichnis :-) > Ich habe bereits einmal den Zielpfad und den Projectpfad > auf C:/win_avr/ geändert Mach das nicht. Projektverzeichnisse u dlg. ändern kann sich in ein Nightmare ausarten. Du weißt nie, ob du alle im Projekt verwendeten Pfade hast oder nicht. Besser: Neues Projekt anlegen. Diesmal aber auf einem vernünftigen Pfad. Alle *.c und *.h dorthin kopieren. Zum Projekt hinzufügen. Compilieren Die Files die vergessen wurden und jetzt einen Fehler verursachen auch noch dorthin kopieren und zum Projekt hinzufügen. Fertig. Auch wenn sich das Prozedere jetzt aufwändig anhört, geht es doch in der überwiegenden Mehrzahl der Fälle schneller, als mühsam Konfigurationen an neuen Pfade anzupassen.
>Sicherer fährt man allerdings doch, wenn man auf derartigen >Dateinamens-Unsinn, zu dem auch Umlaute und dgl. gehört, verzichtet. Nun ja, den Ordner "c:/Dokumente und Einstellungen/" gibt es nun schon mindestens seit Windows 2000, wenn nicht schon seit Windows NT, und ebenso lange legen so ziemlich alle Programme da drunter ihre Dateien ab. Das sollte eigentlich inzwischen jedes noch so alte tool mitbekommen haben, und hat es vermutlich auch. Das es da im WinAVR-Umfeld Probleme mit den Leerzeichen gäbe, wird, wie gesagt, immer wieder gerne wiederholt, ohne Nachweis, daß es so ist. Umlaute und andere Sonderzeichen sind ein Problem, bei machen tools auch Groß- und Kleinschreibung, aber Leerzeichen nicht. Oliver
Moin Leute erstmal, so das ganz Geplänkel mit den pfaden habe ich nun hoffentlich hinter mir gelassen. Habe den Pfad C:\Projekt -> Habe neuen Projektpfad angelegt -> neues Projekt angelegt -> Compiliert und den Fehler: Make: *** No rule to make Target ´../../Dokumente', needed by ´Kreisel.o'. Stop. Was bedeutet dieser Fehler und iwas kann man tun um diesen zu beheben?
Ich habe den Fehler gefunden, bzw. behoben. Ich habe den Zielpfad nun wieder in den Defaultpfad abgeändert, der in den eigenen Dateien wäre, also C:\Dokumente und Einstellungen\WinAVR\projekt . Ich versuche nun einen Build durchzuführen, dabei spuckt mir AVR einen fehler aus, aber auch ohne Roten Punkt. Der Fehler lautet: make: *** [kreisel.elf] ERROR 1 Könnt ihr mir helfen?
Deine Konfiguration scheint ordentlich verbockt zu sein. Da ist mächtig der Wurm drinn. Und es ist schwer da noch irgendwelche Tips zu geben. Das kann alles mögliche sein. Am warscheinlichsten ist IMHO, dass da irgendein anderes Entwicklungssystem auf dem System ist oder zumindest früher mal war, und von dem noch irgendwelche Dinge in wahlweise Reigstry/Windows-Verzeichnisse/Pfad-Verzeichnissen rumhängen.
Ich habe das Programm auch mal auf einen sozusagen nackten System ausprobiert wo ich alles frisch installiert habe, AVR Studio und WinAVR. Ich habe an der Konfiguration nicht herumgepfuscht. Was is deiner Meinung nach denn in der Konfiguration verpfuscht?
Wenn ich das wüsste, würde ich es dir sagen. Aber irgendetwas muss es sein, denn bei allen anderen hier funktioniert das: AVR-Studio installieren WinAvr installieren Drauflos programmieren. Sich darüber freuen, dass sich WinAvr nahtlos in AVR-Studio integriert hat.
Das mag sein, auf den entsprechenden PCs is nämlich noch MPLab und ProgPIC zur PIC programmierung installiert. MPLab und Progpic habe ich nun einmal deinstalliert, der Fehler kommt immer noch. Kann es sein das Simatic Manager für die S7 noch mit reinfunkt oder pg4uw? Ich nutze nämlich einen BeeProg+ von Elnec zum flashen der Hex files.
Mach mal ein Kommandofenster auf, und tippe: which make.exe Was steht dann da? Oliver
Da steht: C:/WinAVR-20090313/utils/bin/make.exe Was hilft mir das jetz weiter?
Das sagt dir, daß da schonmal das richtige make gefunden wird. Also, nächster Versuch: Einen leeren Ordner mit Namen "Test" (oder so) erstellen, da drin ein main.c mit folgendem Inhalt erzeugen:
1 | #include <avr/io.h> |
2 | |
3 | int main(void){} |
dazu ein makefile mit MFile erstellen: Mfile starten (Im Startmenu unter WinAVR) Im Menu "makefile" - main file name auf main.c setzen - MCU Type auf Mega8 setzen dann als "makefile" in dem Ordner, in dem auch main.c steht, abspeichern. Kommandofenster öffnen, in den Ordner mit main.c und dem makefile wechseln, dort make eingeben. Was passiert? Oliver
Angehängte Dateien:
-
shell_makefile.JPG
58 KB
ich habe wie beschrieben das projekt und das Makefile erstellt und auch in der Konsole ausgeführt. Nun hat er das ausgegeben was in dem screenshot steht welchen ich an den Post hier angehängt habe. Was habe ich damit jetzt genau gemacht?
Upps, sorry, mein Fehler. Mach das makefile im Editor mal auf und ändere die Zeile ># Target file name (without extension). >TARGET = main.c in ># Target file name (without extension). >TARGET = main (ohne das .c hintendran) Speichern, und dann nochmal make aufrufen. Oliver
Also mit einem kleinen Testprogramm funktioniert es, das Makefile erstellt die *.elf und auch die *.Hex. Mit dem normalen Programm funktioniert es leider immer noch nicht. Ich vermute, dass der Fehler irgendwo im Programmcode steckt. Den Programmcode kann man sich nach kostenloser registrierung unter http://www.elektor.de/credit-payment.589.lynkx?event=Zur%20Kasse&productGuid=fca16686-bb90-4d9e-a6c1-0ec2b47dd217 herunterladen. Ich habe derzeit die wage Vermutung, dass es evtl. an multiplen Definitionen liegt, weil die Ausgabe in AVR nämlich unter dem grünen Punkt mehrfach "ohne Warnung" darauf hinweist, siehe Anhang.
>Ich habe derzeit die wage Vermutung, dass es evtl. an multiplen >Definitionen liegt, Die wage Vermutung düfte richtig sein ;-) Da wirst du dich mal etwas intensiver mit dem Projekt beschäftigen müssen, um herauszufinden, wie das eigentlich funktionieren soll. Vermutlich benötigst nicht alle der Dateien kreisel.c bzw. kreisel-de.c bzw. kreisel-ct-de.c Projekte von Dritten für andere zu debuggen macht hier keiner gerne. Da musst du schon selber durch. Zur Not musst du dir halt den zugehörigen Elektor-Artikel besorgen, da sollte das alles drinstehen. Oliver
Okay dann wird mir wohl nichts anders übrig bleiben als mich intensivst in das Programm einzuarbeiten. Ich hatte eigentlich gehofft, dass es eine Konfigurationsgeschichte ist. Ich habe in der Ausgabe noch eine andere Warnung gefunden die mir etwas Sorgen bereitet und zwar warnt er mich mit den Worten: warning: # warning"F_CPU not defined for <util/delay.h>" Ich nutze aber auch kein Programmiergerät welches von AVR unterstützt wird, meine Absicht war von vorn herein, mit AVR nur die HEX zu erstellen und mit dem BeeProg+ von Elnec hinteher zu programmieren. Also denke ich, dass diese Warnung irrelevant ist. Liege ich da richtig?
Jannes Borchers schrieb: > erstellen und mit dem BeeProg+ von Elnec hinteher zu programmieren. Also > denke ich, dass diese Warnung irrelevant ist. Liege ich da richtig? Nein, du liegst falsch. F_CPU ist ein Makro, das bei der Berechnung der Delay-Zeiten benutzt wird. Sein Inhalt ist die Taktfrequenz des verwendeten Prozessors auf dem das Programm letztenendes laufen soll. Die Taktfrequenz wird dazu benötigt um ausrechnen zu können, wie oft der µC 'Däumchen drehen soll' bis eine bestimmte Zeitdauer vergangen ist. Eingestellt wird sie auf eine von 2 Arten * entweder man macht einen entsprechenden #define vor dem #include #define F_CPU 4000000 // zb für 4 Mhz * oder man stellt sie in den Konfigurations-Optionen für das Projekt im AVR-Studio ein. Dann erzeugt AVR-Studio das entsprechende Makro. Du solltest dich wirklich mehr mit der Materie beschäftigen. Aus geklauten Programmen einfach nur Dinge zusammenkopieren ohen sie zu verstehen, funktioniert nicht.
Wir haben ja nichts kopiert, das Programm ist ja fertig und eigentlich lauffähig, deswegen rätseln wir daran schon ne halbe Ewigkeit rum. Wir sind Auszubildende Elektroniker für Geräte und Systeme im 4. Lehrjahr kurz vor der Prüfung, haben dieses Projekt nun angefangen, weil es ein kompletter Bausatz der Universität RWTH Aachen ist. Und ärgern uns nun damit rum, dass es partu einfach nicht funktionieren will, und wir kommen da nicht hinter. Wir haben das Internet gut durchforstet und auch Grundwissen in der Programmierung von C. Deswegen ein "lauffähiges" Programm. Andere Leute die sich damit auseinander gesetzt haben haben es sofort zum laufen gebracht, es gibt auch nachträglich nach dem erscheinen dieses Artikel in der Elektor keine Fehlerbedingten Änderungen. Auf jedenfall soweit schonmal ein Danke für deine Bemühungen, wir werden das Projekt nun leider wahrscheinlich nicht zum Abschluss bekommen, wenn es wirklich an dem Code liegen sollte. Ich meine der Kreiesel an sich funktioniert, bei dem Download ist ja ein HEX file dabei, mit diesem Funktioniert es auch, aber wir hatten uns weiter auch vorgenommen den Kreisel umzuprogrammieren weil in dem Programmcode Text ausgabe Programme nur auskommentiert sind. Und dies auzch quasi beschrieben ist wie dies geändert werden kann. Dann wird sich unser Meister für unsere Nachfolger damit beschäftigen müssen :-P Jannes
Jannes Borchers schrieb: > Auf jedenfall soweit schonmal ein Danke für deine Bemühungen, wir werden > das Projekt nun leider wahrscheinlich nicht zum Abschluss bekommen, wenn > es wirklich an dem Code liegen sollte. Ts, ts Ich bin sicher, dass jemand der ein wenig Erfahrung mitbringt, die Probleme in weniger als 15 Minuten ausräumen kann. Wahrscheinlich sogar weniger. Ihr gebt zu schnell auf. Und für die Zukunft merken: Ehe man ein Projekt offiziell angeht erst mal abklären, ob das auch was werden wird. Nur zu oft sehen wir hier Leute, die mit viel Enthusiasmus und guten Vorsätzen ein Wahnsinnsprojekt machen wollen und kläglich scheitern, weil sie das Wissen dafür einfach noch nicht haben und es sich auch nicht während das Projektes aneignen können, weil ihnen alles über den Kopf wächst.
Alsoooo wir sitzen jetzt seit Montag daran, was FERTIG ist und
FUNKTIONIERT!!! Aber nur nicht bei uns, das ganze stellt ein völlig und
komplett funktionierenden Bausatz dar! Wir haben das FERTIGE und
FUNKTIONIERENDE Programm uns von Elektor runter geladen und nur versucht
ein Hex-File zu erstellen um es in den Kontroller zu laden.
Wir sitzen jetzt seit Montag 8!!! stunden JEDEN Tag dabei und versuchen
eins nach dem anderen und haben Prüfungsbedingt nur bis heute Mittag
Zeit dafür.
Ohne dich jetz angreifen zu wollen, ich nehme an, dass du Karl heinz
Buchegger
> ein wenig Erfahrung
mitbringst und so freundlich sein könntest uns 15 Minuten deiner Zeit
opfern könntest um uns aus der Patsche zu helfen, oder fühlst du dich
dazu nicht im Stande? Aber wir sind ja nur die Übereifrigen kleinen
dummen die sich typischer weise wieder völlig übernehmen und KOMISCHER
WEISE dabei scheitern, nä?
Und soetwas von einem Moderator in Gesicht geklatscht zu bekommen
wundert einen doch schon sehr!
Jannes Borchers schrieb: > Alsoooo wir sitzen jetzt seit Montag daran, was FERTIG ist und > FUNKTIONIERT!!! Aber nur nicht bei uns, das ganze stellt ein völlig und > komplett funktionierenden Bausatz dar! Wir haben das FERTIGE und > FUNKTIONIERENDE Programm uns von Elektor runter geladen und nur versucht > ein Hex-File zu erstellen um es in den Kontroller zu laden. OK. Das habt ihr ja hingekriegt, wenn ich das recht verstanden habe. > Wir sitzen jetzt seit Montag 8!!! stunden JEDEN Tag dabei beeindruckt mich ehrlich gesagt gar nicht. Wie du schon sagtest, das ist fix und fertig zum Gebrauch. > und versuchen > eins nach dem anderen und haben Prüfungsbedingt nur bis heute Mittag > Zeit dafür. > Ohne dich jetz angreifen zu wollen, ich nehme an, dass du Karl heinz > Buchegger > >> ein wenig Erfahrung > > mitbringst und so freundlich sein könntest uns 15 Minuten deiner Zeit > opfern könntest um uns aus der Patsche zu helfen, oder fühlst du dich > dazu nicht im Stande? Kein Grund pampig zu werden. Lade das komplette Paket hoch und ev. nimmt sich jemand darum an. Aber: Dann habt wieder nicht ihr das Projekt gestemmt sondern jemand anderer. Und so ganz sehe ich nicht ein, warum ihr dafür dann eine Prüfung bestehen sollt. > Und soetwas von einem Moderator in Gesicht geklatscht zu bekommen > wundert einen doch schon sehr! Ihr seid nicht die ersten denen so etwas passiert. Weder dass sie sich mit einem Projekt übernehmen, noch dass man das auch mit offenen Worten ausspricht. Gewöhn dich daran, das ist das Los in der Softwareentwicklung. Wenn du deinem Kunden etwas zusagst, musst du auch im Stande sein, es zu schaffen. Egal wie. Und wenn dann der Tag 48 Stunden hat und Wochenenden gestrichen werden, Zusage ist Zusage. Bei euch ist es kein Kunde sondern ein Prüfungstermin. Nennt sich nur anders, ist aber vom Prinzip her dasselbe. Arbeiten unter Termindruck ist ganz normal. Wer dann die Nerven verliert und nicht systematisch an die Sache rangeht, hat schon verloren.
So ich hätte jetz nur noch Zwei fragen an dich, einmal back to the roots: Wie zum Henker macht man daraus jetzt ein HEX-File??? und zweitens zurückkommend auf die erste Frage, würdest du 15 Minuten deiner Zeit Opfern??? Geht doch fix. Ich stell dir alles zur Verfügung was du benötigst. und so noch einmal nebenbei das ganze hat recht wenig mit unseren eigenen Prüfungsinhalten zu tun! Nämlich gar nix!
Jannes Borchers schrieb: > So ich hätte jetz nur noch Zwei fragen an dich, einmal back to the > roots: Wie zum Henker macht man daraus jetzt ein HEX-File??? Indem der Programmtext durch dein Compiler/Linker gejagt wird (also F7 Build) und daraus entsteht dann das HEX-File (Bei so einer Frage muss ich sofort zurückfragen: Habt ihr eigentlich schon jemals vorher irgendein Programm für AVR geschrieben?) > und zweitens zurückkommend auf die erste Frage, würdest du 15 Minuten > deiner Zeit Opfern??? Geht doch fix. Ich stell dir alles zur Verfügung > was du benötigst. Ich sagte doch schon: Lad das Projekt hoch und irgendjemand (muss ja nicht ich sein) wird sich ev. darum annehmen die Projektkonfiguration durchzusehen. > und so noch einmal nebenbei das ganze hat recht wenig mit unseren > eigenen Prüfungsinhalten zu tun! Nämlich gar nix! Spielt keine Rolle: Ihr habt euch das Thema gewählt, also müsst ihr da durch. Ich kann auch nicht sagen "Ich baue für meine Abschlussprüfung ein Auto, aber ich montiere nur den Rückspiegel weil ich von allem anderen keine Ahnung habe"
>Was ist nun? >Upload nicht hingekriegt? F7 gefunden... SCNR
>Was ist nun? >Upload nicht hingekriegt? >Den Programmcode kann man sich nach >kostenloser registrierung unter >http://www.elektor.de/credit-payment.589.lynkx?eve... Da dürfte die Elektor was dagegen haben. Oliver
Ich habs mir jetzt mal angesehen. Nun ja, das mitgelieferte Studio-Projekt und das notepad-Projekt sind Murks, aber das makefile funktioniert. Es lebe die Elektor. Also, ein Hinweis: Wenn man ein makefile hat, könnte man einfach mal ein "make all" im Kommandofenster des Ordners ausprobieren. Wie ich schon vermutet hatte, darf von den drei Dateien kreisel.c, kreisel-de.c, kreisel-de-ct.c nur eine dazugelinkt werden. Die sind alle drei ähnlich, worin die Unterschiede bestehen, müsst ihr schon selber rausfinden. Oliver
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.