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
c genauer benutz ich den gcc compiler (winavr) zusammen mit dem avr studio.
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.
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.
Danke für die wirklich ausführliche Antwort "jmoney". Vieleich mögen sich noch weitere zu dem Thema äußern. grüße Torsten
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.
C und wenn nötig assembler implementieren. grade bei zeitkritischen funktionen.
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
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.
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
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
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.
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.
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.
>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.
>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.
> 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 :-)
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.
C ist eine echt miese Programmiersprache, aber es ist nun mal die beste die es für Controller gibt.
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.
Die Güte einer Programmiersprache kann man übrigens auch daran messen, wielange es in 2,4,6 Jahren dauert eine Aenderung zu machen. P.
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
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
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
> 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.
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.
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
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
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 ;)
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 ?
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.
> 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.
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 ;-))
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.
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.
> 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...
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
> 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...
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.
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.
> 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.
>> 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 ?
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
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.
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.