Ich habe bisher Atmel 8bitter mit Assambler im Atmel Studio
programmiert.
Jetzt versuche ich bei einem Atmel SAM C zum ersten Mal das ASF zu
verwenden.
Mein Problem ist, dass die Methoden aus den Tutorials nicht von meiner
IDE erkannt/unterstützt werden.
Ich habe ein "ASF Project" ausgewählt. Ich habe meinen Prozessor
"ATSAMC20J18A" ausgewählt und für meine Eigenbauplatine "Custom Board"
gewählt.
Obwohl ich mit ASF Wizard fast alle Peripherie Module eingebunden habe,
bietet die automatische Vervollständigkeit keinerlei Methoden an.
Ich habe in diversen Tutorials gelesen, dass die GPIO's zum Beipiel mit
"ioport" angesprochen werden. Aber auch "ioport" wird nicht angeboten.
In den Tutorials wird ebenfalls ausschließlich "asf.h" eingebunden.
Aber wieso scheinen keine der vom Wizard eingebundnen Module tatsächlich
eingebunden zu sein?
Hier ist mein Testprogramm bis jetzt. Ich weiß, dass es noch
unvollständig ist. Mir geht es momentan nur darum, dass sich die IDE
nicht mehr über die nicht definierten "ioport"-Methoden beschwert.
Interessant, dass die erste Antwort in diesem Forum immer von oben herab
ist
....aber ich dachte das es wohl reichen müsste das Atmel Studio in
meinem Post nur einmal zu erwähnen, nicht wahr?
F. K. schrieb:> Assambler
So, so, Assambler also...
> im Atmel Studio
Gibt ja nur eines davon.
F. K. schrieb:> meinem Post nur einmal zu erwähnen, nicht wahr?
Schreibst Du welche Version und vielleicht Antworten Du bekommst.
Installier's halt nochmal mit allen Optionen und gut ist's.
MWS schrieb:> Gibt ja nur eines davon.
Die Version ist 7.0.790
MWS schrieb:> Schreibst Du welche Version und vielleicht Antworten Du bekommst.
Und wenn ich nicht der Meinung bin, dass die Version wichtig ist, andere
aber schon, kann man nicht normal nach der Version fragen?
MWS schrieb:> Installier's halt nochmal mit allen Optionen und gut ist's.
Wenn ich schonmal dabei bin, könnte ich doch gleich alle Rechner in der
Strasse neu installieren.....vielleicht hilfts....
F. K. schrieb:> Und wenn ich nicht der Meinung bin, dass die Version wichtig ist, andere> aber schon, kann man nicht normal nach der Version fragen?
Könnte man, aber warum? Du suchst Hilfe, es ist Dein Job das Problem so
genau wie möglich zu beschreiben, wozu eben auch die Version gehört. Es
ist eine Zumutung dem Hilfesuchenden die Würmer einzeln aus der Nase
ziehen zu müssen.
Die Reaktion war jetzt nicht superfreundlich, jedoch verständlich.
> Wenn ich schonmal dabei bin, könnte ich doch gleich alle Rechner in der> Strasse neu installieren.....vielleicht hilfts....
Mit solchen frotzeligen Erwiderungen hast Du im Nu viele Freunde.
Abgesehen davon dürfte der Weg einer Neuinstallation der einfachste
sein. Warum sollten jetzt andere Leser große Mühe reinstecken, aufgrund
Deiner mangelhaften Angaben den Fehler zu erraten, wenn Du Dir nicht mal
die kleine Mühe machst, eine Neuinstallation zu versuchen?
MWS schrieb:> wenn Du Dir nicht mal> die kleine Mühe machst, eine Neuinstallation zu versuchen?
Ich hätte da eine Erklärung dafür: die Neuinstallation ist
in der Tat eine Qual, das tut man sich nicht so einfach mal
schnell wieder an.
Aber wenn das ASF womöglich fehlt muss es wohl sein.
MWS schrieb:> Mit solchen frotzeligen Erwiderungen hast Du im Nu viele Freunde.> Abgesehen davon dürfte der Weg einer Neuinstallation der einfachste> sein. Warum sollten jetzt andere Leser große Mühe reinstecken, aufgrund> Deiner mangelhaften Angaben den Fehler zu erraten, wenn Du Dir nicht mal> die kleine Mühe machst, eine Neuinstallation zu versuchen?
Man könnte die Argumentation auch umdrehen. Warum soll ich mir die Mühe
machen, jede fitzelige Kleinigkeit rauszusuchen und zu beschreiben, wenn
sowieso zu 99% die Antwort kommt "Ja, installier doch einfach neu"?
Ministerial Beamter schrieb:> Aber wenn das ASF womöglich fehlt muss es wohl sein.
Ich konnte das ASF Plugin über die Erweiterungsfunktion ohne Fehler in
die IDE integrieren. Es war auch recht eindeutig, dass das ASF in der
Projektartauflistung bei "neues Projekt" erst nach der Installation des
Plugins auftauchte und damit auswähltbar war. Ebenfalls ohne
Fehlermeldung.
Es macht eher den Eindruck, dass irgendwo ein Häkchen fehlt.
F. K. schrieb:> Man könnte die Argumentation auch umdrehen. Warum soll ich mir die Mühe> machen, jede fitzelige Kleinigkeit rauszusuchen und zu beschreiben, wenn> sowieso zu 99% die Antwort kommt "Ja, installier doch einfach neu"?
Nein, umdrehen geht nicht. Es ist Deine Verantwortung die Details
ausführlich anzugeben, weil nur Du es bist, der etwas will, die anderen
wollen nichts von Dir.
Warum soll sich andere Personen {Elternteile ausgenommen) die Mühe
machen, wenn sie nichts davon haben und der Fragesteller sich noch dazu
wie ein bockiges Kind verhält?
F. K. schrieb:> Jetzt versuche ich bei einem Atmel SAM C zum ersten Mal das ASF zu> verwenden.>> Mein Problem ist, dass die Methoden aus den Tutorials nicht von meiner> IDE erkannt/unterstützt werden.
Aha, du willst die Methoden des Tutorials nachempfinden. Nun, dann guck
doch in deinem Studio, ob sich die Quellen der von dir herangezogenen
Moduln finden. Bei manchen Teilen (z.B. FatFS) kann man auch direkt beim
eigentlichen Hersteller (Chan..) nachschauen. Bei anderen Moduln (FIFO
usw.) frag ich micht, wozu eigentlich.
Generell gilt, daß du auf irgend eine Weise die Header und die Quellen
oder Libs von solchem Zeug in deine Projektquellen hineinkriegen mußt -
und das unabhängig von irgend einer IDE. schließlich muß nicht die IDE
das Zeugs finden, sondern der Compiler, Assembler und Linker.
Also such auf deiner Festplatte einfach nach dem eigentlichen Beef.
W.S.
MWS schrieb:> Warum soll sich andere Personen {Elternteile ausgenommen) die Mühe> machen, wenn sie nichts davon haben und der Fragesteller sich noch dazu> wie ein bockiges Kind verhält?
Ich reagiere allergisch, wenn bei jedem Thread erstmal das Haar in der
Suppe gesucht wird und in einer herablassenden Weise nach informationen
gefragt wird. Nur um dann hinterher die unprofessionelle
Standard-Antwort zu bekommen "Ja,installier doch einfach neu". Für diese
Antwort war die Information mit Sicherheit nicht notwendig.
Ich soll bockig reagieren? Auf Nachfrage nach der Version habe ich die
Information geliefert. Und hast du damit jetzt schon etwas anfangen
können und mir einen Lösungs-Hinweis gegeben?
Der einzige der hier bockig und auf Konfrontation aus ist, bist du.
W.S. schrieb:> Generell gilt, daß du auf irgend eine Weise die Header und die Quellen> oder Libs von solchem Zeug in deine Projektquellen hineinkriegen mußt
Das ist ja der Punkt, der mich irritiert. Laut dem Tutorial soll es
ausreichen, wenn der ASF Wizard den "Port-Treiber" einbindet.
In meinem ASF Wizard (Version 3.38.0) gibt es nur einen Eintrag, der
"Port" im Namen hat. Wenn ich diesen Einbinde, erscheint im Projekt
Explorer "port.c" und "port.h". Ich kann dann auch Methoden aus dieser
Lib verwenden. Wenn ich die Methoden so durchscrolle, müsste auch alles
da sein, um die Ports konfigurieren und ansprechen zu können.
Laut den Tutorials soll aber eigentlich Methoden aus der Kategorie
"ioport" verwendet werden. Nur "port" soll veraltet sein. Der Wizard
inkludiert allerdings keine Lib mit "ioport" Methoden.
In den Tutorials wird ja nie erwähnt, wie die Lib heißt. Dort wird diese
"Arbeit" immer dem ASF Wizard zugeschanzt. Daher weiß ich auch nicht,
wie die Lib eigentlich heißt, die fehlt.
Falls sich keine Antwort findet, versuche ich natürlich, ob ich es mit
den "port" Methoden hinbekomme.
MUSS es denn ASF sein, um eine LED blinken zu lassen?
ASF ist etwas für Leute, die zu faul sind, sich mit einem
Mikrokontroller auseinanderzusetzen, und die glauben, sich ein Projekt
aus 10 Mausklicks zusammenzuklicken. Ungefähr so wie mit Arduino.
Dem ist aber leider nicht so.
Sobald es zu einem noch so kleinen Problem mit ASF oder auch diesen
ganzen Demoprojekten kommt, stehst Du da wie ein Ochs vorm Berg und
darfst hunderte von Files und Funktionen durchforsten, nur um irgendwo
ein doofes Bit einer Peripherieeinstellung zu finden. Dinge wie einfache
Portbits sind im ASF gefühlte 50mal umdefiniert. Nur damit sich ein
Projekt angeblich vom 8Bitter bis zum 32Bitter verwenden lässt. Der
schlimmste Dreck des Jahrhunderts und die Dokumentation (sofern
überhaupt existent) ist hahnebüchen.
Wenn man z.B. ein Projekt kopieren will oder es in einem anderen
Verzeichnis abzuspeichern, findet Atmel Studio danach den Pfad zu diesem
ganzen ASF-Mist nicht mehr. Lösungen zum einfachen Duplizieren von
Projekten -> Fehlanzeige.
Wenn man einem Bekannten ein "Projekt" schicken soll, bei dem die
genannte LED blinkt, muss man dem 200 Megabytes an inkludierten Dateien
schicken. Also "maile mir mal schnell das Projekt" ist nicht.
Ich spekuliere mal jetzt und behaupte dass ein Umsteiger von Assembler
zu ASF unglücklich werden wird..
Hey F. K. (superpcfan),
könntest du mal von deinem Projekt die *.cproj Datei hochladen?
Sollten die benötigten Dateien dort gelistet sein, könnte es vielleicht
mit dem "VAssistX" zusammenhängen, aber dafür lege ich jetzt erstmal
nicht meine hand ins Feuer.
Wie schaut es denn aus, wenn du ein Bsp.-Projekt öffnest, bekommst du
dort die Vervollständigung angezeigt?
@Joachim:
Ich bin vollständig deiner Meinung, dass diese gefühlten 50
Abstraktionsebenen unnützer Ballast sind.
Allerdings bin ich in Assembler auf das Problem gestoßen, dass aufgrund
der komplexeren Hardware der 32bitter die Registeradressen nicht mehr so
einleuchtend (beschrieben) und im Header referenziert sind.
Ich hatte also die Wahl mich in die Registeradressierung (Assembler)
oder in die Abstrakten Methoden des ASF (C++) einzulesen. Ich war/bin
Neugierig auf die Abstraktionsebenen, weil ich diese noch nie verwendet
habe. Deshalb habe ich mich für ASF entschieden. Ich wollte mal sehen,
wie gut sich ein µC in einer Hochsprache programmieren lässt und was das
für Auswirkungen auf das Systemverhalten hat.
Ich möchte schon mehr mit dem µC machen, als LEDs blinken zu lassen.
Später kommt i2c, usart, ein spi-lcd, dma, eine SD-Karte,
Quadraturdekodierung, externe interrupts usw. dazu. Das ist nur ein
erstes Testprogramm, um die redumentäre Handhabbarkeit des ASF zu
testen.
Adam P. schrieb:> könntest du mal von deinem Projekt die *.cproj Datei hochladen?
Habe ich hochgeladen.
Adam P. schrieb:> Wie schaut es denn aus, wenn du ein Bsp.-Projekt öffnest, bekommst du> dort die Vervollständigung angezeigt?
Die Autovervollständigung selbst scheint nicht das Problem zu sein. Die
ist aktiv und enthält auch alle inkludierten Libs. Allerdings scheint
speziell die öminöse ioport Lib (die ich mir zum testen rausgepickt
habe) Probleme zu machen.
Wenn ich ein Beispielprojekt zum SAM4C (zum SAMC20 ist keines da) öffne,
ist ioport.h da und das Projekt lässt sich auch kompilieren.
Wenn ich allerdings selber ein ASF Projekt mit dem SAM4C anlegen lasse,
ist im ASF Wizard kein Modul für ioport da. Sprich die Lib lässt sich
auch dann wieder nicht über den Wizard inkludieren.
Ich müsste jetzt also manuell die ioport.h referenzieren.
Wenn ich schon bei der einfachen Port-Handhabung manuell die Libs und
die Doku suchen muss, kann ich mich auch in die Registeradressierung für
Assembler einlesen. Das ASF ist mir im Moment noch nicht sonderlich
sympatisch. :)
F. K. schrieb:> Wenn ich ein Beispielprojekt zum SAM4C (zum SAMC20 ist keines da) öffne,> ist ioport.h da und das Projekt lässt sich auch kompilieren.
Ich habe es jetzt mal selbst probiert und dein Problem erkannt.
> Wenn ich allerdings selber ein ASF Projekt mit dem SAM4C anlegen lasse,> ist im ASF Wizard kein Modul für ioport da. Sprich die Lib lässt sich> auch dann wieder nicht über den Wizard inkludieren.
Das mit dem "SAM4C" kann hier so nicht stimmen.
Das Problem ist, dass es für den SAMC20 kein ASF-Service gibt, der
"ioport"-Funktionen bereitstellt.
Es gibt im ASF "Driver", auf die aufbauend kommen dann die "Service"
Module.
Kurz zusammengefasst:
µC Driver Service
------------------------------------
SAM4C PIO ---
SAMC20 PORT GPIO / IOPORT
Kannst ja selbst mal die Unterschiede vergleichen:
http://asf.atmel.com/docs/3.35.1/index.html
Deshalb sind gewisse Dinge beim SAM4 vorhanden die es beim SAMC20 nicht
gibt.
Vllt. hilft dir ja das "Atmel-Start" weiter?
Datei -> Neu -> Atmel Start Project
oder
http://start.atmel.com
Leider ist das nun bestimmt nicht die Antwort die du erwartet hast...
Gruß
Danke für das Reinschauen. Ich habe schon vermutet, dass ASF doch
gravierende Unterschiede zwischen eigentlich ähnlichen µC macht.
Mich wundert allerdings, wozu die Abstraktionsebenen nützlich sind, wenn
dann am Ende doch nicht für alle Controller eine einheitliche
Interface.lib verwendet werden kann.
Letzten Endes könnte ich ja auch mit dem "Port" Driver arbeiten. Nur
immer wenn ich nach "ASF Tutorial Port" google, lande ich bei einer
Beschreibung für die "ioport"-.lib. Wenn ich dann doch mal auf der Atmel
Seite lande, geht dort nicht so klar der Unterschied zwischen Driver und
Service hervor und was für welchen µC gilt.
Mit deiner Erklärung und der von dir verlinkten Seite wird klarer,
wonach ich schauen muss. Auf der Seite sind alle Treiber und Services
strukturiert gelistet und ich weiß jetzt, warum manche libs nicht da
sind. Dort ist ja auch eine (zumindest rudimentäre) Beschreibung der
port.lib vorhanden, mit der ich versuchen kann, den Treiber direkt ohne
den Service zu verwenden.
Danke
F. K. schrieb:> Ich hatte also die Wahl mich in die Registeradressierung (Assembler)> oder in die Abstrakten Methoden des ASF (C++) einzulesen.
Es wird wohl noch ein Zwischending geben zwischen asm und asf. Ich bin
mir sicher die Atmel Controller kann man auch weiterhin wie schon seit
Eh und je in ganz normalem C programmieren, mit Datenblatt auf der
rechten Seite offen und den Registerdefines im include. Ganz ohne
"Framework".
F. K. schrieb:> die Abstrakten Methoden des ASF (C++)
Das ASF ist C, nicht C++. Wenn du in einem C++ Projekt den ASF-Wizard
oeffnest, gibt es eine Warnung.
F. K. schrieb:> Mich wundert allerdings, wozu die Abstraktionsebenen nützlich sind, wenn> dann am Ende doch nicht für alle Controller eine einheitliche> Interface.lib verwendet werden kann.
Ja das ist wohl so eine ASF Geschichte...
Jeder Hersteller versucht sein bestes und bei der Anzahl an µC, mach ich
den auch kein Vorwurf - denn Atmel war immer schnell mit den Bug-fixes,
wenn man sie gemeldet hat.
Ich hatte auch schon Probleme mit der USB oder HSMCI (SD) "Lib".
Da bleibt einfach nichts anderes übrig als Datenblatt lesen, und evtl.
die fehlende Funktionalität nachpflegen.
...Oder sich das Datenblatt zur Hand nehmen und eine eigene Lib zu
schreiben, die auf das System und auf die Anforderungen zugeschnitten
ist (ohne Overhead).
Schön wäre eine "Interface.lib", jedoch ist es anscheinend nicht so
einfach zu lösen... man nehme schon alleine die Unterschiede bei der PDC
Nutzung der µc SAM4E und SAM4L...
Der eine hat je Peripherie reservierte PDC bereiche (Register), der
andere einzelne PDC die man erst mit der Peripherie verbinden muss...
obwohl SAM4-Familie... so schnell kanns gehen.
Aber wenn man erstmal die Ecken und Kanten kennt, dann weiß man wo man
schauen muss.