Ja, ihr habt richtig gelesen, schon wieder ein "Anfänger" der etwas Starthilfe sucht ;-) Eine kurze Vorstellung inklusive Vorkenntnisse: -Knowhow eher im analogen Kleinsignalbereich -Grundkenntnisse (Uni Kurs) in ASM und Mikorkontroller Strukturen -etwas Java (aber gerade bei Projektorientierung stieg ich dann irgendwo aus). -Spielereien mit Arduino Ziel: -Der AD Wandler des ATmega E5 soll maximal "ausgequetscht" werden bezüglich der Genauigkeit (Hochgesetztes Ziel ist das Auswerten eine DMS Brücke). Temperatur und eine FFT mit Daten eines anderen ADC Kanals sollen auch ausgewertet werden (FFT keinesfalls in Echtzeit!). Wichtig sind zunächst die Grundfunktionen, einen genauerer ADC oder ein spezieller Sensorchip kann dann immer noch folgen. Das Ganze ist in ein kleines Forschungsprojekt eingebettet, es soll also nix „verkauft“ werden. Mein Probleme: Ich habe einige gut geschriebene Tutorials hier gelesen und habe mittlerweile ein Grundverständnis dafür bekommen, was die Arduino Software mir alles an hardwarenahen Aufgaben abgenommen hat. Nachdem ich aber AVR Studio installiert habe und mir mal bestimmte Beispiele angesehen habe (Besonders: ADC Xmega ADC Calibration) fing ich an mit den Ohren zu schlackern. Mir scheint, dass die Verschachtelung von Funktionen doch einige Ebenen über dem bloßen Ansteuern der Register liegt. Bei allen Beispielprogrammen frage ich mich als immer: Wie komme ich darauf, dass ich genau dieses Packet benötige? Haltet ihr es für Sinnvoll sich stark an den Beispielen per Copypaste zu orientieren oder würdet ihr in meinem Fall das Programm von "neu auf" schreiben und zwar "näher" an der Hardware? Gibt es eine von mir übersehene Hilfe, wo genau dokumentiert ist, für welche "Standardfunktionen" welche Pakete benötigt werden? In folgende Codezeilen habe für mich schon Fragezeichen aufgeworfen. Damit meine ich nicht den Code an sich, sondern dass ich nie auf die Idee gekommen wäre die Befehle mit diesem Namen in dieser Reihenfolge aufzurufen. ____________________________________________________________________ static void main_dac_init(void) { /* DAC module configuration structure */ struct dac_config dac_conf; /* Create configuration: * - AVCC as reference * - right adjusted channel value * - both DAC channels active on : * - DAC0 (PA2 pin) for ADC V+ * - DAC1 (PA3 pin) for ADC V- * - manually triggered conversions on both channels */ dac_read_configuration(&DACA, &dac_conf); dac_set_conversion_parameters(&dac_conf, DAC_REF_AVCC, DAC_ADJ_RIGHT); dac_set_active_channel(&dac_conf, DAC_CH0 | DAC_CH1, 0); dac_set_conversion_trigger(&dac_conf, 0, 0); dac_write_configuration(&DACA, &dac_conf); dac_enable(&DACA); }_____________________________________________________________________ Dieser "Stil" zieht sich aber durch fast alle Beispiele... Für jeden Input und Literaturtipp bin ich euch Dankbar!
Das ist gerade der Punkt beim Arduino. Man lernt damit eher "Programmieren" soweit sich der Begriff auf eine gedankliche Gliederung des Ablaufs und des Transports und der Verrechnung von Daten bezieht. Das ist sehr wertvoll und man kann darauf aufbauen. Ein wenig C kann man damit auch schon. Man muss aber auch sehen, dass die Arduino-Umgebung mit den mitgelieferten Libraries und Funktionen geradezu dazu gedacht ist, den Programmierer von Implementierungsdetails zu isolieren - wie genau und in welcher Reihenfolge am besten die Peripherie zu initialisieren und zu benutzen ist. Davor hat Dich die Arduino-Umgebung sozusagen "bewahrt". Dafür ist sie gedacht. Diesen Schritt, zu verstehen was hinter den Libraries steckt, stehst Du jetzt und davor C so zu vertiefen, dass Du solche Dinge selbst schreiben bzw. fertige Libs auch verstehen und benutzen kannst ohne das es dazu vorgefertigte Beispiele und ausführliche Erklärungen gibt. Aus meiner Sicht ist es empfehlenswert, sich am Beispiel der Tutorials hier zunächst einmal mit den grundlegenen Dingen zu beschäftigen. LED ansteuern, Taster abfragen, LCD ansteuern etc. Alles was die Arduino-Lib zuvor für Dich und an Deiner Stelle getan hat. Da klären sich auch viele Fragen die Du oben gestellt hast. Das AVRStudio kannst Du ruhig benutzen. Es ist kein "Overkill" sondern eben einfach eine IDE. Der wesentliche Unterschied zum Arduino ist, das die vorgefertigten Libraries fehlen. Viel Erfolg.
Stefan schrieb: > Haltet ihr es für Sinnvoll sich stark an den Beispielen per Copypaste zu > orientieren oder würdet ihr in meinem Fall das Programm von "neu auf" > schreiben und zwar "näher" an der Hardware? Würde ich nicht unbedingt versuchen, außer Du kennst schon jedes Bit in jedem SFR des Controllers. Oder willst es kennenlernen und liest dich komplett in die Deteils im Datenblatt ein. > Gibt es eine von mir übersehene Hilfe, wo genau dokumentiert ist, für > welche "Standardfunktionen" welche Pakete benötigt werden? Ja, die ASF-Online-Doku (siehe Link weiter unten in diesem Beitrag) > In folgende Codezeilen habe für mich schon Fragezeichen aufgeworfen. > Damit meine ich nicht den Code an sich, sondern dass ich nie auf die > Idee gekommen wäre die Befehle mit diesem Namen in dieser Reihenfolge > aufzurufen. Das Beispiel verwendet das ASF (Atmel Software Framework), das für die verschiedenen Controller-Familien eine vereinheitlichte API bietet. Gerade als Einsteiger ist es nicht die dümmste Idee, es mal mit dem ASF zu versuchen, anstatt alle seine Treiber auf Registerlevel selbst zu schreiben. Die ASF-Dokumentation für die XMEGA-E Familie findet sich übrigens hier: http://asf.atmel.com/docs/latest/search.html?device=xmegae Das ist eine komplett verlinkte Online-Doku, wo man sich von der Aufgabe (DAC verwenden) über Links Beispiele, die API-Doku usw. aufrufen kann. Die API-Doku für den XMEGA DAC findet sich z.B. hier: http://asf.atmel.com/docs/latest/xmega.drivers.dac.example1.stk600-rc032x_atxmega32e5/html/group__dac__group.html Da sind genau die Funktionen dokumentiert, die in deinem Beispiel aufgerufen werden, um den DAC zu initialisieren.
Wenn ich das richtig verstehe, ersetzt das ASF (Atemel Software Framework) im Prinzip die "vereinfachte" Arduino Sprache? Ich muss mich also Entscheiden, ob ich hier und da direkt "Hardwarenahe" arbeite oder eben die vollen Funktionen des ASF verwende?
Ja, du kannst auch komplett auf die Arduino Libraries und die ASF Libraries verzichten.
Stefan schrieb: > Wenn ich das richtig verstehe, ersetzt das ASF (Atemel Software > Framework) im Prinzip die "vereinfachte" Arduino Sprache? > > Ich muss mich also Entscheiden, ob ich hier und da direkt "Hardwarenahe" > arbeite oder eben die vollen Funktionen des ASF verwende? Im Prinzip ja. Das ASF abstrahiert von der Hardware, genau wie das Arduino-Framework. Es schadet nichts, sich das mal anzuschauen und damit zu arbeiten. Die Entscheidung schiebst Du eben solange auf. Du musst Dir halt bewusst sein, das solche Libs in dem Bestreben veröffentlicht werden, es dem Benutzer einfach zu machen. Diese Isolation und Abstraktion ist ein Vorteil und ein Nachteil gleichermaßen. Du lernst im Grunde nur eine zweiten Abstraktionsmechanismus neben der Arduiono-Variante kennen. Aber eben nicht die HW-Ebene. Das folgende ist kontrovers: Man sollte die unterste Ebene zumindest einmal im Leben praktisch nachvollzogen haben - vielleicht mit einem der einfacheren AVRs. Dann ist man nicht so zwingend darauf angewiesen. Ausserdem zwingt das auch die Tiefen von C zu lernen. Stichwort: Bitmanipulation. Ich benutze auch für ARM die CMSIS. Aber ich habe auch oft Bauchschmerzen damit (das fängt beim oft unnötigen Overhead an) und bastele mir was eigenes oder greife direkt zu.
Stefan schrieb: > Wenn ich das richtig verstehe, ersetzt das ASF (Atemel Software > Framework) im Prinzip die "vereinfachte" Arduino Sprache? So würde ich das jetzt nicht unbedingt formulieren. Da ASF ist eine Bibliothek für die verschiedenen Hardware-Einheiten des Mikrocontrollers. Du kannst sie benutzen, mußt es aber nicht. Selbst in einem Programm kannst du ggf. Teile des Controllers übers ASF ansprechen und andere Teile "zu Fuß" auf Registerebene. Wenn du die Funktionen aus dem ASF benutzt, sparst du dir die Entwicklung eines eigenen Treibers. Mit dem Vorteil, daß die ASF-Routinen normalerweise fehlerfreu funktionieren. Wenn dann etwas nicht funktioniert, fällt der Treiber als mögliche Fehlerquelle also schonmal praktisch raus. > Ich muss mich also Entscheiden, ob ich hier und da direkt "Hardwarenahe" > arbeite oder eben die vollen Funktionen des ASF verwende? Ja. Aber du kannst diese Entscheidung von Fall zu Fall treffen. Man sollte nur nicht an einer Peripherie "zu Fuß" rumfummeln, wenn man an anderer Stelle mit ASF Funktionen auf dieselbe Peripherie zugreift. Ansonsten kann man das in einem Programm auch mischen. Ich würde allerdings empfehlen, für den Einstieg erstmal vollumfänglich die ASF Funktionen zu verwenden. Das macht die Sache leichter. Es entbindet einen zwar nicht von der Pflicht, den entsprechenden Abschnitt im Datenblatt zu lesen und zu verstehen, bevor man eine Peripherie wie den DAC programmiert, aber man muß sich dann nicht mehr um jedes Bit einzeln kümmern, sondern kann den DAC mit ein paar Funktionsaufrufen (und entsprechender Parameterübergabe) konfigurieren.
Zunächst möchte ich mich für die weiteren Antworten von Bitflüster und Thorsten bedanken! Am Wochenende habe ich hier nicht reingeschaut "Arbeit Arbeit" sein lassen und das Wochenende auf dem Fahrrad genossen. Mit frischem Wind bin ich dann nochmal ins AVR Studio gegangen und habe auch dort bemerkt, dass die ASF Doku Verlinkung einem eigentlich ins Auge springen sollte. >Ja. Aber du kannst diese Entscheidung von Fall zu Fall treffen. >Man sollte nur nicht an einer Peripherie "zu Fuß" rumfummeln, wenn man >an anderer Stelle mit ASF Funktionen auf dieselbe Peripherie zugreift. Dazu kann ich jetzt schon eine fast konkrete Frage formulieren: Wie sieht es denn mit dem ASF Sleep Manager aus (Erinnert mich etwas an den ACPI Table eines Rechners). Sobald ich diesen verwende, ist es dann zwingend auch die anderen ASF Libaries zu verwenden, damit eine "Komunikation" stadtfindet? Auch wenn ich noch nicht ganz so weit bin, probiere ich mir vorzustellen, wie eine "relativ schnelle" ADC Wandlung vonstatten geht: CPU schlafen legen (Endlich Ruhe auf der Versorungspannung denkt sich der ADC) -> Sampeln -> CPU wecken -> Register in den Speicher schieben -> zurück zum Anfang. Habe ich ubersehen, dass der ADC direkt in den Speicher schreiben kann (DMA), oder wird das Sampeln nach dem Prinzip wirklich eine "halbe Ewigkeit" dauern?
>(DMA), oder wird das Sampeln nach dem Prinzip wirklich eine "halbe >Ewigkeit" dauern? Ich antworte mir nun selbst, der Xmega ADC beherrscht DMA Zugriff!
> Ich antworte mir nun selbst
Gute Antwort!
Wenn du an dieser Bitfummelei direkt an den Registern Spaß hast - dann
mach es. Dazu gehört halt auch, dass du nächtelang Doku und fremden
Programmcode durcharbeitest.
Woher sollen wir wissen, ob du lieber möglichst schnell irgendetwas
lauffähiges zusammenkopieren willst, oder ob du jedes Bit verstehen
willst?
Wie oben schon jemand geschrieben hat, kann man ASF und direkte Registerzugriffe mischen - also etwa den ADC auf Registerebene Nutzen aber UART und DAC über ASF. Wie es auf Registerebene beim ADC funktioniert sollte man sich wenigstens einmal durchlesen - ggf. auch erst nach den ersten kleinen Tests. Das hilft um ungefähr ein Bild davon zu machen was möglich ist. Wenn man es mit dem internen ADC zum Auslesen einer Brücke auf die Spitze treiben will, wäre zu überlegen eine AC Anregung zu nutzen. Da kommt man noch einmal deutlich weiter als mit der klassischen DC Brücke. Die Hardware ist auch nicht unbedingt komplizierter, nur halt anders. Es kommt aber auch etwas auf die Anwendung an: wenn später mit den Daten eine FFT gemacht werden soll, stört ggf. etwas Drift oder 1/f Rauschen nicht so sehr.
Hallo Ulrich, >Wenn man es mit dem internen ADC zum Auslesen einer Brücke auf die >Spitze treiben will, wäre zu überlegen eine AC Anregung zu nutzen. Da >kommt man noch einmal deutlich weiter als mit der klassischen DC Brücke. >Die Hardware ist auch nicht unbedingt komplizierter, nur halt anders. Es >kommt aber auch etwas auf die Anwendung an: wenn später mit den Daten >eine FFT gemacht werden soll, stört ggf. etwas Drift oder 1/f Rauschen >nicht so sehr. Spielst du damit auf einen Lockin Algorithmus ab? Ein paar Infos wären klasse. Ich bin mitlerweile dabei die Virtuelle Maschine im AVR Studio richtig nutzen zu können und probiere gerade die ersten kleinen Programme aus. Es geht voran!
Stefan schrieb: > Ich bin mitlerweile dabei die Virtuelle Maschine im AVR Studio richtig > nutzen zu können Du meinst den Simulator? o_O
Ja ich mein den Simulator (für mich ist das eine virtuelle Maschine ;-). Dort kann ich zwar die Register auslesen, ich habe aber noch nicht herausgefunden, wie ich bequem die von mir gesetzten Variabeln wiederfinde.
Ich hänge jetzt an meinem ersten Problem fest. Ein neues Projekt mit dem ATMega32E5 wurde erstellt und mit dem Simulationsmodus bleibt er schon nach der ersten Programmzeile hängen: ___________________________________________ #include <asf.h> int main (void){ board_init(); sysclk_init(); do { uint16_t werte[20]; uint16_t i; for(i=0;i=20;i++) {werte[i]=i;}; }while(1); } ______________________________________________ Die ASF dazu: ______________________________________________ // From module: CPU specific features #include <ccp.h> #include <xmega_reset_cause.h> // From module: Common build items for user board support templates #include <user_board.h> // From module: Generic board support #include <board.h> // From module: Interrupt management - XMEGA implementation #include <interrupt.h> // From module: Part identification macros #include <parts.h> // From module: System Clock Control - XMEGA A1/A3/A3B/A4/D/E implementation #include <sysclk.h> // From module: XMEGA compiler driver #include <compiler.h> #include <status_codes.h> #endif // ASF_H ____________________________________________________ In der User_Board wurde nichts weiter definiert (also kein externes Quarz). Irgendwo liegt also ein ganz dummer Denkfehler begraben....
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.