Hi! Ich beschäftige mich seit kurzem mit µControllern. Bis jetzt programmierte ich in Bascom, wollte aber jetzt auf C umsteigen. Als IDE dachte ich an Code::Blocks. Mein Problem ist nun, dass wen ich ein Projekt kompilieren will folgende Fehlermeldung erscheint: "Projektname" uses an invalid compiler. Skipping... Als Compiler is der AVR GNU GCC ausgewählt, der eigentlich auch installiert sein sollte, da ich das Packet mit dem enthaltenen GCC habe. Ausgewählt ist er auch. Was kann ich tun, um endlich wieder kompilieren zu können? Sollte ich auf Eclipse oder ähnliches umsteigen? danke schonmal für die (hoffentlich) nützlichen und vielen Antworten!
> Als Compiler is der AVR GNU GCC ausgewählt, der eigentlich auch > installiert sein sollte, da ich das Packet mit dem enthaltenen GCC habe. > Ausgewählt ist er auch. Soweit erinnert, kommt das Packet mit einem Compiler für den PC. Sicher, dass die AVR-Cross-Toolchain installiert ist? (avr-gcc et al, für MS-Windows: z.B. in WinAVR)
Die installation von WinAVR alleine reicht nicht aus, man muss Code::Blocks auch mitteilen, wo sich der Compiler usw. befindet. Geh auf Settings->Compiler and Debugger, wähl dann den AVR-GCC als Compiler und wechel auf den Tab 'Toolchain Executables'. Dort muss man das Installationsverzeichnis von WinAVR angeben. Danach sollte alles klappen. MfG Mark
Jippie, hat geklappt! Warum ich WINAVR auch noch installieren muss, obwohl ich das mingw PAcket von C::B installiert habe, bleibt mir zwar ein Rätsel, aber solange es geht, is alles im grünen bereich! Danke für die klasse Hilfe!
Gast wrote: >Warum ich WINAVR auch noch installieren muss, obwohl ich das mingw >PAcket von C::B installiert habe, bleibt mir zwar ein Rätsel [...] MinGW ist eine Toolchain für Win32, nicht für AVRs! Deshalb muss man erstmal WinAVR installieren.
Achso, jetzt versteh' ich das. Vielen tausend Dank!
Nochmal eine Frage: Ich taste mich so langsam in die Welt von C vor. Nun da mein C::B wieder geht, kann ich endlich weitermachen, stehe aber schon vor einem Problem:
1 | #include <avr/io.h> |
2 | #define F_CPU 16000000
|
3 | |
4 | |
5 | int main(void) |
6 | {
|
7 | |
8 | DDRC = 0b00000110; |
9 | PORTC = 0b00000110; |
10 | while(1) |
11 | ;
|
12 | |
13 | return 0; |
14 | }
|
Ich habe das Pollin Eval Board V2.0.1. EIgentlich sollten doch alle Leds angehen, oder? Leider tun sie das aber nict, und ich weiss nicht warum. Danke für die Hilfe!
Gast schrieb: > EIgentlich sollten doch alle Leds angehen, oder? > Leider tun sie das aber nict, und ich weiss nicht warum. Du mußt erstmal den AVR-Typ verraten. Es gibt AVRs, da haben manche Pins nach dem Reset Sonderfunktionen, z.B. JTAG-Debug. Das läßt sich per Befehl oder Fuse abschalten. Peter
>Du mußt erstmal den AVR-Typ verraten. Mist! Eigentlich dachte ich, ich hab das angegeben. Es ist ein ATMega16 der mit einem 16MHz Quarz läuft. Due Fuses sind so wie für das Pollin Beispielprogramm gesetzt. Ich denke also die müssten für Zugriff auf die LED's passen. Grüße und danke für die Antwort, Peter!
Gast schrieb: > Ich denke > also die müssten für Zugriff auf die LED's passen. Nicht denken, sondern im Datenblatt nachschauen. Peter
Hi Peter! Mit den Fuses hat der Zugriff auf die LEDs mit dem Pollin Testtool doch geklappt. Und auch eigene Bascom Programme haben so gklappt. An den Fuses kanns also nicht liegen. Ich werde das .hex nochmal neu aufspielen... Grüße...
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.