Forum: Mikrocontroller und Digitale Elektronik AVR Studio Overkill als Anfänger?


von Stefan (Gast)


Lesenswert?

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!

von Bitflüsterer (Gast)


Lesenswert?

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.

von Thorsten S. (thosch)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

Ja, du kannst auch komplett auf die Arduino Libraries und die ASF 
Libraries verzichten.

von Bitflüsterer (Gast)


Lesenswert?

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.

von Thorsten S. (thosch)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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?

von Stefan (Gast)


Lesenswert?

>(DMA), oder wird das Sampeln nach dem Prinzip wirklich eine "halbe
>Ewigkeit" dauern?

Ich antworte mir nun selbst, der Xmega ADC beherrscht DMA Zugriff!

von Wikkommen im Club (Gast)


Lesenswert?

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

von Ulrich (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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!

von Kaj (Gast)


Lesenswert?

Stefan schrieb:
> Ich bin mitlerweile dabei die Virtuelle Maschine im AVR Studio richtig
> nutzen zu können

Du meinst den Simulator? o_O

von Stefan (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.