mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welche Programmiersprachen benutzt ihr ?


Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

da ich im Bezug auf Mikrocontroller noch keine Erfahrung habe und ich 
mich seit kurzem intensiv damit beschäftige habe ich eine Frage an euch.

Was für Programmiersprachen benutz Ihr ?
Wo liegen welche Vor- und Nachteile ?
Bsp. Ist Basic langsamer wie beispielsweise C; Funktionsumfang ?
Was würdet Ihr mir empfehlen ?

Ich habe vor Jahren mit Basic und Delphi Programmiert, und wollte nun in 
die Mikrocontrollerwelt abtauchen. Dazu habe ich gestern zunächst erst 
mal ein ATMEL Butterfly bestellt. Ich möchte auch nicht unbedingt 
mehrere Programmiersprachen lernen müssen, so nach dem Motto „Fang man 
erst mit Basic an“. Wenn ich am Ende sowieso eine andere lernen „muss“.
Was sagt Ihr dazu ?

Grüße Torsten

Autor: sven s. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c

genauer benutz ich den gcc compiler (winavr) zusammen mit dem avr 
studio.

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Programmiersprache ist (erstmal) völlig egal (es gibt aber wohl kein 
Delphi für AVR...).
Wichtig ist es, sich mit dem Datenblatt des Controllers auseinander zu 
setzen, sich auch mal die Tutorien anzugucken
(C: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
AVR-Assembler: http://www.mikrocontroller.net/articles/AVR-Tutorial)
und wenn man sich z.B. für Bascom (Basic-Dialekt für AVR) entschieden 
hat, sich dessen Handbuch genauer anguckt, BEVOR man hier Fragen stellt.
Dann ist es natürlich auch wichtig, erstmal zu gucken, ob nicht jemand 
anders schon das gleiche Problem hatte (Suchfunktion des Forums/Google).

>Ist Basic langsamer wie beispielsweise C; Funktionsumfang ?
Vielleicht nicht langsamer, teilweise aber wesentlich 
resourcenunfreundlicher, sofern man die vorgegebenen Funktionen benutzt.

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zuerst mal angefangen, mich mit Assembler durch die 
Datenblätter zu wühlen. Mittlerweile bin ich bei C gelandet und denke, 
dass mir der Einstieg über Assembler geholfen hat. Ich hatte vorher noch 
keine Erfahrung mit C, lediglich ein wenig Delphi. Mit ANSI C kommt man 
aber ziemlich schnell zurecht, wenn man schon mal eine andere 
Programmiersprache benutzt hat.
Viel langwieriger meiner Meinung nach ist das Erlernen der Vorgänge im 
µC. Wenn man hardware-Funktionen benutzen will (und nicht eventuelle 
library-Funktionen des Compilers nutzt), muss man sowieso einzelne 
Register bearbeiten. Und das geht wiederrum genauso schnell in 
assembler.
Für die ersten kleinen "Hallo Welt"-Programme ist assembler also gar 
nicht verkehrt.
Ich habe aber auch schnell gemerkt, dass man in assembler schon sehr 
strukturiert und geplant vorgehen muss, damit man nicht sofort den 
Überblick über den eigenen Code verliert. Eine höhere Sprache wie C oder 
Pascal erleichtert so eine Strukturierung wie ich finde erheblich. 
Datenblätter lesen und verstehen ist aber für hardwarenahe 
Programmierung auch in Hochsprachen unerlässlich.
Ein anderes Thema ist die Verfügbarkeit. Einen Assembler bekommst du 
sicher zu jeder Architektur kostenlos. C gibt es für AVR mit dem gcc, 
alles andere kostet Geld oder ist in einer kostenlosen Version in der 
Codegröße oder Nutzungsdauer beschränkt. Zu nennen wäre da aber noch 
BASCOM für Basic oder AVRco Pascal. Vielleicht willst du auch gar nicht 
bei AVR bleiben. Für Microchip PIC gibt es beispielsweise auch schöne 
Compiler, allerdings auch fast alle kostenpflichtig. Mit anderen 
Architekturen hatte ich noch nicht zu tun.
Einen C-Compiler wirst du aber so gut wie für jeden Controller auf dem 
Markt finden. Wenn du vielleicht mal professionell mit den Dingern 
arbeiten willst, führt wohl kein Weg an C vorbei.

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die wirklich ausführliche Antwort "jmoney".
Vieleich mögen sich noch weitere zu dem Thema äußern.

grüße
Torsten

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C weil's für mich einfach am bequemsten ist. Besonders, weil ich als 
Hobbyloge nicht auf einen µC fixiert bin. Mal mache ich was mit AVR, mal 
mit ARM, mal mit R8C. Ich bin nicht mehr so fit, um jedes Mal im Kopp 
auf den passenden Assembler Instruction Set umzuschalten. Ich bin froh, 
wenn ich das mit den Spezialregistern schaffe. Vor Assembler schrecke 
ich nicht grundsätzlich zurück, beschränke mich aber darauf beim 
Debuggen. Die handvoll Befehle kann ich in dann nachschlagen.

Autor: dschedsche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C und wenn nötig assembler implementieren. grade bei zeitkritischen 
funktionen.

Autor: _sk_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C gibt es für --jeden-- Microcontroller. Bei jeder anderen Sprache 
kannst Du Glück, aber auch Pech haben.

In Assembler will ich heute kein komplettes Projekt mehr machen müssen. 
Assembler ist ok zum Kennenlernen des Processors und um KLEINE 
zeitkritische Programmteile effizient zu programmieren. In einem großen 
Projekt verlierst Du aber schnell den Überblick. Es gibt viele 
assembler-typische Bugs, die man sich mit den Hochsprachen spart.


Viele Grüße, Stefan

Autor: F.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Ich habe mich für die Pic's von Microchip entschieden.

Da ich auf eine Hochsprache nicht verzichten wollte,habe ich mich auf
die Suche nach einer Programmiersprache für diese Controller gemacht.

Eine visuelle Programmierspache:
http://www.parsic.de/
Ein Tip für diejenigen,die keine Hochsprache erlernen möchten.
Das Preis-Leistungs-Verhältnis ist gut
Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Basic:
http://www.pic-basic.de/
Eine Programmierspache von der,hoffentlich noch eine Menge zu erwarten
ist,derzeit,im Vergleich zu anderen Produkten, leider ein noch zu
schwaches Preis-Leistung-Verhältnis(wenig unterstützte Controller).
Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Basic:
http://www.il-online.de/il_indx1.htm
Dieses Basic ist sehr leistunsfähig,leider liefen meine Applicationen in
der Demoversion nicht auf dem 16F84.(wie angegeben). Die schwefällige
Kommunikation mit dem Hesteller bei Problemlösungen hat zum NEIN, bei
diesem Produkt geführt.
'********************************************************************
Das theoretisch beste Basic für Pic's wäre(meiner Meinung nach):
http://www.mikroelektronika.co.yu/german/compilers.htm
Leider habe ich mit einer Testversion die einfachsten Dinge nicht zum
laufen bekommen,der Support war gleich 0,vielleicht hat ja schon einmal
jemand positive Erfahrungen gemacht ?
Wenn funktionsfähig, 1.ste Wahl.
Erste Wahl,weil Debugger integriert.
**********************************************************************
Die Entscheidung fiel auf:
 http://www.picbasic.org/proton_lite.php
Ein leicht zu verstehendes Produkt,ein an die alte Basic Stamp
angelehnter
Befehssatz.
Ein Support in Punkto Programmierung war bisher nicht nötig.
Nachteil:
Ich habe eine Version,bei der, bei Defekt des Rechners,eine neue
Registration notwendig wird,das kann dann z.B. eine Woche dauern,bis man
wieder arbeitsfähig ist.
**********************************************************************
Sicher gibt es weitere, unerwähnte Umgebungen,aber die obigen habe ich
ausprobiert.

mfg F.H.



Autor: Mikrocon Troll-er (-42-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für AVRs ist BASCOM das Beste was es auf der großen ganzen Welt gibt. Da 
ich dafür zu blöd bin, programmiere ich in Assembler.

MFG

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*lol

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin für C zu blöd, und mache deshalb Assembler...8051

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F.H. wrote:

> Ich habe mich für die Pic's von Microchip entschieden.

Dann solltest Du eigentlich wissen, daß PIC nicht gleich PIC ist.


> schwaches Preis-Leistung-Verhältnis(wenig unterstützte Controller).
> Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Nun für Hochsprachen sind die kleinen PICs nur mit großen Bauchschmerzen 
zu verwenden. Ihnen fehlen einfach zuviele wichtige Befehle.
In nem anderen Thread hatte ich ja kürzlich gezeigt, was für 
schnuckelige Befehle bei anderen 8Bittern das Leben wesentlich einfacher 
machen.


Der Fokus der PIC-Hochsprachenentwickler liegt daher bei den PIC18xxx, 
die anderen 8Bittern befehlsmäßig nahekommen.
Und das wird sich kaum nach abwärts hin ändern.

Bzw. ein 16F84 Compiler würde nicht billiger sondern teurer sein, da er 
ja aufwendiger zu entwickeln wäre.


Peter

Autor: F.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F.H. wrote:

> Ich habe mich für die Pic's von Microchip entschieden.
Dannegger:
Dann solltest Du eigentlich wissen, daß PIC nicht gleich PIC ist.

Antwort: Darum steht da ja auch: Pic's von Microchip


> schwaches Preis-Leistung-Verhältnis(wenig unterstützte Controller).
> Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Dannegger:
Nun für Hochsprachen sind die kleinen PICs nur mit großen Bauchschmerzen
zu verwenden. Ihnen fehlen einfach zuviele wichtige Befehle.
In nem anderen Thread hatte ich ja kürzlich gezeigt, was für
schnuckelige Befehle bei anderen 8Bittern das Leben wesentlich einfacher
machen.

Antwort:
Dann schau Dir mal:
http://www.picbasic.org/proton_lite.php
an. Sehr effizienter Code,ich programmiere damit die meisten 
Durchschnittsanwendungen 10x schneller,als unsere Ing's in Assembler,nur 
in wenigen Ausnahmen kommt es vor , in Assembler programmieren zu 
müssen.

Dannegger:
Der Fokus der PIC-Hochsprachenentwickler liegt daher bei den PIC18xxx,
die anderen 8Bittern befehlsmäßig nahekommen.
Und das wird sich kaum nach abwärts hin ändern.
Antwort: Klar,Die 18er sind im kommen

Dannegger:
Bzw. ein 16F84 Compiler würde nicht billiger sondern teurer sein, da er
ja aufwendiger zu entwickeln wäre.

Blödsinn:
Antwort: Hättest Du dir die Link's angesehen,so hättest Du bemerkt,das 
SÄMLICHE oben genannten HERSTELLER,den 16F84 sowieso integriert haben.
Der 16F84 ist für kommerzielle Anwendungen viel zu teuer,somit könnte 
man eine Programmierumgebung nur für diesen Chip billig anbieten,da nur 
für Bastler interessant.




Autor: Oschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehöre zu denen, denen das Leben zu kurz fuer C ist. Alles andere 
ist gut. Zum Glück gibt's hie und einen Pascal compiler.

O.

Autor: sven s. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen 
das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein 
sollte.

wenn ich nur daran denke in assembler eine formel umzusetzen am besten 
noch mit 16 oder 32 bit auf einem z.b. avr... da würd ich mich lieber 1 
wochenende lang über ein C buch hocken.

basic ist auch nicht schlecht kann mich aber nicht dafür begeistern.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Zum Glück gibt's hie und einen Pascal compiler.
Ich dachte, ich habe von fast allen Programmiersprachen schon mal 
gehört. Aber was ist hie?

Ich programmierer alle meine Anwendungen mit Logo. Ist zwar recht 
langsam, sieht aber schnuckelig aus, wenn das Schildkrötendreieck die 
Umrandungen von Buttons, Fenstern usw. Linie für Linie zeichnet.

Autor: Pffft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen
>das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein
>sollte.

Es geht weniger um packen koennen, als ums wollen. Es ist mir zu blöd. 
Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C 
immer noch keinen. Jeder Controller kann den. Und ich soll einen 
kryptischen Bandwurm deswegen hinschreiben. Nee.

P.

Autor: Mikrocon Troll-er (-42-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C iss mir zu kryptisch.

MFG

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es geht weniger um packen koennen, als ums wollen. Es ist mir zu blöd.
> Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C
> immer noch keinen. Jeder Controller kann den. Und ich soll einen
> kryptischen Bandwurm deswegen hinschreiben. Nee.

in c ganz einfach:
a |= 0x40;  // setzt bit 6
b &= ~0x02; // löscht bit 1

jeder mittelmässige c-compiler setzt das direkt in die entsprechenden 
bit-setz/clear befehle um
:-)

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich programmiere AVR mit Bascom.

a.6 = 1    'setzt das Bit 6 der Variablen a
b.1 = 0    'löscht das Bit 1 der Variablen b

Kommt meiner Denkweise näher als die Schreibweise von Guro in C.
Was jetzt Bascom daraus macht muss ich nicht wissen , da meine
Anwendungen bisher nicht Zeitkritisch sind.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C ist eine echt miese Programmiersprache, aber es ist nun mal die beste 
die es für Controller gibt.

Autor: Pffft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt 2 Ansätze bits zu setzen

a |= 0x40;  // setzt bit 6
a |= 1 << 6;  // setzt bit 6

Wobei der zweite Weg eine Namensgebung erlaubt.

a |= 1 << TxEn;  // setzt bit 6

Wobei man natuerlich wissen muss, dass TxEn am PortA klebt.

Viel einfacher, auch aus dokumentierender Sicht ist doch

TxEn[@PortA,6]:bit;

TxEn:=1;  TxEn:=0;

Ganze Generationen von C Programmiern werden verarscht mit komplizierter 
Schreibweise weil irgendwelche Komitees von alten Sesselklebern, von 
denen natuerlich keiner mehr programmiert, keine Lust haben das zu 
aendern. Das haette man schon vor 20 Jahren aendern koennen.

P.

Autor: Pffft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Güte einer Programmiersprache kann man übrigens auch daran messen, 
wielange es in 2,4,6 Jahren dauert eine Aenderung zu machen.

P.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ich las Hobby-MikrocontrollerBastler C. Sollte es irgendwann mal für 
Hobbyisten bezahlbare Mikros mit richtig viel SRAM geben, wäre C++ das 
Mittel meiner Wahl, aber bis dahin halt C. Aktuelle 
Pascal-Implementierungen kenne ich nicht, die, die ich kennengelernt 
habe, waren zur hardwarenahen Programmierung ungeeignet.

Ich habe während meiner Studienzeit einiges im Bereich NC-Steurungen 
programmiert. In Pascal, C, C++, und immer wieder Assembler. Erste 
Programmiererfahrungen gabs zur Schulzeit in Basic. Mit allen Spachen 
kann man problemlos völlig strukturlose, schwer zu lesende und gar nicht 
zu wartende Programme schreiben. Saubere Programmstrukturen, definierte 
Schnittstellen, wiederverwendbare Module bekommt man auch mit allen hin, 
allerdings erfordert das mit Assembler höchste Disziplin, und mit Basic 
geht es schlicht und einfach gar nicht. Vielleicht ja mit Visual Basic 
auf dem PC, das kenne ich nicht.

Ich erfasse ein paar Daten an meiner Heizung mit einer C-Control, und 
jedes mal, wenn ich da wieder Basic anwerfen muß, bekomme ich fast 
Schreikrämpfe. Für 20-zeilige Miniprogramme, quick and dirty, ist das 
prima, für mehr aber nicht.


Meine Meinung
Oliver

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

für meine Projekte war bisher Assembler die erst Wahl.
Voreingenommen, weil auch schon Z80, 6800, 6510 Assembler. ;)

Man kann auch in Basic saubere Strukturen programmieren, allerdings: ASM 
zwingt dazu mehr oder weniger schnell, wenn man seinen eigenen Kram in 4 
Wochen noch verstehen will, C zwingt auf Grund seiner Struktur dazu, bei 
Basic muß man es ganz von alleine machen, weil es eben auch völlig ohne 
geht (Spaghetti-Code eben).

Ich muß auch in Basic nicht zwingen dutzende GOTO verwenden, nur weil es 
geht.

Für meine Projekte habe ich bisher mit C meist das Problem, daß mir die 
komplexen Rechenergeschichten durch Bibliotheken bisher nicht wirklich 
fehlten.
Bit-Schubsereien sind mir da in ASM lieber.
Ich bin auch kein Freund von Universal-Bibliotheken, eher von 
Teilebaukästen. UART-Init mit den nötigen Berechnungsformeln für die 
Registerwerte kann ich in ASM genauso schnell kopieren, SendByte und 
ReceiveByte auch.
Routinen, die Register nach ASCI wandeln, auch für 16Bit-Werte liegen 
irgendwo rum usw.
Meine LCD-"Bibliothek" besteht genau aus LCD_Init, LCD_Write_Line, 
LCD_Clear_Line. Ich schreibe bis jetzt immer eine komplette Zeile, das 
hat noch nie wirklich gestört. Sollte es eine Ausnahme geben, baue ich 
mir die eben und setze sie wieder ein, wenn nötig.
Wozu soll ich aber diese Funktionen immer mit einbauen, nur weil ich sie 
in einem von hundert Fällen mal brauche?

Alles persöhliche Meinung von mir... ;)

Gruß aus Berlin
Michael



Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. wrote:


> C zwingt auf Grund seiner Struktur dazu, bei
> Basic muß man es ganz von alleine machen, weil es eben auch völlig ohne
> geht (Spaghetti-Code eben).

Auch in C kann man Spaghetti Code schreiben, einfach main(){... und los.
Aber C macht es einem leicht, in Funktionen zu schreiben, Basic dagegen 
macht Spaghetticode leicht.

Und das ist der Hauptunterschied, niemand kann 1.000 Zeilen Spaghetti 
verstehen, 10.000 Zeilen in Funktionen unterteilt dagegen schon.

Man sieht das sehr deutlich, wenn hier Bacom Quelltext gepostet wird, 
sind die Antworten rar. Dauert eben erheblich länger da durchzusteigen.

Auch, wenn man von Assembler aufsteigen will, ist C viel schöner, da man 
dort ja die ganzen indirekten Pointerzugriffe machen kann, wie unter 
Assembler.


> Für meine Projekte habe ich bisher mit C meist das Problem, daß mir die
> komplexen Rechenergeschichten durch Bibliotheken bisher nicht wirklich
> fehlten.

Unter C liegen alle Bibliotheken in der Regel als Quelltext vor und man 
kann sie anschauen, wie sie funktionieren oder auch modifizieren, wenn 
man einen Bug entdeckt.

Unter Bascom hat man aber nur Legosteinchen in die man nicht reinsehen 
kann.
Gerade bei größeren Programmen krachts dann gewaltig, weil man eben 
nicht die Seiteneffekte der Legosteinchen erkennen kann.


> Bit-Schubsereien sind mir da in ASM lieber.

Ist ne reine Gewöhnungsssache, die 1<<Bit Operatoren hinzuschreiben, 
nach einem Tag C proggen merkste das garnicht mehr.


Bezüglich ASM mit Hochsprache mixen ist meine Meinung, unbedingt sein 
lassen.
Es zerstört total die Portabilität und bringt rein garnichts. Was sind 
1000 eingesparte Zyklen je Sekunde (0,005%).


Peter

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> C und wenn nötig assembler implementieren. grade bei zeitkritischen funktionen.

Dieses Argument kommt immer wieder und ich möchte gerne mal ein Beispiel 
sehen, aus meiner Sicht blödsinn.

> C gibt es für --jeden-- Microcontroller. Bei jeder anderen Sprache kannst Du 
Glück, aber auch Pech haben.

So ist es, das war auch für mich der Grund. Immer wieder einen neuen 
Assembler, nach dem 2en hatte ich die Faxen dicke.
Allerdings muß ich sagen das ich 15 Jahre lang Assembler programmiert 
habe und es zu weilen noch verwende.

> bin für C zu blöd, und mache deshalb Assembler...8051

> Ich gehöre zu denen, denen das Leben zu kurz fuer C ist.

Kann ich nachvollziehen. Die die C beherrschen verweisen auf K&R, 
genauso gut könnte man Laurel & Hardy empfehlen.
Ich kenne kein schlechteres C Buch, aber so ist es. Hat man den Einstieg 
gefunden so ist der K&R wieder zu gebrauchen.

Man muß davon ausgehen das Fachbücher von Leuten geschrieben werden die 
wissen wie es geht und genau hier liegt das Problem ;-))

> C iss mir zu kryptisch.
Das kann es sein, muß es aber nicht. Es liegt an dir.

> an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen
das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein
sollte.

Siehe Kommentar "blöd". Im Prinzip stimme ich hier voll zu aber häufig 
scheint eben nur der Einstieg das Problem zu sein, ging mir auch so.
Hat man den Einstieg so wird man in C eine Eleganz entdecken die 
Assembler weit vorraus ist.

> Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C immer 
noch keinen.

Na ja, beschäftige dich mit C für MC's und du wirst sehen das die 
Aussage falsch ist.

> C ist eine echt miese Programmiersprache, aber es ist nun mal die beste die es 
für Controller gibt.

Der gefällt mir.

Fazit: Wer MC's im profeesionellen Umfeld programmieren will kommt an C 
nicht vorbei. Wenn es Hobby ist dann ist es eh wurscht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe wrote:
>> C und wenn nötig assembler implementieren. grade bei zeitkritischen funktionen.
>
> Dieses Argument kommt immer wieder und ich möchte gerne mal ein Beispiel
> sehen, aus meiner Sicht blödsinn.

Ja aber voll und ganz meine Meinung !!!

Es ärgert mich zwar, daß AVR-GCC in jedem Interrupthandler 3* völlig 
umsonst pusht und popt (*), aber so richtig stören tuts trotzdem nicht.


Peter

(*)
Wenn einfach als Zero R2 und als SREG-save R3 definiert würden, wären 2* 
"PUSH R0" und 1* "PUSH R1" erspart geblieben.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze hauptsächlich als Prossesor AVR Mega Serie (Preis/Leistung)
daher finde ich Bascom und FastAVR in Verbindung mit Assembler mit
Assembler Routienen am Besten.

Dir Programmiersprache C auch zu Kryptisch.

MfG

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe wrote:

> Siehe Kommentar "blöd". Im Prinzip stimme ich hier voll zu aber häufig
> scheint eben nur der Einstieg das Problem zu sein, ging mir auch so.
> Hat man den Einstieg so wird man in C eine Eleganz entdecken die
> Assembler weit vorraus ist.


Ich hab jahrelang Assembler gemacht.
Ein Kollege hatte etwa 10.000 Zeilen C aufm 8051 geschrieben und die 
Firma verlassen.
Ich mußte dann in diesem Programm Erweiterungen einbauen.
Ich weiß zwar immer noch nicht, was jede der 10.000 Zeilen genau macht, 
aber die Änderungen laufen einwandfrei und seitdem mache ich auch alles 
andere in C.
Ich kann nur sagen, daß ich diesem Kollegen sehr dankbar dafür bin.


Peter

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich programmiere in Assembler, hab damit angefangen und auch damit 
weiter gemacht. Zwischendurch hab ich auch mal in C programmiert, 
gefällt mir aber irgendwie nicht so richtig. Bis jetzt habe ich aber 
auch noch nichts kompliziertes auf nem µC gerechnet. Ich denke wenn man 
Floatingpoint Zahlen durcheinander teilen muss wird das mit Assembler 
langsam unangenehm ;) Bisher brauchte ich das aber auch noch nciht und 
ich denke auch, dass man auf so einem kleinen µC sehr selten bis nie FP 
braucht ;)

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke,

habe FP sowohl in Assembler als auch in C verwendet, im Prinzip beides 
kein Problem. Aber heute schreibe ich keine Matheroutinen mehr in 
Assembler. Mein letztes Projekt dieser Art liegt 2 Jahre zurück und in 
ASM war es eine Qual.

> Zwischendurch hab ich auch mal in C programmiert, gefällt mir aber irgendwie 
nicht so richtig.

Mich würde das Irgendwie mal interessieren. Wo genau ist denn das 
Problem ?

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist schwer zu erklären. Bis man erst mal alle Compiler etc am laufen hat 
und andere Rätsel von C generell gelöst hat (Makefiles waren mir am 
anfang ein riesen Rätsel) ist erst schon mal ne Zeit vergangen. Bei C 
ist es irgendwie so, wenn man drin ist, ist alles ganz einfach, aber 
wenn man versucht einzusteigen versteht man nur Bahnhof. Bei den AVRs 
ist das ja noch relativ human mit dem AVR-Studio und eingebundenem C. 
Wobei ich dort auch schon probleme hatte, ich wollte was Simulieren, auf 
dem µC funktionierte es prima, aber in der Simulation blieb er ohne 
erkennbaren grund hängen (hab ihn eine Nacht laufen lassen). Aber für 
die ARM7 Reihe hab ich das ganze noch nicht zum laufen bekommen (was 
nicht heißen soll, dass ich vorhabe die in Assembler zu programmieren).

Alles in allem hab ich bis jetzt noch nicht dringend C gebraucht und bin 
deswegen auch schon an den kleinen Hürden hängen geblieben.

Autor: Flexverbinder mit Wackelkontakt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bis man erst mal alle Compiler etc am laufen hat

Das ist allerdings nur eine Frage des OS sowie des Compilers. Wenn 
beides stimmt, reduziert sich alles auf anklicken einer setup.exe, und 
alles rennt. Und ein guter Compiler nimmt einem außerdem das 
Makefilegeraffel komplett ab.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, makefile ist auch keine "schwarze Kunst" ;-))

>Bei C ist es irgendwie so, wenn man drin ist, ist alles ganz einfach, aber wenn 
man versucht einzusteigen versteht man nur Bahnhof.

Das bestätigt aber das was ich weiter oben ausgeführt habe. Also, Hände 
weg von K&R ;-))

Autor: Kai Scheddin (zeusosc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c, c++, asm
und basecom (gezwungerner maßen),...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ordentlich geschriebene C-Programme sind sehr gut auf andere 
Compiler/Prozessoren portierbar (z.B. die Entprell-, RC5- und 
DCF7-Routinen von Peter). Wenn die Hardware nicht 100% abstrahiert ist 
muss man halt ein paar kleine Änderungen vornehmen, aber das ist immer 
noch besser als alles neu schreiben zu müssen.

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Real men only program in ASM :lol:

C ist viel einfacher/schnellen zu programmieren als asm, und viel 
einfacher zu debuggen.

"Use Interfaces" sind viel einfacher auf C als auf ASM, aber mit asm du 
kannst mehr Kraft für deines Geld bekommen.

Aber wie immer, wer wird dein Quellcode sehen ?, nur du ?, egal. Am 
Arbeitsplatz ?, besser wenn es gut dokumentiert ist, für alle.

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für ich las Hobby-MikrocontrollerBastler C. Sollte es irgendwann mal für
> Hobbyisten bezahlbare Mikros mit richtig viel SRAM geben, wäre C++ das
> Mittel meiner Wahl...

c++ ist zwar die eierlegende wollmilchsau unter den programmiersprachen, 
aber  wenn man es so verwendet, wie's die c++ fans machen (konsequenter 
einsatz der ganzen oo-features, templates, laufzeitpolymorphie usw.), 
dann zwingst du damit den dicksten controller in die knie...
einer maschine, die ausreichend performant mittelgrosse c++ anwendungen 
ausführen kann, kannst du auch gleich eine java-vm spendieren ;-)
selbst abgespecktes embedded-c++ konnte sich bis heute nicht 
durchsetzen...

Autor: Steven Wetzel (steven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz wrote:
> Ordentlich geschriebene C-Programme sind sehr gut auf andere
> Compiler/Prozessoren portierbar (z.B. die Entprell-, RC5- und
> DCF7-Routinen von Peter).

"Ordentliche" C-Programme sind meist nicht µC-optimiert.
Interrupt-Routinen für den AVR werden wohl nicht dieselben wie beim PIC 
oder MSP430 sein. Mag sein, dass man ein c=a+b; portieren kann, aber 
wenn es um Timeraufgaben, Senden über UART oder CRC32-Check mi Hilfe der 
eingebauten Hardware, kurz, wenn es um die interne Hardware geht, ist 
C-Portierung einfach am Ende.

Desweiteren verstehen einige C-Compiler für µC Bitmanipulation, welche 
sich überhaupt nicht portieren lassen, da sie nicht einmal ANSI-C sind. 
Dafür erzeugen sie sehr kompakten Code. Man braucht nur den aufgeblähten 
Code eines GCC mit dem eines Codevision AVR zu vergleichen.

Steven
betacom@my-japan.de

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man braucht nur den aufgeblähten Code eines GCC mit dem eines Codevision
> AVR zu vergleichen.

ich verstehe auch nicht, warum GCC so einen guten ruf hat. nur weil er 
umsonst ist? eigentlich kann er den kommerziellen compilern nicht das 
wasser reichen. ich habe noch keinen GCC erlebt, der schlanken, 
schnellen code erzeugen kann...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steven Wetzel wrote:
> Andreas Schwarz wrote:
>> Ordentlich geschriebene C-Programme sind sehr gut auf andere
>> Compiler/Prozessoren portierbar (z.B. die Entprell-, RC5- und
>> DCF7-Routinen von Peter).
>
> "Ordentliche" C-Programme sind meist nicht µC-optimiert.
> Interrupt-Routinen für den AVR werden wohl nicht dieselben wie beim PIC
> oder MSP430 sein. Mag sein, dass man ein c=a+b; portieren kann, aber
> wenn es um Timeraufgaben, Senden über UART oder CRC32-Check mi Hilfe der
> eingebauten Hardware, kurz, wenn es um die interne Hardware geht, ist
> C-Portierung einfach am Ende.

Solche Dinge muss man natürlich neu schreiben. Aber schau dir die schon 
erwähnten Programme von Peter an (Codesammlung). Da änderst du 1-2 
Zeilen, und schon kannst du die RC5-Dekodierung o.ä. statt auf dem AVR 
auch auf dem ARM verwenden. Anderes Beispiel: du kannst Programmteile 
zum Testen komfortabel auf dem PC ausführen und den selben Code direkt 
für den Controller kompilieren. Mache ich so bei meinem MP3-Player mit 
der ID3-Tag-Auswertung. "make id3test", der Code wird auf dem PC mit 
verschiedenen MP3-Files auf korrekte Funktion überprüft, "make program", 
der selbe Code landet auf dem µC.

> Desweiteren verstehen einige C-Compiler für µC Bitmanipulation, welche
> sich überhaupt nicht portieren lassen, da sie nicht einmal ANSI-C sind.
> Dafür erzeugen sie sehr kompakten Code. Man braucht nur den aufgeblähten
> Code eines GCC mit dem eines Codevision AVR zu vergleichen.

Das hat absolut nichts mit der Syntax zu tun, die ist nur Kosmetik. Der 
GCC kann aus "PORTB |= 1<<2" genausogut ein "sbi PORTB, 2" machen wie es 
Codevision (hoffentlich) aus "PORTB.2 = 1" kann.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guro wrote:
>> Man braucht nur den aufgeblähten Code eines GCC mit dem eines Codevision
>> AVR zu vergleichen.
>
> ich verstehe auch nicht, warum GCC so einen guten ruf hat. nur weil er
> umsonst ist?

Weil er ein sehr gutes Preis/Leistungs-Verhältnis hat.

> eigentlich kann er den kommerziellen compilern nicht das
> wasser reichen. ich habe noch keinen GCC erlebt, der schlanken,
> schnellen code erzeugen kann...

"Schlank" und "schnell" ist relativ. Der vom (AVR-)GCC erzeugte Code ist 
für viele Anwendungen schlank und schnell genug. Und es ist ja nicht so 
dass der Code dreimal so groß wäre wie der von IAR erzeugte.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> eigentlich kann er den kommerziellen compilern nicht das
> wasser reichen

Ach? Sehe ich anders, jedenfalls was die Qualität des vom Compiler 
erzeugten Codes angeht. Von den Herstellern kommerzieller Compiler 
angestellte Vergleiche sind wie üblich mit Vorsicht zu geniessen.

Die Nachteile liegen eher woanders:

- In der Unterstützung spezieller Features wie getrennten Adressräumen 
für Code/Daten/EEPROM und dergleichen. Damit kommt GCC nicht zurecht, 
kommerzielle Compiler hingegen schon.

- In der Library. Speziell die bei GCC/ARM oft verwendete newlib neigt 
zu einer gewissen "Grundlast". Dass es auch anders geht, beweist 
WinAVR/avr-libc. Und mit dem Compiler hat das sowieso nichts zu tun.

- Manche Anwender schwören auf Compilererweiterungen, mit denen die Bits 
von I/O-Registern angenehmer abgebildet werden können. Aber Vorsicht, 
proprietäre Falle: Umstieg dann unmöglich.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> So falsch ist die Aussage gar nicht. C für µC ist meistens kein ANSI-C.
>> Und somit erübrigt sich auch die Feststellung, man solle ASM und
>> Hochsprachen der Portierbarkeit nicht mixen. Das ist mit C für µC
>> ohnehin schlecht machbar.

Das Thema Portierbarkeit wird auch oft falsch angegangen. Ich schreibe 
für diverse MC Typen/Hersteller und mit Ausnahme des I/O Handling sowie 
spezifische Funktionen wie Interrupts, Timer... läßt sich alles in kürze 
portieren. Der Arbeitsaufwand liegt bei ca. 20%

In ASM gehts überhaupt nicht, 100%

Was ist vorteilhafter ?

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, gelernt habe ich inzwischen Assembler, Pascal+Delphi, C und 
Derivate,  VB etc und Clipper. Beim Atmel mag Bascom recht kompfortabel 
sein, aber spätestens beim Umstieg auf andere Prozessoren guckt man in 
die Röhre. Also kommen eigentlich nur Assembler und C in Frage. Ich 
nutze C, weil es (meiner Meinung nach, nicht schlagen) wesentlich 
übersichtlicher und einfacher ist. Assembler ist da so ein bischen 
Urschleim. Bei Controllern ist man eh Recht hardwarenah am arbeiten, im 
PC-Bereich würde ich Assembler gar nicht mehr anfassen. Allerdings halte 
ich es für nicht unwichtig, sich mit Assembler auseinanderzusetzen, 
schon allein weil man dann die Funktionsweise eines Prozessors besser 
kennenlernt.

Ich persönlich bewundere die Assembler-Programmierer. Aber ich bewundere 
auch Boxer und würde mir selber nie für Geld die Fresse polieren lassen 
;-)


Gruß
Günni

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer ins Assembler programmieren will, na lass sie machen.

Mann kann diese Leute auch Masochisten nennen..

Allerdings in einem muss ich zustimmen.
Wer auf µC programmiern will ( muss) , kommt ohne Assembler nicht aus.

Nicht zum Programmieren, aber beim Debuggen im System geht es nicht 
ohne.

Wer seinen µC mit den Resourcen so knapp kalkuliert hat, das es auf 
einzelne Takte ankommt, hat etwas grundlegendes falsch gemacht.

Software wird IMMER größer als geplant.



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.