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?
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!
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....
