Hallo, ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in welcher Sprache ich meine µC programmieren sollte... Ich hab eig. gedacht ich mache es mit C++ aber in letzter Zeit bin ich mir da nicht mehr so sicher, ich habe mehr über Basecon und C gelesen und frage mich nun welche Sprache wohl "leichter", übersichtlicher und zukunftsorientierter wäre. Natürlich wäre es auch wichtig, dass man geeigneten Support im Inet dazu findet. :-/ Auf eure Meinungen freu ich mich schon sehr.
Ich dachte auch immer C++ wäre der Nachfolger von C und damit "moderner" also vielseitiger und einfach besser und beliebter.
Für kleine µC ist C noch immer das Mittel der Wahl. Manchmal ist auch Assembler sinnvoll. C++ eher weniger.
Da ist natürlich die erste Rückfrage: Was für ein µC? Zur Zeit reicht die Auswahl vom Pic12 mit 1k Programmspeicher bis zu ARMs mit Linux Betriebssystem.
leinad R. schrieb: > und frage mich nun welche Sprache wohl "leichter", übersichtlicher und > zukunftsorientierter wäre. Alles geht nicht. Leichter ist wohl Bascom, nach allem, was ich gehört habe, übersichtlicher ist Geschmackssache und zukunftsorientierter ist C. leinad R. schrieb: > Ich dachte auch immer C++ wäre der Nachfolger von C und damit "moderner" > also vielseitiger und einfach besser und beliebter. Im PC-Bereich. Aber man könnte sagen, die kleinen Controller haben da nicht mitgehalten. C++ ist eine Erweiterung von C, deren neue Fähigkeiten aber zu komplex für kleine Controller sind. Vor Allem fehlt der RAM. Übrigens wird das hier sicher wieder ein C-gegen-Bascom-Diskussion.
leinad R. schrieb: > Hallo, > ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in > welcher Sprache ich meine µC programmieren sollte... Worum geht es denn? Beruf oder Hobby? "egal" beschrieb es schon, aber wie man hier im Forum sieht, beschäftigen sich auch noch Leute mit Bascom.
leinad R. schrieb: > In welcher Sprache sollte man programmieren? Wenn du programmieren solltest, kannst du das in C tun, mußt es aber nicht.
Dussel schrieb: > Übrigens wird das hier sicher wieder ein C-gegen-Bascom-Diskussion. Wozu, die Lage ist doch klar.
Wie ist folgender Vorschlag: -Lern einfach programmieren, dann ist die Sprache egal. Je nach Aufgabenstellung und Einsatzgebiet nimmst du dann die Sprache deiner Wahl.
Ich könnte in C, Pascal und Basic. Für meine Hobbyzwecke habe ich mich für LunaAvr und Bascom entschieden. Für rein berufliche Zwecke nehme C weil es in diesem Umfeld einfach Standard ist. Schnuppere mal in alle Sprachen rein und entscheide Dich für das für DICH passende.
K.R. schrieb: > Dussel schrieb: >> Übrigens wird das hier sicher wieder ein C-gegen-Bascom-Diskussion. > > Wozu, die Lage ist doch klar. Ist sie das? Bisher ist es ruhig geblieben, aber ich bin davon ausgegangen, dass hier wieder die Leute einfallen, die meinen, dass nur ihre Position die richtige ist. Ich bin ja froh, dass es bisher nicht so ist. Mir ist auch noch eingefallen, dass Matlab und Simulink stark an Bedeutung gewinnen. Es verbreitet sich immer mehr, dass Modelle geschrieben und für Controller umgesetzt werden. Für den Hobbybereich ist das nicht relevant, da die entsprechenden Programme viel zu teuer sind, aber in der Industrie setzt sich das immer mehr durch.
C++ ist im Prinzip eine Erweiterung von C um Features zur objektorientierten Programmierung. Die sind nützlich wenn man große Programme mit vielen ähnlichen Objekten hat, die am besten auch noch zur Laufzeit entstehen und rumgereicht werden müssen. In typischen Mikrocontrolleranwendungen ist das aber nicht der Fall, deshalb reicht dafür normales C. Der Vorteil von C ist, dass es eine schlanke Programmiersprache mit wenig Schlüsselwörten und nur den wichtigsten Bibliotheksfunktionen ist. Die Datentypen sind sehr hardwarenah. Man kann die Programmiersprache daher gut überschauen und nachvollziehen, was der Code tatsächlich im Mikrocontroller macht. Im Vergleich zum Assembler werden einem viele Detailentscheidungen abgenommen, man bleibt aber für eine Hochsprache ziemlich nah am Geschehen. Der Unterschied von C im Vergleich zu anderen Sprachen wie Bascom ist, dass C ohne Bibliotheken im Prinzip nichts kann, daher wird C auch manchmal als "Makroassembler" bezeichnet. Die Programmiersprache enthält z.B. keine vorgefertigen Befehle oder Funktionen, um die Peripherie eines Mikrocontrollers zu nutzen, nicht mal zum Ein/Ausschalten eines einzelnen Pins. Alles was C kann, ist Werte an bestimmte Speicherzellen schreiben. Welche Speicherzellen das sind und was da reingehört, muss man selber im Datenblatt des Mikrocontrollers nachschauen. Gut daran ist, man versteht wirklich, was dabei passiert. Schlecht ist, man braucht wesentlich länger, um ein lauffähiges Programm zu erzeugen. Das gilt zumindest, wenn man alles selber machen will. Man muss das natürlich nicht, denn es gibt jede Menge fertiger C-Bibliotheken, die einem die Funktionen des Mikrocontrollers über einfache Funktionsaufrufe bereitstellen. Das Problem ist nur, dass man in dem riesigen Angebot erstmal eine gute Bibliothek finden muss und sie meistens noch auf seinen speziellen Controller anpassen muss. Jeder Programmierer gestaltet seine Bibliotheken anders und auch die Qualität variert enorm. Wenn man Pech hat, sind zwei Bibliotheken, die für sich beide funktionieren miteinander inkompatibel und man muss doch wieder selber Hand anlegen. Das kann alles sehr mühsam sein, so dass man für viele Dinge sich seine Bibiotheken doch lieber selber schreibt. An der Stelle kommen dann alternative Programmiersprachen wie Bascom, Luna, die Arduino-Entwicklungsumgebung usw. ins Spiel. Bei diesen Sprachen sind schon mehr oder weniger umfangreiche Bibliotheken direkt in die Programmiersprache integriert. Der Vorteil ist, diese Bibliotheken werden auf einheitliche Weise verwendet und sind zueinander kompatibel (natürlich nur innerhalb der gleichen Sprache). Man kann damit also sehr schnell funktionierende Programme zusammenbasteln. Was dabei genau im Mikrocontroller passiert, bleibt aber hinter der Abstraktionsschicht verborgen. Zum Lernen sind sie daher meiner Meinung nach ungeeignet. Außerdem decken diese Bibliotheken natürlich nicht den gesamten Funktionsumfang des Mikrocontrollers ab, sondern nur einen abstrahierten Ausschnitt davon. Wenn man etwas spezielleres machen möchte, muss man sich doch wieder auf die Registerebene hinab begeben und bei Null anfangen. Die integrierten Bibliotheken lassen sich, zumindest soweit ich weiß, nicht modifizeren bzw. nur in Teilen weiterverwenden. Bei Bascom kommen dann noch syntaktische Unterschiede dazu, die Leute ansprechen, die vorher schon Basic programmiert haben und sich damit beim Einstieg/Umstieg in die Mikrocontrollerprogrammierung leichter tun. Als Anfänger bringt Dir das keinen Vorteil, denn die C-Syntax ist nicht schwieriger oder leichter, sie ist nur anders. Sie findet sich außerdem in den anderen gebräuchlichen Sprachen wie C++, C#, Java, PHP usw. wieder, sie hat sich also (imo nicht ohne Grund) durchgesetzt. Wenn Du also etwas universelles, zukunftsorientiertes lernen möchtest, dabei auch verstehen, was im Mikrocontroller passiert und seinen ganzen Funktionsumfang nutzen können willst, dann lerne C. Wenn Du mal auf C++ oder einen anderen Controller umsteigst oder PC- oder Webprogrammierung betreiben willst, ist dieses Wissen keineswegs verloren. Wenn es Dir dagegen hauptsächlich darum geht, schnell zum Ziel zu kommen und Du den Mikrocontroller mit weniger Aufwand für Standardaufgaben einsetzen willst, ohne allzu tief in die Programmierung einzusteigen, dann ist vielleicht auch eine der alternativen Sprachen etwas für Dich.
Wenn schon Hochsprache, so schadet es aber nicht, wenn man zu seinem µC auch den Assembler etwas kennt. Die Architektur des µC muß man sowieso kennen. Assemblerkenntnisse helfen bei Fehlern und Nachschauen in den Listings oft ungemein. Z.B. was genau auf dem Stack passiert, und bei Funktionsübergabeparametern.
Fabian O. schrieb: > Der Unterschied von C im Vergleich zu anderen Sprachen wie Bascom ist, > dass C ohne Bibliotheken im Prinzip nichts kann, die aber Bestandteil des Standards sind. Der Unterschied ist das du dir die Teile so zuschneiden kannst wie du es brauchst. > daher wird C auch > manchmal als "Makroassembler" bezeichnet. Was es ja auch ist, nur eben ein universeller, hochportabler und konfigurierbarer Makroassembler > Die Programmiersprache enthält > z.B. keine vorgefertigen Befehle oder Funktionen, um die Peripherie > eines Mikrocontrollers zu nutzen, nicht mal zum Ein/Ausschalten eines > einzelnen Pins. Was auch keinen Sinn macht weil dann alle oben genannten Eigenschaften schlicht weg wären. Dafür macht sich der Compilerhersteller dran das reinzubauen. Mit dem Ergebnis das du beides (mit Abstrichen) bekommst. Ich hab mit Assembler angefangen, dann Basic gemacht und bin jetzt bei C. Assembler ist wie eine Handkarre bei der du dich mühsam über den Acker schiebst, Basic wie ne fette Familienkutsche die gemächlich vor sich hinschaukelt (aber schon bei 5cm Schnee nicht den Berg hochkommt und C wie n Formel 1 Renner. Eine falsche Drehung am Lenkrad und schon fliegst du aus der Kurve. Aber wenn du dann fahren gelernt hast gehts ab (in allen Belangen ;-). Dann hast du noch n Riesen Werkzeug- und Ersatzteillager die du alle mit ein wenig zurechtfeilen einsetzen kannst. Das bietet weder die Handkarre noch die Kutsche.
Liest sich hier gerade als hätten die meisten noch nicht viel C++ programmiert. C++ lässt sich hervorragend auch auf kleinen Mikrocontrollern verwenden wenn man sich um die Kosten verschiedener Sprachfeatures bewusst hält. Dinge die man abwägen sollte sind etwa virtuelle Funktionen oder Exceptions. Ansonsten hält sich C++ stark nach dem Motto: "nichts bezahlen für Dinge die man nicht nutzt".
heeen schrieb: > C++ lässt sich hervorragend auch auf kleinen Mikrocontrollern verwenden > wenn man sich um die Kosten verschiedener Sprachfeatures bewusst hält. Natürlich. Jedes C-Programm ist auch ein C++-Programm, aber wenn man von C++ spricht, geht es um die Erweiterungen von C. Die wahrscheinlich bedeutendste ist die Objektorientierung. Und damit wird es auf einem kleinen Controller knapp.
Der Rächer der Transistormorde schrieb: > Das bietet weder die Handkarre noch die Kutsche. Und C ist halt das Mittelding, was man aber auch zur Oberklasse ausfeilen kann. Man muß halt vieles selbst machen. Ich fing einst auch mit Basic an, auch mit Assembler. Ein leistungsfähiger Makroassembler bietet mal noch was, ist aber stark toolabhängig. heeen schrieb: > Liest sich hier gerade als hätten die meisten noch nicht viel C++ > programmiert. Das stimmt. Mir erschloß sich der Grund nie so recht.
OK das war ja jetzt schonmal ewig viel zu lesen :D Ich denke ich werde mir jetzt nach etwas C++ mal C anschauen und dann einfach mal sehen was sich ergiebt. Auf alle Fälle danke an alle, besonders an Fabian für diesen ausführlichen Roman :-)
heeen schrieb: > Liest sich hier gerade als hätten die meisten noch nicht viel C++ > programmiert. Was haben denn die Sprachwerweiterungen auf einem µC für Vorteile? Bei den Projekten die ich mache ist die Kapselung von C genau das richtige. Die ++ Komponenten erscheinen mir (als C++ Novize) eher wie eine höhere Abstraktionsebene. Auf einem Kontroller vermeide ich So was aber. Aus diversen Gründen.
> In welcher Sprache sollte man programmieren?
In einer, die für den konkreten Anwendungsfall geeignet ist.
Bei Mikrocontrollern ist C nun mal der Standard, was aber nicht heißt
dass man keine andere Sprache verwenden darf. Zumindest aber macht man
nichts grob verkehrt, wenn man sich hier für C entscheidet.
Um mal ein bisschen dieser gefährlichen und halbwissenden Behauptung "C++ = C with Classes" entgegen zu wirken. Ja, C++ ist damals in den 80er Jahren so entstanden und ja, C++ kann man größtenteils wie C programmieren (viele Elemente sind gleich oder ähnlich). Aber seit den Anfängen von C++ sind mittlerweile fast 30 Jahre vergangen und C++ und C sind vollkommen verschiedene Sprachen. Die obenstehende Behauptung ist also schon seit Jahrzehnten hinfällig.
Herbert Sutter: Für alle die glauben, dass man C++ nach überschaubarer Zeit beherrschen kann (http://gotw.ca/gotw/) Hermann Wacker: Die C-Katastrophe (http://www.wackerart.de/c.html) Henning Thielemann: C-Hasser in 10 Tagen (http://www.henning-thielemann.de/CHater.html)
André M. schrieb: > Anfängen von C++ sind mittlerweile fast 30 Jahre vergangen und C++ und C > sind vollkommen verschiedene Sprachen. C Programme lassen sich mit nur geringfügigen Änderungen in C++ übersetzen. Der Übergang von C zu C++ insbesondere bei µCs ist also fliessend, zumal man sich unterhalb der dicken Brummer auf dafür verträgliche Sprachkonzepte beschränken muss. Aus Sicht eines Anwendungsprogrammierers auf PCs stellt sich das freilich anders da.
Thomas der enterbte schrieb: > Herbert Sutter: Für alle die glauben, dass man C++ nach überschaubarer > Zeit beherrschen kann (http://gotw.ca/gotw/) > Hermann Wacker: Die C-Katastrophe (http://www.wackerart.de/c.html) > Henning Thielemann: C-Hasser in 10 Tagen > (http://www.henning-thielemann.de/CHater.html) Ich selbst bin das beste lebende Beispiel dafür. Hochsprachen haben mich an sich nie gequält, aber so ein +++++ Zeugs.
A. K. schrieb: > André M. schrieb: >> Anfängen von C++ sind mittlerweile fast 30 Jahre vergangen und C++ und C >> sind vollkommen verschiedene Sprachen. > > C Programme lassen sich mit nur geringfügigen Änderungen in C++ > übersetzen. Der Übergang von C zu C++ insbesondere bei µCs ist also > fliessend, zumal man sich unterhalb der dicken Brummer auf dafür > verträgliche Sprachkonzepte beschränken muss. Aus Sicht eines > Anwendungsprogrammierers auf PCs stellt sich das freilich anders da. Bei dem reduzierten Sprachumfang, auf den man dann zurückgreifen würde, stimmt das natürlich. Allerdings zwingt man dann gewissermaßen einen C++ Compiler C Code zu übersetzen. Wie unsinnig das ist, sollte offensichtlich sein.
leinad R. schrieb: > ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in > welcher Sprache ich meine µC programmieren sollte... Das klingt recht theoretisch. Welche uC hast du denn? Und welche Programmiersprachen stehen dafür dir überhaupt zur Verfügung? Mal abgesehen vom Tagesgeschäft, wo man sich nach einer ganzen Reihe von Randbedingungen richten muß (was es gibt, was man sich davon überhaupt leisten kann, was für's konkrete Problem überhaupt angemessen ist ... usw) meine ich, daß man eigentlich ein bissel auf den Erhalt wenigstens einer kleinen Vielfalt von Programmiersprachen achten sollte. Sonst läuft es auf Monokultur hinaus und die ist nach allen Erfahrungen der Menschheit immer schlecht. Derzeit reden die meisten von C und C++, ein bissel BASIC gibt es auch noch, aber das ist eigentlich schon etwas zu monokulturartig. Schau einfach mal, was es sonst noch so gibt, Pascal oder Modula(-->Codesammlung) oder sonstwas noch bishin zu Java (jaja per "JamaicaVM" auch auf uC's) - wenn kein wirtschaftlicher Druck dahinter ist, kann und sollte man sich das alles mal ganz ruhig zu Gemüte ziehen. Ich will dich nicht zu irgendeiner speziellen Sprache animieren, sondern: Guck dir am besten alles an, was es so gibt. W.S.
André M. schrieb: > Wie unsinnig das ist, sollte offensichtlich sein. Die eigene Ansicht ist offensichtlich, die des Anderen absurd. ;-) Wie oben schon skizziert gibt es zwischen zig MB grossen C++ Windows-Anwendungen und reinem C ein weites Feld. Daher finde ich es keineswegs unsinnig, für µCs ein reduziertes C++ zu verwenden. Leider weigern sich reine C Compiler standhaft, ein solches reduziertes C++ zu übersetzen. Dass (nicht nur) ich C++ für µCs keineswegs für offensichtlichen Unsinn halte hatte wurde bereits dort aufgeführt: Beitrag "C++ für Embedded: ab welchen Prozessormerkmalen?" Aber das ist eine der gängigen und unlösbaren Streitfragen, die immer wieder mal aufkommen und immer wieder mit der These anfangen, dass C++ für µCs offensichtlicher Unsinn sei. Aus der Sicht eines professionellen Windows-Programmierers mag diese These angehen, weil er sich ein solches C++ mitunter überhaupt nicht vorstellen kann. Nur ist auch ein reduziertes C++ weit mehr als C, grad so wie C mehr ist als Assembler. Was die Jahrzehnte und alte Sprachen angeht: Die bei µCs verwendete C Sprache ist meistens noch C89/C90.
Der Rächer der Transistormorde schrieb: > Assembler ist wie eine Handkarre bei der du dich mühsam über den > Acker schiebst, Basic wie ne fette Familienkutsche die gemächlich vor > sich hinschaukelt (aber schon bei 5cm Schnee nicht den Berg hochkommt > und C wie n Formel 1 Renner. Eine falsche Drehung am Lenkrad und schon > fliegst du aus der Kurve. Aber wenn du dann fahren gelernt hast gehts ab > (in allen Belangen ;-). Dann hast du noch n Riesen Werkzeug- und > Ersatzteillager die du alle mit ein wenig zurechtfeilen einsetzen > kannst. Die Beschreibung ist gut, muss ich mir mal merken . :-) Bascom mag ja vielleicht Vorteile haben ( ich hab noch keine gefunden). Hat aber einen großen Nachteil. Es gibt es nur für eine µC Familie. Solange man nur dort unterwegs ist, mag BASCOM eine Alternative sein, sonst eher nicht. Assembler, ist auf jeder µC Familie anders. Also jedes mal zu einem relative hohen Prozentsatz neu lernen. C Compiler gibt es für nahezu jede µC Familie. Ich wüsste jetzt µC Familie keine für den ich noch keinen Compiler gefunden hätte. Solang man sich mit dem Programm an die Standards hält ist es nahezu egal für welchen µC man das Programm schreibt. Der Code lässt sich dann auf jedem Compiler übersetzen. Natürlich müssen die Hardwarezugriffe dem jeweiligen µC angepasst werden. C++ Nunja nicht alle Compiler für µC unterstützen den C++ Befelssatz. Ansonsten ist C++ nichts anderes als ein aufgebohrtes C. Wenn du also mit C anfängst ist der Aufstieg zu C++ nicht mehr die Welt. Oder anderes rum, wenn du C kannst , dann kannst du auch auf einem PC alles machen was C++ auch kann, nur musst du dann mehr Sachen "zu Fuß" machen die C++ als Funktion schon mitbringt. Von der Seite ist meine Empfehlung für µC eindeutig "C". Damit bist du am flexibelsten und außerdem ist es in der industriellen Entwickler weitgehend der Standard.
A. K. schrieb: > André M. schrieb: >> Wie unsinnig das ist, sollte offensichtlich sein. > > Die eigene Ansicht ist offensichtlich, die des Anderen absurd. ;-) > > Wie oben schon skizziert gibt es zwischen zig MB grossen C++ > Windows-Anwendungen und reinem C ein weites Feld. Daher finde ich es > keineswegs unsinnig, für µCs ein reduziertes C++ zu verwenden. Leider > weigern sich reine C Compiler standhaft, ein solches reduziertes C++ zu > übersetzen. Du weißt aber sicher worauf ich hinaus will ;-) C++ wie C zu programmieren und es dann trotzdem C++ zu nennen, nur des Namens wegen, führt doch irgendwie auch zu nichts. Sobald ich aber trotz reduziertem Umfang eindeutige Merkmale von C++ verwende, dann macht es Sinn.
Der Rächer der Transistormorde schrieb: > Assembler ist wie eine Handkarre bei der du dich mühsam über den > Acker schiebst, Basic wie ne fette Familienkutsche die gemächlich vor > sich hinschaukelt (aber schon bei 5cm Schnee nicht den Berg hochkommt > und C wie n Formel 1 Renner. Eine falsche Drehung am Lenkrad und schon > fliegst du aus der Kurve. Aber wenn du dann fahren gelernt hast gehts ab > (in allen Belangen ;-). Dann hast du noch n Riesen Werkzeug- und > Ersatzteillager die du alle mit ein wenig zurechtfeilen einsetzen > kannst. Wunderschön und treffend ;)
leinad R. schrieb: > ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in > welcher Sprache ich meine µC programmieren sollte... Die Frage ist zuerst, welche Leistungsklasse an MCs und Anwendungen schwebt Dir denn überhaupt vor? Heutzutage nennt sich ja alles MC, vom kleinen ATtiny13 mit 1kB Flash bis zu großen ARM-Boliden mit vielen MB Flash. C hat den Vorteil, daß man man sie alle damit programmieren kann. Wenn man aus der PC-Welt kommt, braucht es allerdings etwas Einarbeitung, um auf 1kB Flash programmieren zu können. Ich mache gerne kleine Steuerungen mit kleinen 8Bittern, wo man nicht monatelang an irgendwelchen GUIs rumbasteln muß, um dann den User mit langweiligen Animationen zu nerven, statt sofort auf einen Tastendruck zu reagieren. Ich weiß, der Trend geht leider in die andere Richtung. Heutige Fernseher haben ja schon wieder Einschaltzeiten, die man von früher nur von den alten Vollröhrenfernsehern gewohnt war. Peter
leinad R. schrieb: > Ich dachte auch immer C++ wäre der Nachfolger von C und damit "moderner" > also vielseitiger und einfach besser und beliebter. Nö, ist zwar geschichtlich so, aber es gibt genug Leute, die C trotz freier Wahl C++ vorziehen. Verstehe ich teilweise sogar, C++ ist ein ziemliches Monster. Ansonsten denke ich, dass man mit C immer gut beraten ist.
Ich möchte auf __flash und __uint24 nicht mehr verzichten. In C++ gibts das nicht.
Ich schon... ein nettes const anstatt __flash ist viel schöner
avr schrieb: > In C++ gibts das nicht. In C auch nicht. Es sei denn, du definierst es oder jemand anderes hat das für dich gemacht. mfg.
avr schrieb: > __uint24 Ich hab das noch nie gebraucht. Wenn uint16_t nicht reicht, nehme ich einfach uint32_t. Peter
leinad R. schrieb: > Ich dachte auch immer C++ wäre der Nachfolger von C und damit "moderner" > also vielseitiger und einfach besser und beliebter. Nur in dem Sinne, daß ein Fahrrad moderner ist als Laufschuhe, ein Auto moderner als ein Fahrrad und ein Flugzeug moderner als ein Auto. Und wie in diesem Vergleich sind es auch bei der Wahl der Programmiersprache die konkreten Umstände, die bestimmen was die jeweils beste Wahl ist. Wobei es durchaus auch eine Kombination sein kann. XL
Coder schrieb: > Ich schon... > ein nettes const anstatt __flash ist viel schöner ach echt und was bringt das in c++ auf dem avr? Peter Dannegger schrieb: > Ich hab das noch nie gebraucht. Wenn uint16_t nicht reicht, nehme ich > einfach uint32_t. Ich konnte dadurch in meinem letzten Projekt einen kleinen Avr nehmen. Mit uint32_t wäre mehr Ram nötig gewesen.
avr schrieb: > Coder schrieb: >> Ich schon... >> ein nettes const anstatt __flash ist viel schöner > > ach echt und was bringt das in c++ auf dem avr? > Mag an deiner Controller-Familie liegen, dass Dir das nichts bringt. Du solltest dir in Erinnerung rufen, dass __flash ebensowenig Bestandteil von C oder C++. Stattdessen ist es Toolchain-Spezifisch, kenne ich z.B. vomIAR?
Coder schrieb: > dass __flash ebensowenig Bestandteil > von C oder C++. richtig, es ist ja nur ein Argument für avrgcc auf dem Avr.
Hallo, im Rahmen der freien Meinungsäußerung möchte ich auch was zu meinen persönlichen Erfahrungen sagen. Vor vielen Jahren habe ich aus der Hobbyecke mit der C-Control und Basic in die MC Ecke hineingerochen. Aufgrund der Kosten der Controller war ich dann in die Open C-Control gerutscht. Basic war damals für mich eine les- und beherschbare Sprache und den Anforderungen angemessen. Als es dann nötig wurde auch kleine Zeiten zumessen reichte ein Timer Interupt von 20ms (Standard bei C-Control) bei weitem nicht aus und so bin ich zu den AVR 8 Bittern und Bascom gekommen. Vieles konnte ich mit Bascom erledigen und ansteuern allerdings oftmals nicht ohne spez. Dateien die durch die Hardwareanbieter oder andere User zur Verfügung gestellt wurden. So gingen wieder 3 Jahre ins Land. Der Bruch mit Bascom kam erst mit einer Hard- und Software Entwicklung für den CAN BUS. Bascom ist bei meiner Routeranwendung echt zulangasm gewesen. So habe ich dann vor 2 Jahren mit C begonnen und mich dank der wegweisenden Hilfe echter Profis hier im Forum Schritt für Schritt vor getastet. Heute bin ich froh den Schritt gemacht zuhaben. C ist "die" für mich passende Plattform. Ich habe das nicht studiert oder beruflich damit zutun, hänge auch noch bei den für mich ausreichenden 8 Bit AVRs fest. Programmprobleme löse ich gerne aus eigener Kraft, bleibt dann auch besser im Kopf, aber manchmal...auch öfter.... gehts halt nicht und da sind die Denkanstösse oder Hilfen hier im Forum einfach klasse. Danke !!!!! Peter C. PS: Dem Vergleich mit der Handkarre, Kutsche und der Formel1 würde ich zustimmen.
egal schrieb: > Für kleine µC ist C noch immer das Mittel der Wahl. Manchmal ist auch > Assembler sinnvoll. C++ eher weniger. Wieso nicht C++ lernen? Da lernt man den Funktionsumfang von C doch gleich mit.
Nicht wirklich. Klar kann C++ das meiste von dem, was C kann auch, aber der Stil, in dem man die beiden Sprachen programmiert, ist schon ziemlich unterschiedlich.
Im Moment mache ich zwar wenig bis gar nichts in Sachen Programmierung, da ich nun etwas beim Fertigen von Leiterplatten fest hänge, aber ich habe mit C++ angefangen (oder will das), weil gerade der gesteigerte Funktionsumfang dann einen nicht so schnell an Grenzen stoßen lässt. Korrigiert mich, wenn ich völlig falsch liege. Außerdem ist die Portierbarkeit von allem aus der C Ecke leichter. Angefangen hatte ich mit Arduino (die Boards finde ich immer noch gut, gerade das Nano) und ganz schnell gesehen, dass ich doch irgendwie auf C angewiesen bin, weil ich für jeden Sensor und viele andere Bauteile libs brauche, die alle in C geschrieben sind. Wenn ich also irgendwas ändern will oder nicht genau weiß wie ich da was ansprechen muss, dann muss ich entweder dauernd fragen oder mich selbst einlesen. Ich begann zu lesen was ich für eine Sprache nehmen soll. Assembler fiel weg, da ich damit (wenn ich später vielleicht mal vom Computer aus steuern will, das Interface dann wohl kaum mit Assembler für µC machen kann) nicht viel auf dem PC anfangen kann. Ihr wisst alle selbst, fragst du drei Leute, bekommst du fünf Meinungen. Mein Sohn lernt gerade C#. Nicht schlecht, aber für µC noch nicht so verbreitet. Er zeigte mir gerade erst ein Programm das, wie er sagt, in C++ doppelt so lang ist. Andere schreiben C braucht man doppelt so viel Code wie für C++. Wie auch immer. Ich hab hier an die 1000 Seiten C++ und die werden gelesen werden. Ich hab mir die nächsten fünf Jahre vorgenommen vom ahnungslosen Anfänger zum Anfänger auf zu steigen.
Peter C. schrieb: > PS: Dem Vergleich mit der Handkarre, Kutsche und der Formel1 würde ich > zustimmen. Jetzt pack mal noch Java, PHP und so ein Zeugs dazu ;)
Frank O. schrieb: > ... ich > habe mit C++ angefangen (oder will das), weil gerade der gesteigerte > Funktionsumfang dann einen nicht so schnell an Grenzen stoßen lässt. > Korrigiert mich, wenn ich völlig falsch liege. Das ist zumindest ein Verständnisproblem. C++ hat keinen "gesteigerten Funktionsumfang". Der Funktionsumfang einer Programmiersprache kommt im wesentlichen aus den vorhandenen Bibliotheken/Modulen. Und die sind weder bei C noch bei C++ Bestandteil der Programmiersprache. Was C++ dir im Vergleich zu C bringt, sind neue, tendenziell stärkere Ausdrucksmittel. Z.B. für Objektorientierung, Operatorüberladung, Polymorphie, Templates, Exceptions. Und du bekommst auch eine Basis-Klassenbibliothek mit richtigen Strings (die char[] in C sind ein schlechter Witz), Containern, Such- und Sortieralgorithmen, etc. Die meisten dieser neuen Möglichkeiten entfalten ihre volle Wirkung erst bei größeren Programmen (z.B. OO, Exceptions), andere tendieren dazu den Code aufzublähen (z.B. Templates). Und wieder andere bekommt man praktisch umsonst (z.B. Polymorphie für Funktionen). Deswegen wird man gerade auf µC kaum den ganzen Umfang von C++ ausschöpfen. Andererseits ist C++ so kompatibel zu C wie nur irgend möglich (das war ein Designziel, um die vorhandenen C-Bibliotheken weiter nutzen zu können; siehe "Funktionsumfang" oben). Man kann also ganz problemlos seinen "C-Stil" beibehalten, wenn man zu C++ umsteigt. In der Gegenrichtung ist das deutlich schwerer. Deswegen würde ich immer empfehlen, erstmal C zu lernen und dann erst C++. Und dann auf µC die Mittel von C++ sparsam einzusetzen. Oder zumindest mit einem geschulten Blick für den Overhead, den man sich damit einfängt. > Assembler fiel weg, da ich damit (wenn ich später vielleicht mal vom > Computer aus steuern will, das Interface dann wohl kaum mit Assembler > für µC machen kann) nicht viel auf dem PC anfangen kann. Ich verstehe nicht woher diese Geringschätzung für Assembler kommt. Je näher man an der Hardware programmiert, desto nützlicher finde es. Natürlich macht man damit keine GUI. Aber die macht man auch nicht unbedingt mit C++. Und wenn doch, dann sind die verwendeten Sprachmittel und Bibliotheken so grundverschieden, daß es sich wie eine andere Sprache anfühlt (z.B. kann man nette GUI in C++ mit Qt machen. Das ist dann 100% OO mit so ziemlich allen Features die C++ bietet) > Mein Sohn lernt gerade C#. Nicht schlecht, aber für µC noch nicht so > verbreitet. C# ist vom Sprachdesign her das, was Java sein sollte. Leider ist es eine Sackgasse (nur ein "Betriebssystem", nur eine(?) Architektur, nur ein Vendor). > Er zeigte mir gerade erst ein Programm das, wie er sagt, in > C++ doppelt so lang ist. Andere schreiben C braucht man doppelt so viel > Code wie für C++. Diese Metrik ist trügerisch. Wenn du die gesuchte Funktionalität in einer Bibliothek hast, ist das "Programm" ein Einzeiler. Egal ob nun PHP, Perl, Java, C#, C++ oder C. Was die ersten 4 aus dieser Liste so mächtig macht, sind ihre riesigen Standard-Bibliotheken. Wenn man vergleichen will, dann lieber die Gesamtmenge an benötigtem Code (ausführbar und Bytecode/Skripte) oder die Anzahl CPU-Zyklen bis zum Ergebnis. Dann stehen die "low level" Kandidaten C und C++ plötzlich viel besser da. XL
Frank O. schrieb: > Im Moment mache ich zwar wenig bis gar nichts in Sachen Programmierung, > da ich nun etwas beim Fertigen von Leiterplatten fest hänge, aber ich > habe mit C++ angefangen (oder will das), weil gerade der gesteigerte > Funktionsumfang dann einen nicht so schnell an Grenzen stoßen lässt. Das halte ich auch für ein Missverständnis. Mit C wirst Du auf einem Mikrocontroller garantiert an keine Grenzen stoßen, die C++ lösen würde. Meiner Meinung nach ist C++ als Anfänger zur Programmierung von Mikrocontrollern ungeeignet. Man kann damit zwar prinzipiell genau wie in C programmieren bzw. nur die Sprachmittel nutzen, die nichts kosten, allerdings wird das in den typischen Büchern/Tutorials zu C++ nicht vermittelt. Da wird von Beginn an objektorientierte Programmierung, gerne gleich mit dynamischem Speicher und virtuellen Methoden gelehrt, so dass einem als Anfänger gar nicht so bewusst wird, dass es auch anders geht. Es ist einfach das Standardvorgehen, ein Objekt mit new zu erzeugen wenn man es braucht, ohne dass man sich groß Gedanken macht, was dabei passiert. Und gerne macht man auch gleich mal alle Methoden virtuell, denn vielleicht will man ja später mal eine überschreiben. Zumindest ging es mir so. Ich habe an der Uni zuerst Java gelernt und sollte darauf in einem Praktikum etwas in C++ programmieren. Es schon fast peinlich, aber für mich war es ein riesiges Aha-Erlebnis, als ich dann gegen Ende des Praktikums irgendwo in bestehendem Code gesehen habe, dass man ein Objekt auch ohne new erzeugen kann ... Erst als ich dann später auf niedrigerer Ebene in C programmiert habe, ist mir der Unterschied zwischen Stack-, Heap- und globalen Variablen richtig bewusst geworden. Außerdem habe ich gesehen, wie man "Objekte" in C nachbauen kann, indem man jeder "Memberfunktion" einen Zeiger auf ein Struct mitgibt. Letztlich macht C++ das ja auch nicht anders, aber es bliebt hinter der class-Syntax verborgen und war für mich viel undurchsichtiger. Ich würde daher empfehlen, lieber erstmal ordentlich C zu lernen. Man entwickelt dabei aus meiner Sicht ein viel besseres Verständnis für das Programm, also wenn man direkt mit den objektorientieren Paradigmen loslegt. Wenn man C beherrscht kann man dann ja mal einen Blick auf C++ werfen. Dann ist man auch in der Lage zu beurteilen, welche der neuen Features in welchen Programmen nützlich sind und welche nicht. Das Wissen aus C ist dabei ja nicht verloren, denn C++ ist ja im wesentlichen eine Erweiterung von C, der Kern ist der gleiche.
Eigentlich ist hier alles gesagt. Ich persönlich mache es so: alles was schnell gehen soll programmiere ich in Bascom. Nur wenn der Kunde es unbedingt wünscht auch in C. Das dauert aber immer viel länger .... und die Fehlersuche kann ein Krampf sein. In Bascom finde ich jeden Fehler innerhalb kurzer Zeit, in C kann man manchmal Stunden damit verbringen. Ein Projekt, was ich ich in Bascom in 16 Stunden inkl. Testen fertigentwickelt habe und abliefern kann, dauert in C sicherlich einen ganzen Tag länger, wenn nicht mehr. Der Geschwindigkeitsunterschied Bascom / C liegt bei Bascom bei rund 80% der Geschwindigkeit, die ein C Programm hätte. In der Regel sind die 80% völlig ausreichend; notfalls kann man bei zeitkritischen Routinen ein paar Assembler-Routinen mit einbauen. Aber C hat natürlich auch einen großen Vorteil: Ich kann es jederzeit auf ein anderes System portieren, da es C Compiler überall gibt. Andere Controller bedingen bei einer Portierung aber oft größere Eingriffe in das Programm, so dass durchaus nochmal 50% der Originalprogrammierzeit notwendig sein können. Wenn Du das beruflich machen willst, würde ich Dir raten C zu lernen. Wenn es eher privat ist, bist Du mit Bascom auch gut bedient, denn Du hast schneller Erfolgserlebnisse und du kannst dann später immer noch C hinzulernen. Andy
JAL ist am besten für anfänger weil kostenlos und einfach zu erlernen und zu verstehen. http://www.casadeyork.com/jalv2/
Andy schrieb: > Eigentlich ist hier alles gesagt. Eigentlich war im letzten Thread schon Alles gesagt. Und der wurde hier auch verlinkt.
Sunny schrieb: > JAL ist am besten Genau. Das hat sich voll durchgesetzt und wird mittlerweile von 99% aller Programmierer verwendet. Bis die nächste supereinfache, selbstverständliche und sich dem Prgrammierer selbst beibringende Sprache kommt. mfg.
Thomas Eckmann schrieb: > Sunny schrieb: >> JAL ist am besten Na, also das ist doch nun offensichtlich ein Troll gewesen *g
Axel und Fabian, vielen Dank für eure deutlichen Worte und sachlichen (und fundierten dazu)Argumente. Wenn ich nun den C++ Wälzer (mit seinen 1000 Seiten) zur Seite lege und nun mit C anfangen möchte. Und ich rede hier ausschließlich von C für AVR Mikrocontroller, welches Buch, welche Bücher würdet ihr mir empfehlen? Lieber Andy, sehr nett mir den Verweis auf Bascom zu geben, aber dann würde ich Arduino weiter machen. Mir geht es ja auch gerade darum, die Bibliotheken lesen und verstehen zu können. Ein Beispiel: Ich wollte den DS18B20 mit Arduino testen (gelang mir auch), aber schon das ändern der vorgegebenen Namen war ein Problem. Zum einen, weil das nicht so klappte wie ich das dachte und zum verstand ich nichts aus der Bibliothek. Genau deshalb sollte es C sein. Und ich dachte (vielleicht naiv), wenn da doch schon C mit eingebaut ist, dann lern ich doch zwei auf einmal. Es gibt auch keine Geringschätzigkeit Assembler gegenüber. Ganz im Gegenteil, finde ich sogar richtig gut (liegt mir wahrscheinlich sogar mehr als alles andere).
Hallo Reinald. > Hallo, > ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in > welcher Sprache ich meine µC programmieren sollte... Ich werfe mal als Alternative zu beiden freeRTOS und PEARL in die Diskussion, und bin gespannt, was passiert. ;O) > und frage mich nun welche Sprache wohl "leichter", übersichtlicher und > zukunftsorientierter wäre. "Leicht" und "Übersichtlich" ist auch eine Geschmacksfrage. Nicht umsonst gibt es Leute, die Windows, und andere, die Linux bevorzugen. > Natürlich wäre es auch wichtig, dass man geeigneten Support im Inet dazu > findet. :-/ Die beste Doku findet man meist über offene Systeme, ist aber manchmal auch etwas sperrig. Für den "Einstig" sind kommerzielle Systeme darum manchmal leichter, weil die Firmen viel tun, bis die Leute einmal angefixt sind..... > Auf eure Meinungen freu ich mich schon sehr. Auf meine Meinung solltest Du nicht wirklich was geben, weil ich ein Spinner bin. Denk aber trozdem drüber nach, vieleicht ist Deine wahre Bestimmung auch, ein Spinner zu sein. ;O)
Wenn du Bascom nicht verstehst, dann wirst du C auch nicht verstehen.C ist noch viel schwieriger und unübersichtlicher als Bascom.In C programieren nur Freaks die alles auf dem schwieriegsten weg machen wollen oder die jenigen die glauben dass C irgendwie besonders ist, aber es ist genauso eine Sprache wie jede andere.In einigen Fällen ist sie besser und in anderen schlechter.
Sunny schrieb: > Wenn du Bascom nicht verstehst, dann wirst du C auch nicht verstehen.C > ist noch viel schwieriger und unübersichtlicher als Bascom. So ein Quatsch! Umgekeht wird ein Schuh draus.
Sunny schrieb: > Wenn du Bascom nicht verstehst, dann wirst du C auch nicht verstehen.C > ist noch viel schwieriger und unübersichtlicher als Bascom.In C > programieren nur Freaks die alles auf dem schwieriegsten weg machen > wollen oder die jenigen die glauben dass C irgendwie besonders ist, aber > es ist genauso eine Sprache wie jede andere.In einigen Fällen ist sie > besser und in anderen schlechter. C ist erheblich einfacher wie Basic - klarer und nicht Wischiwaschi.
leinad R. schrieb: > ich habe mir in letzter Zeit immer häufiger die Frage gestellt, in > welcher Sprache ich meine µC programmieren sollte... Wenn du dich immer häufiger fragst, dann frage ich mich, wie lange das Teil nun schon rumliegt. Fang halt endlich mal an. Tritt in den Hintern!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.