Welche Sprache für Anfänger zum Programmieren von AVR's

Dann nimm C/C++ und gehe das Tutorial hier mal durch:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
AVR-Studio, WinAVR und unter Linux GCC können das ;-)

Frag deinen Bruder ;-) ,der kann dann wenigstens helfen .

Hallo Habibi,

ich persönlich würde Basic als Programmiersprache empfehlen. Schau Dir 
mal den BASCOM AVR Compiler an. Hier kann man eine kostenlose Version 
herunterladen, die lediglich in der Größe des erzeugten Programmcodes 
eingeschränkt ist. Für einen Anfänger ist der geradezu ideal.

http://www.mikrocontroller.net/articles/Bascom_AVR

Man findet auch viele einfache Beispiele, die den Einstieg in die 
Materie leicht macht.

Später kannst Du dann immer noch auf andere Sprachen, wie z.B. den GNU C 
Compiler wechseln, der eher was für Fortgeschrittene ist.

Beste Grüße,

Norbert

Hi
Nun ja, eigentlich gab es nur eine Antwort, die meiner Meinung nach 
richtig war:

Esoteriker schrieb:
> Frag deinen Bruder ;-) ,der kann dann wenigstens helfen .

Eine ideale Sprache gibt es nicht. C ist weit verbreitet und ist im 
professionellen Bereich ein "Muss", aber ob du als Elektronikbastler mit 
selbst erlernter Software jemals ein Profi wirst ..... die Antwort 
kannst du dir selber geben. BASCOM ist, wenn man es von Grund auf lernen 
muss, genauso schwierig, wie C, allerdings ist der Syntax leichter zu 
verstehen. Aber alles nur eine Kopfsache. In der Regel kann ich nur 
sagen: die Sprache ist gar nicht so entscheidend. Wichtig ist denken zu 
können, wie ein Controller. Und da wird die größte Schwierigkeit sein.
Nimm es mir nicht übel, aber allein schon die Frage: welche Sprache 
zeigt mir, wie du denkst. Nix für ungut, soll nicht bös gemeint sein, 
aber überleg mal selbst, wie man heraus findet, welche Sprache sinnvoll 
ist und wie man in kurzer Zeit auch Fortschritte macht. In diesem Forum 
gibt es z. B. Tutorial für C und Assembler. Bei anderen Foren sicherlich 
auch Anleitungen zu BASCOM. Tja, wie soll ich es sagen... vielleicht so:
Wenn du eine Uhr gebaut hast, dann interessiert es dich, wie ein 
Programm gestaltet werden muss. Also schaust du dir die Beiträge zu 
diesem Thema an, und versuchst diese dann auszuprobieren. Schritt für 
Schritt. Schließlich lässt du eigene Ideen einfließen und bist dann 
ständig in der Hilfe der gewählten Sprache, weil du die Lösung für dein 
Problem aus der Hilfe ableiten kannst. Aber klar, du kannst auch fragen.
Mein Text soll dich nicht vor den Kopf stoßen, sondern ich  möchte dir 
helfen, den Weg zu finden. Der Einstieg in eine Programmiersprache ist 
um vieles schwieriger, wenn du deine Gedanken nicht in logische 
Vorgehensweise lenken kannst.
Ich hoffe, du findest den Weg, nicht die Sprache. Egal was du anfängst, 
irgendwann geht es in dieser Sprache nur mit komplizierten Klimmzügen 
unter Verschwendung von Resourcen. Dann stellst du fest, in einer 
anderen Sprache werden die Komponenten bereits geliefert und dann setzt 
du dich hin und liest dich in die Sprache ein, wenn dein Vorhaben damit 
leichter umsetzbar ist.
Beispiel:
Mathematische Funktionen in Assembler, BASCOM oder C
Gruß oldmax

Wenn Du sicherstellen kannst, niemals mit der Außenwelt in Berührung zu 
kommen, niemals beruflich damit zu tun zu haben, niemals an fremden 
Projekten mitarbeiten oder davon partizipieren zu wollen - dann nimm 
das, was Dein Bruder macht.

Ansonsten C.

Aber vielleicht benutzt Dein bruder ja auch C ;-))

oldmax schrieb:
> BASCOM ist, wenn man es von Grund auf lernen
> muss, genauso schwierig, wie C, allerdings ist der Syntax leichter zu
> verstehen.

Wobei man dazu allerdings noch anmerken muß, dass die 
Entwicklungsumgebung von BASCOM noch einen recht umfangreichen Simulator 
enthält, der das Ganze für einen Einsteiger doch recht erleichtert. Auch 
finde ich die ganze Oberfläche von BASCOM in ihrem gesamten Konzept 
recht übersichtlich und einsteigerfreundlich.

Nicht falsch verstehen aber bei einem Einsteiger liegt der Fokus ja 
nicht nur auf der Programmiersprache. Es geht ja auch um den 
Mikrocontroller, seinen Aufbau, um die Ansteuerung einer möglichen 
Peripherie und das ganze weitere Drumherum. Das wird z.B. durch die 
Simulationsmöglichkeiten im BASCOM sehr anschaulich und für einen 
Einsteiger nachvollziehbar dargestellt.

Ich selbst habe in der Vergangenheit eigentlich fast die ganze AVR 
Programmierung mit dem WinAVR in C programmiert aber ehrlich gesagt, 
meine Wunschprogrammiersprache für eingebettete Umgebung ist Ada. Wer 
mal die Möglichkeit hat in diese Programmiersprache richtig 
einzusteigen, der packt einen C Compiler nur noch mit absolutem 
Widerwillen an und wirklich nur noch dann, wenn er unbedingt muß. Es gab 
zwar mal einen Versuch, Ada auf Atmel AVRs zu portieren aber da ist 
leider bislang noch nicht viel Brauchbares rausgekommen. Es fehlt 
einfach noch zuviel von der richtigen Ada Implementation.

Gruß,

Norbert

Ich würde COBOL oder FORTRAN verwenden.

90% der Antworten bei solchen Fragen lauten immer:
Nimm [x] weil das die Sprache ist die ich auch nehme.
x=Assembler; Bascom; C; C++; sonstige

Ansonsten mal ein paar spezifische Antworten:

Wenn du schon erfahrungen im programieren hast, kannst du vieleicht die 
Sprache die du kennst für die µC Programierung verwenden.

Wenn dir dein Bruder helfen kann ist seine Sprache sicher auch eine gute 
Wahl.

Du hast Elektronikerfahrungen, solltest du keine Programiererfahrungen 
haben ist der Einstieg in Assembler am einfachsten.

Willst du es später beruflich einsetzen, dann nimm C.

Die Grenzen sind fließend, wie bei allen Sprachen (auch der 
gesprochenen). Das Beste oder das Schlechteste gibt es dabei nicht, nur 
das was einem gefällt oder was man beherrschen will. Milliarden 
Menschen sprechen chinesisch bzw. indisch, deswegen komme ich aber nicht 
auf die Idee morgen chinesisch oder indisch zu lernen.

Olli Hannsen schrieb:
> Uwe S. schrieb:
>> LunaAVR ist kein Basic!
>
> Selbst auf der LunaAVR-Homepage wird LunaAVR als "Basic-ähnliche
> Programmiersprache" bezeichnet. Die werden es ja wohl wissen.

Pascal ist auch Basic-ähnlich und damit aber nicht automatisch ein 
Basic. Anhand des Sprachaufbaus denke ich ist das auch genau so gemeint, 
insofern ist der Einwurf weiter oben nicht unberechtigt.

Du wirst viel mit Hardware zu tun haben. Da macht es sich gut, wenn Du 
die hier verfügbaren Unterprogramme einfügen kannst. Ein LCD zu 
programmieren geht noch, mit einer lib geht es einfacher. Einen OneWire 
von Null an zu programmieren ist aufwendig. Lieber eine lib einsetzen.
Auch wenn ich jetzt gesteinigt werde: Auch mal bei Arduino 
hereinschauen. Da gibt es auch sehr viele Beispiele (und auch viel 
Mist).
Fazit: bei beidem ist es avr-gcc.

Hi
Ich wiederhole mich nur ungern, aber "programmieren" läuft im Kopf ab. 
Die Sprache ist nur das Werkzeug. Ein Anfänger hat mit jeder Sprache 
Probleme und jede Sprache hat Eigenheiten, die so leicht nicht erkennbar 
sind. Wer es von Grund auf gelernt hat, weiß darum und findet das auch 
nicht weiter schlimm. Wer al  Quereinsteiger erste Gehversuche macht, 
ist froh jemanden an der Hand zu haben, der es bereits kann. Da ist es 
egal, welche Sprache der Bruder spricht, er ist die erste Wahl.
Der Wunsch, eine weitere Sprache hinzu zu nehmen, kommt spätestens dann, 
wenn das bereits Erlernte für die Umsetzung von Projekten nicht mehr 
reicht. Klar, man muss sich einem anderen Syntax stellen, aber die 
Programmierung als solches, die Denkweise dazu, ist dann schon mal 
erlernt und die Compiler die ich kenne haben alle eine Hilfe integriert. 
Wenn's dann mal nicht gleich greifbar ist, in der Hilfe findet sich der 
entsprechende Hinweis.
Außerdem: der TO scheint sich für's Schwimmbad und die Weiber 
entschieden zu haben, während wir noch einen (kleinen) Glaubenskrieg 
führen.
Gruß oldmax

...es wurde Alles schon gesagt, nur von mir noch nicht :-)

Für C spricht, das es für so gut wie jede Architektur verfügbar ist,
wenn man also vo hat später auch mal einen anderen Prozessor zu 
verwenden als die AVRs, wie z.B. ARM oder MSP430, sollte man das 
berücksichtigen.
BASCOM gibt es IMHO nur für AVR.
Man muß nicht den kompletten Maschinenbefehlssatz kennen wie zwingend 
bei Assembler notwendig, aber es erspart nicht die Peripherie die sich 
schon innerhalb einer Architektur sehr stark unterscheiden kann, kennen 
zu müssen.

Ich hacke hier derzeit auf einem MSP430 herum, das Hauptproblem dabei 
ist genau die "andere" Peripherie, der Prozessorkern eigentlich 
überhaupt nicht,
nicht mal die Tatsache das die CPU 16bittig ist und nicht wie die 
kleinen Atmels 8bittig stört da, man hantiert auf Grund der 8 Bit 
breiten Peripherie sowieso meist nur mit Bytes oder logischen Größen. 
Die selbe Erfahrung hatte ich mit ATXMegas, kein wesentlicher 
Unterschied.
Ich schaue mir aber gerne mal den Output des Compilers als 
Assemblerquelltext an, da kann man nebenbei lernen oder auch mal stutzig 
werden wenn der Compiler Sachen weg optimiert (vergessene volatiles).
Ich programmiere auch auf dem PC in C, Intel Assembler kann ich aber 
genau genommen gar nicht (Diverse Microkontroller, 68K u.ä. aber schon) 
will ich aber auch nicht lernen (...gewisser Ekel vor Intel 
Architekturen) und hat mir auch noch nie gefehlt.
Für 95% der Mikrokontrollerei braucht man auch kein Assembler, maximal 
für ein paar schnelle Interrupt Service Routinen und das habe ich in 
Verbindung mit C auch schon öfter genutzt. Von Basic halte ich Nichts, 
das wird ab einer bestimmten Größe immer unübersichtlicher 
Spaghettikram. Pascal ist heute eher unüblich und nicht auf allen 
interessanten Architekturen verfügbar. Interpreter halte ich auf 
Controllern für suboptimal, ein Laufzeitfehler der das Ding irgendwann 
anhält wenn man keine Console dran hat lauert immer. Die anderen "neuen" 
Sprachen .... naja, wenns schee macht...manchmal kann man sich 
interessant machen wenn man was obskures kann..

@oldmax: Du kennst Compiler mit integrierter Hilfe? Whow. Ich nicht.
Ich kenne IDE's mit integrierter Hilfe, aber keine Compiler damit.
Ich benutze keine IDE, es sei denn ich muß ein Projekt für einen Kunden 
auf eine solche "portieren", die Entwicklung mache ich aber unter Unix 
mit den dort üblichen Utilities, das ist um den Faktor 5-10 schneller..


Gruß,

Holm

Man sollte ruhig mal das Stündchen investieren und das erste 
Progrämmchen in BASIC (Bascom) schreiben. Schon allein um zu sehen, wie 
weit man damit kommt. So habe ich es gemacht und es blieb dann auch das 
letzte BASIC-Programm auf dem AVR.

Hi
Sorry für den Compiler... klar ist es die IDE, aber oft sind sie so eng 
beieinander... und letztlich reden wir hier von C, Bascom, Assembler und 
was sonst noch. Und da ist die Hilfe auf jeden Fall drin.
Aber wem hilft das jetzt. Den TO scheint es nicht mehr zu interessieren. 
Schwimmbad ist halt doch interessanter.
Grußldmax

batman schrieb:

> Man sollte ruhig mal das Stündchen investieren und das erste
> Progrämmchen in BASIC (Bascom) schreiben.

Zu was gibt es denn bessere Informationsquellen und Tutorials? Basic 
oder C? C ist Industriestandard, deswegen verwende ich persönlich diese 
Hochsprache, und komme damit reichlich für alle Aufgaben zurecht.

Angefangen habe ich mal mit Basic und C64. Basic war gratis verfügbar, 
andere Compiler nicht. Später auf dem ersten richtigen PC (486DX2) war 
MSDOS 5.0 drauf, das hatte auch noch einen Basic-Interpreter. Der war 
immerhin gratis, und die interpretierten Programme liefen darauf eben so 
schnell wie Compiler.

Ein wenig Assembler, um ein Gefühl für die Maschine und 
Geschwindigkeiten zu bekommen, schadet auch nicht. Der wird aber bei 
größeren Berechnungen sehr mühsam gegenüber einer Hochsprache.

Eine gute komfortable nicht zu komplizierte und von allen Dingen recht 
unabhängige IDE ist Geany, die ich zusammen mit SDCC verwende.

if (S1==0)  LED=1;

kann auch jeder lesen. Das ist mehr Gewöhnungssache.

Hi

>Selbst nach ca 1 Jahr oder etwas mehr mit Bascom, ist für mich ein C
>Code "unleserlich".

Na ja, BASCOM scheint dir auch noch recht fremd zu sein:

http://www.mikrocontroller.net/topic/301132#new

MfG Spess

Thomas der Bastler schrieb:
> jetzt läuft sehe aber nicht ein es zu posten.

Ganz im Sinne eines Forums.
Erst mal falschen Code posten und dann nicht mal die Eier in der Hose 
haben dies einzugestehen.
Und dann noch von "programmieren" sprechen.
Echt ulkig...

Paul Baumann schrieb:
> Zu der Sprache C verweise ich auf unzählige Artikel hier, wo es sich
> herauskristallisiert, daß der Quelltext sich nur mit Axt und Wagenheber
> übersetzen läßt. Was nützt es, wenn man den Algorithmus des Programmes
> in Sekundenbruchteilen in die Kiste wämmert, aber dann Tage braucht, um
> dem Kompiler den Quelltext schmackhaft zu machen?

Im privaten Bereich stimme ich dir vollkommen zu. Wenn man (gerade als 
Anfänger) nicht weiß auf was dass man achten muss bzw. wo es Tücken 
gibt, gibt es bestimmt bessere Sprachen um an ein einfaches Ziel zu 
kommen. Ob jetzt ein paar Byte mehr Flash/RAM belegt werden oder das 
Ganze etwas langsamer ist, spielt im Normalfall keine Rolle. Auch ob für 
jeden Controller ein passender Compiler vorhanden ist, ist in diesem 
Fall zweitranging.

Wenn es aber darum geht Brötchen zu verdienen spielen Flash/RAM/Compiler 
eine sehr große Rolle! Gerade bei Automobilern oder im Consumerbereich 
wo teilweise der Cent im Nachkommabereich umgedreht wird!
Hier versucht man Resourcen und damit Geld einzusparen.
Auch muss man Überlegungen anstellen was passiert, wenn ein Controller 
abgekündigt wird. Wenn man sauber programmiert und einen Hardware 
Abstraction Layer einzieht ist der wechsel auf einen anderen Controller 
meist relativ schnell erledigt. Was passiert allerding wenn für den 
neuen Controller kein passender Compiler vorhanden ist? Dann kann ich 
von Null anfangen! Dann muss ich meine komplette Qualifizierung von 
vorne anfangen und in Zukunft auch zwei Firmware pflegen.

Das macht einen RIESEN Unterschied :-)

So, bis jetzt bin ich komplett ohne eine Erwähnung einer speziellen 
Sprache ausgekommen.
Meine Empfehlung (und so ist sie auch zu nehmen, also ein reiner 
Vorschlag! Kein muss, Kein gepoche auf "Ich habe aber Recht) ist dass 
man es sich im Privaten (solange es Resourcen, sei es Flash/RAM/Timings) 
natürlich so einfach wie möglich machen sollte. Und da gibt es 
leichteres als C/C++.

WENN man allerding beruflich damit zu tun hat (und da meine ich nicht 
nur eine PWM ansteuern und ne LED dimmen), dann sollte man definitiv auf 
C oder wenn die Komplexität zunimmt auf C++ (auch im Embeddedbereich) 
setzen!

Grüße Babbel
(Der jeden Tag in C/C++ beruflich programmieren darf)

Ich hab noch einen, warum AVR und nicht Pic? Damit kann man ihn nun 
endgültig verwirren.

Der Kommentar war übrigens Antwort Nr. 42.

@Karol: Die Entwicklung "einfacher Texteditoren" ist scheinbar nicht an 
dem Punkt stehengeblieben and dem Du das letzte mal damit zu tun 
hattest.(Edit unter DOS?)
Du mußt nicht so arbeiten wie ich, aber Alarmglocken mußt Du gleich gar 
nicht anmachen..

Die Ursache für die enorme Beschleunigung ist das gleichzeitig mögliche 
offen lassen von Editor, Manual Seite, Webbrowser Debugger und 
Build-Fenster
unter einer Art Console Multiplexer genannt X11.
Ich werde mit der Klickerei im AVR Studio wahnsinnig eher die Kiste mal 
das macht was ich von ihr will und ab Version 5 ist das nur viel 
schlimmer geworden. Unix und das Make System automatisiert viele 
Vorgänge, mir gefällt diese Arbeitsweise nun mal deutlich besser als 
Klickibunti mit Werbung. (Unix ist ein OS von Programmierern für 
Programmierer und an dieser Stelle spielt es schonungslos seine Stärken 
gegen Hausfrauensysteme mit NSA Anbindung aus)
Ich habe auch Eclipse hier laufen und auch das CCS von TI mal 
installiert (auch Eclipse) ... ist nicht mein Ding. Allen Oberflächen 
gemeinsam ist, das sie den Compiler als Kommandozeile rufen, das kann 
ich aber auch.
Klar gibts u.U Gimmiks die interessant sind, aber die wiegen die 
Nachteile (für mich) nicht auf.

@Yalu: blos gut das Du geduckt bist :-)

Ansonsten stimme ich explizit Falk zu.
Mit Basic erziehlt man realtiv schnell Erfolge, aber auf längere Sicht 
endet das IMHO in einer Sackgasse, zumal wenn man die Arbeit Anderer 
(also z.B. auch die der Foristen hier) nutzen will und das auch darf.

Gruß,

Holm

Karol Babioch schrieb:
> Ich denke aber, dass hier ein gewisser Konsens darüber herrscht, dass
> man mit C weiterkommt, gerade wenn man nachher auch andere
> Controller(familien) programmieren möchte - unabhängig davon, was nun
> "einfacher" ist. Für mich wäre das Grund genug mich für C zu entscheiden

Das ist der Anspruch, den man in seine Projekte hat.
Wenn man bei AVR bleiben will, dann ist das kein Thema.
Kennt eigentlich noch jemand das AVR-Basic? Das ist ganz schnell 
gestorben, als BASCOM erschien.
Eigentlich ist es doch wurscht, was in einem MC drin steht. Hauptsache 
ist, das es macht was es soll.
C ist und war die Sprache der Profis.
Aber alles ist relativ. Ich hab hier ein "Standard-BASIC" für die 
späteren DDR-PC. Da wackeln die Ohren was das kann, also keine 
abgespeckte Version.

@Karol: Ja ich galube Dir das VIM & CO Dein tägliches Brot sind, ich 
frage mich dann aber doch warum Du damit ineffektiver arbeitest als mit 
Visual Studio z.B...
Es bleibt doch nicht beim Editor, es geht weiter über Sachen wie grep 
oder cvs. Ich schrieb das ich damit schneller bin und damit besser 
zurecht komme
als mit dem Klickibunti Kram, laß es doch dabei..
Hier läuft übrigens kein Ubuntu, nicht mal Linux. Nichts desto trotz 
habe ich die kompletten Sourcen und kann auch das OS neu bauen, gänzlich 
ohne IDE.

@Michael_: Ich weiß was das "Standardbasic" nicht kann, es kann nicht 
mit den seriellen Schnittstellen des A7150..
Die Doku habe ich irgendwo auf meiner Webseite.

Gruß,

Holm