mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Assembler vs. C


Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, nun beginne ich gerade mit avr-programmierung. prinzipiell würde ich
das gerne in assembler tun, da dies etwas rootmäßiger und schlanker
geschieht. vorlesung und praktikum zum thema hatten wir auch,
allerdings am beispiel intel 8x86.
jetzt stehe ich vor dem problem, daß so manches beim avr doch anders
geschieht (allein die befehlstippfehler aus intel-gewohnheit treiben
mich zur weissglut...jump..) und ich nichmal mit abgucken "hallo
welt" aufs display kriege....

macht es sinn, den ganzen murks doch in c zu versuchen?
habt ihr da irgendwelche vergleichenden erfahrungen gemacht?
welche compiler gibts da?
wieweit bläht der compiler den code auf (im vergleich zu
handgestricktem assembler)?
mit welchen entwicklern schreibt ihr für gewöhnlich?

woran könnte es liegen, das der emulator/debugger im kanda avr-workshop
die arbeit verweigert? (error starting dos-shell)

bei bedarf hätte ich noch mehr fragen... ;-)

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe bis jetzt nur ASM programmiert, aber diese paar KB
Speicherplatz bekommt man auch mit ASM schnell voll.

Ich würde beim AVR mit C noch nicht so viel arbeiten. Obwohl die
Strukturierungsmöglichkeiten gut sind.

Bei einem ARM mit massig Speicherplatz würde ich aber irgendwann schon
auf C umsteigen.

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibts ein epfehlenswertes buch zum thema? mit der befehlstabelle und dem
 datenblatt von atmel alleine komme ich nicht wirklich weiter...

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss es wirklich ein AVR sein?

zu PICs git's sehr schöne WebSites (z.B. http://www.sprut.de/) in
deutsch. Und bei PICs lernt man auch schnell Assemblertricksereien -
vieleicht auch unfreiwillig.

Generell: Wenn Du Assembler programmieren willst, musst Du es lerenen.
Da hilft dir C nicht weiter. Wenn Du hardwarenah C rogrammieren willst,
musst du C lernen. Assembler hilft dir jedoch die Hardwarestruktur zu
verstehen.

Aber: Muss es wirklich AVR sein?

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das beste an ASM ist, dass man sich nur eine Befehlstabelle ansehen muss
und man kann alles. Bei C gibt es dann noch unmengen von Funktionen :-)

Sprut finde ich auch super. Die Seite hat mich erst zum Programmieren
von Atmels gebracht. Ich habe sie gelesen und dann habe ich die
Einfachheit der Programmer für Atmels erkannt g

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei ATMEL-AVRs bietet sich als ASM-Entwicklungsumgebung das
ATMEL-AVR-Studio 4.x an. So hat man alles aus einer Hand und kann auf
Funktionsfähigkeit vertrauen (zumindest halbwegs). Anlaufpunkt ist
www.atmel.com

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Der Elektrische Reiter

"Aber: Muss es wirklich AVR sein?"

Na aber klar !!!

In Assembler hat der AVR doch nur Vorteile gegenüber dem PIC.
Die Befehle sind einfach zu lernen, der Code- und Datenbereich ist
linear adressierbar.

Ich habe mit Z80 angefangen und dann den 8051.
Mit dem AVR hatte ich auch keinerlei Probleme.

Dann wollte ich leichtsinniger Weise mal den PIC probieren und bin fast
verrückt geworden:
Banking und Paging (Code nicht verschiebbar, größere Datenpuffer nur
mit Klimmzügen adressierbar), keine mehrfachen Pointer für Code und
Daten, keine Carry-Berechnung bei 16 oder 32 Bit-Operationen, keine
bedingten Sprünge, kein Stack für Parameterübergabe, begrenzte
Call-Tiefe usw.. Der PIC ist mit Abstand die umständlichste
Architektur, die ich kenne.


Peter

Autor: HerrMueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich habe vor einer Weile auch mit AVR Assembler angefangen und bin
begeistert davon. Ich hatte früher  (1986) mit dem C64 viel in 6502
'Maschinensprache' programmiert, allerdings ohne ein
Assemblerprogramm (ohne Labels musste man die Sprungziele selbst
errechnen usw.)Danach habe ich eigentlich nix meht gross programmiert.
Vor 3 Jahren habe ich mir dann ein STK500 gekauft und leider erst vor
ca 3 Monaten angefangen, damit 'rumzuspielen'.

1. Ich habe mir das Buch AVR-RISC Mikrocontroller von Trampert gekauft.
Das ist nicht schlecht, aber inzwischen schon ein wenig alt. Hat
ausserdem 70 Euro gekostet.
2. von der ATMEL Seite das AVR Studio runtergeladen. Das ist ein
kostenloser Assembler und Simulationsprogramm. Damit kann man Programme
schreiben und testen, ob einem der AVR passt, ohne dass man irgendwelche
Hardware braucht, oder Kosten entstehen.
3. Das Internet nach Tutorials durchsucht und alles ausgedruckt,was
interessant war. Da gibt es ne ganze Menge, auch mit Beispielen.
4. Eine Befehlsliste ausgedruckt und drauflosgetippt. Ab und zu hab ich
auch noch Tippfehler von früher ( LDA Load Accu anstatt LDI ),aber den
relativ kleinen Befehlssatz hat man schnell drin. Man muss halt schon
ein bischen lesen, um die Besonderheiten und Tricks zu beherrschen. Am
Anfang sollte es reichen, wenn man ne LED zum Blinken bringt - die
HELLO-WORLD-auf-Display Ansteuerung ist schon etwas fortgeschrittener.
Ich kann inzwischen schon ne IR LED so schnell zum Blinken bringen,
dass mein Radio leiser wird ;-)
Ein wenig Geduld ist also gefragt, aber das ist mit C wohl nicht
anders.

Viel Spass noch
Christian

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Danegger

Alle Deine "Anschuldigungen" treffen zu - allerdings nur bis zur PIC
16xx Serie. PIC 18xx ist ALLES anders; lineares, RAM, Flash,Stack ..
und ein sehr mächtiger ASM (finde ich jedenfalls) der mit seinen
Rechenoperationen weit weniger sich auf gewisse - fix vordefinierte-
Register beschränkt als der AVR.

Michael

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, avr musses schon sein. erstens, weil ich glaube, daß das die am
meisten verbreitete form von low-cost-home-controllern ist (warum an
exoten lernen). zweitens, weil ich im rahmen meines praxissemesters ein
gerät entwickle, daß auf atmel-basis laufen soll (sam7x, is arm und ne
klasse weiter, weiß ich; abere so bleibe ich wenigstens in der familie)
und drittens, weil ich mir nun schonmal ein second-hand stk200 gekauft
habe und es prinzipiell ganz gut finde.
damit scheidet avr-studio aber wohl schon aus, da es (glaube ich) für
die stk500 entwickelt wurde.
ne led per taste ein-und ausschalten kann ich schon (blinken hab ich
noch nicht probiert, sollte aber machbar sein), soweit reichts noch.
ich habe ja, wie gesagt, schon assembler-programmierung (intel) gehabt.
c hammer auch gelernt, es ist also nich so, daß ich ganz bei null
anfange. aber ein funktionstüchtiger debugger, mit dem man sich ports
und register anschauen kann, der fehlt halt irgendwie... gibts noch
alternativsoftware ausser avr studio (oder geht das doch auch aufm
stk200?) und dem standard kanda avr-workshop?

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

"...damit scheidet avr-studio aber wohl schon aus, da es (glaube ich)
für die stk500 entwickelt wurde. ..."
"...(oder geht das doch auch aufm stk200?)..."

das AVR-Studio ist nicht nur mit dem STK500 zu gebrachen.
Es ist ja eine (AVR Assembler) Entwicklungsumgebung mit Simulator. Wie
man den enstehenden (Hex)-Code in den AVR bekommt ist eine andere
sache.
Ich benutze einen STK200 kompatiblen Programmer mit PonyProg und yaap.

Grüße

Quark

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo, ponyprog benutze ich auch, damit ich atmegas (8535) flashen kann.
geht auch wunderbar (ponyprog2000 und original avrisp).
aber ich glaube irgendwo gelesen zu haben, daß avr studio (aus welchem
grund auch immer) nicht für stk 200 geeignet wäre. wenn dem nicht so
ist, werde ich das wohl mal antesten.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR-Studio ist nicht für STK500, sondern für AVRs.

Sein integriertes Brennprogramm unterstützt das STK500 (ISP und
HV-Programming) und das AVRISP (nur ISP), da diese Programmer von ATMEL
sind. Für andere Programmer gibt es dann andere Software wie Ponyprog,
Yaap usw...

Editor, Assembler und Simulator des AVR-Studios sollte man sich aber
erstmal angesehen haben, ehe man es unter "taugt nix" einstuft und
darauf verzichtet. Die restlichen Module (Emulator, JTAG...)
funktionieren natürlich erst bei entsprechender Hardware.

Aber schon für "Trockentraining" ohne Hardware (also reine
Simulation) ist AVR-Studio sein Download-Traffic wert. Sieh es dir
ruhig mal etwas genauer an.

...

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
irgendwie fühle ich mich falsch verstanden..... ICH habe mit keiner
silbe das prädikat "taugt nix" vergeben.
auszug aus dem release note:

Release Notes - AVR Studio 4.12   (11/2005)
---------------------------------------------------------------

What's new?

* Part support
- ATtiny261  (ICE50)
- ATtiny461  (ICE50)
- ATtiny861  (ICE50, JTAGICE mkII, STK500, AVRISP)
- ATmega640  (JTAGICE mkII, STK500, AVRISP)
- ATmega1280  (JTAGICE mkII, STK500, AVRISP)
- ATmega1281  (ICE50,JTAGICE mkII, STK500, AVRISP)
- AT90CAN32  (ICE50,JTAGICE mkII, STK500, AVRISP)
- AT90CAN64  (ICE50,JTAGICE mkII, STK500, AVRISP)

vielleicht hab ich mich halt erschreckt, daß dort zwar stks gelisted
sind, aber halt nich das 200er. ES TUT MIR LEID!
(...download läuft...)

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, das "taugt nix" stammt von mir. Es sollte besser heißen
"taugt nicht für meine Hardware" oder "ist für meine Hardware
ungeeignet".

Es sollte keinesfalls ein Angriff auf deine Person oder irgendeine
andere Person sein.

...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens soll die neueste Version (ich habe sie noch nicht) auch das
Debuggen von C-Programmen unterstützen.

...

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na gut. dann schnappe ich mal wieder aus.....

ich hab mir mal die version 4.12 runtergeladen, die sollte wohl die
neueste sein. das guck ich mir dann zu hause mal an und dann sehen wir
weiter.

die entscheidung "taugt nicht für meine Hardware"habe ich ja auch
schon vor zwei wochen "getroffen", als ich mir im vorfeld das zeugs
gedownloaded habe und nicht wußte, welches programm welchen job
erfüllt. das ein assembler nicht auf ein spezielles eval-board
abgestimmt sein kann, hätte mir (zumindest jetzt) auch langsam mal klar
werden können....

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch nie einen AVR in Assembler programmiert sondern immer nur
in C/C++. Das geht wunderbar: Bisher war immer alles schnell genug und
hat auch reingepaßt.
WinAvr ist für mich eine ganz ausgezeichnete Wahl!
Mit Assembler würde ich mich nur befassen, wenn es wirklich nicht
anders geht.

Ich weiß, dass das manche anders sehen. Mein Beitrag soll kein Angriff
sein sondern nur MEINE Einstellung darstellen.

Gruß, Michael

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, daß du das drunter schreibst, das scheint in diesem forum manchmal
wichtig zu sein..... ;-)

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JA, in der Tat!  :)

Ich möchte meine Meinung sogar noch einmal relativieren:

Für mich ist C/C++ die erste Wahl um zu erreichen was ich will.
Für den Einsteiger in die Materie allerdings ist ds Programmieren in
Assembler erstmal besser, da man hierbei ganz genau weiß, was der
Controller wie macht. Man erhält ein Gefühl und Verständnis für sein
Funktionsweise. Diesen Punkt soll man nicht unterschätzen.

Aber um eine Anwendung möglichst schnell zum Laufen zu bringen ist wie
gesagt eine Hochsprache (auf Controllern am ehesten C/C++) das beste.
Auch unter dem Gesichtspunkt Lesbarkeit und Wartbarkeit des Quellcodes
sehe ich hier nur Vorteile: Einem C-Quellcode sieht man viel leichter
an, was das Programm tut, als das bei Assembler der Fall wäre.
Ich will jetzt nicht darauf eingehen, dass manche Menschen leider die
Möglichkeit nutzten, auch in Hochsprachen unlesbaren Code zu schreiben.
(Über die Schreibweise des Wortes "Code" ist an dieser Stelle dann
gesondert nachzudenken...)

Gruß, Michael

Autor: Martin B. (methusalem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich habe für den Einstieg diese Buch gekauft:

"Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie" von
Günter Schmitt. ISBN: 3486577174

Ich bin damit sehr zufrieden. Das schöne: Die Beispiele werden sowohl
in ASM als auch in C beschrieben.

--
Martin

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist doch mal ne ansage.....danke sehr!

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich kann inzwischen schon ne IR LED so schnell zum Blinken bringen,
dass mein Radio leiser wird ;-)
Ein wenig Geduld ist also gefragt, aber das ist mit C wohl nicht
anders."
Das mag jetzt angeberisch klingen, aber nachdem ich meinen ersten
Programmmer geätzt habe(das erste, was ich je gemacht habe) habe ich
sofort eine Displaysteuerung gemacht. Die hat prinzipiell auch
funktioniert. Da wo ein schwarzer Punkt sein sollte war auch ein
schwarzer punkt. Das Display hatte aber scheinbar so seine Probleme mit
dem Kontrast, so dass das auch im Textmodus immer wieder zu heftigen
Pixelfehlern kommt.
Woher die Pixelfehler kommen habe ich nie erforscht. Es muss etwas mit
der Kontrastspannung zu tun haben, obwohl ich das Poti voll aufgedreht
habe.
Codemäßig hat alles erstaunlicherweise auf Anhieb funktioniert, obwohl
ich es nicht gleich gemerkt habe, da ich vergessen habe das Display zu
löschen.
Scheinbar funktiniert das Display aber nur dann korrekt, wenn eine
große Anzahl von Pixeln schwarz ist.
An dem Taktgenerator habe ich danach schon länger gesessen g

Autor: Klaus Bröntgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht bricht da ja ne spannung ein...?

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja mit nem Multimeter ist nichts messbar, aber vielleicht kommt das so
kurz gepulst, dass ich das nicht messen kann. Das Display braucht
übrigens +12 und -12V und wird seit über 15 Jahren nicht mehr
gebaut(Toshiba)
Ich habe dafür schon mehrere Threads geöffnet, aber alle meinten, dass
die Tatsache, dass mein Name auf dem Display erscheint (15 Buchstaben )
ein reiner Zufall ist und ich eigentlich nicht verstanden habe, wie
alles funktioniert grr

Aber die Disskussionen wurden hauptsächlich von dem kaputt gemacht, der
hier auch irgendwo so einen AVR an 230V thread hatte*g*

Das mit dem Display ist auch fast egal. Ich habe die Elektronik noch
komplett da. Schade nur, dass ich extra ein paar Schieberegister
zusätzlich aufgelötet habe...
Den Inverter habe ich glücklicherweise mobil über Kabel angebaut.

Naja Pollin hat neue Displays ich versuche es mit denen. Die kann man
einfach über den PC testen und wenn sie da schon nicht funktionieren
sollten, dann gibt es entweder leute, die den Controller kennen oder
welche, die mir sagen können, dass ich Schrott herumliegen habe :-)

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.