Sodale, erst mal ein herzliches "Grüß Gott" an das Forum. Seit einer Woche habe ich die Aufgabe, mich in das Thema µControler einzuarbeiten. Nachdem ich es bei diesem Kaltstart hinbekommen habe, das Bord zu "bedienen", und mit den Beispielprogrammen zu beschreiben kommt jetzt das Übel des Erstellens eigenen Codes. Neben diversen Online-Tutorials (u.a. auch die auf der ATMEL-HP) und Forums-Leserei verzweifle ich langsam, da ich trotz C-Kenntnissen nicht mal die einfachsten Befehle zum Laufen bekomme. Hier unser Equipment: HW: STK600 mit ATMEGA2560 Karte, JTAGICE MKII SW: AVR Studio5 Nun das konkrete Problem: Bereits das AVR-GCC Tutorial hier auf der Homepage, Punkt 6, Einführungsbeispiel kann ich nicht umsetzen. ***************************************************** #include <avr/io.h> // (1) int main (void) { // (2) DDRB = 0xFF; // (3) PORTB = 0x03; // (4) while(1) { // (5) /* "leere" Schleife*/ // (6) } // (7) /* wird nie erreicht */ return 0; // (8) } ***************************************************** Also eigentlich Easy-Pisi, aber sowohl für (3) als auch für (4) bekomme ich beim Compilen Fehlermeldungen. "DDRB undeclared (first use in this function)" und "incompatible types when assigning to type PORT_t from type int". In den Beispielprogrammen, die ich mir angesehen habe, wird der Befehl DDRx auch benutzt und funktioniert, möchte ich den Befehl jedoch in einem leeren Projekt umsetzen, gibt es Fehler. Genutzte Drivers: IOPORT, UTILITY, GPIO, Includes (aus Verzweiflung): #include <asf.h> #include <stk600/rc064x/stk600_rc064x.h> #include <avr/io.h> #include <gpio.h> #include <asf/common/utils/interrupt.h> #include <asf.h> #include <config/conf_board.h> #include <stdio.h> Meine Frage: Kann mir jemand erklären, woran die Nicht-Nutzbarkeit der Befehle liegt? Gibt es für µC-Noobs geeignete Tutorials, die auch auf solche Fragestellungen eingehen? Mein Ziel ist erst mal die High-down-Schaltung einzelner Pins. Zuerst durch Tastendruck, dann bei Spannungsabfall durch Unterbrechung einer Lichtschranke. Doch auch mit dem Befehl gpio_set_pin_high/low gibts Probleme. Keine Fehlermeldungen, jedoch keine Reaktion auf dem Board.... Das war jetzt viel Text, für Unterstützung wäre ich aber sehr dankbar! P.S.: Übrigens auch für Tipps, die das Einarbeiten erleichtern... :) Beste Grüße Andreas
Hi, vielleicht liegt dein Problem in AVRSTudio 5? Die meisten Tutorials dürften mit AVRStudio 4 + winavr gemacht worden sein....
Das vermute ich auch, denn avr/io.h müsste für die Registerzugriffe reichen, siehe auch: http://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC/_Register
Ist bei dem Projekt auch der richtige Prozessor angegeben bzw. wird der auch unterstützt? Gruß Dietrich
Gast
#2460110
Andreas König schrieb: > DDRB undeclared (first use in this > function) sagt dir, daß der Compiler mit DDRB nix anfangen kann. Das wird über avr/io.h definiert. Entweder findet der Compiler io.h nicht (dann sollte es dazu aber eine Fehlermeldung geben), oder du hast keinen oder auch einen ungültigen mmu-Typ eingestellt. Ob Studio 4 oder 5, ist egal, da steckt überall der gleiche Compiler dahinter. Oliver
Ok, jetzt wird's das erste Mal peinlich. Beim Nachschlagen des Devices taucht da ein ATxmega256A3 statt des ATmega2560 auf... Bei den Beispielprojekten war das korrekte gewählt. Vielen Dank für die Idee! Kann es sein, dass dann die Verwendung von Studio5 nicht so empfehlenswert ist? Wenn ich ein normales leeres Projekt starte, dann kann ich keine Driver hinzufügen - ist anscheinend ein bekannter Bug. Unter den ATMEL BOARDS ist nur das STK600 mit 2 ATxmega-Chips aufgeführt - das 2560 fehlt. Bleibt als letzte Möglichkeit unter AVR Studio5 nur, ein Beispielprogramm zu laden, zu leeren / modifizieren und dann zu nutzen? Beste Grüße Andreas
Jetzt muss ich aber gleich noch einmal einhaken: Ist das ok, dass ich weder unter einem geladenen Example-Projet, noch unter einem neuen "leeren" Projekt dann Drivers hinzufügen kann? Ist diese Option für ATMEGA2560 generell nicht verfügbar?
AVRStudio 5 ist halt noch relativ neu. Das könnte ein Grund sein, warum das noch nicht so viele (mich eingeschlossen) ausprobiert haben.
Hallo Bernd, ja das scheint mir auch so, zumal die Stimmen zu Ver5 eher skeptisch sind... Danke soweit für die Unterstützung, nur zum Thema "Drivers" bräuchte ich noch Hilfe. Gibt es Quellen, wo ich mich einlesen kann? Guten Start in die Woche!
Mir ist nicht klar, was du mit Drivers meinst? (Hab ein bischen recherchiert, da ich auch die Ver5 noch nicht verwende). Kann es sein, dass du Device meinst, aber Driver sagst?
Also auf mein Vokabular will ich noch nicht schwören... Aber im Tutorial auf der ATMEL-HP wird für die Verwendung der GPIO-IO Befehle bei einem xplain-Board unter AVR Studio 5 im Menü "Project" der Punkt "Select Drivers from ASF" ausgewählt. Dort stehen mehrere Drivers zur Auswahl, um eben beispielsweise spezielle Counterfunktionen oder GPIO-Funktionen erst nutzen zu können. Meine ersten Erfahrungen waren die, dass ich die entsprechenden .h Files erst nach Einbinden der Treiber einbinden konnte. Ansonsten war "File not Found" zu sehen. Wenn ich in meinem Fall das "korrekte" Board Mega2560 auswähle, ist diese Option im Menü jedoch grau hinterlegt. Am Anfang gab es bei Studio5 wohl Bugs, die das sporadisch verursachten. Wähle ich bspw. den (falschen) xMega256A3, kann ich nämlich Treiber auswählen. Vielleicht kann/braucht aber der mega2560 gar keine Drivers... Ich bin da aus dem Stadium der Verwirrung noch nicht ganz raus, sorry.
Karl Heinz Buchegger schrieb: > Mir ist nicht klar, was du mit Drivers meinst? > > (Hab ein bischen recherchiert, da ich auch die Ver5 noch nicht > verwende). Kann es sein, dass du Device meinst, aber Driver sagst? Ich hab die Version5 auch nicht, aber es scheint so etwas zu sein wie beim DAvE von Infineon...???
Andreas König schrieb: > Dort stehen mehrere Drivers > zur Auswahl, um eben beispielsweise spezielle Counterfunktionen oder > GPIO-Funktionen erst nutzen zu können. Meine ersten Erfahrungen waren > die, dass ich die entsprechenden .h Files erst nach Einbinden der > Treiber einbinden konnte. Ansonsten war "File not Found" zu sehen. > > Ich bin da aus dem Stadium der Verwirrung noch nicht ganz raus, sorry. Um spezielle Funktionen eines Controllers zu nutzen brauchst du bestimmt keine Drivers. Allerhöchstens erleichtern die dir die Verwendung (oder tragen zur Verwirrung bei :-) ). Mal schön das UserManual lesen und die Verwendung der GPIOs verstehen. Dann geht das auch ohne Drivers.
Der Mega2560 ist doch ein ganz normaler Mega (nicht aber der XMega). D.h. die Tutorials hier AVR-Tutorial AVR-GCC-Tutorial sind vollinhaltlich sinngemäss anwendbar. Wozu brauchst du da Device-Driver?
Karl Heinz Buchegger schrieb: > Wozu brauchst du da Device-Driver? :D Du greifst damit meine Frage: "Was ist ein Device-Driver und was macht der" auf :D Ich habe eben noch keine Ahnung was das so genau ist. Bis dato sind meine C-Projekte immer nur von Verschiedenen eingebundenen .h-Files abhöngig gewesen. µCs sind für mich neu, Driver deshalb auch...
Andreas König schrieb: > Karl Heinz Buchegger schrieb: >> Wozu brauchst du da Device-Driver? > > :D Du greifst damit meine Frage: "Was ist ein Device-Driver und was > macht der" auf :D > > Ich habe eben noch keine Ahnung was das so genau ist. Bis dato sind > meine C-Projekte immer nur von Verschiedenen eingebundenen .h-Files > abhöngig gewesen. µCs sind für mich neu, Driver deshalb auch... meinst du sowas: http://asf.atmel.com/docs/latest/ µCs sind für mich nicht neu, Drivers aber schon. Du kannst µC programmieren ohne Drivers.
Ja benau das meinte ich. Wenn ich weiß, dass das ein Feature anderer Controller ist, reicht mir das jetzt vollkommen aus. Dann kann ich die Drivers erst mal vernachlässigen! Danke!
Andreas König schrieb: > Karl Heinz Buchegger schrieb: >> Wozu brauchst du da Device-Driver? > > :D Du greifst damit meine Frage: "Was ist ein Device-Driver und was > macht der" auf :D Soweit ich das verstanden habe, ist das einfach nur eine Sammlung von Funktionen, mit denen man Standardaufgaben einfach erledigen kann. Dies deshalb, weil bei einem XMega die Dinge nicht mehr so einfach sind wie bei den Megas. Aber ob du jetzt eine Funktion richtig aufrufst, die dir an einem I/O Port die gewünschten Pins auf Ausgang stellst, oder ob du (auf einem Mega) einfach die Konfiguration ans DDRx Register zuweißt, ist doch gehupft wie gesprungen. Die Konfiguration einer UART ist bei einem normalen Mage ziemlich straight forward: Baudrate ins richtige Register schreiben und in einem anderen Register das Bit für "Transmitter ein" setzen und schon läuft der UART. Das mag beim XMega nicht mehr ganz so einfach sein und dann ist es schon gut, wenn man eine Funktionssammlung hat, die einem das abnimmt. Was natürlich bei solchen Drivern toll ist: Man entkoppelt damit das Programm besser von der aktuellen Hardware. Denn der Aufruf ist dann bei allen Prozessoren (theoretisch) immer gleich, unabhängig davon was dann tatsächlich zu tun ist. > meine C-Projekte immer nur von Verschiedenen eingebundenen .h-Files > abhöngig gewesen. µCs sind für mich neu, Driver deshalb auch... Persönlich denke ich, du gehst da jetzt in die falsche Richtung. #include avr/io.h und wenn der Prozessor im Projekt richtig eingestellt ist, hast du damit fürs erste alles verfügbar, was du brauchst. So einen Mega zu programmieren ist keine große Hexerei, die man ohne Untertützung durch vorgefertigte Funktionen nicht hinkriegen würde.
Das beruhigt mich! Vielen Dank für die Unterstützung!!!
Andreas König schrieb: > Ja benau das meinte ich. Wenn ich weiß, dass das ein Feature anderer > Controller ist, reicht mir das jetzt vollkommen aus. Dann kann ich die > Drivers erst mal vernachlässigen! > Danke! Das hängt nicht vom Controller ab! Es liegt daran, dass diese Frameworks erstmal jemand zusammenstellen muss und in die Entwicklungsumgebung integrieren muss. Da aber verschiedene Controller sich in ihren Porbelegungen unterscheiden passt eben nicht jede Funktion für jeden Controller. Du kannst sicherlich auch XMegas ohne Driver programmieren. Wenn welche da sind, heißt das aber nicht, dass damit alle Funktionen dieses Controllers ausgeschöpft sind. Das AVR-Tutorial ist da sicherlich ein guter Einstieg. Edit: uups, ich war zu langsam
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.