Wo finde ich Code Beispiele für ein einfaches LED blicken für einen AVR32 Mikrocontroller in der Programmiersprache C? Es sollte sehr einfach sein und nicht zig Headfiles noch benötigen.
Danke Sandro, aber dies ist nur AVR Code. Ich suche AVR32 Code, also den MC mit 32 Bit. Oder ist der Code identisch. Ich glaube nicht.
Nach ein wenig googlen..
1 | #include <avr32/io.h> |
2 | #include "gpio.h" |
3 | int main( void ) |
4 | {
|
5 | while (1) { |
6 | gpio_set_gpio_pin(AVR32_PIN_PA03); // pin high setzen |
7 | gpio_clr_gpio_pin(AVR32_PIN_PA03); // pin low setzen |
8 | gpio_tgl_gpio_pin(AVR32_PIN_PA03); // pin togglen |
9 | |
10 | } |
11 | return 0; |
12 | }
|
Fehlt nur noch die Zeit : )
Die Headerdatei und ihr dazugehöriger C-Code befinden sich in dem sogenannten "Atmel Software Framework". Ein ziemliches Trumm mit einigen Beispielen und Treibern wie auch gpio.h/c.
In einer der letzen Ausgaben des "Embedded Projects Journal" ist ein Artikel über "natives C" auf dem Grasshaopper (AVR32). Gruß 900ss
amateur schrieb: > Die Headerdatei und ihr dazugehöriger C-Code befinden sich in dem > sogenannten "Atmel Software Framework". Nein, im ASF-Framework befindet sie sich nicht. > Ein ziemliches Trumm mit einigen Beispielen und Treibern wie auch > gpio.h/c. Es gibt zwei Versionen einer 'gpio.h' in den Board-Examples. Und auch dort ist wieder mal nichts dokumentiert. Vielleicht bin ich ja von ST und TI etwas verwöhnt, aber langsam drängt sich mir der verdacht auf, bei Atmel-Software arbeiten nur Frickler...
Hey Roland, Schau einfach mal auf der www.avr32-wiki.de Webseite, da steht das sehr gut beschrieben. Vorallem das einfache LED blinken ist dort Schritt für Schritt erklärt.
Das Tutorial hat (mal wieder) einen Schönheitsfehler: Es bezieht sich auf Dateien, welche in der aktuellen Fassung des Framework nicht (mehr) existieren! Lest ihr eigentlich die vorangegangenen Posts durch, bevor ihr was schreibt? Über das Problem des (nicht nutzbaren) ASF bin ich inzwischen hinweg. Dank etlicher gugelbarer Userprogramme habe ich langsam raus, nach welchem (kranken) Schema man bei Atmel seine Headerfiles ür die Register baut. Aber was anderes: Muss man dem AVR32 mit Studio6 evtl einen besonderen Kuchen backen, damit er Funktionsaufrufe bearbeitet? Ich verwende den gepatchten Linker-script aus dem wiki, und sämtliche Aufrufe von Funktionen oder Prozeduren aus der main() schlagen fehl. Und nein, ich kann kein Incircuit-Debugging machen. Ich sehe nur an Hand einiger Muster auf Portpins, wo der Atmel sich gerade rumtreibt. (Und dass er die Unterprogramme nicht betritt)
Roland schrieb: > Lest ihr eigentlich die vorangegangenen Posts durch, bevor ihr was > schreibt? Liest Du überhaupt irgendetwas durch, bevor Du anfängst Fragen zu stellen? Komm anstatt zu weinen: RTFM.
Dann zeige mir das FineManual. Ich würde es gern lesen. Es gibt nur keins. Aber wenn du schon so klug dahertippen kannst, kannst du mir sicher auch verraten, warum der AVR keine mcall-Anweisungen ausführt. Danke
Wie wäre es mit dem hier: http://www.atmel.com/images/doc32000.pdf weiterhin: http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents und mit google kommst Du noch an viel mehr Informationen. Viele Grüße
Hey Roland, Auf der wiki benutzen die das Framework von Atmel überhaupt nicht. Funktionsaufrufe funktionieren aber bei mir ohne Probleme, zeig mal dein Projekt, Quellcode.
Paul schrieb: > Wie wäre es mit dem hier: http://www.atmel.com/images/doc32000.pdf > Hab ich schon. Dumm nur, dass Atmel vergessen hat, die in der Dukomentation genannten Register per Headerfile zugänglich zu machen. Aber vielleicht ist es ja auch nur von mir vermessen zu erwarten, dass ein Register, welches in der Dokumentation (z.B.) GCTRL genannt wird, dann in ASM/C/etc auch mit diesem Namen bearbeiten zu können. Wenn man bei Atmel tiefer gräbt, wird auf ASF verwiesen. Und dort hört die Doku bei der conf_board.h auf. Tolle Wurst. GPIO-API-Doku? Eine Liste der Funktionen und das wars. Keine Erläuterungen zu Parametern oder Strukturen. Von einem Beispiel ganz zu schweigen... Wenn Atmel an der Stelle schon ST kopieren will, sollen sie es bitte richtig machen... > weiterhin: > http://www.atmel.com/products/microcontrollers/avr... > Einen Großteil der Dokumente habe ich schon überflogen. Auch diese lösen das Grundsätzliche Problem nicht, dass Atmel in seinen Dokumenten auf Resourcen verweisst, welche nicht existieren, oder nicht funktionieren weil überholt. Selbst das o.g. verlinkte Wiki frickelt um das eigentliche problem drumrum und zaubert mit Informationen, deren Herkunft nicht genannt wird. (Mal ganz davon abgesehen, dass die dort verwendeten Treiber nicht vollständig, inkompatibel zum aktuellen Atmel Rest und damit für micht nutzlos sind). > und mit google kommst Du noch an viel mehr Informationen. > Ah. Toll. Gugel wirds schon richten. Nur gut, dass Atmel so treue Fans hat, die sich ihre Informationen selber suchen oder schreiben... Wenn du nicht weiterhelfen kannst, halte doch einfach die Pfoten still. Ich habe inzwischen selber rausbekommen, dass der Stack nicht passt, und er deswegen falsch springt. Schön nur, dass die startup_uc3.s mit mit Symbolen aus INTC.o kollidiert. (ich wusste doch, dass ich die wegen irgend welchen Fehlern mal aus dem Linker geworfen hatte...) Roland (der nach 3 Tagen AtmelNichtDoku die Schnauze gestrichen voll hat)
Roland schrieb: > Wenn du nicht weiterhelfen kannst, halte doch einfach die Pfoten still. Ach, das gejammer hoert ja immer noch auf. Wenn Du mal in der Industrie arbeitest, dann wirst Controller bekommen, welche so neu sind, dass nicht mal ein korrektes Datenblatt existiert. Du scheinst ganz schön verwöhnt und offenbar nervlich neuen Dingen nicht gewachsen zu sein. Ich bin übrigens auch mehr bei ST zu hause. Aber wenn Du dich über Atmel so aufregst, dann geh doch zur Polizei!
Ich bin durch äußere Umstände gezwungen, das tote Pferd zu reiten. Sonst hätte ich den Mist vor 2 Tagen schon atActa gelegt. es scheint halt irgend welche Entscheider zu geben, die als Kind mal mit Atmel gespielt haben, und das auch weiter tun wollen.
Du bist wirklich davon überzeugt, daß es allein Atmels Schuld ist, daß du nicht zurande kommst? Ich habe auch bisweilen Probleme mit unbekannten Dingen, aber dann Suche ich zuerst die Schuld bei MIR selber und meiner Auffassungsgabe... unfassbar. Bist du ein Beispiel für den aktuellen Bildungsstandort Deutschland? Daß es wenig Spaß macht, dir zu helfen oder es wenigstens es zu versuchen sollte dir einleuchten wenn du dir deine Ausdrucksweise noch mal durchliest, oder?
Vielleicht bin ich ja wirklich zu blöd für Atmel. Aber wenn ich mit ARM7, ARM9, Cortex, MSP und PIC (und dem jeweiligen User-Guide) klarkomme, ohne Nachfragen oder Gugeln zu müssen, legt das doch nahe, dass das Problem nicht nur bei mir liegt. Ansonsten: Wenn du zur Lösung nichts beitragen kannst: NUHR.
Hallo, nachdem etlich Vorwürfe geschrieben wurde habe ich das eigentlich Problem überhaupt nicht mehr raus finden könnnen... aber hier trotzdem einzwei Links die mir geholfen haben: https://www.kth.se/social/upload/300/Writing%20your%20own%20program%20(AVR32%20Studio)_pm_20100910.pdf http://blog.anujrai.com/2012/08/tutorial-1-getting-started-with-evk1105.html Vielleicht erweisen sie dir auch deinen Dienst. Grüße HenrY
Das aktuelle Problem ist immer noch die nicht vohandenen Dokumentation zum Atmel ASF. Und dort bei allem, was über die GPIOs hinaus geht. Das Problem davor (fehlerhafte Sprünge) war eine Folge der Mischung von #include <avr21/io.h> aus diversen verlinkten Beispielen und Teilen des ASF. Ist nämlich nicht mischbar, da dann nämlich die exeption.s und die startup_uc3.s kollidieren. Ohne startup keine Sprünge, und ohne exeption keine ISR. Also kann man entweder komplett ohne ASF arbeiten. Dann fehlt die Doku zu den Headern/Registerbezeichnungen aus io.h, oder komplett mit ASF, dann hört die Doku bei board_conf.h auf. Dass die Atmel-Jungs irgend wann den Faden verloren haben, sieht mans schon daran, dass vom Benutzer zu bearbeitende .h-Dateien nicht nur in ../config liegen. Roland
@Roland Wie kommt es eigentlich, dass ich unter: ...asf-3.4.1\avr32\drivers\gpio die Dateien gpio.c und gpio.h finde? Zugegeben die Dokumentation in .h haut keinen vom Hocker, aber wie bei Atmels üblich, sollte die Prozessordokumentation nicht weit weg sein. Die nicht existenten Beispiele fand ich unter: asf-3.4.1\avr32\drivers\gpio\?????_example z.B. in der Datei: gpio_local_bus_example. Übrigens unter: ...asf-3.4.1\avr32\drivers\ gibt’s jede Menge Sachen zu adc, gpio, usart jeweils mit .c .h und Beispiel. ...asf-3.4.1\avr32 Wie schon gesagt: Die Dokumentation ist wirklich nicht der große Bringer, aber manchmal hilft auch die Bibel. In der steht schon: Suchet so werdet Ihr finden.
Also so schwer ist es doch gar nicht mit ASF zu arbeiten, und für eine GPIO was willst da groß schreiben? Ich würde die Aufregung ja verstehn wenn es für irgendwelche Treiber wie z.b. USB Stack kaum Doku gäbe, aber für GPIO??? Wenn ich auf asf.atmel.com gehe, klick auf API, dann category: IO auswählen, Device als Beispiel UC3C bekomme ich alles was ich brauche: - Interrupt EIC - External Interrupt Controller - General-Purpose Input/Output - IOPORT - General purpose I/O service Als bsp IOPORT: IOPORT - General purpose I/O driver that includes functions for various I/O operations (set direction, set/get pin value, toggle pins etc.) Common API for XMEGA, UC3 and SAM. Darin: Einen Link zum Quickstart wie man diesen Service nutzt. Sogar ein Workflow ist beschrieben was man Schritt-Für-Schritt tun muß: http://asf.atmel.com/docs/latest/uc3c/html/ioport_quickstart.html Und die API zum Service: http://asf.atmel.com/docs/latest/uc3c/html/group__ioport__group.html Mehr braucht man für eine GPIO nun wirklich nicht. Anders sieht es bei komplexen Stacks aus, aber da finde ich das ASF vorbildlich: Als Bsp die USB CDC: http://asf.atmel.com/docs/latest/uc3c/html/udi_cdc_quickstart.html Steht alles Schritt für Schritt drin wie man den USB CDC nutzt, anschaulich mit Beispielcode beschrieben und gut kommentiert. Ich habe meine Applikation zunächst auf dem AVR32 geschrieben mit Hilfe des ASF, ein Port auf den SAM3 war recht einfach. Meine ganze Applikation blieb unverändert, geändert wurden lediglich low-level Treiber. Selbst mein USB Beispiel sieht gleich aus auf dem Xmega, AVR32 und SAM3. Das einzige was Xmega/AVR32 und SAM3 unterscheidet ist dass ich im board init die Peripheral Clocks zuschalten mußte da diese beim Xmega von einem Clock getriggert werden, die Pin-Zuordnung geändert und das wars. Ich weiß nicht wozu das Geschrei :-D Die Doku finde ich richtig gut bei Atmel. Vergleicht dazu mal eine NXP LPC11xx Doku..
Erst mal danke an alle, die versuchen zu helfen. (Is letztes WE etwas kurz gekommen... reine Nervensache) > ...was über die GPIOs hinaus geht. Wenn es nur die GPIOs, Clocks und IRQs wären, bräuchte ich das ASF nicht. Sicher ist es theoretisch möglich sich durch die 5..8 Header-Dateien zu graben. Das Problem daran ist: Es dauert einfach zu lange, bis man die benötigten Inforamtionen richtig interpretiert hat. In eine .h-Datei gehört die Info, wie eine Funktion zu benutzen ist, was sie macht und wie die Parameter ggf aussehen. Dann solten noch die Kommentare konsistent in Sachen Bezeichner sein. Um mal bei der gpio.h zu bleiben: > \name Common defines for GPIO_FLAGS parameter Das Wort 'parameter' taucht in der ganzen Header-Datei nur ein einziges mal auf. In der zitierten Stelle. Ich muss mir dann denken, wann 'flags' = 'parameter' ist. Da sind dann kleine Inkosequenzen wie init-blah-gpio(DEF_GPIO...) vs init_blah-uart(&DEF_UART...) schon fast harmlos. Dass man bei der UART dann schon eher hellsehen muss, was als Größenangabe für das Array rein muss ist dann schon wieder mangelhaft. USB oder Ehternet brauche ich hier ausnahmsweise mal gerade nicht... ;) Dafür darf ich bei der UART/SPI jetzt weiterraten, ob und wie eine bidirektionale Komunikation geht, ohne dass ich die selber dengeln muss. Den bei den pu/get ist auch (mal wieder) nicht dokumentiert, wie sich die Funktionen verhalten. Und ohne Debugger ist das b******t. Wenn ich so arbeiten würde, wär ich schon lange rausgeflogen... Ich mach jetzt hier an der Stelle Schluss in dem Thread, das artet sonst zu sehr aus.
ttl schrieb: > Wieso willst du jetzt lernen ein totes Pferd zu reiten? Nimm irgendeinen > ARM und gut ist Weil ich die UC3 besser finde als z.B. einen Cortex M4 (Wobei ich STM noch besser finde als z.B. TI). Ein UC3A0512 mit 32MB SDRAM ist eine ganz feine Sache. Während man mit den Cortex M4 nicht weit über Blinky-Projekte rauskommt, hat man mit dem UC3 schon fast einen PC zur Verfügung. Ganz vergessen kann man die Billig-Emulatoren der ARM-Starter-Boards. Beschränkte Anzahl Breakpoints, nicht während dem Programmlauf setzbar usw. Roland (Gast) schrieb > Das aktuelle Problem ist immer noch die nicht vohandenen Dokumentation > zum Atmel ASF. Niemand zwint Dich dazu, das ASF zu benutzen. Ich benutze das AVR32 Studio 2.7.0 Das Framework dazu ist besser dokumentiert als die Libs zu den meisten ARM. Umfangreicher sowieso. Obwohl das AVR32 Studio 2.7.0 auch auf Eclipse aufsetzt, läuft es inzwischen wesentlich stabiler als z.B. das CCS5 von TI. Auch das Atollic ist wirklich nicht der Bringer. Also, auch beim ASF gibt es genügend Beispiele zur Programmierung der UC3. Wer sich diese Beispiele anschaut, hat keine Probleme mit der Programmierung der UC3. Aber ich verstehe schon, Datenblatt duchlesen ist uncool, Beispiele anschauen erst recht. Lieber bei facebook den Status aktualisieren und andere Leute bei mikrocontroller.net mit immer den gleichen Fragen nerven.
Roland schrieb: > dann zeige mir das ASF-Beispiel für sysclk. Immer wieder die gleichen Fragen. Wenn Du bei Atmel "sysclk" oder "I2C" suchst, wirst Du genauso scheitern wie bei Texas Instruments mit "SPI". Deshalb Beispiele anschauen. Der cycle_counter ist nahezu in jedem Beispiel eingebunden. Das spezielle Beispiel dazu heißt "CPU Cycle counter example" und ist wesentlich umfangreicher als die ARM-Beispiele zum sysclk. AT32UC3 ist nichts für ARMe ;-)
Liest du eigentlich durch, was du beantwortest? Ich suche Informationen zum sysclk-Treiber (.c/.h). Ich hege inzwischen den Verdacht, dass dessen Funktionalität sich mit PM (.c/.h) überschneidet, und möchte das gern nachprüfen. Kein Mensch redet hier von cycle_counter. Dessen Beispiele kommen nämlich allesamt ohne sysclk aus.
mmmh ich finde zu den sysclk auch keine direkten Beispiele... UC3 schrieb: > spezielle > > Beispiel dazu heißt "CPU Cycle counter example" wirklich ? weil da ist die sysclk (.c/.h) gar nicht erst mit drinne... ich hatte selbst mal die einfachen funktionen der sysclk benutzt, sysclk_init() und sysclk_get_cpu_hz()... da gibts auch noch das system control interface (scifa) wo du auch noch einiges einstellen kannst ;) aber vielleicht brauchst du die sysclk auch gar nicht und kannst das über PM und SCFI erledigen, was du auch immer vorhast...
Ich wollte ja gern nachprüfen, ob ich über PM das selbe einstelle, wie über SYSCLK und die zugehörige .conf. Die sysclk ist nämlich komfortabler als die riesigen Strukte, die PM verwendet. Durch die fehlende InCuircit-Debugging kann ich aber nicht in die Register gucken, und durch den Wust von .h und .c-Files wühlen dau3ert ja Wochen... Ich glaube auch, dass man das Gebrabbel von "UC3" nicht so ernst nehmen muss. Das war nur ein Reflex, weil hier über seine geliebte Architektur geschimpft wurde...
mmmhh.... okay, dann gebe ich zu kann ich dir nicht weiter helfen... (mein wissen ist da einfach zu beschränkt.... auch wenn ich mit ihm (uc3c) seit 5 wochen arbeite) vielleicht mal bei avr freaks... nach fragen ?!
Hey Roland, ich bin eben auf einen Beitrag auf avrfreaks gestoßen der unteranderem das behandelt wo nach du suchst... http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=116711&start=0
>In eine .h-Datei gehört die Info, wie eine Funktion zu benutzen ist, >was sie macht und wie die Parameter ggf aussehen. Das ist ein philosophisches Problem! Du kannst eine Header-Datei schreiben, aber Du kannst auch einen Roman verfassen. Der erste, der den liest, sagt dann aber: "Das gehört doch in den Source-Code rein. Wer sucht denn das in der Header-Datei!". Und der nächste: "Es geht doch nichts über ein gepflegtes Manual". Die 99€-Frage lautet also: "Wer hat den nun recht"?
> Der erste, der den liest, sagt dann aber: "Das gehört doch in den > Source-Code rein. Wer sucht denn das in der Header-Datei!". Dann hat derjenige was falsch gemacht. Denn nicht immer ist der Source-Code als .c-Datei verfügbar. In vielen (kommerziellen) Produkten werden die .c-Files vorkompiliert als Lib mitgeliefert. Man macht ja schließlich auch ein #include <blah.h> und nicht <blah.c> Das "Problem" hat sich zwischenzeitlich erledigt, das tote Pferd ist jetzt beim Abdecker...
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.