Da nun der RC5-Code-Empfänger von Peter Dannegger so wunderbar auf mehreren Mikrocontroller-Typen bei mir funktioniert, wollte ich einfach mal diesen vorgefertigten RC5-Sender http://blog.a-netz.de/2007/08/rc5-infrarot-fernbedienung/ http://blog.a-netz.de/wp-content/uploads/2012/01/remote-control-20061019.tar.gz nachbauen und bin schon beim Compilieren auf eine Schwierigkeit gestoßen, wie man der unten angegeben Fehlermeldung entnehmen kann. Beide Programmteile lassen sich mittels "Compile" in AVR-Studio 4.18 separat fehlerfrei compilieren. Jedeoch der Befehl "build" bringt die Fehlermeldung: Build started 25.1.2013 at 00:33:00 avr-gcc -mmcu=attiny2313 -Wl,-Map=RC5-Sender_Andreas_Schroeder.map test.o rc.o -o RC5-Sender_Andreas_Schroeder.elf rc.o: In function `__vector_1': C:\Dokumente und Einstellungen\erster\Eigene Dateien\default/../rc.c:68: multiple definition of `rc5data' test.o:(.data+0xf): first defined here rc.o:(.data+0x0): multiple definition of `bitcounter' test.o:C:\Dokumente und Einstellungen\erster\Eigene Dateien\default/../test.c:38: first defined here rc.o: In function `main': C:\Dokumente und Einstellungen\erster\Eigene Dateien\default/../rc.c:135: multiple definition of `main' test.o:C:\Dokumente und Einstellungen\erster\Eigene Dateien\default/../test.c:62: first defined here make: *** [RC5-Sender_Andreas_Schroeder.elf] Error 1 Build failed with 1 errors and 0 warnings... Also die Variablen sind tatsächlich an zwei Stellen definiert. Und Main kommt in beiden Dateien vor. Muß man eine der Variablen "extern" definieren?? Oder warum überhaupt ist das Programm so geschrieben? Dummerweise kann ich nicht ein mal das Programm simulieren, da es ja nicht komplett kompiliert werden kann. Kann mit da jemand mit Tipps weiter helfen? mit freundlichem Gruß
Psst. Das Programm test.c ist ein Programm für den PC. Erkennbar daran, dass da gar nichts hardwarespezifisches drinn vorkommt und printf verwendet wird. Oder kann dein AVR mit printf aus dem Stand was anfangen? Das hat er benutzt, um die bitweise Zerlegung auf dem PC zu testen, wo er viel schönere und bessere Debug-Möglichkeiten hat. Ein Bildschirm, auf dem man sich mal auf die Schnelle ein paar Zwischenergebnisse ausgeben kann, ist dann doch schon um einiges komfortabler, als das Studieren eines Oszillogramms und rückschliessen, was denn im Code für das Gesehen verantwortlich sein könnte. Kann ich nur empfehlen: Algorithmen erst mal auf dem PC zu laufen zu bringen und dort zu debuggen. Also: raus damit aus dem Projekt. Das hat da drinn nichts verloren.
Hallo, vielen Dank für den Tipp. Die Sache war mal wieder einfacher als gedacht. Nur wäre ich nie auf die Idee gekommen, daß der Teil test.c für den PC / die Konsole sein soll. Leider war in test.c keinerlei Hinweis auf ein PC-Programm dabei. Das "printf" ist mir nicht aufgefallen. Es werden keine PORT- oder Timer-Register initialisiert. Aber die richtigen Schlüsse hätte ich nicht daraus gezogen. Wieder etwas gelernt! Der Teil hier dürfte bei einem Mikrocontroller keinen Sinn ergeben: #define ENABLE_MODULATION printf("1") #define DISABLE_MODULATION printf("0") Tatsächlich: Wie schon ursprünglich erwähnt, läßt sich RC5.c fehlerfrei compilieren. AVR Memory Usage ---------------- Device: attiny2313 Program: 478 bytes (23.3% Full) (.text + .data + .bootloader) Data: 5 bytes (3.9% Full) (.data + .bss + .noinit) Build succeeded with 0 Warnings... mit freundlichem Gruß
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.