hi. In was sollte man kleinere, einfachere Sachen besser programmieren? Also einfache Sachen die man problemlos auch mit nem TTL Grab und OP's machen könnte und die nur aus Bequemlichkeit und wegen geringerem Bauteileaufwand mit einem uC gemacht werden. C oder ASM? Oder beides, also C mit viel Inline-Assembler? Mit was progrmmiert ihr sowas?
ich denke asm wird nur noch eingesetzt wenn es wirklich benötigt wird, wegen geschwindigkeit ansonsten würde ich eigentlich sagen immer C egal für was bessere Wartbarkeit etc.
C oder gleich C++ damits in der entwicklung schneller geht. asm nimmt man im äußersten notfall noch, wenn es wirklich auf die letzte µs ankommt (wobei man da dann einfach ne andere hardware nimmt )
Unkown User schrieb: > C oder ASM? Oder beides, also C mit viel Inline-Assembler? Das, was Du besser (lernen) kannst. Assembler und C mixen aber auf keinen Fall, damit erhält man nur die Summe der Nachteile von beiden und kaum Vorteile. Sachen >2kB Binärcode sollte man aber immer in C machen. In Assembler steigt dann der Aufwand, den Überblick nicht zu verlieren und die Programmierzeit unverhältnismäßig stark an. Peter
Wer in einer Sprache fit ist, sollte die nehmen. Wer keine Sprache richtig kann, sollte sich zunächst auf eine festlegen, diese dann lernen und dann programmieren.
Peter Dannegger schrieb: > Assembler und C mixen aber auf keinen Fall, damit erhält man nur die > Summe der Nachteile von beiden und kaum Vorteile. Hallo Peter, komisch dass fast alle real existierenden Systeme von der Waschmaschine bis zum PC in C UND ASM programmiert sind - deine sicherlich überragenden Programmierfähigkeiten müssen offensichtlich unter den ITlern erst noch allgemein bekannt werden. Aber, wie man sieht, du arbeitest ja dran. Gruss Reinhard
Peter schrieb: > Informiere dich erst mal, über wen du da herziehst... Wenn du damit sagen willst, es mangelt mir an Ehrfurcht - ja, genau so ist es. Unsinn ist Unsinn, egal von wem. Ich schreibe Software, seit es überhaupt programmierbare Systeme gibt, anzubetende Götter sind mir bisher nicht begegnet. Gruss Reinhard
Um die Hardware des µC kennenzulernen ist ASM ideal aber eben zeitraubend. In Sachen portierbarkeit und Übersicht ist C auf jeden Fall zu bevorzugen. Peter Dannegger schrieb: > Sachen >2kB Binärcode sollte man aber immer in C machen. Dem schließe ich mich an. Auf den AVR bezogen: Tinys mit wenig Speicher (oder ohne SRAM, Tiny11) in ASM, falls die Anwendung das zulässt, manche Sachen sind in C eben einfacher zu realisieren, obwohl es nur kleine Aufgaben sind.
@ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) Ich glaube Peter Dannegger meinte nur man sollte nicht Assembler und C in einem Quelltext mischen, so wie das bei Inline-Assembler Anweisungen geschieht. Womöglich habt ihr da nur ein ein wenig aneinander vorbei geredet. Ich habe auch schon Sätze gelesen, dass Peter zeitkritische Routinen sehr wohl in Assembler schreibt, dort wo es angebracht ist und ansonsten in C programmiert. (kann mich aber auch täuschen ;))
Reinhard Kern schrieb: > komisch dass fast alle real existierenden Systeme von der Waschmaschine > bis zum PC in C UND ASM programmiert sind Das erstaunt mich aber sehr. Ich wüßte keinen Grund, warum man eine Waschmaschine gemischt programmieren sollte. Auch auf dem PC kenne ich keine Applikation, die so programmiert ist. Und auf meiner Arbeit ist mir sowas auch nicht untergekommen. Natürlich enthält ein OS auf dem PC Assembler, aber das programmiert man ja nicht selber. Es geht ja hier um die Anwendungsprogrammierung und nicht um ein OS. Peter
Für ein kleine Projekt würde ich auch mit ASM anfangen, dabei lernt man die Hardware besser kennen. Wenn man danach C Programmiert wird einem schneller bewusst warum man einige Dinge die in C einfach aussehen nicht auf einem µC machen wollte. Weil es dafür keine passenen Befehle gibt und der Compiler sich etwas einfallen lassen muss. z.b. Divisionen und Bit shifts um eine Variabel länge.
Andi D. schrieb: > C oder gleich C++ damits in der entwicklung schneller geht. C++ würde ich bei Mikrocontrollern vermeiden. Die meisten Aufgaben, die die absolvieren müssen, erfordern auch nicht wirklich objektorientierte Programmierung. Eher im Gegenteil.
Hi >Sachen >2kB Binärcode sollte man aber immer in C machen. Wo liegt der Unterschied zwischen <2k und >2k? >In Assembler steigt dann der Aufwand, den Überblick nicht zu verlieren >und die Programmierzeit unverhältnismäßig stark an. Ist wohl eine weniger eine Frage des Programmierstils als der Programmiersprache. Man kann auch mit C bei 0,5k den Überblick verlieren. MfG Spess
c++ und objektorierntierte Programmierung muss kein Nachteil sein. Ich bin sogar der Meinung, dass man mit strenger OOP viel saubereren Code hinlegt, als ohne. Aber: OOP braucht teilweise mehr Resourcen als althergebrachte prozedurale Programmierung. Für einen uP ist das eher kontraproduktiv. Man kann in c++ aber auch genauso gut prozedural programmieren, wie in klassischem C. Also: Schau Dir C an, schau Dir ASM an. Nimm das, was dir eher liegt. Bei mir war es anfangs ASM (auf dem 6502 und Z80, danach 8051). Erst auf dem PC bin ich dann an C gekommen und benutzt es mittlerweise auch für uP.
Peter Dannegger schrieb: > Reinhard Kern schrieb: >> komisch dass fast alle real existierenden Systeme von der Waschmaschine >> bis zum PC in C UND ASM programmiert sind > > Das erstaunt mich aber sehr. > Ich wüßte keinen Grund, warum man eine Waschmaschine gemischt > programmieren sollte. Ich auch nicht, hängt wohl vom verbauten Controller ab. Man sollte strikt gegen Assembler sein, wo er nicht aus Performance-Gründen unabdingbar ist. Grundsätzlich sollte alles so lesbar (und somit verständlich und wartbar) wie möglich sein, dafür gibt es Hochsprachen. Allerdings bringt C keine Vorteile, wenn man kryptische Abkürzungen oder Benennungen benutzt und die strukturellen Elemente der Sprache (im weitesten Sinne ist hier Divide & Conquer gemeint) verzichtet. Dann schon lieber sauberen Assembler. > Auch auf dem PC kenne ich keine Applikation, die so programmiert ist. > Und auf meiner Arbeit ist mir sowas auch nicht untergekommen. Sieht man selten. Die Sources des Spiels Quake enthielten viel Inline-Assembler für die Grafikroutinen. Mit Kommentaren versehen wie ("We don't know how it works, but it works"). Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP oder gar nen NOP-Slide mittels inline Assembler. Bei manchen Controllern/Compilern soll sich das sogar positiv auf den Stromverbrauch auswirken, weil die in einer Idle-Loop sonst ganz andere Dinge tun.
Johnny Voltage schrieb: > Sieht man selten. Die Sources des Spiels Quake enthielten viel > Inline-Assembler für die Grafikroutinen. Mit Kommentaren versehen wie > ("We don't know how it works, but it works"). Das war vor 15 Jahren. Heutzutage arbeiten vielleicht die Entwickler von speziellen Bibliotheken (z.B. zur Physiksimulation) noch mit Assembler, aber die Spieleentwickler garantiert nicht mehr. Wenn man heutzutage Performance gewinnen will, dann investiert man die Arbeit lieber in Vektorisierung und Parallelisierung von Berechnungen, statt mit Assembler zu versuchen hier und da mal einen Takt zu sparen. > Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP > oder gar nen NOP-Slide mittels inline Assembler. Wozu?
Platinenschwenker .. schrieb: > @ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) > > Ich glaube Peter Dannegger meinte nur man sollte nicht Assembler und C > in einem Quelltext mischen, so wie das bei Inline-Assembler Anweisungen > geschieht. Womöglich habt ihr da nur ein ein wenig aneinander vorbei > geredet. Haben wir keineswegs: meine Meinung ist nach wie vor, dass man mathematische Berechnungen besser in C schreibt, Hardwarezugriffe wie das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler (wird oft HAL genannt, aber das führt jetzt zu weit). Peter hat das für totalen Mist erklärt (angeblich vereint das die Nachteile beider Methoden). Und das mit der Autorität eines von hier seinen Jüngern verehrten Software-Gottes. Tut mir leid, da müsst ihr euer Abendmahl schon alleine feiern, I am not convinced. Mehr gibt es dazu auch nicht mehr zu sagen. Von PC-Applikationen war ja sowieso nicht die Rede. Gruss Reinhard
@ Reinhard Kern Ich hatte das halt so herausgelesen ihn aber da wohl doch falsch interpretiert. Macht aber nichts. ;)
Andreas Schwarz schrieb: >> Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP > >> oder gar nen NOP-Slide mittels inline Assembler. > > > > Wozu? 1.) Ich bin gerne sehr explizit. Hast du schonmal aus Versehen einen Strichpunkt hinter einem Schleifenkopf vergessen und dann stundenlang nach dem Bug gesucht? Auch die Intention ist dann gleich klar aus dem Quelltext ersichtlich. Guter Code dokumentiert sich selbst. 2.) Ich hatte mal (evtl. falsch) gehört, dass sich das positiv auf den Stromverbrauch auswirkt. Nach weiterer Recherche habe ich jedoch jetzt nur herausgefunden, dass es sich, zumindest beim x86, um den HLT und nicht um den NOP Befehl handelt. Bei Win95 / 98 lief der Prozessor in der Idle-Loop nämlich ständig unter Vollast. Könnte mir allerdings schon vorstellen, dass der NOP Befehl energetisch günstiger ist. Reinhard Kern schrieb: > Hardwarezugriffe wie > > ... das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler > > (wird oft HAL genannt, aber das führt jetzt zu weit). Welchen Grund gibt es, das zu tun? Für die Wartbarkeit ist es Gift, verschiedene Codes in den gleichen Dateien zu mischen.
Reinhard Kern schrieb: > meine Meinung ist nach wie vor, dass man mathematische Berechnungen > besser in C schreibt, Klar, dieser Meinung bin ich auch. > Hardwarezugriffe wie das Auslesen eines empfangenen Bytes aus einem > UART dagegen in Assembler Wieso denn das? Das geht doch in C mindestens genauso gut. Da schreibe ich (für einen AVR) einfach
1 | byte = UDR; |
In Inline-Assembler würde die gleiche Anweisung etwa so aussehen:
1 | __asm("in %0,%1" : "=r" (byte) : "I" (_SFR_IO_ADDR(UDR))); |
Noch etwas aufwendiger wird es, wenn man dafür eine Assemblerfunktion in
einer eigenen Quelldatei schreibt.
Nicht dass ich das Mischen von C und Assembler verdammen würde, aber die
Fälle, wo dies sinnvoll ist, sind meiner Meinung nach recht rar gesät.
Man sollte sich auf jeden Fall alle drei Möglichkeiten offen halten:
- reines C: für fast alles
- C und Assembler gemischt: für einige wenige zeitkritische Anwendungen
- reiner Assembler: falls C vom µC nicht unterstützt wird oder
Programmspeicherverbrauch ein entscheidendes
Kriterium ist
Für reine Hobbyanwendungen wählt man natürlich immer diejenige der drei
Alternativen, die am meisten Spaß macht :)
Johnny Voltage schrieb: > 1.) Ich bin gerne sehr explizit. Hast du schonmal aus Versehen einen > Strichpunkt hinter einem Schleifenkopf vergessen und dann stundenlang > nach dem Bug gesucht? Auch die Intention ist dann gleich klar aus dem > Quelltext ersichtlich. Guter Code dokumentiert sich selbst. Würde diesen Zweck ein {} nicht besser als ein __asm("nop") erfüllen? > Nach weiterer Recherche habe ich jedoch jetzt nur herausgefunden, dass > es sich, zumindest beim x86, um den HLT und nicht um den NOP Befehl > handelt. Ja, der HLT-Befehl hält den Prozessor tatsächlich an (ähnlich dem Idle-Modus bei Mikrocontrollern). Mit einem NOP spart man vielleicht deswegen etwas Strom, weil dabei die ALU nicht aktiv wird, aber das dürfte fast vernachlässigbar sein. Bei längeren Idle-Loops wird man sowieso überlegen, ob man nicht besser den Controller schlafen legt und durch einen Interrupt wecken lässt. Das spart dann tatsächlich Strom.
Yalu X. schrieb: > Ja, der HLT-Befehl hält den Prozessor tatsächlich an (ähnlich dem > > Idle-Modus bei Mikrocontrollern). Mit einem NOP spart man vielleicht > > deswegen etwas Strom, weil dabei die ALU nicht aktiv wird, aber das > > dürfte fast vernachlässigbar sein. Und ob der NOP energetisch günstiger ist, er gilt sogar als Referenzmaß für die verwendete Energie bei Instruktionen (basierend auf MSP430): http://www.eecs.harvard.edu/emnets/papers/laneEmnets06.pdf Da gehts um Low-Power Compilation! Yalu X. schrieb: > Bei längeren Idle-Loops wird man sowieso überlegen, ob man nicht besser > > den Controller schlafen legt und durch einen Interrupt wecken lässt. Das > > spart dann tatsächlich Strom. Das ist natürlich wahr! Yalu X. schrieb: > Würde diesen Zweck ein {} nicht besser als ein __asm("nop") erfüllen? Ich finde die explizite Version besser als die implizite. Dann gibt es an der Intention keinen Zweifel.
Ich sehe da folgende Entscheidungskriterien:
Performance
-------------------------
Hinreichend diskutiert. Die Teile einer Anwendung, die eine hohe
Performance benötigen, bzw. CPU-Zeit sparen müssen, werden in Assembler
programmiert. Damit meine ich auch Mischen von Assembler und C.
Stückzahl/Kostendruck
-------------------------
Die Programmierung von Routinen in Assembler erlaubt möglicherweise den
Einsatz eines kleineren Controllers. Das rentiert sich natürlich nur bei
entsprechender Stückzahl. Beispiele wären z.B. Software-UARTs ("Hilfe,
ich brauche 8 UARTs!") oder Tonerzeugung ("Hilfe! Ich brauch noch nen 4.
Timer!), Signalverarbeitung ("33 Bit mit AVR").
Komplexität
-------------------------
Ab einer bestimmten Größe einer Firmware verbietet sich der Einsatz von
Assembler von alleine, jetzt mal von ein paar Profis abgesehen, die ihre
ultimative Makrosammlung einfach nicht im Stich lassen können ("Meine
Makros erlauben Programmierung quasi in Hochsprache!").
Eine Pauschalisierung ist wie immer generell nicht möglich ;-)
Reinhard Kern schrieb: > Peter hat das für > totalen Mist erklärt (angeblich vereint das die Nachteile beider > Methoden). Ist es auch für einen Anfänger. Wenn man Assembler und C mixen will, muß man schon fundierte Kenntnisse über die Internas des verwendeten Compilers haben und das haben Anfänger nunmal nicht. Und deshalb fallen sie dabei regelmäßig auf die Nase. Is so. Hat man aber ne Weile in C programmiert, merkt man schnell, daß man auch (nahezu fast) alles in C machen kann ohne Nachteile. Wenn die Compilerbauer Lib-Funktionen in Assembler schreiben, ist das was anderes, die haben ja Ahnung davon. > Und das mit der Autorität eines von hier seinen Jüngern > verehrten Software-Gottes. Das ist Quatsch mit Soße. Ich halte doch nicht deshalb mit meiner Meinung hinterm Berg, nur weil sie jemandem nicht passen könnte. Wenn Du mich für einen Gott hältst, ist das allein Dein Bier. Ich habe das gleiche Recht, meine Meinung zu posten, wie jeder andere. Peter
Eddy Current schrieb: > Ich sehe da folgende Entscheidungskriterien: Eines kommt noch hinzu: Es gibt Konzepte, die in C nicht wirklich gut abgebildet werden können. Beispiel: unterschiedliche Memory Spaces, z.B. X, Y und P Space beim DSP56k, wo es wichtig war, die Daten passend auf X und Y Memory zu verteilen. Ansatzweise sieht man das beim AVR beim Zugriff auf den Program Space. Bei neueren Prozessoren wird sehr darauf geachtet, dass es ein C Compiler leicht mit ihnen hat, aber wer noch eine Architektur aus den 70'ern verwendet (PIC16 z.B.), der wird eher geneigt sein, das C wegzulassen. fchk
Johnny Voltage schrieb: > Und ob der NOP energetisch günstiger ist, er gilt sogar als Referenzmaß > für die verwendete Energie bei Instruktionen (basierend auf MSP430): Aber groß ist der Unterschied ja trotzdem nicht. Der verschwenderischste unter den 1-Zyklus-Befehlen ist nach dem verlinkten Artikel der BIS-Be- fehl, der 12% mehr Energie als ein NOP braucht. Der in Abfrageschleifen üblicherweise anzutreffende BIT-Befehl braucht nur 6% mehr als der NOP. Dieser Geweinn relativiert sich u.a. dadurch, dass ohne den zusätzlichen NOP in der Schleife diese bei Eintreffen des erwarteten Ereignisses im Mittel einen halben Taktzyklus früher verlassen werden kann, was der CPU etwas mehr Zeit für sinnvollere Dinge als Däumchendrehen verschafft. Und wenn die durch den NOP in der Schleife verschlechterte Reaktionszeit nicht stört, kann man evtl. auch gleich die Taktfrequenz des Controllers etwas herunterzusetzen, was mehr Energie spart als der NOP.
ASM-Grundkenntnisse sind auf einem Mikroprozessor Pflicht, finde ich. Nicht, weil das so toll ist, zehntausend Zeilen ASM zu tippen, sondern weil man nur dadurch versteht, warum manche C-Konstrukte ungünstig sind (z.B. Schieben auf dem AVR), wozu manchmal ein scheinbar überflüssigs 'volatile' vonnöten ist und so weiter. Auch, um mal ein Listing zu untersuchen, wenn plötzlich der Programmspeicher überläuft.
Ich bin schon sehr über die Tonart hier verwundert. Wir sind alle erwachsene Leute. Ich bin kein Moderator oder sonstiges außer Gast in diesem Forum. Dennoch möchte ich mich vor allem bei Peter Dannegger bedanken. Ich habe hier seinen Namen gefunden. Den Code über das Herausfinden einer ID. eines 1.Drahtsensors habe ich irgendwann mal, wo weiß ich nicht mehr heruntergeladen. Ich habe das Teil auf mehr als 16 Meßstellen erweitern können. Vielen Dank an Peter!! Trotzdem, jeder hat eine andere Ansicht und das ist auch gut so! Wenn ich aber die 1. Frage richtig gelesen habe ging es um ASM oder C. Ich bin für das Verständnis eines Mikrokontrollers für ASM. Wenn es um Portabilität geht aber eher für C. Aber Vorsicht ich bin schon seit der Mondlandung Basic geschädigt. Alfons.
Reinhard Kern schrieb: > Haben wir keineswegs: meine Meinung ist nach wie vor, dass man > mathematische Berechnungen besser in C schreibt, Hardwarezugriffe wie > das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler Wenn du wirklich für das Lesen der Bytes aus dem UART Assembler benutzt, dann geht das sicherlich, das ist nicht die Frage. Aber warum sollte ich dafür Assembler für einsetzten? Sorry, aber solch ein Quatsch ist mir noch nicht unter gekommen. Da hat Assembler nichts zu suchen. Bitte nenne mir einen wirlich vernünftigen Grund dafür. > (wird oft HAL genannt, Ich kenne bisher keinen HAL, der in Assembler geschrieben ist. Mit Ausnahme der Interruptbehandlung oder der Taskwechsel bei einem OS. Und ein paar Embedded OS hab ich schon gesehen. Von 8-Bit bis 32-Bit. Überall war nur soviel in Assembler, wie notwendig. Und einen Cortex-M3 bekommt man sogar gänzlich ohne Assembler zu laufen. Ich meine den Startup-Code. Man braucht im Prinzip keine Zeile Assembler dafür. > totalen Mist erklärt (angeblich vereint das die Nachteile beider > Methoden). Hat er Recht. Assembler nur dort, wo es anders nicht geht. Entweder aus Performancegründen (was recht selten ist) oder weil man sich in 'C' manche Dinge einfach nicht erledigen kann. > Und das mit der Autorität eines von hier seinen Jüngern > verehrten Software-Gottes. Da mußt du dich wohl jetzt an die eigene Nase fassen. > Tut mir leid, da müsst ihr euer Abendmahl > schon alleine feiern, I am not convinced. Me too about you :-) > Mehr gibt es dazu auch nicht mehr zu sagen. Nee, stimmt. :-) Alles auch ein wenig eine Philosophiefrage. Gelle? :-)
http://avr-asm-tutorial.net/avr_de/beginner/Warum.html Generell würde ich Assembler immer lernen. So lernt man den Controller besser kennen. Und wenn man es mal braucht, und sei es nur für einen kleine Routine, dann kann man es.
Peter Dannegger schrieb: > Assembler und C mixen aber auf keinen Fall, damit erhält man nur die > Summe der Nachteile von beiden und kaum Vorteile. Gilt natürlich nicht, wenn man ein Betriebssystem entwickelt :-)
ich bin ein anhänger der these "für jede arbeit ein passendes werkzeug..." sicher kann man z.b. versuchen, für einen garagenzubau den mörtel mit einer bohrmaschine, quirl und einzelnen zutaten zu rühren, aber mit einer mischmaschine und passender fertigmischung geht das ganze leichter und schneller. genauso verhält es sich - meiner meinung nach - mit programmiersprachen: in erlang z.b. kann man einen kompletten quicksort (schön lesbar) in zwei zeilen schreiben - in C braucht man schon eine weile länger. ich sehe jedenfalls keinen grund, "spezielle" funktionalitäten als assembler-funktionen - in einer eigenen datei gekapselt - zu implementieren (auch wenn mir im moment nichts einfällt...)
Daniel F. schrieb: > ich bin ein anhänger der these "für jede arbeit ein passendes > werkzeug..." Sehr löblich. Dann besorg Dir doch mal das passende Werkzeug zum tippen. Auf Deiner Tastatur ist ja offensichtlich die Shift-Taste defekt.
Micha H. schrieb: > Sehr löblich. Dann besorg Dir doch mal das passende Werkzeug zum tippen. > Auf Deiner Tastatur ist ja offensichtlich die Shift-Taste defekt. Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles Argument vorbringen, aber über einen Beitrag herziehen, weil da Groß- und Kleinschreibung nicht beachtet wurde... Wenn da interpunktion und Absätze fehlen würden, könnt ich's ja verstehen, aber auf so einem niederen Niveau hier zu posten ist eigentlich meine Aufgabe...
Leute, ich liebe Assembler und werde einen 8-Bitter nicht wieder mit C veralbern. Für die Übersichtlichkeit eines Programms ist der Programmierer verantwortlich - nicht die Sprache !!! Einen 8-Bit uC mit C programmieren, ist wie Basic auf dem PC. Und übrigens ist C schon seit 15 Jahren tot. Da hilft es auch nicht weiter, wenn einige Leute nicht loslassen können und sich nicht weiterentwickeln. Für 32-Bit uC muss mann sich leider meist noch C behelfen :-(
IchLiebeAssembler schrieb: > Und übrigens ist C schon seit 15 Jahren tot. Was ist denn grade so angesagt?
IchLiebeAssembler schrieb: > Für die Übersichtlichkeit eines Programms ist der Programmierer > verantwortlich - nicht die Sprache !!! Warum programmierst du dann nicht gleich mit Binärcodes? Wenn du sie schön anordnest, versteht sicher jeder das Programm ;-) > Einen 8-Bit uC mit C programmieren, ist wie Basic auf dem PC. Diesen Vergleich habe ich jetzt überhaupt nicht verstanden. > Und übrigens ist C schon seit 15 Jahren tot. Da muss ich die Beerdigung verpasst haben, stand da was in der Zeitung? > Für 32-Bit uC muss mann sich leider meist noch C behelfen :-( Wieso? Gibt es denn keine 32-Bit-Assembler?
Also, wenn man sich mal gut unterhalten möchte stellt man hier einfach die Frage nach C oder Assembler. Warum gibt es immer wieder Leute, die bereit sind darüber kleinliche Diskussionen zu führen? Man hat doch nicht die Weißheit gepachtet, nur weil man gut in C oder Assembler programmieren kann! Und zu einem besseren Menschen wird man auch nicht, nur weil man in der "besseren" Sprache programmieren kann. Tut mir leid, Aber solche Diskussionen sind einfach nur jedesmal wieder aufs neue peinlich. Jeder von Euch ist gut in dem was er kann. Es gibt keine Gründe, jemanden schlecht zu machen, der in einer anderen Sprache gut programmieren kann. Mit vielen Grüßen, Tom.
Tom schrieb: > Tut mir leid, Aber solche Diskussionen sind einfach nur jedesmal wieder > aufs neue peinlich. Jaja... immer diese Kindergartenkinder ;)) Ein kleiner Tropfen meiner Meinung: 1. Ich denke C ist ein guter Kompromiss zwischen Performance und Lesbarkeit, 2. Ich liebe diese z.T. kryptische Syntax: i -= z++; 3. und den Leuten, die Assembler beherrschen, gebührt mein Respekt!
Wir (4 Leute) arbeiten zur Zeit an nem ATmega2560. Der eine macht die Peripherie, einer das Ethernet, einer das Userinterface und einer die Regelung. Und das klappt erstaunlich gut. In Assembler stelle ich mir das als ein Ding der Unmöglichkeit vor. Peter
Fragt mal Dave Jones ;) Die Sache ist eben ob es einen C-Compiler gibt, bzw einen freien wenn man darauf besteht. Letzteres ist bei AVR und ARM mit gcc gegeben, fuer 8051 taugt SDCC inzwischen gut, bei PIC wird die Sache haarig (gibt SDCC-Support aber der scheint noch nicht sehr reif zu sein).
Meine Meinung dazu: Immer C, sofern Assembler nicht zwingend notwendig wird (besonders zeitkritische Teile). Ansonsten hilft Assembler natürlich ungemein beim Verständnis dessen, was in einem Controller so passiert.
faustian schrieb: > Die Sache ist eben ob es einen C-Compiler gibt, Also ich kenne keinen Controller, für den es keinen C-Compiler gibt. Wer auf Nummer sicher gehen will lernt C und Assembler.
Sorry, aber ASM ist wirklich so gut wie tot. Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den kompletten Quellcode mit. Ich habe nirgends, außerm in der Startup-Routine des Prozessors irgendwelchen ASM Code gesehen. Ein guter Compiler erzeugt heute fast immer gleich guten, wenn nicht besseren code als ein ASM programmierer ( es muss jemand schon sehr gut in ASM sein um das zu toppen). Ich habe neulich mit einem Freund der wirklich ein extrem guter Programmierer (auch ASM, er hat die ersten Soft DVD Dekoder auf dem Markt entwickelt) mal getested, was z.B. bei MMX-Programmierung mit Handoptimierung rauszuholen ist und wir haben festgestellt, dass der Code des Compiler fast nicht zu verbessern war. Dazu kommt, dass ein 8-Bitter mit ein paar Registern noch gut zu überschauen ist. Sobald aber ein Prozessor einen Cache und eine mehrstufige Pipeline mit Branch prediction besitzt, ist der Complier fast immer im Vorteil, da er über größere Codeabschnitte optimieren kann. Was die Codegröße angeht, würde ich auch gern mal einen Vergleich zwischen C und gutem ASM code sehen wenn man den Compiler auf Größe optimieren läßt. ASM ist für jeden Prozessor irgendwie anders, d.h. man muss immer neu lernen bzw. umschalten wenn man mit mehr als einer Prozessorfamilie arbeitet. Auch die Frage nach C++ oder C ist in hinsicht Performance längst geklärt, C++ ist genauso schnell als C. Nur in den Anfangszeiten als C++ als Präprozessor realsiert war, war C++ langsamer und der Code viel Größer. Die Argumente Übersichtlichkeit wurde schon erwähnt. Wichtiger ist aber noch die Wartbarkeit. Sich in ASM Code von jemandem anderen einzuarbeiten und zu verstehen was der Urheber erreichen will ist ausgesprochen mühsam. Was natürlich nicht schadet, wenn man ASM LESEN kann, damit man im Debugger auch mal überwachen kann was denn Dein code gerade macht. Wer heute noch in ASM arbeitet macht das entweder weil er dass schon seit 20 Jahren macht (das haben wir immer so gemacht) oder weil er es halt cool findet ASM zu beherrschen (oder zumindest das glaubt) Gruß Tom
Thomas Burkhart schrieb: > Sorry, aber ASM ist wirklich so gut wie tot. > > Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den > kompletten Quellcode mit. Wir reden doch hier von 8 Bit Mikrocontrollern, nicht von 32 Bittern oder PCs. Und tot wird ASM nie sein, weil das die einzige Sprache ist, die ein Controller versteht. Und an den allmächtigen Compiler, der idealen Code generiert, glaube ich nicht. Wenn es wirklich an's Eingemachte geht kommt man mit einem Compiler nicht weit. Mit einem Servo Controller bin ich da an die Grenzen gestoßen. Ging nur mit ASM weiter. Und einen Tiny13 würde ich auch nicht in C programmieren
Na, das ist ja wieder ein prima Glaubenskrieg geworden.... ;-) Nur um den lieben "Staubsaugervertreter" auch noch meine Meinung wissen zu lassen: Ich mache alles in ASM. Warum? .... weil ich das(s) schon seit 20 Jahren mache oder weil ich es halt cool finde ASM zu beherrschen ..... ;-) Es kommt natuerlich immer auf das System an. Natuerlich schreibt keine PC Software in Assembler. (Aber einen Dongle zum umgehen wird ohne ASM Kenntnisse nicht gelingen ;-) Aber gerade die ARMs oder PICs sind recht Speicherkritisch und vor allem Peripheriekritisch. Da muss ich genau wissen, welches uC-Beinchen gerade wir steht und das ist bei jedem Chip auch noch anders. Das Argument der Mathematik lass ich nicht gelten, denn wenn man wirklich das schon "seit 20 Jahren macht", hat man alle notwendigen Routinen schon bereitliegen (Wurzeln ziehen, Multiplizieren, PID-Regler.....) und bindet sie ein einen - natuerlich relokierbaren - Code schnell ein. Also hoer nicht auf uns alle, es gibt kein Knigge fuer die Wahl der Programmiersprache. Schau was Dir besser liegt. Gruss Michael
Herzlichen Glückwunsch, Staubsaugervertreter, Du hast es wieder einmal geschafft den alljährlichen C – ASM Thread zu eröffnen. Und natürlich gibt es wie immer die komischsten Kommentare... Übrigens, ich habe auch eine Meinung dazu...
Troll schrieb: > Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles > Argument vorbringen, Sinnvolle Argumente beim xx. "was ist besser"-Thread, soso. Bereits mit der 3. Antwort waren alle objektiven Argumente genannt, an subjektivem "mir gefällts aber so besser" oder "me too"-Getröte beteilige ich mich nicht. Und - Überraschung - an der Diskussion war und bin ich durchaus beteiligt, ich habe nämlich einen Beitrag als Antwort auf einen anderen Beitrag geschrieben. > aber über einen Beitrag herziehen, weil da Groß- > und Kleinschreibung nicht beachtet wurde... Du hast nicht verstanden. Oder nicht gelesen. Oder beides. Also nochmal zum mitschreiben: Zur Kommunikation benötigt man Sprache. In unserem Kulturkreis wird selbige aus Groß- und Kleinbuchstaben zusammengesetzt. Am PC ist das passende Werkzeug dazu die Tastatur; auf der linken Seite davon findet man die Taste um Groß/Klein auszuwählen. Und - Achtung, jetzt kommts - D.F. wollte "für jede arbeit ein passendes werkzeug...", tat's aber dann doch nicht. Paradoxon, ick hör dir trapsen. Du kannst ja mal spasseshalber versuchen beim C-Programmieren oder auch nur so auf einem unixoiden System ohne Großbuchstaben auszukommen. > auf so einem > niederen Niveau hier zu posten ist eigentlich meine Aufgabe... Was meinst Du mit "eigentlich"? Du hast doch Deinem Nick alle Ehre getan!?
[offtopic] Troll schrieb: > Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles > Argument vorbringen, aber über einen Beitrag herziehen, weil da Groß- > und Kleinschreibung nicht beachtet wurde... Wenn da interpunktion und > Absätze fehlen würden, könnt ich's ja verstehen, aber auf so einem > niederen Niveau hier zu posten ist eigentlich meine Aufgabe... Die Spinnen Die spinnen Warum sind füllige Frauen gut zu Vögeln? Warum sind füllige Frauen gut zu vögeln? Er hat liebe Genossen. Er hat Liebe genossen. Wäre er doch nur Dichter! Wäre er doch nur dichter! Sich brüsten und anderem zuwenden. Sich Brüsten und anderem zuwenden. Die nackte Sucht zu quälen. Die Nackte sucht zu quälen. Sie konnte geschickt Blasen und Glieder behandeln. Sie konnte geschickt blasen und Glieder behandeln. Der gefangene Floh. Der Gefangene floh. Helft den armen Vögeln. Helft den Armen vögeln. Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und Kleinschreibung wäre nicht wichtig... [/offtopic] StaubsaugerVerdreher schrieb: > Herzlichen Glückwunsch, Staubsaugervertreter, Du hast es wieder einmal > geschafft den alljährlichen C – ASM Thread zu eröffnen. Und natürlich > gibt es wie immer die komischsten Kommentare... > Übrigens, ich habe auch eine Meinung dazu... Ist mindestens schon der zweite in diesem Jahr. Beitrag "welche Programmiersprache?"
:
Wiederhergestellt durch Admin
TrollTroll schrieb: > Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und > Kleinschreibung wäre nicht wichtig... YMMD :D
TrollTroll schrieb: > Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und > Kleinschreibung wäre nicht wichtig... Sehr amüsant, aber trotzdem ein schlechtes Argument. Bei gesprochener Sprache funktioniert es ja auch ohne Groß- und Kleinsprechung. Interessant fand ich in dem Zusammenhang die Studie in den Niederlanden, die festgestellt hat, dass auch für niederländische Muttersprachler niederländische Texte schneller lesbar waren, wenn darin die deutschen Regeln für Groß-/Kleinschreibung angewendet wurden (nach niederländischen Regeln werden nur Satzanfänge und Eigennamen großgeschrieben). Siehe http://www.uni-koeln.de/ew-fak/Deutsch/projekte/koebes/KoeBeS1.pdf ab Seite 45. Andreas
Hi Ist ja ein wunderbarer Glaubenskrieg und ehrlich, ich staune da nicht schlecht. Zur Erinnerung der Eröffnungsthread: Unkown User schrieb: > hi. > > > > In was sollte man kleinere, einfachere Sachen besser programmieren? > > Also einfache Sachen die man problemlos auch mit nem TTL Grab und OP's > > machen könnte und die nur aus Bequemlichkeit und wegen geringerem > > Bauteileaufwand mit einem uC gemacht werden. > > > > C oder ASM? Oder beides, also C mit viel Inline-Assembler? > > > > Mit was progrmmiert ihr sowas? Ich programmiere sowas in Assembler, weil ich C (noch) nicht kann. Mit BASIC sieht's nicht anders aus. Letztlich ist's egal, in welcher Sprache programmiert wird, auf's Ergebnis kommt's an. Wenn ich C könnte würd ich auch nicht extra Assembler lernen, bloß weil's halt chic ist. Oder professionell, oder ... egal. Auch steht vielleicht auch eine Anforderung dahinter: klar, ich kann einem Kunden kein Assemblerprogramm liefern, wenn er C verlangt und ich michdrauf eingelassen habe. Aber solange im Hobbybereich die Pflichtenhefte selbst geschrieben werden, ist das eigene Können der Maßstab und nicht die Meinung, das irgendwas "tot " ist. Grundlagen sind heutzutage nach wie vor wichtig. Kein Mensch käme auf die Idee, die Mathematik als "Tot" zu bezeichnen, bloß weil es ja Taschenrechner gibt. Gruß oldmax
Thomas Burkhart schrieb: > Sorry, aber ASM ist wirklich so gut wie tot. > > Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den > kompletten Quellcode mit. > Ich habe nirgends, außerm in der Startup-Routine des Prozessors > irgendwelchen ASM Code gesehen. Das bezweifle ich insofern, als dass irgendwo im Code des Betriebssystems sicherlich die Test-and-Set Instruktion oder ihr Äquivalent verwendet wird, um zum Beispiel Semaphoren zu implementieren. Wie war das doch gleich, TAS bei Motorola, XCHG bei Intel...
@Mark: Sicher wird es den geben, aber wieviel % des OS ist dass dann? Alle Treiber jedenfalls waren pures C
Andreas Ferber schrieb: > Bei gesprochener > Sprache funktioniert es ja auch ohne Groß- und Kleinsprechung. Natürlich gibts Groß- und Kleinschreibung auch bei gesprochener Sprache. Mann nennt sie dort nur anders, nämlich "Betonung".
bis auf den post von TrollTroll kann man diesen Thread doch nun mal getrost löschen :)
A. B. schrieb: > bis auf den post von TrollTroll kann man diesen Thread doch nun mal > getrost löschen :) Jaaaa, und meinen bitte auch lassen ;-) Staubsaugervertreter, Assembler ist nichts für Skriptkiddies, nur etwas für gestandene Männer, die noch ihren Code selbst schreiben können. Das lernt man aber nicht über Nacht - viele C-Spezialisten lernen es nie, wie man in den Hilferufen hier im Forum merkt. Ein richtiger Assembler-Programmierer schreit nie nach Hilfe, er schaut ins Datenblatt. Und welcher C-Code ist noch nach 5 Jahren brauchbar? Mal ganz davon abgesehen, dass der aktuelle Compiler damit nichts mehr anfangen kann. Das mag für den Consumer-Markt noch angehen, aber wer im privaten Bereich nach 5..10 Jahre an einem Projekt etwas änder will, kann sich solchen Sch... nicht leisten.
Alter Sack schrieb: > Und welcher C-Code ist noch nach 5 Jahren brauchbar? Ich hab mal in ein älteres Projekt geschaut: Die älteste Datei ist vom 23.10.1995. Die letzte Änderung erfolgte am 3.7.2009. C-Code ist also sehr wohl über viele Jahre wartbar (bisher haben schon 3 Personen nacheinander daran gewerkelt). Die Hardware hat sich zwischenzeitlich sogar geändert. Zu Anfang ware es ein 8031 mit externem EPROM, SRAM. Jetzt ist es ein 8051 mit internem Flash, SRAM und Bootloader. Peter
Alter Sack schrieb: > Und welcher C-Code ist noch nach 5 Jahren brauchbar? Wie jeder erfahrene Programmierer weiß, hat Code allgemein immer nur eine sehr kurze Lebensdauer. Deswegen gab es ja auch nie ein Jahr 2000 Problem :-) In meinem aktuellen Projekt sind die ältesten C-Files über 10 Jahre alt. Und wie man sieht kommen heute noch Änderungen hinzu, und womöglich auch in zehn Jahren von heute an noch.
In 10 Jahren bin ich 70. Da ändere ich an keinem Code mehr etwas. Aber, weitermachen, der Fred liest sich sehr gut beim Frühstück.
Mark Brandis schrieb: > Alter Sack schrieb: >> Und welcher C-Code ist noch nach 5 Jahren brauchbar? > > Wie jeder erfahrene Programmierer weiß, hat Code allgemein immer nur > eine sehr kurze Lebensdauer. Deswegen gab es ja auch nie ein Jahr 2000 > Problem :-) > > In meinem aktuellen Projekt sind die ältesten C-Files über 10 Jahre alt. > Und wie man sieht kommen heute noch Änderungen hinzu, und womöglich auch > in zehn Jahren von heute an noch. Ich biete 20 Jahre für "meine" Anwendung; allerdings brauche ich sie schon lange nicht mehr "am Tropf halten" und die verschiedensten OS- und Hardware-Wechsel "niederkämpfen" - von Compilerwechseln ganz zu schwerigen. So, das war mein "Frühstücksei". Bernhard
Alter Sack schrieb: > Assembler ist nichts für Skriptkiddies, nur etwas > für gestandene Männer, die noch ihren Code selbst schreiben können. Und so einer (und Chuck Norris) isst auch keinen Honig, der kaut Bienen... IM Privatbereich darf doch jeder machen, was er will. Die einen lernen Telefonbücher auswendig, andere sammeln Kronkorken, und manche programieren halt Assembler. Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns' denn Spaß macht, so what? Oliver
Peter Dannegger schrieb: > C-Code ist also sehr wohl über viele Jahre wartbar (bisher haben schon 3 > Personen nacheinander daran gewerkelt). In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht bei neuer Hardware mit neuen Möglichkeiten. Alter Code ist doch meist nur zum Reinschauen und Kopfschütteln. Alter Sack, Du bist wohl wie Linus Torvalds, der schreibt auch seine langsamen Gerätetreiber selbst (als echter Mann). Dies allerdings mehr in Macros als in C.
Hi Oliver schrieb: > Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns' > > denn Spaß macht, so what? Das kann ich so nicht stehen lassen...... 1. Man lernt was ( was auch immer) 2. Du sagst es selbst, es macht Spaß (kein sinnvoller Nutzen ?) 3. Es kurbelt die Wirtschaft an (Hersteller wollen auch leben....) Wenn ich noch ein wenig nachdenen würde, ich käme auf reichlich sinnvolle Nutzen. Was redet ihr hier eigentlich ? Ist euch noch klar, was die Startfrage war ? Kleinere , einfachere Sachen..... Nicht on Betriebssystemen, Waschmaschinen oder gar eine Motorsteuerelektronik ist hier die Rede. Die Antwort ist lediglich, das was du schon kannst oder bereit bist zu lernen. Es ist fraglich, ob bei Null-Start C schneller begriffen wird, als ein Assembler. Und wenn bereits vorbelastet, dann ist Assembler auch kein Problem. Gruß oldmax
Hi so jetzt hoffentlich fehlerfrei, man ist mir das peinlich..... Oliver schrieb: > Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns' > > denn Spaß macht, so what? Das kann ich so nicht stehen lassen...... 1. Man lernt was ( was auch immer) 2. Du sagst es selbst, es macht Spaß (kein sinnvoller Nutzen ?) 3. Es kurbelt die Wirtschaft an (Hersteller wollen auch leben....) Wenn ich noch ein wenig nachdenken würde, ich käme auf reichlich sinnvolle Nutzen. Was redet ihr hier eigentlich ? Ist euch noch klar, was die Startfrage war ? Kleinere , einfachere Sachen..... Nicht von Betriebssystemen, Waschmaschinen oder gar Motorsteuerelektronik ist hier die Rede. Die Antwort ist lediglich: "das was du schon kannst oder bereit bist zu lernen". Es ist fraglich, ob bei Null-Start C schneller begriffen wird, als ein Assembler. Und wenn bereits vorbelastet, dann ist Assembler auch kein Problem. Gruß oldmax
Alles neu macht der Juli schrieb: > In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht > bei neuer Hardware mit neuen Möglichkeiten. Deine Kunden zahlen Dir alle paar Jahre die komplette Neuentwicklung der Software? Du Glücklicher, Du hast eine Gelddruckmaschine. Viel Spass und langes Gelingen. Ach ja, den Sarkasmus darfst Du auch gerne kostenlos behalten. Da nich für, Micha
Alles neu macht der Juli schrieb: > In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht > bei neuer Hardware mit neuen Möglichkeiten. Alter Code ist doch meist > nur zum Reinschauen und Kopfschütteln. Nein, ist er nicht. Ich bin auch nicht der Original-Autor, sondern habe nur Erweiterungen hinzugefügt. Und das ging ganz gut. Ich hab mir nur die Stellen angeschaut, wo ich die Änderungen machen mußte. Eine komplette Erneuerung wäre viel zu aufwendig. Dann müßte man ja den ganzen Code analysieren. Daher ist die neue Hardware auch kompatibel, nur eben weniger Chips und von außen updatebar. Peter
moin moin, mal als Anmerkung: Ich baue ein med. Behandlungsgerät, so eine Art "Blutwaschmaschine". Diese wird von 2 MC Typ 80386 gesteuert und überwacht. Die beiden MCs arbeiten als Master-Slave und sind nach TÜV-Vorgaben in ASM programmiert. Nur so ist sichergestellt, das gleiche Funktionen auf unterschiedlichen Wegen zum (hoffendlich) selben Ergebnis kommen. Bei unterschiedlichen Ergebnissen stoppt das System. Hochsprachen sind hier nicht brauchbar. Mit Gruß Pieter
Pieter schrieb: > Die beiden MCs > arbeiten als Master-Slave und sind nach TÜV-Vorgaben in ASM > programmiert. Na ob man damit glücklich wird... Je komplexer die Software, um so weniger ist Assembler als einzige im Projekt zu verwendende Sprache sinnvoll. Ab einer gewissen Komplexität schießt man sich mit einer solchen Anforderung doch selbst in den Fuß (autsch), was Wartbarkeit und Erweiterbarkeit betrifft. Außerdem will mir die Logik nicht so recht einleuchten, wonach bei einer Fahrzeugsteuerung Hochsprachen okay sind (da sterben bei einer Fehlfunktion womöglich etliche Leute auf einmal, in einem voll besetzten Zug vielleicht sogar ein paar Hundert) und bei einer Maschine, die maximal an einem Menschen gleichzeitig Schaden anrichtet, soll es dann nicht okay sein... das verstehe wer will? Okay, Zug fahren ist nicht das Gleiche wie Dialyse, aber trotzdem nicht so wirklich konsequent das Ganze.
Es ist sicherlich der Regelfall, das der Otto-Normal Forumsteilnehmer seine zusammengebastelten Geräte durch den TÜV bringen muss. Also eindeutig pro Assembler ;) Soll ja jeder machen wie er denkt, aber ich würde mir freiwillig kein Assembler antun. Wer zu Hause am Code rumfuhrwerkt kann das ja machen wie er mag und wie er damit zurecht kommt...aber wer mit mehreren Leuten (2 reichen schon) an Software rumschraubt und dabei freiwillig auf Assembler zurückgreift muss masochistischer Veranlagt sein als ich es je sein werde. Und wer sich schonmal durch alten C-Code anderer Menschen wühlen durfte kann mir nicht erzählen, dass er das lieber mit AssemblerQuellcode machen würde?!?!!? Genauso wie ich es auch für sehr Zweifelhaft halte, dass ein a = b + c; schwerer zu durchschauen sein soll als ein Wust aus movs & adds usw. Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird, liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen unterm Schreibtisch :)
AlterSach schrieb: > Und welcher C-Code ist noch nach 5 Jahren brauchbar? Hmm, fast alle unter Linux verwendeten Programme ? Die meisten stammen doch aus den 70gern. Das beginnt schon mit VI, ohne den nix ediert werden kann. In meinen kommerziellen Programmen sind auch Teile drin, die ich selbst vor über 25 Jahren geschrieben habe. Man muss nicht jedesmal alles neu entwickeln, wenn man vorher sinnvolles getan hat, wenn man nicht so blöd ist, mittendrin die Sprache zu wechseln (von Pascal nach C nach Java...). PeDa schrieb: > Die Hardware hat sich zwischenzeitlich sogar geändert. Du lieferst gleich die Gegenargumente zu deiner eigenen Denkweise: 8031 und 8051 verwenden denselben Assemblercode, es hätte deinem Code also mitnichten geschadet, gleich in Assembler fomuliert worde zu sein. Euer C ist mitnichten portabel, wenn es zuweisungen der Art PORTC=0xFF verwendet (und vieles andere) Jedes C-Programm enthält Asseblerstücke, nämlich zumindet den Präambelcode-der main aufruft, und meist grosse Teile der Standardbibliothek. Es spielt dabei keine Rolle, ob er von dir selbst oder vom Hersteller geschrieben wurde, es zeigt sich nur, auf welche einfacheren Teile der Programmierung du dich beschränkst. Aber deine Auffassung, der C und Asselbler mischt wäre blöd, ist Humbug. Wenn man ernsthaft programmiert, wird man Asselber benötigen, z.B. in Interruptfunktionen und ähnlich schnellem. Klar kann man versuchen, ineffizient compilierten C-Code einfach durch einen uC der 2 Nummern grösser ist zu beschleunigen, kosteneffektiv ist das aber nicht (und manchmal reicht's trotzdem nicht). Dennoch bietet es sich nicht an, mehr als 1k Code in Asselber zu formulieren, da kriegt man ja sonst eine Krise. Vor allem beim Microchip PIC, aber da kriegen auch die Compiler eine Krise. Pieter schrieb: > 80386 ... in ASM Ach du liebe Scheisse. Der 80386 ist nun einerseits steinalt, über 25 Jahre, und andererseits kein uC. Sicher kann man ihn auch in Assembler programmieren, aber ab bestimmter Codegrösse geht da die Übersicht verloren, das ist also sicher unsicherer als in einer Hochsprache. Selbst im Flugzeugnavigationsumfeld darf man compilieren, man guckt halt hinterher in den erzeugten Assemblercode. Wartet also bloss, bis euch eine klügere Konkurrenzfirma mit viel geringeren Softwareerstellungskosten vom Markt fegt.
A. B. schrieb: > Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird, > liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen > unterm Schreibtisch :) LOL :-) ¡Vamos a España!
A. B. schrieb: > Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird, > liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen > unterm Schreibtisch :) YMMD !
MaWin schrieb: > Euer C ist mitnichten portabel, wenn es zuweisungen der Art > PORTC=0xFF > verwendet (und vieles andere) Keine Angst, enthält er nicht. Ich hab ja schon in Assembler EQU benutzt und daher in C dann selbstverständlich #define. Magische Zahlen im Code sind mir ein Greuel. Ein Umstieg von 8051 auf AVR wäre auch prinzipiell möglich gewesen und dabei den Großteil des Codes zu behalten. Allerdings benutzt das 8051-Programm Interruptprioritäten und das wäre ein Problem geworden. Im Nachhinein gesehen, wäre mir auch der I2C-Multimaster-Bug der AVRs auf die Füße gefallen. Nur nen moderneren 8051 zu nehmen, war daher auch eine Risiko-Minimierung. Peter
MaWin schrieb: > Du lieferst gleich die Gegenargumente zu deiner eigenen Denkweise: > 8031 und 8051 verwenden denselben Assemblercode, es hätte deinem > Code also mitnichten geschadet, gleich in Assembler fomuliert > worde zu sein. > Euer C ist mitnichten portabel, wenn es zuweisungen der Art > PORTC=0xFF > verwendet (und vieles andere) Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um einiges portabler ist als ASM? Das die ASM Varianten zweier Mikrocontroller kompatibel sind ist ja nun nicht der Normalfall.
MaWin schrieb: > Aber deine > Auffassung, der C und Asselbler mischt wäre blöd, ist Humbug. Hör bitte endlich auf, Aussagen aus dem Kontext zu reißen. Es ging darum, was man als Anfänger nicht machen sollte. Der OP hat jedenfalls nicht den Eindruck erweckt, als wäre er mit den Compiler-Internas vertraut. Die Frage Assembler und C zu mixen kommt in der Regel von Umsteigern von Assembler auf C und da kann es nur klar heißen: Finger weg! Es sei denn Du bist gerne schadenfroh, wenn andere tagelang umsonst arbeiten. Peter
MaWin schrieb: > Euer C ist mitnichten portabel, wenn es zuweisungen der Art > PORTC=0xFF > verwendet (und vieles andere) Dass man in C aber auch keine Makros ändern kann... Teufelszeug. Mit entsprechenden Anpassungen in den Makros ist C-Code architekturunabhängig. ASM funktioniert nur auf genau dem µC, für den der Code erstellt wurde. Nichtmal bei PICs ist es ohne Weiteres möglich, ASM-Code zu portieren, dabei wurde da sehr auf Kompatibilität geachtet. Für einen ARM-Kern muss man lediglich seine Headerfiles anpassen und die Makros entsprechend ändern, neuen Startup-Code dazu und fertig ist der Umstieg von ARM7 auf Cortex.
Beitrag "Java oder C++" Um mich nicht ständig selber wiederholen zu müssen verweise ich mal auf meinen Text in "Java oder C++". Einfach nach Horst suchen, der 2. Treffer ist es dann. Wobei ich der Nr.1 auch nicht widersprechen kann.
Ook! Würde ich dann auch empfehlen. Hat bestimmt Zukunft - da könnte man den Thread noch ewig verlängern... Wo ist denn eigentlich der Staubsaugervertreter, er hat sich doch noch garnicht wieder gemeldet. Ist das dieser Kleine, der von der Seitenlinie immer mal wieder Öl ins Feuer gießt?
Hi Wenn Du keine Zeitkritischen Sachen machen musst und einen neueren Chip mit einigermassen genug speicher verwendest so würde ich das in C machen. C braucht etwas mehr einarbeitungs Zeit ist aber überschaubarer als ASM. Beachte auch das Du Dich in C nicht um Mapping Probleme kümmern musst und keine Banken auswählen musst. Gruss
Hi >Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um >einiges portabler ist als ASM? Auf welchen anderen Controller ist die Initialisierung der z.B. Timer- oder ADC-Register eines AVRs portierbar? Oder auf welchen µCs hast du die gleichen Interrupts? MfG Spess
spess53 schrieb: > Hi > >>Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um >>einiges portabler ist als ASM? > > Auf welchen anderen Controller ist die Initialisierung der z.B. Timer- > oder ADC-Register eines AVRs portierbar? Oder auf welchen µCs hast du > die gleichen Interrupts? Gut, diese Dinge sind klarerweise immer anzupassen. Aber denk zb bei den AVR daran, dass manche Konfigurationsregister ihre Adresse verändert bekommen haben und dann nicht mehr mittels IN/OUT erreichbar sind. Ich geb zu, dass man das sicherlich mit Makros auch in Assembler portabel hinbekommt, aber damit machst du dann schon den ersten Schritt in Richtung 'Hochsprache'-C. Assembler ist in meinen Augen dann nützlich, wenn man aus den Statusflags nutzen ziehen kann. AUch 12 Bit Arithmetik für Zwischenergebnisse für 8-Bit Rechnerei mit eingeschränktem Zahlenbereich ist nun mal so mit C nicht möglich. Das das aber den Geschwindigkeitsboost bringt wage ich zu bezweifeln.
spess53 schrieb: > Auf welchen anderen Controller ist die Initialisierung der z.B. Timer- > oder ADC-Register eines AVRs portierbar? Peripheriezugriffe sind selten portabel, egal welche Programmiersprache benutzt wird. Mit C sind aber immerhin diejenigen Programmteile, die nur die CPU nutzen, portabel, mit Assembler nicht einmal diese. Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte Programme sind auch meist in Assembler genauso gut lesbar wie in C. Anders sieht es aus, wenn der Controller "intelligente" Dinge tun soll, also komplizierte Algorithmen abgearbeitet werden. Da freut man sich, wenn man den implementierten Algorithmus ohne Änderungen auf einen anderen Controller übertragen kann. Der weise Programmierer trennt die Algorithmik von den Peripheriezugrif- fen, so dass bei einer Portiereung sofort klar ist, welche Programmteile neu geschrieben werden müssen und welche mehr oder weniger unbesehen übernommen werden können.
Yalu X. schrieb: Ich sprech jetzt nur für mich (und dann verzieh ich mich wieder aus diesem Thread) > Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und > mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben > werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte > Programme sind auch meist in Assembler genauso gut lesbar wie in C. Für mich wird da anders rum ein Schuh draus: Ich zahl in solchen Fällen in C gegenüber Assembler keinen Penalty und selbst wenn, dann ist er so klein, dass ich ihn getrost ignorieren kann.
Karl heinz Buchegger schrieb: >> Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und >> mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben >> werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte >> Programme sind auch meist in Assembler genauso gut lesbar wie in C. > > Für mich wird da anders rum ein Schuh draus: > Ich zahl in solchen Fällen in C gegenüber Assembler keinen Penalty und > selbst wenn, dann ist er so klein, dass ich ihn getrost ignorieren kann. Das sollte auch kein Aufruf sein, solche Programme nur noch in Assembler zu schreiben. Es sind aber genau (und nur) diese Programme, wo spess53s Argument der fehlenden Portabilität uneingeschränkt greift, weswegen hier Assembler eher sinnvoll ist als bei algorithmischen Anwendungen. Aber auch hier würde ich Assembler nur dann einsetzen, wenn C wirkliche Nachteile mit sich bringt (bspw. Schwierigkeiten bei der zyklengenauen Ausführung), was aber selten der Fall ist. Insofern bin ich mit dir einer Meinung.
> Dass man in C aber auch keine Makros ändern kann... Teufelszeug.
Du hast nicht mal verstanden, was das Beispiel zeigt:
Nämlich einen direkten Zugriff auf die Hardware von C aus.
Bei anderer Hardwareverdrahtung, z.B. statt PORTC nun 3 bit auf PortB
und 5 bit auf PortD (weil die anderen Bits belegt sind), sind
Programmänderungen unumgänglich. Ebenso wenn ich Werte in
Timer-Control-Register schreibe (die auf einem anderen Prozessor
natürlich komplett anders organisiert sind) oder eben sonstwie bits der
Hardware ändere.
Da helfen dir Macros kaum weiter. Aber schön, daß du geblubbt hast.
Was weiterhilft, ist ein HAL, Hardware Abstraction Layer. Der übrigens
oft als Interface in C, als Implementation in Assembler geschrieben ist,
womit man wieder beim Thema ist.
MaWin schrieb: > Der übrigens > oft als Interface in C, als Implementation in Assembler geschrieben ist > womit man wieder beim Thema ist. Wobei eine auch kühne Behauptung nicht umbedingt etwas mit der Realität zu tun haben muß. Es mag in der großen weiten Welt sicherlich einige Programme gteben, die einen HAL in Assembler mit C-Interface haben. Aber daß das "oft" so ist, oder das überhaupt ein sinnvoller Grund existiert, es genau so zu machen, bezweifele ich mal. Oliver
MaWin schrieb: >> Dass man in C aber auch keine Makros ändern kann... Teufelszeug. > > Du hast nicht mal verstanden, was das Beispiel zeigt: Doch. Ich denke das haben wir schon. > Nämlich einen direkten Zugriff auf die Hardware von C aus. Ich seh nur nicht, wie Assembler diese Situation entschärfen könnte > Was weiterhilft, ist ein HAL, Hardware Abstraction Layer. Der übrigens > oft als Interface in C, als Implementation in Assembler geschrieben ist, > womit man wieder beim Thema ist. Und warum muss der in Assembler geschrieben sein? Ein HAL hat die Aufgabe, physikalische Geräte in logischen Geräten abzubilden. Wiederrum erschliesst sich mir nicht wirklich, inwiefern da jetzt Assembler zum Muss wird. Das Beispiel war einfach nur schlecht gewählt.
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.