Hallo! Ich programmiere den 80c535 seit längerem in Assembler! Ist der Umstieg auf C vorteilhaft, oder ist Assembler vorzuziehen? (PS: Mit C kenn ich mich auch recht gut aus) Gruß der Jense
Hallo Jense ist ein bisschen Ansichtssache. ich meine, solange du nur ein paar Bits manipulierst, ist Assembler gut. Anspruchsvoll wirds, wenn Du anfängst jenseits von Integer zu rechnen. Oder wenn Du IF-Then Else-Strukturen brauhst, oder wenn allgemein dein Programm komplex wird, dann st C einfacher und übersichtlicher - und das ohne daß man sich anstrengen muß. Mit Assembler geht das natürlcih auch, aber float in Assembler, oder bloß Teilen - das nervt unter Assembler - mich zumindest. Gerhard
Ich bin wirklich bei jeder Aufgabe mit dem 8051 bisher um C herumgekommen (beim M16C ist das was anderes). Anstelle irgeneine Zahl durch 0,0732421875 zu teilen, fügt man eben 2 Low Bytes an und teilt das ganze durch 4800. Ist nichtnur schneller, sondern das ganze Programm ist auch kleiner als nur die Float Routinen für C... Für 8051 sollte man Assembler verwenden, bei AVR muss man schon besser überlegen was man verwendet, denn der ist für C optimiert.
Ich verstehe nicht, warum sich manche Leute immer um C herumdrücken. Keine professionelle Softwareentwicklung findet in Assembler statt, höchstens noch ein paar zeitkritische Optimierungen. C ist nicht schwer zu erlernen und man spart sich solche unnötigen Verrenkungen wie "low bytes anfügen und dann durch 4800 teilen". Was soll das? Warum sollte man sich das Leben unnötig kompliziert machen, wenn man von einem C-Compiler solche stumpfsinnigen Aufgaben abnimmt? "AVR ist für C optimiert, der 8051 nicht". Sowas ist imho absoluter Schwachsinn und höchstens ein Marketingslogan von Atmel. Die Codequalität und damit die Ausführungsgeschwindigkeit oder Codegröße hängt vom Compiler ab - man vergleiche dazu beispielsweise C-Compiler für 8051 von Keil mit dem freien. Ich lasse mich in diesem Punkt aber gerne eines besseren belehren, aber bitte mit Fakten. Fazit: C lernen lohnt sich auf jeden Fall denn es vereinfacht vieles und ermöglicht strukturierte und professionelle Softwareentwicklung. In Assembler programmieren zu können ist aber deswegen keinesfalls unnötig, denn die Kenntnis trägt maßgeblich zum Verständnis bei. Wer aus Prinzip dennoch nicht C lernen will ist entweder zu dumm oder ein Ignorant.
>"AVR ist für C optimiert, der 8051 nicht". Sowas ist imho absoluter >Schwachsinn und höchstens ein Marketingslogan von Atmel. Die >Codequalität und damit die Ausführungsgeschwindigkeit oder Codegröße >hängt vom Compiler ab - man vergleiche dazu beispielsweise C-Compiler >für 8051 von Keil mit dem freien. >Ich lasse mich in diesem Punkt aber gerne eines besseren belehren, aber >bitte mit Fakten. Schau Dir die Adressierungsarten des AVR an, z.B.: "Data indirect with displacement" In Hochsprachen ist es üblich, lokale Variablen zu benutzen. Mit dieser Adressierungsart kannst Du bequem bis zu 64 Byte an lokalen Variablen adressieren - ohne irgendwelche Pointer-Berechnungen. Data indirect with pre-decrement und data indirect with post-increment sind weitere Befehle, die Hochsprachencode einfacher machen. Das trifft natürlich nicht nur auf den AVR zu, der 68000 hat da noch wesentlich mehr geboten. Und auch nicht nur auf C, sondern auf Hochsprachen allgemein. Stefan
@Stefan Kleinwort: Mensch, Du erwähnst tatsächlich den 68000 und machst mich richtig Wehmütig! Hatte früher, bevor die PC´s langsam zu reifen begannen, einen Atari ST mit nen MC 68000. Für Assembler wirklich ein geiler Prozessor. Da braucht man wirklich keine Hochsprache wie C wenn man einigermassen perfekt Assemembler beherscht. Kartenspiele, Zeichenprogramme und Soundediting in Assembler ohne Probleme. Muß natürlich zugeben, das vom TOS schon ein paar Subs verwendet wurden. C ist für mich wie Hibräisch. Gruß Andi
"C ist nicht schwer zu erlernen und man spart sich solche unnötigen Verrenkungen wie "low bytes anfügen und dann durch 4800 teilen". Was soll das?" rechenzeit sparen, speicherplatz sparen. floats sind für die meisten kleinen uC recht unhandlich
@Andi: naja, den "echten" 68000 hatte ich nie programmiert, sondern den 68332 (embedded-Version). Natürlich lies der sich auch sehr hübsch in Assembler programmieren. Aber der Befehlssatz war auch genial für den C-Compiler, Du konntest in den Assembler-Befehlen richtig einzelne C-Zeilen erkennen. @Tobi: Solche "Verrenkungen" liebe ich auch. Float benutze ich praktisch nie. Ein kleines bischen abstrahieren, und schon hat man das Problem mit int gelöst. Das Beispiel von Benedikt fand ich klasse! Stefan
"Schau Dir die Adressierungsarten des AVR an, z.B.: "Data indirect with displacement" In Hochsprachen ist es üblich, lokale Variablen zu benutzen. Mit dieser Adressierungsart kannst Du bequem bis zu 64 Byte an lokalen Variablen adressieren - ohne irgendwelche Pointer-Berechnungen." Vielleicht existieren beim AVR Adressierungsarten, die den Einsatz von C favorisieren. Jedoch lasse ich dieses Argument nicht gelten, denn entscheident ist, was am Ende rauskommt. Wir haben bei uns in der Firma ein großes Projekt aus professionellem Umfeld (ca. 32KByte Code) sowohl auf AVR als auch 8051 compiliert. Der Code war jeweils auf den entsprechenden Controller optimiert (keine ASM-Optimierungen). Der Unterschied in der Codegröße war minimal und vernachlässigbar. "rechenzeit sparen, speicherplatz sparen. floats sind für die meisten kleinen uC recht unhandlich" Rechenzeit und Speicherplatz sparen ist sicherlich wichtig, jedoch haben Prinzipien des Softwareengineering Vorrang, z.B: -Reuse -Abstraktion -Modularität -Information Hiding, um nur einige zu nennen. Diese Prinzipien sollte jeder gute Programmierer anstreben, und Assembler macht das ungemein schwerer. Mit den floats gebe ich Dir recht, die blähen den Code schon ziemlich auf. Ich habe sie bis jetzt auch immer vermieden, aber nur, wenn es nicht auf Kosten der Lesbarkeit geht. Rechenzeit und Speicherplatz wird heutzutage stetig güstiger, die Entwicklungszeit eines Programmierers zum Glück nicht. Und um noch ein Argument in den Raum zu werfen: Die Benutzung von C ermöglicht die Portierung von Code auf fast jedes beliebige Target mit minimalem Aufwand, bei ASM ist das unmöglich.
>Vielleicht existieren beim AVR Adressierungsarten, die den Einsatz von >C favorisieren. Jedoch lasse ich dieses Argument nicht gelten, denn >entscheident ist, was am Ende rauskommt. Wir haben bei uns in der Firma >ein großes Projekt aus professionellem Umfeld (ca. 32KByte Code) sowohl >auf AVR als auch 8051 compiliert. Der Code war jeweils auf den >entsprechenden Controller optimiert (keine ASM-Optimierungen). Der >Unterschied in der Codegröße war minimal und vernachlässigbar. Es wird immer Projekte geben, die die Vorteile der einen (oder anderen) Architektur besser nutzen. Wobei die Codegrösse für mich den kleinsten Faktor darstellt. Allerdings finde ich es bei der AVR-Architektur klar erkennbar, dass die Entwickler die Codeerzeugung durch Compiler im Blick hatten. Manche Befehls- oder Adressierungsarten findet man eben kaum in Assemblerprogrammen, dafür umso mehr im Output des Compilers. Insofern finde ich es kein reines Marketing-Argument von Atmel. Bei float fallen mir immer die Leute ein, die AD-Ergebnisse in float umwandeln, weil sie natürlich auch die mV ausgeben wollen. Im Übrigen sind wir uns (denke ich) so ziemlich einer Meinung. Am liebsten programmiere ich in C und schaue ab und zu im Assembler-Output, was der Compiler da gebastelt hat. Was noch hinzu kommt bei den Vorteilen in Hochsprache: bei sinnvoller Wahl der Variablennamen ist C-Code geradezu selbsterklärend - jedenfalls im Vergleich zu Assembler. Stefan
bin ganz deiner Meinung. Ich kann keinen verstehen, der auf reiner Assemblerprogrammierung besteht, es sei denn, er ist reiner Hobbyist mit unbegrenzt vorhandendener Zeit und einem gewissen Zwang zur Selbstkasteiung. Bei etwas komplizierteren Programmen schätze ich das Entwicklungszeitverhältnis Assembler/Hochsprache auf min. 10:1 (bei PICs eher 20:1 :-). Weitere Riesenpluspunkte für C und Konsorten: die Lesbarkeit/Wartbarkeit und Fehlersuche. Ich konzentriere mich lieber auf das eigentliche Programmierproblem, als mir ständig über Adressierung, Stack und Bibliotheken zusätzlich den Kopf zu zerbrechen. Argument Speicherplatz: ab einer bestimmten Grösse des Programms hat auch da Assembler keinen Vorteil mehr, durch Optimierungen des Compilers können Bytes freigeschaufelt werden, die man in Assembler entweder gar nicht sieht oder das Programm zu einem totalen Chaos werden lassen, an das man, wenn es denn einmal laufen sollte, am besten nie wieder rangeht. Ebenso ist die RAM-Nutzung meist besser (lokale Variablen). Argument Laufzeit: mit einem gewaltigen Einsatz an Denk- und Fleissarbeit ist manchmal was möglich in Assembler, meist aber auf Kosten einer ordentlichen Programmstruktur. Ausserdem sind nie alle Programmteile so zeitkritisch, dass es sich nur mit allen möglichen Programmiertricks lösen lässt (wenn doch: falschen Prozessor gewählt)
Irgendwie erlebe ich ein Deja-vu (schreibt man das so? Nie franz. gelernt...). Die Frage wurde doch schon öfters behandelt. Ich würde es auch so sehen: Assembler als Hobby, C für den Profi. Allerdings gibt es böse Zungen, die behaupten, C sei nur ein Makroassembler ;) Es geht im Profibereich vor allem darum, daß ein Programm auch nach Jahren noch für einen neuen Mitarbeiter lesbar ist. Aber das ist keine Frage der Programmiersprache, sondern des Programmierstils und der Dokumentation. Mal eine Frage an die Profis: Wenn ihr euch ein ca. 5 Jahre altes Programm anschaut, steigt ihr da sofort durch? Bezweifle ich. Man kann sowohl in C als auch in Assembler gut strukturierte oder aber auch unübersichtliche Programme schreiben. Ich persönlich sehe es als Hobby, brauche keine Floats, meine Programme sind sehr klein, ergo: Assembler. Bei größeren Projekten würde ich wahrscheinlich auch irgendwann den Einsatz einer Hochsprache einsehen, dann aber eher Basic, als C. Warum? Die vielfach hochgelobte Portierbarkeit kann man bei µC doch vergessen. Wenn man ein Programm, das PWM, UART und (Hardware-)TWI benutzt, vom Atmel auf z.B. einen MCS-51 oder einen M16C portieren will, muß man alles, was mit Hardwareansteuerung zu tun hat, umschreiben. Da kann mans auch gleich mit einem anderen Basic-Dialekt versuchen. Schaut mal rein, sehr aufschlußreich: http://www.kuro5hin.org/story/2004/2/7/144019/8872
Ich habe schon mehrmals ein Programm in C und in Assembler für den 8051 geschrieben. In C war das Programm fast immer zu groß für den Speicher (vor allem wenn man den AT89C2051 mit 2k Flash verwendet.) Der 8051 ist so leicht in Assembler zu programmieren, da macht es wenig Sinn C zu verwenden, vor allem da der Controller nicht gerade der schnellste ist. Rechnet man da mit float, dann kann man sich über 100 Rechenoperationen pro Sekunde freuen und sich über die 1,5k float Routinen ärgern, während die Integer Berechnung gerade mal etwa 100Bytes braucht und in etwa 1ms gelöst ist (für eine 64bit/64bit Division) Bei Controllern macht Assembler dagegen wenig Sinn, wenn man auch nicht ganz drum rum kommt. So muss die StartUp Datei in Assembler geschrieben werden. Außerdem ist es sinnvoll einige Routinen in Assembler zu schreiben (z.B. um den Flash zu programmieren.)
Klar, um 2k Code vollzukriegen, in dem wohl jeder 2.Befehl die Hardware anspricht, macht es wenig Sinn, einen Compiler anzuwerfen. Für (fast) jedes Problem gibt es eben eine oder mehrere gute Lösungen - aber eben nicht eine gute Lösung für alle Probleme. Wäre ja auch schrecklich, genauso, wie wenn das ganze Jahr über die Sonne scheinen würde, oder alternativ das ganze Jahr über regnen würde. Oder wenn es nur Meschen mit blauer Hautfarbe gäbe ... Stefan
@Stefan, >>Ich lasse mich in diesem Punkt aber gerne eines besseren belehren, aber >>bitte mit Fakten. >Schau Dir die Adressierungsarten des AVR an, z.B.: >"Data indirect with displacement" Du hast die Frage nicht verstanden. Matthias meinte praktische Beispiele und keine Theorien über Adressierungsarten. Und da kann ich ihm nur zustimmen, Meine C Programme auf dem 8051 sind auch generell kleiner als auf dem AVR und manchmal sogar kleiner als Assembler auf dem AVR. In Steuerungsaufgaben geht es nunmal vorrangig um Statemaschinen und Bitmanipulationen (z.B. Portpins togglen) und nicht möglichst große Mengen an SRAM zu ver(sch)wenden. Zum Thema: Ich würde es an der Programmgröße festmachen: Bis 2kB (8051) bzw. 4kB (AVR) ist Assembler noch gut beherrschbar. Darüber hinaus verliert man leicht den Überblick und kann Fehler machen. Da bedeutet die automatische Variablenverwaltung von C eine sehr mächtige Erleichterung und deshalb sind C Programmer schneller geschrieben und fehlersicherer. Und das C Programme portabel sind, ist auch eine große Zeitersparnis. Ich teste z.B. viele Routinen im guten alten Borland-C auf ihre funktionale Richtigkeit. Und erst recht, wenn man C kann, spricht überhaupt nichts dagegen, seinen 8051 in C zu programmieren. Ich benutze zwar nur den Keil, aber inzwischen gibt es ja auch viele billigere Alternativen, die auch nicht wesentlich schlechter sein sollen. Und float ist auch kein Thema, wenn man nicht platz- oder zeitkritische Anwendungen hat. Ich habe z.B. einige Male floats auf dem AT89C2051 verwendet, daß belegt einmalig etwa 700 Byte, also sind noch 1,3kB für die Anwendung übrig. Peter
Gähn ...
>Du hast die Frage nicht verstanden.
Die Frage habe ich sehr wohl verstanden, und wie ich Dich kenne, hast
Du auch meine Antwort verstanden.
Was ich nicht verstehe, ist Dein Posting ... ist da irgendwas, was noch
nicht gesagt, wäre, oder über das wir bedeutend anderer Meinung wären?
Grübel ... Stefan
P.S.:
Noch ein dummes Beispiel für die besagte Adressierungsart, einfach mal
durch gcc schicken und sehen, was rauskommt. Bitte keine Kommentare,
wie sinnvoll dieser Code tatsächlich ist ... er ist rein zum
Compilertesten.
uint32_t test(uint32_t x, uint32_t y, uint32_t z, uint32_t p){
volatile uint32_t a,b,c,d,e,f,g,h,i,j,k;
a = x * 2;
b = y * 3;
c = p * 5;
d = x * 6;
e = y * 7;
f = z * 8;
g = x * 9;
h = y * 10;
i = z * 11;
j = x * 12;
k = y * 13;
if (p == 1){
return(a+b+c+e+f+g+h+i+j+k);
}
else{
return(a*b*c);
}
}
Das wäre doch mal eine interessante Sache: Der Compiler/Assembler-Clash Jeder versucht, mit seinem Compiler/Assembler den "besten" Code zu erzeugen. Der Sinn sei jetzt mal dahingestellt... Dann müssten wir aber noch die Rahmenbedingungen festlegen.
Hm, was sollte es nützen? Man kann keine objektive Bewertung des Ergebnisses vornehmen. Manchmal zählt einfach nur Zeitersparnis beim Entwickeln, ein anderes Mal nur die pure Laufzeit, dann wieder Codegrösse oder RAM-Bedarf. Das wird dann sowas wie ein CPU-Benchmark...
"Bitte keine Kommentare, wie sinnvoll dieser Code tatsächlich ist ... er ist rein zum Compilertesten." "Hm, was sollte es nützen? Man kann keine objektive Bewertung des Ergebnisses vornehmen." Ganz genau. Ich will doch meine Anwendungen realisieren. Und dabei nützen mir irgendwelche praxisfernen Compilertests nicht die Bohne. Einfach mal einige reale Anwendungen in C und Assembler auf verschiedenen µC voll funktionsfähig zu programmieren hat wesentlich mehr Aussagekraft. Peter
Weil wir gerade dabei sind, wie sieht das eigentlich mit Pascal aus. Scheint ja eher für AVRs nich so verbreitet zu sein. Aber hat da eventuell doch schon jemand Erfahrungen, was so die Codeeffizienz anbelangt? Gruß Ingo
Pascal war meine erste Sprache, und manchmal mache ich immer noch etwas damit. Ist mir eigendlich sehr sympathisch. Im mc-Bereich sieht es mit Pascal aber meistens schlecht aus. Es gibt zwar diverse Pascal-Compiler für verschiedene mc. Aber nur bei C kann man sich wirklich sicher sein, bei einem Plattformwechsel wieder in C programmieren zu können. Bei der Code-Effizienz kommt es meiner Meinung nach weniger auf die Sprache und vielmehr auf die Qualität des Compilers drauf an. Und natürlich, wie effizient das Programm geschrieben ist. Stefan
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.