www.mikrocontroller.net

Forum: Compiler & IDEs Doku zu Winavr Funktionen?


Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alle zusammen,

bitte, gibt es eine möglichst deutschsprachige Erklärung mit Beispielen
für die vielen mit Winavr mitgelieferten Bibliotheken?
Mir fällt es sehr schwer, diese zu benutzen. Wie habt Ihr das gelernt?
Ich merke, dass ich mit meinem C Lehrgang aus der Volkshochschule nicht
sehr weit komme. Als Beispiel: es gibt eine delay.h -> wie benutze ich
nun den Befehl wenn ich eine bestimmte Verzögerungsschleife in meinem
Programm brauche? Die hier im Forum genannte "offizielle
dokumentation" hilft mir nicht so recht weiter.
Und ja, gegoogelt hab ich auch schon. Beim Assembler hatte ich eine
Doku mit allen Befehlen und am Ende immer ein oder zwei Beispiele, wie
der Befehl angewandt wird. Würd mich freuen, wenn ich aus Euren
Erfahrungen lernen könnte.

P.S. wenn die Frage zu blöd ist, bitte einfach ignorieren!

Gruss Holger

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hilft Dir die offizielle Doku nicht?

Um Englisch wirst Du wohl oder übel nicht herumkommen.  Auch wenn ein
Gutteil der avr-libc Doku wohl von mir sein dürfte, sorry, ich
schreibe sie nicht deshalb extra in Deutsch.  Die Datenblätter
übersetzt Dir schließlich auch niemand extra, und die brauchst Du
mindestens genauso dringend wie die avr-libc Doku, sonst bist Du
aufgeschmissen.

Was <avr/delay.h> betrifft, besteht dessen Dokumentation derzeit
allerdings nur aus der Datei selbst.  Andererseits: so schlimm kann es
doch auch nicht sein zu verstehen, wenn man 3 Takte pro
Schleifenzyklus braucht, wieviel Schleifenzyklen man dann bei N MHz
Taktfrequenz für M µs Verzögerung benötigt.  Relativ simple Division,
sollte man spätestens mit der Mathematik der 8. Klasse erledigen
können.  Einzige Besonderheit: bei der ,,kleinen'' Schleifenvariante
muß man darauf achten, daß man nicht über 255 Durchläufe kommt, bei
der ,,großen'' sind es 65535.

Harte delays sind aber sowieso weit nicht so praktikabel, wie auf den
ersten Blick angenommen.  Über kurz oder lang wirst Du nicht an der
Verwendung eines Hardware-Timers vorbeikommen -- dafür sind sie ja
auch da.

Autor: Werner A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger:
wo hast Du die Doku zu Assembler denn gefunden? Sowas suche ich schon
länger, leider findet man in der Vielzahl der angegebenen Sachen nicht
so leicht was
Werner

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, daß er entweder den Atmel-Assembler meint oder deren
Appnote über die Opcodes.

Der GNU assembler ist bei GNU ganz gut dokumentiert.  Das Einzige, was
leider komplett undokumentiert ist, sind die AVR-spezifischen
pseudo-Ops des GNU assembler. :(

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Werner:

sehr geholfen hat mir das Buch von Safinaz/Volpe -> ISBN Nr. und
genauen Titel suche ich raus
und die Doku von Atmel:
http://www.atmel.com/dyn/resources/prod_documents/...

@Jörg

Ja 8.Klasse hatte ich nich, 5. hab ich 3x gemacht und 6. bin ich
rausgeflogen grins
Nö! mal ohne Spass: Meine ersten Erfahrungen habe ich mit einem 8052
gemacht und ein Bekannter von mir hat programmiert, ich hab zugesehen.
Die ersten eigenen Versuche hab ich dann mit einem Atmel gemacht, sogar
Einführungskit gekauft. Wie oben gesagt hat mir sehr das Assembler Buch
geholfen. Lernen durch probieren!
Jetzt hatte ich ein Projekt vor und hab erstmal ein HD44780 Display und
1 Taster, 1 Drehgeber und 2 Lumis angelötet. Habs auch zum spielen
bekommen, einfach durch abschreiben und selber probieren.

Mit C hab ich eben Probleme. Obwohl ich schon das hier im Forum
genannte Buch gekauft habe und noch ein zweites welches auf Atmel, aber
auf den IAR Compiler eingeht.

Mein erstes Projekt ist jetzt ein Nokia 3310 Display und ein Atmel
Mega8. Und natürlich WinAvr, denn wenn man hier so liest heisst es ja
ständig: lerne C und nochmal C und nochmal....
Hab ich also gegoogelt und bin auf Microsyl.com gestossen.
Text kopiert, neuestes Winavr installiert und krieg bisher nicht mal
ein einziges Pixel auf das Display. Mit Assembler hatte ich schneller
Erfolge. Das liegt unter anderem auch daran, dass ich ne Menge, was der
Winavr an Fehlermeldungen ausgibt nicht verstehe. Ist für mich einfach
Fachchinesisch. Offensichtlich geht hier auch eine rasante Änderung vor
sich. Mir scheint es so, als wenn ständig neue Befehle und Funktionen
erfunden werden und andere wieder wegfallen.(z.B. das setzen des DDR
Portregisters - hab ich verschiedene gelesen, ging wohl erst über outp,
jetzt nicht mehr? Ich bin verwirrt.)
Kann auch sein, dass ich einfach zu alt bin um das alles zu kapieren.
Nimm es jetzt nicht als persönliche Kritik Jörg, ich bin Dir dankbar
für deine Antwort. Aber ein einfaches Beispiel, wie delay() aufgerufen
wird hätte mir schon geholfen. Sowas würde ich mir für alle
mitgelieferten Funktionen wünschen. Ich weiss z.B. was ich machen will,
hab aber Probleme bei der Umsetzung. Ich muss einfach mal x ms warten,
wie gehts richtig?
Ich entnehme Deinen Ausführungen, dass es sich bei delay.h auch nur um
einfache Zählschleifen handelt. Warum wurde mir hier im Forum geraten
anstelle der delay Funktion von Microsyl die delay.h vom GNU C zu
nehmen? Sind doch scheinbar beides harte Schleifen?


Übrigens, nach 'ner deutschen Bedienungsanleitung hab ich gefragt,
weil ich englisch eben nicht ganz so gut kann. In meiner Schulzeit und
an meiner Schule gabs nur russisch und französisch!

P.S.
Wie hast Du denn C für Atmel gelernt? Ich gehe davon aus, dass Du nicht
eines Morgens aufgewacht bist und Programmierprofi warst.

Gruss Holger

Autor: Sebastian Schildt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

"Wie hast Du denn C für Atmel gelernt? Ich gehe davon aus, dass Du
nicht
eines Morgens aufgewacht bist und Programmierprofi warst."

Wenn ich mal stellvertretend antworten dürfte :). Das Problem ist, dass
es ziemlich schwierig ist C auf einem Mikrocontroller zu lernen. Da gibt
es so viele Randbedingungen und teilweise auch Controller spezifische
Besonderheiten, dass es am Anfang ziemlich verwirrend ist.

Am Anfang lernt sich C besser auf einem PC, wo man sich
 - nicht um Hardware kümmern muss
 - "unendlich" Ressourcen hat
 - man gut debuggen kann, und nicht gleich alles steht, wenn das eigene
Prog Mist baut

Mit der nötigen Portion Hartnäckigkeit kann man C natürlich auch auf
dem Mikro lernen.

Was das Englsich angeht, kann ich mich nur anschließen: Auf lange Sicht
kommst du nicht darum herum. Ich weiß, dass es am Anfang schwierig ist,
aber gucke trotzdem immer wieder in dei englischen Quellen, irgednwann
wird das verstehen einfacher. (http://dict.leo.org/ zum nachschlagen
einzelner Wörter).

Am besten lernt es sich an Beispielen. Die Codesammlung hier ist echt
eine Goldgrube und einige Beispiel sind sogar recht gut dokumentiert.
Einfach mal was abkupfern und dann versuchen zu ändern.

Außerdem sollte man noch mit einem guten allgemeinen C Buch bewaffnet
sein. Ich liebe: http://www.amazon.de/exec/obidos/ASIN/3446154973 . Das
ist nicht gerade ein Einsteiger Buch zum lernen, sondern mehr eine
Referenz, aber da steht wirklich alles drin, auch die Konzepte von C
(also Zeiger, Structe und Co - alles was einem in ASM so nicht
begegnet) sind gut erläutert und es ist auch nicht so schwer zu
verstehen.

Evtl. solltest du dir am Anfang ein kleineres Projekt vor nehmen und
nicht gleich mit einem Graphik LCD anfangen. Vielleicht erstmal ein
paar LEDs blinken oder ein alpha numerisches LCD um ein Gefühl für C zu
bekommen.

"Kann auch sein, dass ich einfach zu alt bin"

Quatsch! Einfach weiter machen nicht auf aufgeben. Früher oder später
wird es funzen!

MfG

Sebastian

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volle Zustimmung für Sebastian!

Den K&R würde ich auch empfehlen, Wermutstropfen ist nur, daß er
,,ANSI-C'' (anderer Name: ANSI C-89, oder ISO C-90) beschreibt.
Mittlerweile hat sich auch der Sprachstandard weiterentwickelt, ISO
C-99 ist nun aktuell.  Der GCC implementiert es noch nicht
vollständig, aber zu einem großen Teil.

Ich habe C nicht durch frühmorgens Aufwachen gelernt, aber immerhin
noch zu Zeiten, als MS-DOS mit seinen Debugmöglichkeiten nicht viel
besser als heutige Microcontroller war... insbesondere war der Zugriff
auf falsche Pointer damals dort genauso tödlich, wie er das bei
Controllern nach wie vor ist.  Hier hat uns Hardware + Betriebssystem
mit Speicherzugriffsschutz im Bereich der Universalcomputer einen
echten Segen gebracht.  (Gleich danach durfte ich das C dann auf einem
MC 86030 unter OS/9 benutzen.  Dort mußte man erstmal die Bugs des
Compilers suchen...  Das war übrigens mein erster Job nach dem
Studium, als C-Programmierer -- obwohl ich zuvor noch nie in C
programmiert hatte.  Den K&R habe ich mir damals gekauft.)

Zu Deinem konkreten Problem: mit dem AVR-GCC sollst Du bitte die
delay-Makros aus <avr/delay.h> benutzen und nicht irgendwelche
anderen, weil für diese Macros einfach mal garantiert werden kann, daß
der Compiler genau das damit tut, was in der Beschreibung steht (die
in diesem Falle leider nur im Header-File selbst steht).  Wenn Du
etwas anderes benutzt riskierst Du, daß der Compiler daraus entweder
was zimmert, was nicht Deinen Erwartungen entspricht (beispielsweise
weil weniger Zeit in der Schleife gewartet wird, als das mit einem
anderen Compiler der Fall gewesen wäre), oder daß vielleicht
eingebetteter Assemblercode dabei war, für den jeder Compiler halt
seine eigene Syntax (und Semantik) hat.

Ansonsten: Wartezeiten im Millisekundebereich überläßt man besser
einem Hardware-Timer.  Und ja, das macht man gleich mit Interrupts,
die Dinger sind für einen Microcontroller so esentiell, daß man gar
nicht erst versuchen sollte, sich davor zu drücken.  Nicht umsonst
benutzt selbst das simple demo.c, das bei avr-libc (und damit bei
WinAVR) mit dabeiliegt und so eine Art ,,Helloworld!'' für den AVR
ist
bereits Interrupts.

Das einfache Beispiel für die Makros aus <avr/delay.h> ist übrigens:

_delay_loop_1(42);

Ohne aber zu verstehen, was diese Makros machen, fürchte ich, daß Dir
das nicht viel nützt so. :)  Für 1 MHz CPU-Takt würde das übrigens 3 *
42 µs = 126 µs Verzögerung ergeben.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vor englischen Datenbüchern und Codebeschreibungen sollte man sich nicht
allzuviel Angst machen. Der Wortschatz ist meistens derartig
eingeschränkt, dass es kein Problem ist, sich da durchzuwursteln.
Immerhin werden die Datenbücher oft von Leuten geschrieben, deren
Muttersprache alles andere als Englisch ist.

In der Elektronik ganz ohne Englisch auszukommen ist dagegen praktisch
unmöglich. Also durchbeissen, das Fachenglisch ist auch nicht schwerer
als eine Programmiersprache!

Stefan

Autor: Werner A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger:
Danke für den Link, das Document hatte ich nicht gesehen. Als Buch
meinst Du wahrscheinlich AVR-Mikrocontroller-Praxis aus dem
Elektor-Verlag. (ISBN 3-89576-063-3). Sind die Beispiele im Buch OK?
Ich lerne halt auch am besten mit Beispielen..

Werner

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich lerne halt auch am besten mit Beispielen.

Die bekommst Du aber (beinahe) kostenlos zuhauf aus dem Internet.
Warum willst Du dafür Geld ausgeben?  Spendiere das Geld lieber in die
genannte ,,C-Bibel''.  Wer C wirklich einmal verstanden hat und das
nötige Gefühl für die Controller-Hardware mitbringt, dem fällt der
Übergang von C auf einem ,,großen Computer'' zu C auf einem
Controller
nicht allzu schwer.

Just my EUR 0.02.

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

Ich danke Euch, dass Ihr mir Mut macht. Das C und C auf Controllern
unterschiedlich sind, hab ich mit meinem C Kurs in der Volkshochschule
auch schon gemerkt. Geschafft haben mich nicht so sehr die englischen
Datenblätter, ein bischen kann ich das ja lesen, mehr sind es z.B. die
Fehlermeldungen vom GCC. Auch wenn ich es wörtlich übersetzt hab,
konnte ich oft nicht feststellen, was das Ding von mir will. Obwohl das
WWW ja viel weiss, hab ich auch keine Quelle gefunden wo das dann
jeweils näher erklärt wurde.
Die Links und Tipps von Euch helfen mir schon mal weiter, das
Wörterbuch kannte ich noch nicht. Danke!


@Werner
genau das Buch meinte ich! Die Beispiele haben mir sehr geholfen. Ob
sie komplett OK sind weiss ich nicht, aber immerhin haben sie mir
ermöglicht, mein HD44780 Display innerhalb von 2 Tagen dazu zubringen
mir anzuzeigen, wass ich mir ausgedacht habe - mit blinken und
Laufschrift u.s.w.

Und noch mal Lob und Dank an Alle hier, die so bereitwillig helfen.
Ich werd mich mal weiter durchwurschteln.
Ja und ich seh schon: Ich war wohl durch meine ersten Erfolge mit
Assembler ein bischen euphorisch. Denn wenn ich mir Eure History so
ansehe: Studium, Programmierer, DOS Zeiten -> da steckt jahrelange
Erfahrung drin und gesammeltes Wissen. Das hatte ich wohl verdrängt!

Gruss Holger

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du Sorgen mit den englischen Fehlermeldungen des GCC hast, poste
hier Deine (konkreten) Fragen, dann wird Dir auch geholfen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.