Mich würde die Meinung der Experten dazu interessieren: Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen?
ASM brauchst Du fast nie, das ist heutzugage nur noch für das theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. Also: C Lasse Dir keinen unsinn von der "Ich habe meinen AVR/PIC in asm" Fraktion erzählen. Fange gleich in C auf einem ARM an.
mathe schrieb: > ASM brauchst Du fast nie, das ist heutzugage nur noch für das > theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. Genau – aber auch für das praktische Verständnis der inneren Zusammenhänge eines Mikrocontrollers. > Lasse Dir keinen unsinn von der "Ich habe meinen AVR/PIC in asm" > Fraktion erzählen. Fange gleich in C auf einem ARM an. OK, dann erzähle ich eben Unsinn. :-) Im Grunde funktionieren beide Wege. Im Fall von C ist jedoch eines sehr wichtig: lerne zuerst die Sprach C! Erst wenn du diese wirklich beherrschst, wage dich in C an einen Mikrocontroller. Sehr viele Probleme, die hier im Forum diskutiert werden, würden gar nicht erst entstehen, wenn die Leute C wirklich gelernt hätten. Assembler hingegen ist so primitiv, dass man das auch direkt zusammen mit der Mikrocontrollertechnik lernen kann. Besonders große Programme sollte man in Assembler natürlich nicht schreiben, weil man da leicht den Überblick verliert. Dafür gibts dann C. :-)
Lass dir keinen Unsinn von Mathematikern erz"ahlen ;-) ASM oder C ist nicht die einzige Frage. Das sind auch noch deine Tools, Linkerscripts usw. Ich bin auf jedem ARM uC bisher mit ASM gestartet: ARM7TDMI, Cortex-M3, Cortex-M0. Das hier ist die sch"onste Anleitung die ich kenne: http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html
mathe schrieb: > ASM brauchst Du fast nie, das ist heutzugage nur noch für das > theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. Unsinn. Assembler braucht man ständig, weil man sonst weder kontrollieren kann, ob der Hochsprachencode korrekt umgesetzt wurde, noch ob die Umsetzung unnötig umständlich erfolgte und der Code dadurch deutlich zu langsam und/oder zu lang ist. Wer den generierten Assemblercode nicht lesen kann, hat keine Möglichkeit diese Probleme zu lösen und "unerklärliche" Fehler zu finden. C/ASM schrieb: > Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? Erst C/C++ lernen, am besten auf dem PC. Da lassen sich Programme leicht debuggen, so dass man schnell lernt was man falsch gemacht hat. Anschließend lernst Du, welche Besonderheiten man bei der Benutzung von Hochsprachen auf µCs beachten muss. Gleichzeitig lernst Du Assembler, in dem Du kleine C-Programme schreibst und den daraus generierten Assemblercode studierst.
Andreas schrieb: > mathe schrieb: >> ASM brauchst Du fast nie, das ist heutzugage nur noch für das >> theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. > Unsinn. > Assembler braucht man ständig, weil man sonst weder kontrollieren kann, > ob der Hochsprachencode korrekt umgesetzt wurde, noch ob die Umsetzung > unnötig umständlich erfolgte und der Code dadurch deutlich zu langsam Aha? Wie wäre es, wenn man einfach einen funktionierenden und gut optimierenden C-Compiler verwendet? Dann muss man das Compilat gar nicht kontrollieren. Und wenn es nicht auf die letzten 10% Geschwindigkeit ankommen, dann muss man auch nicht in ASM optimieren. Bei AVR-GCC mag es anders aussehen, aber wer jetzt mit µC einsteigt, sollte es sowieso nicht mehr auf 8 bit tun.
Andreas schrieb: > Anschließend lernst Du, welche Besonderheiten man bei der Benutzung von > Hochsprachen auf µCs beachten muss. Gleichzeitig lernst Du Assembler, in > dem Du kleine C-Programme schreibst und den daraus generierten > Assemblercode studierst. Das ist einfach Unsinn. Für den erzeugten Assemblercode interessiert sich wirklich niemand au´ßer den Compilerprogrammierern und ein paar Spezialisten.
wenn man von Null anfangen möchte ist es besser wenn man mit ASM anfängt. Weil dann versteht man besser wie Hardware arbeitet. Meine Meinung. Gruß, Matthias K.
Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche Meinungen ansehen...
mathe schrieb: > Andreas schrieb: >> Anschließend lernst Du, welche Besonderheiten man bei der Benutzung von >> Hochsprachen auf µCs beachten muss. Gleichzeitig lernst Du Assembler, in >> dem Du kleine C-Programme schreibst und den daraus generierten >> Assemblercode studierst. > > Das ist einfach Unsinn. Für den erzeugten Assemblercode interessiert > sich wirklich niemand au´ßer den Compilerprogrammierern und ein paar > Spezialisten. Unsinn ist es nur wenn man es nicht braucht. Es ist ja das gleiche wie bei einem Studium, wenn es ganz schief läuft braucht man 99.2 % nicht.
Programmieren lernt man am besten, wenn man eine relevante Sprache nutzt. Am besten fängst Du mit Javascript an und lernst jquery zu nutzen. Zur Not können es auch Python oder Ruby sein. Wenn Du die beherrscht, kannst Du Dich an die elitären Sprachen wie Go und Haskell wagen. C und ASM soll Opi weiter programmieren. Das benötigt man nur für Treiber.
Ich möchte auch noch mal kurz meinen Senf dazugeben. Leider bin ich zwar kein Experte an die du deine Frage im ersten Post gestellt hast, allerdings habe ich vor kurzem mit µC Programmierung begonnen und vielleicht interessieren dich meine Erfahrungen (bis jetzt). Also ich habe mich entschieden mit ASM zu beginnen. Nicht zuletzt weil ich nicht so die Erfahrung in C habe. Außerdem interessiere ich mich ziemlich für das was exakt im µC vorgeht. Deshalb habe ich mich für ASM entschieden. Ich als blutiger Anfänger bin damit auch bis jetzt ganz gut klar gekommen. Wie schon einige Beiträge vorher denke ich, dass C mehr Sinn machen würde wenn man die Sprache schon gut beherrscht. C parallel zur µC Hardware, etc. zu lernen stelle ich mir im Gegensatz zu ASM aufwändiger vor. MfG
Mal wieder ein Thread, in dem sich alle streiten, wer die bessere Sprache spricht. Ich persönlich habe mit Assembler angefangen, habe das eine oder andere kleine Projekt damit umgesetzt. Für mich persönlich war das gut so, so habe ich manche Zusammenhänge verstanden, die ich für mich brauche, um etwas anzuwenden. Inzwischen mache ich auch viel in C. Es ist eine extrem subjektive Frage, schau dir hier einfach mal das Assembler-tutorial an, ist wirklich gut gemacht. Wenn dir das zu tief in die Materie geht, schau dir das C-Tutorial an. Und nicht gleich nach zwei Stunden aufgeben, es ist normal, wenn du die ersten Tage nicht alles verstehst, was dort geschrieben ist.. Dennis
Dennis H. schrieb: > Mal wieder ein Thread, in dem sich alle streiten, wer die bessere > Sprache spricht. Ja, und Threads dieser Art tauchen immer am Wochenende auf. Komisch, nicht?
Ich finde es schön, wenn man asm des entsprechenden Controllers beherrscht - wer sonst sollte den Herren Compilerbauern erklären, wo noch Optimierungspotential besteht? Für den praktischen Alltag und das schnell funktionierende Produkt ist es sinnlos und es lohnt sich i.a. nicht mehr, zu schnell wechseln die Plattformen. Effektiv arbeiten kann man inzwischen nur noch mit einem Compiler des persönlichen Vertrauens. Kommt man in Grenzbreiche, kann man entwder versuchen, mit asm noch was zu retten oder steigt einfach um auf die nächste Klasse. Ich bin mal gespannt, was ich noch so erleben werde.
konrad M. schrieb: > C parallel zur µC > Hardware, etc. zu lernen stelle ich mir im Gegensatz zu ASM aufwändiger > vor. Das war ein Punkt meiner Überlegungen. Ein weiterer ist, dass IF, Schleifen und Rechnungen >8bit in C einfacher sind als in ASM. Bei ASM hat man nur eine Hand voll Befehle und bei C hat man Funktionen, Pointer,... Also muss man erst C auf dem PC lernen, bevor man zum µC übergeht, es kann also länger dauern bis zum Erfolgserlebnis (LED Blinkt endlich), es könnte aber auch sein, dass ASM auf einen Anfänger komisch und unlogisch wirkt. Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe meiner Ausbildung gelernt.
C/ASM schrieb: > Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich > mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe > meiner Ausbildung gelernt. Und was ist dann die Frage bitte? Ob man mit ASM einsteigt ist eher theoretisch. Es gibt extrem wenig aktuelles Lehrmaterial zum Einstieg mit ASM. Und das ist auch gut so/hat auch einen Grund.
mathe schrieb: > C/ASM schrieb: >> Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich >> mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe >> meiner Ausbildung gelernt. > > Und was ist dann die Frage bitte? Ob man mit ASM einsteigt ist eher > theoretisch. Es gibt extrem wenig aktuelles Lehrmaterial zum Einstieg > mit ASM. Und das ist auch gut so/hat auch einen Grund. Welchen Grund hat es?
Wenn ich einen anderen µC lerne würde ich in ASM anfangen, da ich wissen will, was in der CPU so abgeht. Mick interessiert aber wie's für einen kompletten Neueinsteiger aussieht. Was würde ihr einem anfänger Empfehlen, der nach der Lösung für ein relativ einfache Projekt fragt?
Wie wäre es mit einem Gedankenexperiment: Wie würde Arduino aussehen, wenn Assembler die Einstiegssprache der Wahl währe?
Robocop schrieb: > Wie wäre es mit einem Gedankenexperiment: > > Wie würde Arduino aussehen, wenn Assembler die Einstiegssprache der Wahl > währe? Das sind ja keine Elektroniker mit Programmier Kenntnissen sondern Softwerker die was um setzen wollen mit einer funktionierenten Plattform. Es ist die Frage ob man beide Seiten beherschen will oder nur die Eine. Ich persönlich will von der Hardware zur Software kommen. Gruß, Matthias K.
Robocop schrieb: > Wie wäre es mit einem Gedankenexperiment: > > Wie würde Arduino aussehen, wenn Assembler die Einstiegssprache der Wahl > währe? Die Arduinofans würden dann zwangsläufig verstehen was sie da tun oder tun wollen! Ich habe vor Jahren mit ASM angefangen und es macht richtig Spaß,den AVR an der kurzen Leine zu haben. Möchte dazu gern C lernen, um auch mal über die 8 Bitter hinaus zu kommen. Ok, hat nichts mit der Bitbreite zu tun, die Cortexe sind aber sehr sehr komplex im Vergleich zum AVR. Daher möchte ebenkeiner jedes Register in ASM setzen. Der Faulheit (oder Übersichtlichkeit) wegen, spricht man dann gerne von "hochsprachenoptimierter" Struktur.
Tom schrieb: > Ok, hat nichts mit der Bitbreite zu tun, die Cortexe sind aber > sehr sehr komplex im Vergleich zum AVR. Ach ja? Du must doch nicht jede Adressierungsart beherrschen, kannst Dich auf den Cortex-M0-Befehlssatz anfangs beschr"anken. MOVS, LDR r0,[r1], STR r0,[r1] fertig. Schon kannst Du in alle Register schreiben oder daraus lesen. Okay noch LDR r1,=... Ist das auf dem AVR so viel einfacher??
:
Bearbeitet durch User
Marc P. schrieb: > Ist das auf dem AVR so viel einfacher?? Nein. Beim AVR setzt man, 2,3 Register und er rennt. Bei den Cortexen gibt es mehr einzustellen. Die Peripherie ist komplexer, die Fehlerträchtigkeit damit größer. Daher macht es mehr Sinn, eine Lib zu nutzen.
Tom schrieb: > Bei den Cortexen gibt es mehr einzustellen. Die Peripherie ist > komplexer, die Fehlerträchtigkeit damit größer. Daher macht es mehr > Sinn, eine Lib zu nutzen. Ja und was? Man muss clock enable für die GPIO setzten. Sonst gibt es keinen Unterschied zu den AVR.
Robocop schrieb: > Ja und was? > > Man muss clock enable für die GPIO setzten. Sonst gibt es keinen > Unterschied zu den AVR. Ach hör doch auf. Schau dir die Datenblätter an, oder mal eine Lib von innen. Das sind nicht nur Kleinigkeiten. Wie bezieht mann denn die z.B. DMA in das Ganze mit ein. Mal als Beispiel. Auf solchen leistungsfähigen Maschinen programmiert doch keiner sein EA-DOG Grafikdisplay mehr in Assembler. Macht doch keine Sinn, sieht doch niemand mehr durch. Ich bin ja gern mit ASM unterwegs, nur eine umfangreiche Anwendung mit verschiedenen Peripherien und einem GLCD würde ich mir nie in ASM zutrauen. Ich glaube, dass dafür eine Hochsprache unumgänglich ist. Außer man ist Masochist.
Tom schrieb: > Ach hör doch auf. Schau dir die Datenblätter an, oder mal eine Lib von > innen. Das sind nicht nur Kleinigkeiten. > Wie bezieht mann denn die z.B. DMA in das Ganze mit ein. Mal als > Beispiel. Das Beispiel hinkt. Auf einem einfachen AVR gibt es kein DMA. Mein Argument ist sowieso, dass ein Einstig mit ASM Schwachsinn ist. Aber wenn man es sich schon antun will, gibt es keinen großen Unterschied zwischen AVR und ARM.
C/ASM schrieb: > Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? Einfacher ist für jeden anders, das wirst du selbst herausfinden müssen. Bei ASM hängt es auch vom verwendeten Prozessor ab. > Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? Es ist schlicht wurscht Fang mit C an (ist einfach universeller). Wenn du mehr Zeit investieren und Tiefenwirkung erreichen willst lässt du noch ein paar Led's in ASM blinken. Selber bin ich übrigens mit Microcode angefangen. Mit Dil Schiebeschaltern die Bits direkt ins RAM geschoben. Das schult auch, ich weiß bloß nicht für was.
Der Rächer der Transistormorde schrieb: > C/ASM schrieb: >> Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? > Mal in eigener Sache: Da ich die Funktion der Hardware gut kenne, selber Elektroniker bin, ist es dann notwendig, C zuerst auf dem Rechner zu lernen, oder kann es gleich auf dem AVR/ARM los gehen? Tom
Tom schrieb: > Da ich die Funktion der Hardware gut kenne, selber Elektroniker bin, ist > es dann notwendig, C zuerst auf dem Rechner zu lernen, oder kann es > gleich auf dem AVR/ARM los gehen? Ich würds auf dem PC lernen. Ist flexibler, benötigt keine zusätzliche Hardware und Werte können für Debug-Zwecke einfach mit printf ausgegeben werden. Ansonsten müsstest du ja zuerst eine Ausgabe programmieren (oder eine Lib benutzen), aber wenn du gar kein C kannst... Ich schreibe und teste hardwareunabhängigen Code immer zuerst auf dem PC. Flashen und längere Laufzeiten für aufwändigere Tests der Funktionen erspare ich mir, das macht ein PC genau so gut.
mathe schrieb: > C und ASM soll Opi weiter programmieren. Das benötigt man nur für > Treiber. Vor allem braucht man es, um Script Kiddies wie Dir aus der Patsche zu helfen, wenn ihr weinend in der Tür steht, weil euer Zeug nicht läuft und ihr keine Ahnung habt, warum. ;)
Tom schrieb: > Da ich die Funktion der Hardware gut kenne, selber Elektroniker bin, ist > es dann notwendig, C zuerst auf dem Rechner zu lernen, oder kann es > gleich auf dem AVR/ARM los gehen? Neben der Frage was sinnvoll ist gibt es IMHO eine noch viel entscheidendere Frage: Was macht mehr Spaß? Und wenn man uC programmieren will dann gleich auf AVR losgehen und parallel C lernen und sich mit Hilfe der Beispiele laufend in C verbessern. Und sich freuen wenn die Led blinkt. Will man C lernen dann am Computer.
Es macht Spass, sich in ASM mal einige kleine Befehlsfolgen in AVR Studio einzutippen, und sich dann mit dem Simulator Schritt für Schritt anzusehen, was mit den Registern, Flags, PC usw. passiert. Hilfreich kann es auch mal sein, ein paar 16-bit Operationen zu testen. Das ist lehrreich und hilft evtl. später mal. Als es noch nicht anders ging, hat man früher auch mal in ASM Programme für die Produktion geschrieben. Das ist heute wahrlich nicht mehr nötig, weil C Programme besser wartbar und auch portierbar sind. Immerhin habe ich mal eine recht komplexe BLDC Steuerung mit minimalen Aufwand vom Mega88 auf XMega und STM32 portieren können innerhalb weniger Tage, das wäre mit ASM nie möglich gewesen. Also, für die Innereien des MC ruhig mal mit ASM rumspielen, wenn es dann ernst wird, besser mit C.
Wenn man den Prozessor so auslutscht, dass man schon mit Assembler optimieren muss, hat man in der heutigen Zeit zu 99% etwas falsch gemacht. Das war vielleicht vor 10-20 Jahren noch sinnvoll. Bei Bastlern kommt es nicht so auf den Preis an und in der Industrie (und auch für viele Bastler) zählt die Portierbarkeit, Wartbarkeit und Erweiterbarkeit. Nur bei extrem hohen Stückzahlen bei Billigst-Consumerelektronik mag das eine Rolle spielen (aber selbst da glaube ich es nicht einmal). Wenn man wirklich ein tieferes Verständnis für Mikrocomputertechnik bekommen will, ist Assembler sehr hilfreich, allerdings ist das auch eher unabhängig von der Plattform. Als Elektrotechnikstudent sollte man eigentlich mindestens 2-3 Plattformen kennenlernen (bei mir war das 8085, 8051 und 54er DSP). Wenn man dann mal später nach Compilerfehler sucht, hilft das Wissen, auch bei fremden Plattformen, dafür braucht man dann oftmals gar nicht den spezifischen Assembler im Detail kennen. Ich würde folgendes Vorgehen vorschlagen: 1. C am PC lernen 2. C auf einem Controller umsetzen 3. Sich mit Mikrocomputertechnik auseinandersetzen und dabei ein paar einfachere Probleme in Assembler lösen. Die "Drecksarbeit", die keinen Lerneffekt bringt, kann man dann schön in C erledigen.
Leute, die ganze bisherige Diskussion ist doch ziemlich hohl. Lest doch mal den Anfangssatz gründlich: C/ASM schrieb: > Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? Dazu sage ich zum TO: Lies zu allererst die Dokus zur Hardware, denn du willst ja einen (deinen..) µC kennen lernen. In was für einer Sprache man ihn mal programmieren will, kommt erst später. Vorher sind Hardwarekenntnisse und der Umgang mit den Programmier- (sprich "Brenn-") Utilities und deren Vorbereitung in der konkreten Schaltung angesagt. Hier geht es zwar nicht dediziert um das Thema ARM/Cortex, aber dies ist ein sehr lehrreiches Beispiel, denn in diesem Thema sind viele Disputanten herzlich ahnungslos, eben weil sie darauf drängen, immer nur C zu lernen, sich in C-Gefilden herumzusielen und sich standhaft weigern, mittels ASM in die Nähe der darunter liegenden Hardware zu kommen. SO lernt man keinen µC kennen, SO erfährt man auch nicht, was für nützliche Funktionen die Hardware denn so hat. Ich rede hier nicht von den im RefMan ausgewiesenen Peripherie-Cores, sondern von Dingen, die die CPU selbst zu bieten hat. Wieviele ARM-Programmierer kennen schon den FIQ? oder den SVC? Oder kennen sich mit den Exceptions wirklich aus? Manches hat sich beim Cortex erledigt (z.B. die verschiedenen Stacks), aber trotzdem bieten die Cortexe eben mehr als man nur per C-Lernen erfährt und später sinnvoll nutzen kann. Kurzum, C ODER ASM ist überhaupt keine relevante Frage, allenfalls müßte man sie mit einem großen UND beantworten. mathe schrieb: > ASM brauchst Du fast nie, das ist heutzugage nur noch für das > theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. Soll ich mal schreiben, wie mein innerer Dolmetscher mir solche Sätze übersetzt? Also, da steht im Klartext: "Ich bin einer, der sich weigert, die eigentliche Arbeit zu machen, deswegen will ich meinen Kopf auch nicht mit irgendwelchem Verständnis der Details belasten und deswegen bestehe ich darauf, einen Neger zu haben, der mir die Arbeit macht, mit der ich später dann vor dem Chef glänzen kann, als wäre sie meine eigene Leistung. Ich konzentriere mich da lieber auf die Karriere." Man kann so leben, ja das geht - größtenteils sogar pekuniär besser als mit ner Liebe zur eigenen Profession. Aber dieses einem jungen Interessenten für die Mikrocontrollertechnik als Lebensmaxime anzuraten, käme MIR nicht in den Sinn. W.S.
W.S. schrieb: > Kurzum, C ODER ASM ist überhaupt keine relevante Frage Doch, ist es. Auch im Embedded Bereich haben sich unterschiedliche Spezialisierungen gebildet. Da gibt es die Lowlevel-Spezialisten und dann die Applikationsleute. Aber auch bei hardwarenaher Treiberprogrammierung nimmt man kein ASM mehr. Nur bei den kleinen Krücken und wenn es sehr zeitkritisch wird, schaut man mal im ASM nach. Die Compiler optimieren so gut, dass man es oft nicht besser kann.
Meinst du mit µC von 0 auf komplett ohne Ahnung von SW und HW ? Dann ist es eigentlich keine Frage von asm oder C sondern welche Grundlagen lernt der Anfänger schneller? Wie eine CPU Befehle verarbeitet oder wie man eine Aufgabe in ein Programm umsetzt. Damit er dann auf dem µC irgendwas erreicht sollte er von beidem zumindest nen blassen Schimmer haben. Sonst wird er nen einfaches Programm was auf nem PC funktioniert nicht auf dem Controller zum laufen bringen oder mit den zur Verfügung stehenden asm Befehlen kein funktionierendes Programm zusammenbekommt.
C/ASM schrieb: > Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? Erst C lernen, dann mal kurz Assembler um grob zu verstehen was da vor sich geht und anschließend den µC in C programmieren.
Ohne jetzt alles gelesen zu haben würde ich sagen, dass es darauf ankommt was du mal machen willst. Willst du nur LEDs blinkeln lassen (oder sowas in der Richtung) dann nimm C. Wenn du RCHTIG verstehen willst was in dem Prozessor "ab geht", dann lern ASM
Daniel Münzi schrieb: > Wenn du RCHTIG verstehen willst was in dem Prozessor "ab geht", dann > lern ASM Blöööööödsinn, dann nimmt VHL oder Verilog!
ROFLMAO Eine Hochsprache ist eben "höher" als Assembler :-P Der Vorteil liegt auf der Hand ein Programm das in einer Hochsprache geschrieben wurde läßt sich schneller und einfacher an eine neue Umgebung anpassen als ein reines Assemblerprogramm.
dental schrieb: > Daniel Münzi schrieb: >> Wenn du RCHTIG verstehen willst was in dem Prozessor "ab geht", dann >> lern ASM > > Blöööööödsinn, dann nimmt VHL oder Verilog! Ach was, wenn man das wirklich verstehen will, dann holt man sich erstmal ein paar tausend Transistoren und fängt an Logik-Gatter zu stecken....
Hi C/ASM, C/ASM schrieb: > Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber > nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich > zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche > Meinungen ansehen... Zweifellos C. Und zwar aus vielen verschiedenen Gründen, deren wichtigster es ist, daß C recht schnell zu Erfolgserlebnissen verhilft. Daß wir überhaupt in diesem Zusammenhang über ASM sprechen, liegt daran, daß Mikrocontroller sehr begrenzte Ressourcen haben und die Programme, die auf einem uC laufen können, sehr klein sind. Deswegen sind Strukturierung, Les- und Wartbarkeit des Code nicht ganz so wichtig und die Produktivität des Entwicklers leidet nicht ganz so stark wie bei großen Systemen, wo aus genau diesen Gründen kein Mensch mehr über Assembler redet. Aber die Programmiersprachenkriege sind vorbei, und die Hochsprachen haben gewonnen. In Wirklichkeit haben die Skriptsprachen gewonnen, aber danach war hier ja nicht gefragt. Die Hochsprachen und mit einem Blick über den Tellerrand auch die Skriptsprachen haben gewonnen, weil sie produktiver sind, weil der Code besser strukturiert und dadurch besser les- und wartbar ist. Und dank immer besser optimierender Compiler ist der C-Code oftmals nicht einmal schlechter oder langsamer als der ASM-Code. Deswegen ist Assembler ein Relikt aus vergangenen Zeiten, das der Könner hin und wieder mal hervorholt, um spezielle Dinge damit zu tun. Das sind primär Funktionen, die ein genaues Timing benötigen, beispielsweise in der Signalverarbeitung oder bei Bussystemen wie Software-USB. Aber solche Dinge sind eher die Ausnahme, und das bisschen Assembler, das man dafür braucht, lernt ein guter C-Entwickler an einem Abend. Denn um ein guter C-Entwickler zu werden, muß man ohnehin ein ganz gutes Verständnis dafür entwickeln, wie die Hardware funktioniert. Insofern ist es gut, wenn man ein bisschen Assembler kann. Aber was man wirklich können muß und wo man spätestens dann, wenn man das beruflich machen will, nicht herum kommt, ist C. Und mehr Literatur, Beispielcode und Hilfe findet man für C im Zweifelsfall auch. HTH, Karl
Hallo Tom, Tom schrieb: > Mal in eigener Sache: > Da ich die Funktion der Hardware gut kenne, selber Elektroniker bin, ist > es dann notwendig, C zuerst auf dem Rechner zu lernen, oder kann es > gleich auf dem AVR/ARM los gehen? Das ist nicht notwendig, aber hilfreich. Oft ist es einfach hilfreich, ein Stückchen Code mal auf dem PC zu übersetzen und zu testen. HTH, Karl
Hallo,
bin selbst noch Programmieranfänger aber mit "viel" (nur hobbymäßigen)
Erfahrungen und auch einiges an Wissen in der Elektronik.
Assembler ist natürlicherweise ziemlich schwer zu durchschauen und
recht crytisch - aber wenn man das richtige Tutorial (wie z.B. hier das
vom µC.net) mit einen evtl. älteren dafür aber noch relativ einfach im
Detail durschaubaren ATmega 8 (oder ähnliches) durcharbeitet - lehrnt
man tatsächlich im Detail wie ein µC arbeitet und wie man wichtige
Informationen aus den Datenblättern herausholt - halt was so richtig auf
Hardwareebene passiert.
Nachdem mann dann die Grundlagen durchgearbeitet und auch verstanden
hat, ist es dann doch sinnvoll mit einer höheren Sprache (z.B. C) weiter
zu machen und diese auch richtig zu erlernen, also nicht nur die
Grundlagen sondern "alles" und mit dieser erlernten Sprache dann auch
später seine eigenen Projekte zu entwickeln.
Es ist aber auch wohl ein Frage was das Ziel ist:
Geht es nur darum ein Problem mit den µC zu lösen und man kann
Komponenten mit weitverbreitet Protokollen, Bussystemen usw. verwenden
sind Hochsprachen (ohne jedewelche ASM Kentnisse) vorteilhaft und
zielführend, als Extrem reicht sogar der Adruino mit seiner
Programmierumgebung aus (ich meine hier ausdrücklich den privaten Hobby
und Bastlerbeich )
Interessiert einen aber auch was im µC Hardwaretechnisch vorgeht, wie
Komponenten nur anhand von Datenblattinformationen und z.B.
Busprotokollen im Detail "verheiratet" werden so sind zumindest
Grundlagen in ASM und es auch mal, wenn auch nur Oberflächlich, gemacht
zu haben sehr erhellend und tragen dazu bei den (einfachen) µC in seinen
"Innersten" zu verstehen.
Ob der letzte Punkt für einen wichtig ist muß mann selbst entscheiden
(für mich gehört er auf jeden Fall dazu auch wenn mann es später direkt
wohl nur höhst selten in der Praxis noch benötigen wird).
mfg
Bastler
Ich bin auch interessiert kann mir jemand ein buch empfehlen für die Sprache c, wirklich von null ? Assembler ist nicht so meins hatte schon ein buch und bin nicht durchgestiegen , das war Assembler für Windows.
Selber schuld.. Wenn schon Assembler am PC dann low-level mit DOS ;-)
Hi Wieder mal ein kleiner Glaubenskrieg. Das aber geht nicht: Robocop schrieb: > Mein Argument ist sowieso, dass ein Einstig mit ASM Schwachsinn ist. Es ist kein Argument, sondern eine Meinung. Und genau so falsch wie du hier den Begriff anwendest ist auch die Aussage. Es gibt außer der professionellen Softwarebude die irgendwelche Programme für anwenderrelevante Hardware wie Rasierer, Zahnbürsten, Waschmaschinen usw. schreibt, noch Welten, da ist schon die Programmierung nahe an der Maschine. Ich denke da nur an S5 oder S7 Software, die in AWL programmiert ist. Natürlich gibt's mittlerweile auch grafische planbezogene Software, keine Frage und ich nehm die allemal lieber wie eine AWL. Aber manchmal geht's halt nicht anders und da bin ich froh, das ich in der Vergangenheit auch mal Spaß an Assembler hatte. Ich denke, Assembler oder C oder irgendwas als Programmiersprache zu benutzen ist eine Sache. Programmieren aber hängt in keiner Weise von der Sprache ab, sondern wie man in der Lage ist eine Aufgabe in ein Programm umzusetzen. Ein guter Programmierer würde niemals eine Sprache in eine Schublade mit der Aufschrift "Überflüssig" packen, sondern wenn er der Meinung ist, diese anwenden zu müssen, sich hinsetzt und diese lernt. @ASM/C Nun zu deiner Frage, was Experten raten... Tja, ich glaube auf keinen Fall "Lass die Finger von.." sondern die erste Aussage wäre die Gegenfrage: "Was hast du bereits gemacht, wo hast du Erfahrung?" Liegen Programmierkenntnisse vor und diese sind auch auf einen Controller anzuwenden, warum das nicht nutzen und wenn es BASCOM ist.Der Wunsch, C zu lernen um auch mal etwas anderes anzugehen oder einfach nur mitreden zu können, kommt sowieso irgendwann und wenn jemand auch mal einem Controller auf seine Innereien schauen will, wird er sich auch für Assembler interessieren. Was ich einem Anfänger raten würde, hmmmm, das steht auf einem anderen Blatt da ich mich nicht zu den "Experten" zähle. Gruß oldmax
tja wo ist denn der TO hin? schon lange nicht mehr da. Wenn du wirklich von 0 anfangen willst denn beschäftige dich mit der Architektur des entsprechenden µC z.B. hier auf der Seite oder bei Roboternetz oder gebe "Aufbau eines mikrocontrollers" mal in der Suchmaschine deiner Wahl ein und da hast du genügend Stoff zu durchwälzen unabhänging von der Sprache. Wer die Grundlagen nicht versteht wird, egal in welcher Porgrammiersprache, Probleme haben. http://www.avr-asm-tutorial.net/avr_de/beginner/asm_konzept.html (Im Sinne der Programmgestaltung) Dadurch das es für ASM nur geringe bis keine Bibliotheken gibt, um den Einstieg zu erleichtern, denken manche das es so richtig schwer ist!!! nein, dem ist nicht so. Das gleiche gilt für C nur mit dem Unterschied da haben sich Leute hingesetzt haben und so kleine Bibliotheken erstellten -> deshalb schneller im Aufbau eines Programmes. Und ein ganz wichtiger Punkt ist auch noch der Programmierstil, der absolut dizipliniert sein sollte... aber schau mal ins www....
oldmax schrieb: > Programmieren aber hängt in keiner Weise von > der Sprache ab, sondern wie man in der Lage ist eine Aufgabe in ein > Programm umzusetzen. Aus den Ausführungen ist das der einzige brauchbare Inhalt. Es gibt verschiedene Wege, sein entworfenes Programm nieder zu schreiben. Man kann Schablonen mit Blockschrift und Bleistift nutzen (ASM) oder am Rechner mit autovervollständigen arbeiten (Hochsprachen, C usw.). Bei der heutigen Qualität der Entwicklungstools ist ASM für den Normaluser obsolet. Mit ASM konzentriert man sich auf genau eine Architektur. Der Blick über den Tellerrand fällt dann schwer. Die Diskussionen laufen hier. Mit einer Hochsprache lerne ich das Programmieren HW unabhängig. => Empfehlung: C auf dem PC, C auf µC, ASM auf µC (wenn viel Zeit vorhanden)
chris schrieb: > Suchmaschine deiner Wahl ein und da hast du genügend Stoff zu > durchwälzen unabhänging von der Sprache. Wer die Grundlagen nicht > versteht wird, egal in welcher Porgrammiersprache, Probleme haben. > > http://www.avr-asm-tutorial.net/avr_de/beginner/asm_konzept.html Zitat: "Mit Assembler lernt der Programmierer die Hardware kennen, weil er ohne die Ersatzkrücke Compiler auskommen muss," Also für mich klingt das nicht sehr Objektiv. Ist so eine Einführung wirklich ernst zu nehmen? > (Im Sinne der Programmgestaltung) > Dadurch das es für ASM nur geringe bis keine Bibliotheken gibt, um den > Einstieg zu erleichtern, denken manche das es so richtig schwer ist!!! > nein, dem ist nicht so. Ja, und wo sind die Bibliotheken? Die Stärke von z.B. Arduino ist ja dass ein Anfänger mal eben ein paar Komponenten zusammenstöpseln kann und das Blinky dann vom Webbrowser gesteuert werden kann.
Hi, ich stand vor nicht allzu langer Zeit vor der gleichen Frage. Allerdings habe ich mich nach ein wenig "Hallo-Welt"-experimentieren mit ASM und C für Basic entschieden. Aus dem einfachen Grund, dass ich diese Sprache bereits kannte und mir das den Einstieg enorm erleichtert hat. Um speziell für "den Einsteiger" eine Empfehlung abgeben zu können müsste man seine Ziele kennen. Wenn er basteln will ohne das Rad neu zu erfinden sollte jede Hochsprache (C, Basic, Pascal, etc) für seine Zwecke geeignet sein. Und genau das würde ich ihm/ihr empfehlen. Gruß, Raphael
Tim schrieb > Ja, und wo sind die Bibliotheken? chris schrieb: >> Dadurch das es für ASM nur geringe bis keine Bibliotheken gibt, um den..
Offensichtlich haben hier bisher erst wenige Experten geantwortet. Unser Freund C/ASM (Gast) möchte ja offensichtlich zunächst die Funktionsweise eines Mikrocontrollers erlernen. Wie wär es zunächst mit einem passenden Buch zur Hardwarearchitektur bevor man sich mit einer entsprechenden Programmiersprache beschäftigt?
Joe G. schrieb: > Unser Freund C/ASM (Gast) möchte ja offensichtlich zunächst die > Funktionsweise eines Mikrocontrollers erlernen. Nein, das hat er nicht so geschrieben. Ganz im Gegenteil. Von daher wäre das: Joe G. schrieb: > Wie wär es zunächst mit > einem passenden Buch zur Hardwarearchitektur bevor man sich mit einer > entsprechenden Programmiersprache beschäftigt? nicht zielführend.
C/ASM schrieb: > Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? Ich gebe zu, ich habe den in Kiddybabysprache geschriebenen Satz folgendermaßen interpretiert. „Ich bin absoluter Anfänger. Ich möchte zunächst die Grundlagen der Mikrocontrollertechnik erlernen um dann die Mikrocontroller zu programmieren.“ Asche auf mein Haupt! Kiddysprache – schwere Sprache.
Die Entscheidung ist von vielem abhängig. Braucht man es beruflich oder Hobby? Beruflich: In jedem Fall C. Wenns Hobby ist dann hat man schon viel mehr Entscheidungsfreiheit. Möchte man nur Programmieren lernen dann ist auch eher C anzuraten. Hat man aber konkrete Projekte im Sinn und weiß genau was man will kann man sich auf einen bestimmten Controller beschränken und diesen genauer kennenlernen. Dann aber holt man mit Assembler das meiste heraus und hat alle Freiheiten der Welt. Dafür müssen aber gewisse Voraussetzungen gegeben sein. Soll es keine besonders datenintensive Anwendung werden (viele Programme aus dem Messen/Steuern/Regeln Bereich) ist ein typischer AVR- oder Pic Controller aus dem 8-Bit dafür das einfachste. Die sehr viel leistungsstärkeren aus der 32-Bit Welt mit ARM-Kern sind für sehr viel mehr Daten gedacht und C-optimiert, erfordern deutlich mehr Einarbeitungszeit (einmal die Datenblätter vergleichen!) und werden eher in der Industrie eingesetzt. Wenn man mit Assembler einsteigt muß man anfangs vieles von 0 auf Hundert selbst machen, auch wenn es hier im Forum ein gutes Tutorial und viel Beispielcode gibt. Zu lernen gibt es aber nur die Befehlscodes seines Wunschcontrollers (gut um die Hundert bei AVR)- und dessen Datenblatt sollte stets zum Nachschlagen bereitliegen. Seine Funktionen kann man aber genauso wie in C schön gliedern, dokumentieren und später bei Bedarf inkludieren. Was das Programme entwickeln mit Assembler angenehm macht: - Keine dicken C-Bücher wälzen mit ausufernder Syntax - kurze Anweisungen, keine komplexen Ausdrücke - kein Compiler verändert und verzögert den Code, der Controller tut GENAU DAS was man hinschreibt - das Wissen den besten (kürzesten/schnellsten) Code erstellen zu können ;) Was Assembler schwieriger macht: - von vorhandenem Beispielcode abgesehen, man muß ALLES selbst machen - insbesondere Berechnungen macht C viel einfacher - eine Funktion später noch zu verstehen, deshalb ist gute Doku wichtig Gleichzeitig Vor- wie Nachteil: Man kann die zahlreichen C-Libs nicht verwenden. Man spart sich aber auch - ggf. die für seinen Controller nötigen einzubinden - sie für die speziell gesuchte Funktion zu finden - ihre Dokumentation zu studieren - ihre Eigenheiten und möglicherweise enthaltene Fehler Über all diese Fragen toben im Forum viele Auseinandersetzungen weil jeder selbst und auch Hobby/Industrie eigene Bedürfnisse, Vorlieben, Notwendigkeiten haben. Man probiert am besten selbst was einem liegt. Mit Assembler erwirbt man aber in jedem Fall ein Wissensfundament, auf dem später Hochsprachen aller Art sehr stabil gebaut sind.
Vielleicht hättest du einfach nur mehr als den Eingangspost lesen sollen? C/ASM schrieb: > Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber > nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich > zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche > Meinungen ansehen... Zugegeben, das ist etwas schwerer als einfach nur unreflektiert seine Meinung herauszuposaunen.
Andreas schrieb: > mathe schrieb: >> ASM brauchst Du fast nie, das ist heutzugage nur noch für das >> theoretische Verständnis, sowie einige Sonderoptimierungen notwendig. > Unsinn. > Assembler braucht man ständig, weil man sonst weder kontrollieren kann, > ob der Hochsprachencode korrekt umgesetzt wurde, noch ob die Umsetzung > unnötig umständlich erfolgte und der Code dadurch deutlich zu langsam > und/oder zu lang ist. Wer den generierten Assemblercode nicht lesen > kann, hat keine Möglichkeit diese Probleme zu lösen und "unerklärliche" > Fehler zu finden. > > So ein Quatsch .. Compiler kontrollieren ... sorry ... Den Assemblecode muss man sich nur anschauen, wenn der Programmierer mal wieder mit 5 Seiten C-Code auf komplizierte Weise eine Konstante programmiert hat und sich wundert weil der Compiler das merkt und den ganzen Code richtiger Weise durch eine Konstante ersetzt. > C/ASM schrieb: >> Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? > Erst C/C++ lernen, am besten auf dem PC. Erst C++ lernen ? .. Da ist er aber ein weilchen beschäftigt ;) > Da lassen sich Programme leicht debuggen, so dass man schnell lernt was > man falsch gemacht hat. > Anschließend lernst Du, welche Besonderheiten man bei der Benutzung von > Hochsprachen auf µCs beachten muss. Gleichzeitig lernst Du Assembler, in > dem Du kleine C-Programme schreibst und den daraus generierten > Assemblercode studierst. Er soll also Assembler aus dem vom Compiler erzeugten Code lernen und damit hinterher den Compiler kontrollieren ?
Antimedial schrieb: > Zugegeben, das ist etwas schwerer als einfach nur unreflektiert seine > Meinung herauszuposaunen. Zugegeben, unreflektiert zu provozieren ist einfacher als mal die Threadüberschrift zu lesen und das Thema wirklich zu erfassen ;)
Ein MC Anfänger sollte erst einmal Datenblätter lesen lernen und sich mit den Komponenten, ihren Steuer-Registern und Bits beschäftigen. Denn wenn ein Ausgang falsch konfiguriert ist, bleibt eine LED in Assembler genauso dunkel wie in C.
Tim schrieb: > Ja, und wo sind die Bibliotheken? Die Stärke von z.B. Arduino ist ja > dass ein Anfänger mal eben ein paar Komponenten zusammenstöpseln kann > und das Blinky dann vom Webbrowser gesteuert werden kann. Und dann verwendet man um einzelne bits zu speichern gleich ein integer oder word, weil irgendwo hat man das ja mal gelesen. (In welchem zusammenhang es dann da stand, interessiert nicht, denn man versteht es ja nicht) Arduino ist zwar schön, für Leute die keine Ahnung haben und/oder zu faul sind, sich mit der Materie auseinander zu setzen. Der einstieg mit ASM schadet auf jedenfall nicht, denn man lernt auch schnell die limitierungen des controllers kennen. Wo man in C einfach mal ein double schreibt, muss man sich in ASM gedanken machen, wie man eine Kommazahl vernünftig darstellen kann (Festkomma). Die meisten AVRs sind für hobbypeojekte schon viel zu schnell, auch wenn man verschwenderisch mit den recourcen umgeht. Ein bischen verständniss von der Materie schadet mit sicherheit nicht. Deswegen mein fazit mit ASM in zumindest einen Controller einarbeiten, es muss nicht für jeden sein und somit wenigstens die inneren Abläuft verstehen und auch mal etwas mehr als nur blinklicht ein und ausschalten programmieren, auch mal schaun, wie das mit dem berechnen funktioniert. Erst wenn man versteht, wie es im Controller funktioniert, kann man ein gefühl dafür entwickeln, welcher Controller für welche Aufgabe notwendig ist. Nach einem schnelleren Prozessor wird immer schnell geschrieben, mit dem eigentlichen Problem beschäftigt sich niemand. Früher ist man mit der Rechenleistung eines heutigen Taschenrechners zum Mond geflogen, für das installieren von windows 7 wird eine 1Ghz CPU und 1GB RAM benötigt.
Moby schrieb: > Soll es keine > besonders datenintensive Anwendung werden ... Mensch Moby, reicht dir der andere Thread nicht? Musst du auch hier deine sehr eingeschränkte Kenntnis zur µC Technik zur Schau stellen? Bitte bleib beim Thread Thema und blamiere dich zur Bitbreite weiter im anderen Thread. Danke!
Moby schrieb: > Zugegeben, unreflektiert zu provozieren ist einfacher als mal die > Threadüberschrift zu lesen und das Thema wirklich zu erfassen ;) Du warst doch gar nicht angesprochen. Dass du Unsinn schreibst, ist ja schon hinlänglich bekannt, versuchst als Hobbyist, der mit ARM überfordert ist dir anzumaßen, dass du weißt, was für einen Profi am besten ist?
Antimedial schrieb: > für einen Profi Das ist doch sehr die Frage ;) Antimedial schrieb: > überfordert ist Womit Du wohl überfordert bist? In jedem Fall mit der Beratung von Einsteigern...
Robin schrieb: > Und dann verwendet man um einzelne bits zu speichern gleich ein integer > oder word, weil irgendwo hat man das ja mal gelesen. (In welchem > zusammenhang es dann da stand, interessiert nicht, denn man versteht es > ja nicht) Ja und? Wo ist das Problem?
C/ASM schrieb: > Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber > nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich > zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche > Meinungen ansehen... C/ASM schrieb: > Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich > mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe > meiner Ausbildung gelernt. Es ist geworden wie es ist. Bei Jedem eben anders. Wenn man Langeweile hat, kann man darüber nachsinnen, wenn man mal wieder auf die Welt kommt, ob man da C oder ASM zuerst lernt. Dabei ist doch der Vergleich nicht zulässig. ASM ist eine Maschinensprache. C ist eine Hochsprache die auf ASM aufbaut und es benutzt.
Moby schrieb: > Womit Du wohl überfordert bist? > In jedem Fall mit der Beratung von Einsteigern... Da sagen die Anfänger, die ich bisher beraten habe, etwas anderes. Die sind aber auch nicht so lernresistent wie du. Robin schrieb: > Wo man in C einfach mal ein double > schreibt, muss man sich in ASM gedanken machen, wie man eine Kommazahl > vernünftig darstellen kann (Festkomma). Stimmt so nicht, auch in C muss man Festkommarithmetik nutzen, wenn man keine FPU hat. Umgekehrt kann man auch Floating Point Operationen in Assembler durchführen, wenn man eine FPU zur Verfügung hat. Robin schrieb: > Die meisten AVRs sind für > hobbypeojekte schon viel zu schnell, auch wenn man verschwenderisch mit > den recourcen umgeht. Das kommt immer noch auf das Hobbyprojekt an. Sobald man eine schnelle SPI braucht, ist der AVR wegen seiner schwachen Peripherie völlig überfordert. Und auch eine 3-Phasen-PWM ist mit einem Atmega schon kein Spaß mehr.
Hi, also über manche Meinungen hier kann man einfach nur den Kopf schütteln. Entweder ist es den Schreibern entgangen das es um die (theoretische, da ein gewisser Wissensstand beim TO bereits erreicht) Frage geht was zum Erwerb eines fundierten Wissens sinnvoll ist und nicht um die Frage womit man heute kommerzielle Projekte fertigt, oder diese haben selber nur maximal ein Halbwissen und wollen es sich nur nicht eingestehen. Zuerst einmal: ASM sollte in aktuellen Projekten tatsächlich nur noch die absolute Ausnahme sein - das Mittel der Wahl ist heute einfach C. (Einige Meinungen sprechen mittlerweile sogar von C++) Damit ist klar das es für jemanden der von sich behaupten will solide Kenntnisse in der µC Programmierung zu besitzen vollumfassende C Kenntnisse absolut verpflichtend sind. Da gibt es kein Vertun! ABER: Zu den soliden Kenntnissen gehört auch das man weiß wie der µC das Programm tatsächlich umsetzt. Das muss nicht wirklich bis auf Gatterebene heruntergehen wenn man nicht auch sowieso in die allgemeine Elektronik einsteigen will, aber zumindest bis auf die Ebene wie ein µC Prinzipiell die Befehle verarbeitet, was ein Register und der Adressbus ist und wie der mit Zahlen die größer als die Bitbreite sind rechnet sollte vorhanden sein. Und dieses Wissen erlernt man am einfachsten beim Programmieren mit ASM. Daher: Will man wirklich ein solide fundiertes Wissen erwerben gehört auch ASM dazu. Und ich bin der Meinung das ASM Übungen VOR den ersten C Übungen AUF DEM µC die richtige Reihenfolge sind. Allerdings sollte man das heute auch nicht mehr übertreiben, viel mehr als ein paar HelloWelt Übungen müssen das zum Einstieg dann auch nicht sein. Danach kann man direkt mit C weitermachen. (Also Beispielsweise neben dem LED blinken mal eine Tastenabfrage, mal nen Timerinterrupt und ne AD Wandlung machen lassen, danach mit C weiter...) Es ist dabei heute auch absolut nicht mehr notwendig wirklich für jeden verwendeten µC ASM lernen. Hauptsache man hat das überhaupt mal für eine oder zwei Architekturen selbst gemacht. Weitergehende Kenntnisse können natürlich insbesondere beim Debugging nützlich sein, aber wenn man einmal ein oder zwei ASM Dialekte verstanden hat kann man sich das notwendige Wissen für eine konkrete Architektur, so es denn für eine besonders Zeitkritische Routine oder zur Fehlersuche notwendig sein sollte, notfalls auch schnell aneignen. Da es beim Lernen von C sehr Sinnvoll ist zumindest die allerersten Schritte auf den PC zu machen kann man beim Einstieg von Null die Beschäftigung mit ASM und C durchaus auch mal Parallel laufen lassen. C auf dem PC lernen und wenn man dann dort aus der allerschwierigsten Anfangsphase heraus ist und in die etwas einfachere Vertiefungsphase übergeht zur Abwechslung bereits das ein oder andere µC Projekt in ASM anpacken. ISt man dann der Meinung C grundsätzlich verstanden zu haben geht es dann mit C auf dem µC weiter. (ISt aber etwas Charakterabhängig, einige -wie ich- brauchen ab und zu etwas Abwechslung und kommen mit Parallelen Themen besser zurecht, für andere ist das strikte Nacheinander aber doch die bessere Wahl) Also: Es ist keine Frage ob ASM ODER C lernen, sondern nur eine Frage wie viel von jedem man lernen sollte. Und da gilt einfach: Etwas ASM hilft fürs Verständniss ungemein weiter und gehört deshalb unbedingt dazu, aber mehr als Grundlagenwissen ist dann in den meisten Fällen nicht mehr nötig weshalb der absolute Schwerpunkt einfach auf C liegen muss. (Für einen Hobbyisten der nur mal ein Projekt machen will mag es natürlich anders aussehen, aber hier war ja nach dem Weg zu SOLIDEN FACHKENNTNISSEN gefragt) Gruß Carsten
Moby schrieb: > Was das Programme entwickeln mit Assembler angenehm macht: > - Keine dicken C-Bücher wälzen mit ausufernder Syntax > - kurze Anweisungen, keine komplexen Ausdrücke Die Ansi-C "Syntax" passt auf eine Seite. Die Dokementation ist für die Libraries. Dass diese für Assembler nicht vorhanden sind, ist aber kein Vorteil. > - kein Compiler verändert und verzögert den Code, der Controller tut > GENAU DAS was man hinschreibt Das macht er mit jedem funktionierenden Compiler. > - das Wissen den besten (kürzesten/schnellsten) Code erstellen zu können > ;) Ganz ehrlich, die meisten Assemblerkünstler in diesem Board werden nicht den besten Code erstellen, wenn er überhaupt besser als das C-Compilat ist. Da habe ich schon viele Beispiele gesehen.
Antimedial schrieb: > Sobald man eine schnelle > SPI braucht Das sind doch Spezialfälle. Für Sensoren & Speicher ist AVR schnell genug. Antimedial schrieb: > 3-Phasen-PWM Welcher Hobbyist braucht das? Das sind Spezialfälle. PWM langt in der Regel. Tim schrieb: > Die Ansi-C "Syntax" passt auf eine Seite. Ach so. Der Rest in den dicken Büchern sind leere Seiten... Tim schrieb: > Ganz ehrlich, die meisten Assemblerkünstler in diesem Board werden nicht > den besten Code erstellen Das würde vorraussetzen Du kennst solchen Code. Schau mal in der Codesammlung. Da gibts schöne Beispiele! W.S. schrieb: > Kurzum, C ODER ASM ist überhaupt keine relevante Frage, allenfalls > müßte man sie mit einem großen UND beantworten. Also ich schreibe auch größere Programme rein in Asm und bin bestimmt nicht der Einzige. Das geht durchaus.
Antimedial schrieb: > Robin schrieb: >> Wo man in C einfach mal ein double >> schreibt, muss man sich in ASM gedanken machen, wie man eine Kommazahl >> vernünftig darstellen kann (Festkomma). > > Stimmt so nicht, auch in C muss man Festkommarithmetik nutzen, wenn man > keine FPU hat. Umgekehrt kann man auch Floating Point Operationen in > Assembler durchführen, wenn man eine FPU zur Verfügung hat. Sry, hätte schreiben sollen, das ich von keiner vorhanden FPU ausgegangen bin (AVR). Aber man muss nicht, man sollte und genau das versteht nicht umbedingt jeder, der vom PC mit c kommt und dann auf einem µC ohne FPU die selbe Leistung erhofft. > Robin schrieb: >> Die meisten AVRs sind für >> hobbypeojekte schon viel zu schnell, auch wenn man verschwenderisch mit >> den recourcen umgeht. > > Das kommt immer noch auf das Hobbyprojekt an. Sobald man eine schnelle > SPI braucht, ist der AVR wegen seiner schwachen Peripherie völlig > überfordert. Und auch eine 3-Phasen-PWM ist mit einem Atmega schon kein > Spaß mehr. Da hat sich wohl ein fehler eingeschlichen, sollte eigentlich "für die meisten hobbyprojekte sind die AVRs schon zu schnell" da stehen :D
Moby schrieb: > Das sind doch Spezialfälle. Für Sensoren & Speicher ist AVR schnell > genug. Für dich ist er vielleicht schnell genug, für andere eben nicht. Nicht wenige Bastler möchten eine SD-Karte anschließen und nicht dass nur ein paar kByte pro Sekunde über die Schnittstelle tröpfeln. Moby schrieb: > Welcher Hobbyist braucht das? > Das sind Spezialfälle. PWM langt in der Regel. Für BLDC braucht man das. Und das machen auch nicht so wenige Bastler. Nicht alles, was du nicht verstehst, sind Spezialfälle!
Moby schrieb: > Antimedial schrieb: >> Sobald man eine schnelle >> SPI braucht > > Das sind doch Spezialfälle. Nö, das ist heute ein Standard-Interface und wird intensiv genutzt. Moby schrieb: > Antimedial schrieb: >> 3-Phasen-PWM > > Welcher Hobbyist braucht das? RGB Ansteuerung ist gerade im Hobbybereich sehr beliebt. Moby schrieb: > Also ich schreibe auch größere Programme rein in Asm ... > ... Das geht durchaus. Na klar, ich kann auch die Geschäftsreise von Berlin nach München zu Fuß antreten. Das geht durchaus, aber ist das zeitgemäß? Schade, dass du den Thread kaperst. :-(((
Moby schrieb: > Tim schrieb: >> Die Ansi-C "Syntax" passt auf eine Seite. > > Ach so. Der Rest in den dicken Büchern sind leere Seiten... Die Erklärung dazu kam im Satz danach. Du willst wohl nur das sehen, was Dir in den Kram passt?
ASM oder C? Am besten ASM und C, zumindest den ASM seines µC etwas kennen. Es ist hin und wieder interessant, mal in die ASM-Listings eines C-Programmes hinein zu schauen, z.B. was der Stack bei Interrupts so macht. Bspw. 8051, wenn man schon eine Menge des internen RAM belegt hat, und der Stack noch mäßig Platz hat. Wenn ich am SDCC-Compiler nichts besonderes einstelle, z.B. Pragmas und Schlüsselworte, dann pusht der mir bei einem Interrupt mal eben blind 12 Bytes zusätzlich auf den Stack, was man in ASM ganz sicher nicht so machen würde. Noch schlimmer wird es bei geschachtelten Interrupts. Da wundert es dann, daß ein zeitkritischer Interrupt immer lahmer wird. Vor allem werden ja gepushte 12 Register am Ende auch wieder zurück gepopt, was dann insgesamt verlorene 48 Maschinenzyklen sind. Man wühlt sich dann durch das Compiler-Manual, und findet irgendwo ein Pragma "naked", womit man das erst wieder abstellen kann. Oder die Registerbankwahl, Speichermodell small oder large, wie verwende ich für ein Flag wirklich nur ein bit anstatt eines Bytes, Prolog/Epilog, und viele weitere solcher Spezialitäten. Auch kann es sein, daß man für ein Derivat eines µC (z.B. der 80C517A der 8051-er) mal die Compiler-Libraries anpassen muß, und das ist eben auch wieder ASM. SDCC hat z.B. den 80C517A nicht im Paket mit drinne, und behandelt diesen dann wie einen Standard-8051. Die Mathe-Libraries auf die MDU des 80C517A angepaßt, rechnet er bis zu hundert mal schneller. Oder die multiplen Datapointer für schnellere Speicheroperationen. Im Gegensatz zum SDCC hat Keil sowas fertig drinnen, kostet aber auch ordentlich Geld.
Moby schrieb: > Tim schrieb: >> Ganz ehrlich, die meisten Assemblerkünstler in diesem Board werden nicht >> den besten Code erstellen > > Das würde vorraussetzen Du kennst solchen Code. Schau mal in der > Codesammlung. Da gibts schöne Beispiele! Aha? Zahlen, Daten, Fakten, bitte. Ich erwarte ganz normale Applikationen. Spezialfälle kann ich mir selber heraussuchen (Bootloader, Devicetreiber).
Schiedsrichter schrieb: > dass du den Thread kaperst. Ja ist aber auch unangenehm wenn einer ständig gegen den Strich bürstet, was? @ Antimedial Dein Problem ist glaube ich daß Du überall einen Leistungsbedarf siehst den Millionen Anwendungen nicht erfordern, die selbst einen 8-Bitter nicht mal ansatzweise auslasten. Das sprengt Deine Vorstellungskraft leider ebenso wie die Tatsache, daß man in Asm was auf die Beine stellen kann. Wer aber ständig seine industrieelle Praxis in ein von Hobbyisten beherrschtes Forum projiziert muß sich über manche Reaktion nicht wundern. Antimedial schrieb: > Da sagen die Anfänger, die ich bisher beraten habe, etwas anderes Gibts da etwa eine Umfrage? Tim schrieb: > Bootloader, Devicetreiber ... ist nur der Anfang einer langen Liste. Die Arbeit mach Dir ruhig mal, auch wenns schwerfällt und nicht in Deinen Kram paßt :-)
Moby schrieb: > Dein Problem ist glaube ich daß Du überall einen Leistungsbedarf siehst > den Millionen Anwendungen nicht erfordern, die selbst einen 8-Bitter > nicht mal ansatzweise auslasten. Natürlich sehe ich die, und ich sehe auch, dass ARM auch in diesen Anwendungen besser und einfacher sind. Zusätzlich können sie ein größeres Spektrum abdecken, weil sie eben jene Anwendungen abdecken können, bei denen ein AVR schon längst nicht mehr ausreicht. Moby schrieb: > Das sprengt Deine Vorstellungskraft > leider ebenso wie die Tatsache, daß man in Asm was auf die Beine stellen > kann. Hier gilt das gleiche: Man kann, aber man ist damit wesentlich ineffizienter. Moby schrieb: > Gibts da etwa eine Umfrage? Wer lesen kann, ist klar im Vorteil. "Die Anfänger, die ich beraten habe" sind Menschen, die ich persönlich kenne, und ja, mit diesen Menschen rede ich tatsächlich.
Tim schrieb: > Ich erwarte Ich erwarte auch eine Menge... aber leider, meist muß man es sich dann doch selbst erarbeiten. So ein Mist.
Moby schrieb: > Tim schrieb: >> Ich erwarte > > Ich erwarte auch eine Menge... aber leider, meist muß man es sich dann > doch selbst erarbeiten. So ein Mist. Troll. Fakt ist: Du willst und kannst keine Beispiele nennen.
:
Bearbeitet durch User
Antimedial schrieb: > Wer lesen kann, ist klar im Vorteil. "Die Anfänger, die ich beraten > habe" sind Menschen, die ich persönlich kenne, Ach so. Das eine folgt bei Dir logisch aus dem anderen. Wie bei so vielen Dingen. Es ist mühsam mit Dir. Und ich kann verstehen wenn Du andere schnell als lernresistent bezeichnest wenn sie nicht folgsam sind. Antimedial schrieb: > dass ARM auch in diesen > Anwendungen besser und einfacher sind Amen. Oder wie man in der Mathematik sagt: w.z.b.w.
Tim schrieb: > Troll. Fakt ist: Du willst und kannst keine Beispiele nennen. Troll. Fakt ist: Du bist zu faul Dir die zu suchen.
Wilhelm F. schrieb: > den 80C517A nicht im Paket mit drinne Dein schönes Beispiel zeigt, dass man mit ASM stehen bleibt. Bei Infineon findet man zum 80C517A folgendes: Unfortunately, there are no corresponding matches. Please refine your search. Der µC wurde nicht nur abgekündigt, sondern gleich aus dem "Gedächtnis" gestrichen. ASM dient dir, um uralten Schrott zu erlernen. Das möchtest du keinem Anfänger anraten, oder? Für die aktuellen Bausteine bietet Infineon ein grafisches Tool zu Konfiguration. Die Ausgabe ist C Code zur direkten Verwendung.
Moby schrieb: > Ja ist aber auch unangenehm wenn einer ständig gegen den Strich bürstet, > was? Das wäre kein Problem, aber den Einen gibt es hier nicht. Du kannst nur nicht aus deinem ATiny Gehäuse hinaus. Dir fehlt es Know How und Wissen anderer µC, um eine Bewertung abzugeben. Meine Bitte aber war, deinen µC Krieg im anderen Thread weiter auszufechten. Du machst den Thread hier kaputt. Nein, du hast ihn bereits kaputt gemacht. Schade!
Schiedsrichter schrieb: > Du kannst nur > nicht aus deinem ATiny Gehäuse hinaus. Ein guter Schiedsrichter sollte nicht mit vorgefaßten Meinungen auf den Platz kommen. Ich habe mich klar zum Thema geäußert. Ansonsten reagiere ich- das aber sehr gerne. Das mußt Du leider ebenso akzeptieren wie ich Deine Meinung.
today schrieb: > Für die aktuellen Bausteine bietet Infineon ein grafisches Tool zu > Konfiguration. Die Ausgabe ist C Code zur direkten Verwendung. Das allerdings sehe ich auch als Fortschritt. Wenn schon die Controller komplexer werden dann wenigstens die grafische Bändigung ihrer Konfigurationsvielfalt!
Leute! ihr seid hier im falschen Fred. Der Kampf geht doch im anderen Thread. :-))
Moby schrieb: > Wenn schon die Controller > komplexer werden dann wenigstens die grafische Bändigung ihrer > Konfigurationsvielfalt Das gilt für die 8-Bit XC800 mit 8051 Kern. Moby schrieb: > Ein guter Schiedsrichter sollte nicht mit vorgefaßten Meinungen auf den > Platz kommen. Aber er erkennt das Foulspiel! Moby schrieb: > Ich habe mich klar zum Thema geäußert. Aber im falschen Thread. Bitte kämpfe im anderen Thread weiter um die Bits. Hier geht es um ASM oder C für den Einsteiger mit Null Ahnung.
Schiedsrichter schrieb: > Das gilt für die 8-Bit XC800 mit 8051 Kern. spricht auch nichts dagegen. Hoffentlich macht das Schule. Schiedsrichter schrieb: > Aber er erkennt das Foulspiel! ... oder auch nicht! Schiedsrichter schrieb: > Aber im falschen Thread. nein im richtigen. Schiedsrichter schrieb: > Bitte kämpfe soweit muß man das doch nicht hochstilisieren!
Moby schrieb: > - Keine dicken C-Bücher wälzen mit ausufernder Syntax Das hast du dir ausgedacht. "Programmieren in C": insgesamt 262 Seiten (C Teil + Unix Einführung + C-Sprachbeschreibung). Essentieller C Teil: 143 Seiten "C Programmieren von Anfang an": insgesamt 311 Seiten (C Teil + OS spezifisches Zeug + weiterführende Techniken + kleiner C++ Schnupperkurs + C-Referenz). Essentieller C Teil: ~140 Seiten Das sind beides Taschenbücher. "Assembler Programmierung" unter MS-DOS etwa 150 Seiten. Da tut sich nicht wirklich viel. Moby schrieb: > - kurze Anweisungen, keine komplexen Ausdrücke Wenn du unbedingt auf komplexe Ausdrücke verzichten willst, kannst du das doch auch in C. Niemand zwingt dich in C deine Formeln oder Ausdrücke komplett in eine Zeile zu quetschen ;). In ASM hast du keine Wahl.
Moby schrieb: > Amen. Oder wie man in der Mathematik sagt: w.z.b.w. Beispiele habe ich - in Gegensatz zu dir - schon genug genannt (schnellerer Kern, DMA vs. fehlende Puffer im SPI, Floating-Point-Einheit, Totzeiterzeugung bei einer PWM). Und dass Preis und eine einheitliche Toolchain eine Rolle spielen (wo wir auch wieder bei einem Argument für Hochsprachen wären). Aber da kommst du immer mit Ausflüchten ("aber... aber... das sind doch Spezialanwendungen?!). Übrigens sollte dir auffallen, dass einige Beispiele recht wenig mit dem Kern zu tun haben.
TriHexagon schrieb: > Das sind beides Taschenbücher Ok ich nehme "dick" zurück. War ein Blick ins Bücherregal und da stehen zwei Wälzer >1000 Seiten, aber über C++ ;) Soll ja Leute geben die das auch für die kleinen Controller empfehlen. Immerhin, selbst 140,150 Seiten sind nicht 1 Blatt und viel mehr als die kurze Liste der ASM-Befehle. TriHexagon schrieb: > "Assembler Programmierung" unter MS-DOS etwa 150 Seiten. Wir sind hier aber nicht bei MS-DOS sondern bei den Controllern. Da langt die Befehlsbeschreibung. TriHexagon schrieb: > Wenn du unbedingt auf komplexe Ausdrücke verzichten willst, kannst du > das doch auch in C. Niemand zwingt dich in C deine Formeln oder > Ausdrücke komplett in eine Zeile zu quetschen ;) Aber was für ein Schreibaufwand! Weswegen Formeln und Ausdrücke ja auch nicht weniger komplex sind bzw. werden können. TriHexagon schrieb: > In ASM hast du keine > Wahl. In ASM ist zumindest jede Zeile seeehr kurz, klar, verständlich. Ich wollte C jetzt nicht unbedingt verteufelt wissen.
Was ist denn an c schwer?! :-)) Ich habe die Firmware meines kompletten Quadrokopters in c geschrieben. Was habe ich hauptsächlich benötigt? - If-Abfragen - For-Schleifen - While-Schleifen - Case-Abfragen - Funktionen - Variablen Deklarationen/ Initialisierungen - Zeiger Das war alles! Eine Handvoll total simpler Konzepte. Das versteht doch selbst ein Schüler! Also entweder bin ich besonders begabt (sicher nicht!) oder c ist wirklich so einfach zu verstehen. Ich tippe mal schwer auf Letzteres. :-))
Achso Nachtrag: Als ich damals Assembler in der Schule hatte fand ich das extrem schwer zu verstehen oder umzusetzen. In c hingegen steht ja praktisch alles in Klartext da! Das können selbst Kinder oder Jugendliche lernen. Ohne Probleme!
Hier ist eine Ansi-C Referenz auf zwei Seiten: http://users.ece.utexas.edu/~adnan/c-refcard.pdf Zur Sprache selbst ist die erste Seite ausreichend. Die zweite Seite beschreibt bereits die Funktionen der Stdlib.
Kleiner C-Schlupf schrieb: > c ist wirklich so einfach zu verstehen Hat doch auch keiner bestritten. Klar geht das, solange der C-Code noch in den Speicher paßt ;) Arduino ist noch einfacher. Und doch bietet auch Asm Vorteile, so daß die tausendfach gestellte Ausgangsfrage C oder Asm wohl auch die nächsten Jahre ihre Berechtigung hat.
Mach zum Einstieg den Video-Kurs bei ET-Tutorials: http://ET-Tutorials.de/Mikrocontroller Dann hast Du einen ersten Überblick und kannst dann mit den ganzen Antworten hier mehr anfangen.
Ich verstehe ja den Spaß an C. Aber angenommen, ich habe jetzt einen winzigen PIC mit nur 512 Byte Codespeicher, und der wird mir von der Geschäftsleitung vor gesetzt, mit dem Argument, der Code muß da hinein, egal wie, und das geht auch. Das habe ich mal spaßeshalber als Hobbyist getestet, und völlig gleiche Programme einmal in ASM und parallel dazu in C gemacht. Ja, und der C-Output paßt dann leider nicht mehr immer so ins Flash, wo aber der ASM-Output noch locker paßt. Das kann bei Millionenstückzahlen mal ein paar Cent ausmachen, weil man den einen Cent billigeren µC wählen kann. Selbst wenn sich da ein Entwickler mal zwei Stunden länger mit ASM quält, als es in C wäre.
Wilhelm F. schrieb: > Ich verstehe ja den Spaß an C. > > Aber angenommen, ich habe jetzt einen winzigen PIC mit nur 512 Byte > Codespeicher, und der wird mir von der Geschäftsleitung vor gesetzt, mit > dem Argument, der Code muß da hinein, egal wie, und das geht auch. Und was machst Du bei folgenden Vorgaben, welche in einem realistischen Projekt viel wahrscheinlicher sind? - Du sollst schnell fertig werden, denn die HEK spielen bei dem Projekt nur eine untergeordnete Rolle. - Keine Fehler machen. - Dein Kollege soll den Code in drei Jahren auch noch verstehen. - Man möchte sich offen halten, später einen Mikrocontroller von einem anderen Hersteller einzusetzen.
:
Bearbeitet durch User
Tim schrieb: > Die zweite Seite > beschreibt bereits die Funktionen der Stdlib. Na ohne die gehts aber auch nicht in C... Die lange Sucherei nach Bibliotheksfunktionen ist überhaupt etwas was mich persönlich von C abhält. Zum Beispiel in Atmels ASF. Dann programmier ich lieber selber und hab paßgenau was ich will.
Moby schrieb: > Klar geht das, solange der C-Code noch > in den Speicher paßt Wilhelm F. schrieb: > völlig gleiche > Programme einmal in ASM und parallel dazu in C gemacht Ich behaupte ganz frech, dass ein aktueller optimierender Compiler (natürlich den richtigen Schalter gesetzt) besseren Code erzeugt, als eure Bastlerhände. Das gilt für Codesize oder Speed.
Moby schrieb: > Na ohne die gehts aber auch nicht in C... > Die lange Sucherei nach Bibliotheksfunktionen ist überhaupt etwas was > mich persönlich von C abhält. Natürlich geht es ohne Bibliothek. Mit ist es effizienter. Du kannst aber auch in C das Rad immer wieder neu erfinden. In ASM muss ich den vollständigen Befehlssatz lernen, ich muss den Stack verwalten, Register retten, ... Diese langweilige Fleißarbeit lasse ich lieber den Compiler erledigen. Aber ihr programmiert ja noch den 517A. Wisst ihr, dass es schon Farbfernseher gibt? ;-)))
Wettbüro schrieb: > Ich behaupte ganz frech, dass ein aktueller optimierender Compiler > (natürlich den richtigen Schalter gesetzt) besseren Code erzeugt, als > eure Bastlerhände. Das gilt für Codesize oder Speed. Ja, sicher. Das steht auch immer am Compileroutput dran: Die Kaufversion würde ihren Code noch um xx% reduzieren. Aber wir sind ja im Hobby, mit kleinem Budget.
Antimedial schrieb: > Beispiele habe ich - in Gegensatz zu dir - schon genug genannt > (schnellerer Kern, DMA vs. fehlende Puffer im SPI, > Floating-Point-Einheit, Totzeiterzeugung bei einer PWM) Beispiele die vielleicht den Einsatz von Cortex-Mx rechtfertigen. Ja, und? Das ist ein Bruchteil der realen Anwendungen. Antimedial schrieb: > Und dass Preis > und eine einheitliche Toolchain eine Rolle spielen (wo wir auch wieder > bei einem Argument für Hochsprachen wären). Ja, in der Industrie vielleicht. Und dort sicher auch längst nicht überall sondern nur dort, wo entsprechend Produkte verschiedener Leistungsklassen gemeinsam in der Pipeline sind. Oder wo Normen, Security oder was weiß ich einzuhalten ist.
Wilhelm F. schrieb: > Die Kaufversion > würde ihren Code noch um xx% reduzieren. Steht wo? http://www.keil.com/demo/limits.asp
Limburg schrieb: > Diese langweilige Fleißarbeit Gibt es. Programmiert man. Setzt man immer wieder ein. Limburg schrieb: > In ASM muss ich den vollständigen Befehlssatz lernen Das sind z.B. beim Mega168 131 Instruktionen. Ja, die lernt man. Aber nur die. Limburg schrieb: > ich muss den Stack > verwalten Mußt Du gar nicht. Sogar der Stackpointer ist oft nicht mehr zu initialisieren. Limburg schrieb: > Register retten, Dazu macht man sich ein grundlegendes System welche Register man wofür nutzt und sichert dann via Makro. Ein AVR hat genügend!
Ich habe zuerst ASM auf dem PIC16F84 gelernt, neben rudimentären C-Kenntnissen. Der Effekt war, dass ich dank diesen ASM-Vorkenntissen das C-Verständnis während der Übungen an der Uni enorm vertieft habe und meiner Meinung nach die Materie viel besser verstanden habe als die Kollegen "Uni-Abstraktionskünstler". Als ASM-Könner programmiert man anders - man programmiert weniger "verschwenderisch", man kann auch Dinge optimieren, die der Compiler übersieht (und das ist mir mit Keil C schonmal passiert). Merkt ihr nicht, dass heutzutage sehr viel schlechter Code produziert wird? Geräte brauchen Ewigkeiten zum Booten, UIs reagieren ohne Grund erst mit Verzögerungen im Sekundenbereich (da zig Ebenen Frameworks dazwischen sind), ... Mein Argument ist: C ist viel flexibler als ASM. Bei ASM muss schon vor der Entwicklung die Architektur des Programms weitgehend fixiert sein, spätere Ändernungen sind schwierig. Man kann problemlos, wenn ein Programm in C fertig entwickelt ist und man es optimieren will Teile davon in ASM neu machen. Ich verwende mittlerweile C für alle Projekte, welche Berechnungen, Strings, LCDs oder komplexeres wie SD-Karten ... verwenden. Bei Video-Sachen teilweise mit Inline-ASM-Routinen. Reines ASM verwende ich gerne auf 8-Beinern (PIC12F) für simple Steueraufgaben bzw. Bitschubsen da das wesentlich einfacher mit ASM geht. Bei Code < 1-2K macht ASM für mich auch heute noch Sinn.
Meine Empfehlung: Lerne ASM und probiere Programme bis hin zur Ansteuerung eines HD44780-LCDs zu entwickeln. Danach solltest du keine Probleme mehr mit dem Verständnis von Pointern haben, da du dir unter einer Adresse was ganz konkretes vorstellen kannst - einem der Hauptprobleme von C-Anfängern.
Moby schrieb: > Das sind z.B. beim Mega168 131 Instruktionen Beim ATiny123 ..., beim ATiny456 ..., beim ATMEGA789 ..., beim MEGA32 ..., beim Xmega .... Bei jedem Baustein eine neue Sprache ;-( Moby schrieb: > Dazu macht man sich ein grundlegendes System welche Register man wofür > nutzt und sichert dann via Makro. Ein AVR hat genügend! Eine Bibliothek? ;-) Das Rad neu erfinden also. ;-) Im AVR sind Makros (eine Bibliothek) entahlten? ;-) Du bringst gerade nur Argumente für eine Hochsprache an.
Wettbüro schrieb: > Wilhelm F. schrieb: >> Die Kaufversion >> würde ihren Code noch um xx% reduzieren. > > Steht wo? > http://www.keil.com/demo/limits.asp Nix mit Keil. PIC und MPLAB und den eingebundenen Freeware-Compiler. Die Meldung erscheint nach jedem Compiliervorgang dort im Ausgabefenster. Aber die Demo-Versionen von Keil für 8051 kannste auch vergessen, Codelimitierung 2kB.
Wilhelm F. schrieb: > ich habe jetzt einen winzigen PIC mit nur 512 Byte > Codespeicher, und der wird mir von der Geschäftsleitung vor gesetzt, mit > dem Argument, der Code muß da hinein Deshalb muß bei C-Verwendung der Chip meist auch eine Nummer größer kalkuliert werden ;)
Limburg schrieb: > Bei jedem Baustein eine neue Sprache Quatsch. Der Instruktionssatz bleibt derselbe. Erweitert sich höchstens noch etwas. Schauen muß man auf die verfügbare Peripherie. Limburg schrieb: > Eine Bibliothek? ;-) Das Rad neu erfinden also. ;-) > Im AVR sind Makros (eine Bibliothek) entahlten? ;-) Nix Bibliothek. Ein Makro definiert man sich aus mehreren Instruktionen.
Moby schrieb: > Deshalb muß bei C-Verwendung der Chip meist auch eine Nummer größer > kalkuliert werden ;) Wilhelm F. schrieb: > PIC und MPLAB Foul! Da muss ich nach dem Schiedsrichter rufen.
Moby schrieb: > Der Instruktionssatz bleibt derselbe. Erweitert sich höchstens > noch etwas. Also doch, bei jedem Baustein ... Moby schrieb: > Nix Bibliothek. Ein Makro definiert man sich aus mehreren Instruktionen. Und mehrere Makros bilden eine Bibliothek ... Du wirst noch zum Hochsprachenfan.
Moby schrieb: > Beispiele die vielleicht den Einsatz von Cortex-Mx rechtfertigen. Ja, > und? > Das ist ein Bruchteil der realen Anwendungen. Du kennst doch gar keine realen Anwendungen. Das letzte Mal hast du irgendwas von Ampelsteuerungen gefaselt (die allein wegen den Sicherheitsanforderungen auf großen Prozessoren umgesetzt wird). Moby schrieb: > Ja, in der Industrie vielleicht. Und dort sicher auch längst nicht > überall sondern nur dort, wo entsprechend Produkte verschiedener > Leistungsklassen gemeinsam in der Pipeline sind. Oder wo Normen, > Security oder was weiß ich einzuhalten ist. Ja, und wo glaubst du, werden die meisten Anwendungen realisiert? Sicher nicht im Bastlerbereich. Moby schrieb: > Deshalb muß bei C-Verwendung der Chip meist auch eine Nummer größer > kalkuliert werden ;) Unsinn. Ich habe schon die ein oder andere Anwendung mit einem Attiny10 umgesetzt. Selbstverständlich in C.
Antimedial schrieb: > Unsinn. Ich habe schon die ein oder andere Anwendung mit einem Attiny10 > umgesetzt. Selbstverständlich in C. Das ist tatsächlich einer der wenigen Fälle, wo man den Assembleroutput wirklich gut im Auge behalten sollte. Der tinyavr-Support von AVR-GCC ist noch ziemlich buggy.
Limburg schrieb: > Also doch, bei jedem Baustein ... Schon mal mit den AVRs Kontakt gehabt? Der Befehlssatz ist einheitlich. Der letzte Schrei von Xmega hat nur sehr wenige Instruktionen mehr (z.B. für Verschlüsselung) Limburg schrieb: > Du wirst noch zum Hochsprachenfan. Hast mich fast soweit... Aber dazu langt die Zahl meiner Makros noch nicht ;)
Moby schrieb: > Deshalb muß bei C-Verwendung der Chip meist auch eine Nummer größer > kalkuliert werden ;) Das ist es ja, was sich im Profibereich mit hohen Stückzahlen in ASM programmiert dann eben wieder rechnet, und wenn der kleinere µC nur einen einzigen Cent billiger ist. 100 Stück sind nur ein Euro, aber 100.000 Stück wiederum 1000 Euro, was zwei Tage des Entwicklers locker deckt. Ein Prof. aus dem Automotive-Bereich erklärte uns mal, daß er einen Fall erlebte, wo ein Entwickler ein ganzes Jahr lang nur einen Kondensator optimieren mußte, und die Einkaufspreise stark im Auge behalten mußte. Das hätte sich trotz seines Gehaltes für Stückzahlen z.B. ein paar Millionen gut gerechnet. Ääh, ja, und die PIC 10Fxxx gibt es nach wie vor.
Also entweder Antimedial schrieb: > Moby schrieb: >> Beispiele die vielleicht den Einsatz von Cortex-Mx rechtfertigen. Ja, >> und? >> Das ist ein Bruchteil der realen Anwendungen. > > Du kennst doch gar keine realen Anwendungen. Das letzte Mal hast du > irgendwas von Ampelsteuerungen gefaselt (die allein wegen den > Sicherheitsanforderungen auf großen Prozessoren umgesetzt wird). unterstellst Du mir was und bestreitest, daß 8-Bitter in der Industrie nach wie vor und nicht ohne Grund eine bedeutende Rolle spielen, > Moby schrieb: >> Ja, in der Industrie vielleicht. Und dort sicher auch längst nicht >> überall sondern nur dort, wo entsprechend Produkte verschiedener >> Leistungsklassen gemeinsam in der Pipeline sind. Oder wo Normen, >> Security oder was weiß ich einzuhalten ist. > > Ja, und wo glaubst du, werden die meisten Anwendungen realisiert? Sicher > nicht im Bastlerbereich. liest nicht richtig, > > Moby schrieb: >> Deshalb muß bei C-Verwendung der Chip meist auch eine Nummer größer >> kalkuliert werden ;) > > Unsinn. Ich habe schon die ein oder andere Anwendung mit einem Attiny10 > umgesetzt. Selbstverständlich in C. oder verstehst ein bischen Satire nicht. Obwohl, das hätte ja sogar einen gewissen Hintergrund da C doch etwas mehr Speicher braucht.
Moby schrieb: > unterstellst Du mir was und bestreitest, daß 8-Bitter in der Industrie > nach wie vor und nicht ohne Grund eine bedeutende Rolle spielen, Der einzige Grund ist, dass bis vor zwei Jahren 8-Bitter noch unschlagbar günstig waren. Das hat sich aber schlagartig geändert. Moby schrieb: > liest nicht richtig, Du hast von Bereichen geschrieben, die keinen Normen unterliegen. Nur sind das eben alle Anwendungen, außer Bastler und Studenten. Moby schrieb: > oder verstehst ein bischen Satire nicht. Obwohl, das hätte ja sogar > einen gewissen Hintergrund da C doch etwas mehr Speicher braucht. Nicht wirklich.
Antimedial schrieb: > Du hast von Bereichen geschrieben, ... wo entsprechend Produkte verschiedener Leistungsklassen gemeinsam in der Pipeline sind. Die gemeinsame Toolchain als Argument, 8-Bitter mit Deinem großen Favoriten Cortex-M0 zu ersetzen. Was die Ampelsteuerung anbetrifft- warum sollte das ein 8-Bitter nicht sicher bewältigen?
Moby schrieb: > ... wo entsprechend Produkte verschiedener Leistungsklassen gemeinsam in > der Pipeline sind. Die gemeinsame Toolchain als Argument, 8-Bitter mit > Deinem großen Favoriten Cortex-M0 zu ersetzen. Und das sind fast alle professionelle Anwendungen. Die Hauptargumente bleiben aber der Preis, der bei modernen 32-Bittern geringer ist und die deutlich geringere Softwarekomplexität durch den geschickten Einsatz von mächtigen Peripheriekomponenten. Allein eine Halbbrücken-PWM ist bei einem alten Atmega schon unheimlich umständlich. Moby schrieb: > Was die Ampelsteuerung anbetrifft- warum sollte das ein 8-Bitter nicht > sicher bewältigen? Es geht schon, und wurde sicher auch gemacht, aber würde heute bei einer Neuentwicklung keiner mehr machen, weil man eine ganze Menge von Überwachungs- und Diagnosefunktionen benötigt und der Preis des Controllers gegenüber dem Zertifizierungsaufwand untergeht.
Tim schrieb: > Das ist tatsächlich einer der wenigen Fälle, wo man den Assembleroutput > wirklich gut im Auge behalten sollte. Der tinyavr-Support von AVR-GCC > ist noch ziemlich buggy. Ziemlich buggy, wenig buggy, ohne Compiler: gar nicht buggy ;)
Limburg schrieb: > Moby schrieb: >> Der Instruktionssatz bleibt derselbe. Erweitert sich höchstens >> noch etwas. > > Also doch, bei jedem Baustein ... > > Moby schrieb: >> Nix Bibliothek. Ein Makro definiert man sich aus mehreren Instruktionen. > > Und mehrere Makros bilden eine Bibliothek ... > > Du wirst noch zum Hochsprachenfan. Du hast noch nie was mit ASM zu tun gehabt, aber bildest dir schon von vorn herein eine Meinung darüber. Was im µC letztendlich passiert ist dir dann letztendlich auch egal, hauptsache es kommt was raus. Und wenn dann mal das programm zu langsam ist, ist dein Controller schuld und es muss ein schnellerer her. Antimedial schrieb: > Moby schrieb: >> unterstellst Du mir was und bestreitest, daß 8-Bitter in der Industrie >> nach wie vor und nicht ohne Grund eine bedeutende Rolle spielen, > > Der einzige Grund ist, dass bis vor zwei Jahren 8-Bitter noch > unschlagbar günstig waren. Das hat sich aber schlagartig geändert. Und weil man jetzt auf einmal 32 Bit hat, fangen die ersten schon an, mit Java und C++ zu programmieren, weil es ja soooo viel besser ist und recourcen sind ja genug vorhanden.
Nun will ich mal meinen Senf dazugeben. Ich bin absoluter Anfänger in Sachen µC... Meine Ausgangssituation: - Basiswissen Elektronik - PC-Programmierung in den "Idiotensprachen" Basic, Pascal und Java einigermassen ok - Grundkenntnisse in PC-Programmierung in C und C++ Meine Herangehensweise: - analoge Elektronik vertiefen - digitale Elektronik erlernen (also basteln mit TTL und 4000er CMOS) - Arduino fürs schnelle Erfolgserlebnis - Assembler und C mehr oder weniger parallel und damit die µC-Programmierung "erforschen" Ich fahr bis jetzt ganz gut damit. Zur Betonung (wie schon öfter in anderen Threads): Es geht mir nicht darum bestimmte Projekte umzusetzten, sondern ums Lernen an sich. Ich seh mich als Hobby-Bastler, d.h. auch dementsprechend wenig Zeit steht dafür zur Verfügung. Meine Meinung zur Frage des TO: Die Frage ob Assembler ODER C stellt sich nicht. Mit Assembler bekommt man halt Einblick was im "Innersten" passiert - mit C kommt man schneller zum gewünschten Ergebnis. Ich behaupte nicht, dass ich richtig liege (sofern das überhaupt möglich ist). Das ist mein Weg und für mich ist der ok.
Robin schrieb: > Du hast noch nie was mit ASM zu tun gehabt Wie stützt du deine Behauptung? Woher willst du das wissen? Ich kenne ASM von verschiedenen Plattformen. Heute nutze ich ASM aber so gut wie gar nicht mehr. Robin schrieb: > Was im µC letztendlich passiert ist > dir dann letztendlich auch egal Wenn er fehlerfrei läuft und der Code verifiziert wurde: Ja! Auf der Bugsuche: Nein! Robin schrieb: > C++ zu programmieren Kennst du C++?
Antimedial schrieb: > Die Hauptargumente > bleiben aber der Preis Wie sagte mal einer treffend im "anderen" Thread: Der Preis geht im Rauschen unter. Siehe auch unten Antimedial schrieb: > deutlich geringere Softwarekomplexität Frage aus der aktuellen "Elektronik" Mikrocontroller-Studie: "Durch welche Maßnahmen wollen Sie der immer größeren Software-Komplexität Herr werden?" Von höchstens noch Herr werden ist heutzutage die Rede. Bin schon gespannt auf das Ergebnis der Umfrage, weil es da auch um den beabsichtigten Umstieg auf 32 Bit bei den Firmen geht. Antimedial schrieb: > Es geht schon, und wurde sicher auch gemacht, aber würde heute bei einer > Neuentwicklung keiner mehr machen, weil man eine ganze Menge von > Überwachungs- und Diagnosefunktionen benötigt und der Preis des > Controllers gegenüber dem Zertifizierungsaufwand untergeht. Erschreckend, wenns so wäre. Aber im Namen der Sicherheit ist offensichtlich alles zu rechtfertigen.
Moby schrieb: > Wie sagte mal einer treffend im "anderen" Thread: Der Preis geht im > Rauschen unter. Siehe auch unten Wenn ich für 50ct eine Funktionalität umsetze, für die ich vor 5 Jahren noch 2 Euro ausgegeben habe, trifft das nicht mehr zu. Moby schrieb: > Frage aus der aktuellen "Elektronik" Mikrocontroller-Studie: "Durch > welche Maßnahmen wollen Sie der immer größeren Software-Komplexität Herr > werden?" Und eine gute Antwort ist: Der Einsatz von 32-Bit-uC mit mächtigerer Peripherie. Genauso wie der Einsatz von Hochsprachen mit portierbaren Standardbibliotheken. Moby schrieb: > Erschreckend, wenns so wäre. Aber im Namen der Sicherheit ist > offensichtlich alles zu rechtfertigen. Das ist nicht erschreckend, sondern höchst erfreulich, wenn man in der Lage ist, professionell mit dem Stand der Technik zu arbeiten, um seine Sicherheitsanforderungen zu erfüllen.
Robin schrieb: > Und weil man jetzt auf einmal 32 Bit hat, fangen die ersten schon an, > mit Java und C++ zu programmieren, weil es ja soooo viel besser ist und > recourcen sind ja genug vorhanden. Vor allem aber steigt die Software-Komplexität immer weiter an, obwohl Antimedial immer wieder versucht Techniken aufzuführen, die die (selbstgeschaffene) Komplexität dann wieder zu reduzieren suchen. Auf diese Weise geht es dann 2 Schritte vor, einer zurück spiralförmig immer weiter nach oben bis kaum einer mehr was sieht= versteht wenns nicht funktioniert. Beim PC haben wir nun schon megabytegroße Maustreiber- für mich ein Sinnbild für das was wohl auch bei Kleinstelektronik droht.
Antimedial schrieb: > höchst erfreulich Für die Fans der 32 Bitter sicherlich ... Ich frage mich nur welche großartigen "Sicherheitsanforderungen" und Zertifizierungen da zu erfüllen sind- obwohl, man kennt ja Deutschland.
Moby schrieb: > Vor allem aber steigt die Software-Komplexität immer weiter an, obwohl > Antimedial immer wieder versucht Techniken aufzuführen, die die > (selbstgeschaffene) Komplexität dann wieder zu reduzieren suchen. Die Komplexität steigt durch die Anforderungen. Und die von mir genannten Techniken sind wirksam. Das beweise ich tagtäglich in meinem Beruf. Moby schrieb: > Für die Fans der 32 Bitter sicherlich ... Ich frage mich nur welche > großartigen "Sicherheitsanforderungen" und Zertifizierungen da zu > erfüllen sind- obwohl, man kennt ja Deutschland. Wie wärs, wenn du dich mal selbst informierst? Ach, ich hab ganz vergessen, dass du völlig lernresistent bist.
Wie viele Threads werden eigentlich noch mit der Bit-Diskussion verseucht? Ihr seid vom Thema abgeschweift...
Moby schrieb: > Beim PC haben wir nun schon megabytegroße Maustreiber- für > mich ein Sinnbild für das was wohl auch bei Kleinstelektronik droht. Mobys Maus: http://commons.wikimedia.org/wiki/File:Xerox_Alto_mouse.jpg
nicht ganz ernst schrieb: > Moby schrieb: >> Beim PC haben wir nun schon megabytegroße Maustreiber- für >> mich ein Sinnbild für das was wohl auch bei Kleinstelektronik droht. > > Mobys Maus: > http://commons.wikimedia.org/wiki/File:Xerox_Alto_mouse.jpg WO HAST DU DAS FOTO HER ?
Antimedial schrieb: > Ach, ich hab ganz > vergessen, dass du völlig lernresistent bist. Gewisse Resistenzen sind auch bei Dir erkennbar. Aber ich bin ein höflicher Mensch.
Moby wird bestimmt freuen, welche Komplexität in einem USB/Bluetooth-Adapter für 1 EUR steckt. Nur mal als Beispiel. Hier ist das Datenblatt des SOCs http://www.mikrocontroller.net/attachment/193445/CW6626-Datasheet-DS6626V1.1.pdf http://cowboycoders.org/bluetooth-gps-on-the-mini2440/ Auch wenn da ein 8051 drinnen werkelt, ist die Firmware in C programmiert. Ich hab z.B. die CSR4.0 Firmware hier herumfliegen. Die moderneren Bluetooth SOCs nutzen fast alle 32 Bit Prozessoren. z.B. Cortex oder irgendwelche Eigengewächse wie eben bei CSR. Auf Seite einer Bluetooth Maus kommt dann noch einmal das gleiche für den Receiver dazu. Dann gibt es noch einen Controller für die optische Bewegungserkennung.
:
Bearbeitet durch User
Moby schrieb: > Gewisse Resistenzen sind auch bei Dir erkennbar. > Aber ich bin ein höflicher Mensch. Du kannst auch zeigen, dass ich mich und recherchier mal schön nach Sicherheitsanforderungen und Zertifizierungen, anstatt hier immer dumme Fragen zu stellen. Aber ich helfe dir auch gerne auf die Sprünge: Eine TÜV-Zertifizierung kann gerne mal zwei Mannjahre in Anspruch nehmen. Es wird die Einhaltung der einschlägig harmonisierten Normen geprüft. Und in diesen Normen wird auch der Entwicklungsprozess geprüft. Dazu gehört auch der Einsatz einer erprobten Toolchain und Codeanalysetools. Schon einmal etwas von MISRA-C gehört? Das wird meistens gefordert. Assembler wird übrigens in den allermeisten Fällen nicht akzeptiert.
Antimedial schrieb: > Die Komplexität steigt durch die Anforderungen. Ach so. Wolltest Du nicht weismachen sie sei subjektiv? Antimedial schrieb: > Und die von mir > genannten Techniken sind wirksam. Das beweise ich tagtäglich in meinem > Beruf. Was die Entwicklung nicht ändert. Und Du bist Teil von ihr. Offensichtlich blind dem Gesetzgeber hörig ;) Tim schrieb: > Moby wird bestimmt freuen, welche Komplexität in einem > USB/Bluetooth-Adapter für 1 EUR steckt. Nur mal als Beispiel. Na da gehen auch ordentlich Daten durch. Hab kein Problem damit. 32 Bit rechnen sich eben bei allen datenintensiven Apps. Hatte ich das noch nicht erwähnt?
Moby schrieb: > Ach so. Wolltest Du nicht weismachen sie sei subjektiv? Das widerspricht sich doch nicht. Der Trend hat nichts mit dem subjektiven Niveau zu tun. Moby schrieb: > Was die Entwicklung nicht ändert. Und Du bist Teil von ihr. > Offensichtlich blind dem Gesetzgeber hörig ;) Ich kann alleine die Entwicklung nicht ändern. Ich habe aber schon Anwendungen auf einem simplen 3-Euro-M4 umgesetzt, für die man vor zehn Jahren einen dicken DSP mit externen Flash und SRAM benötigt hat. Ich trage also schon meinen Teil zur Vereinfachung bei. Und was soll der Kommentar mit dem Gesetzgeber? Soll ich jetzt meine Entwicklungen nicht normenkonform sagen, weil es deine Vorstellungskraft übersteigt, dass man Normen erfüllen muss? Haha.
gibt es jetzt für hobby/privat bereich überhaupt "libraries" in ASM? dass man jetzt alles (jeder) von grund auf selber entwickelt ist doch eher "utopisch" fängt ja schon (um mal aufzuzählen was ich so z.B. verwende) bei softwareserial an für zusätzliche zb. rs485, oder 1-wire, CRC berechnungen, rcSwitch und vorallem Ethernet (hauptsächlich UDP..) also wenn jetzt nicht gerade der WEG das Ziel ist, und man keine 20 jahre Zeit hat, und kein Student ist sondern einen job hat ;-) (und der geschwindindkeitsvorteil von ASM sowieso gleich mal eher ein theoretischer ..) versteh ich nicht warum man mit ASM anfangen soll (die Argumente hier im thread sind auch teilweise ziemlich an den haaren herbei gezogen) vielleicht kann mir ja mal jemand ein paar in ASM geschriebe projekte (auf z.B: sourceforge) zeigen, wäre interessant wo man das jetzt in der praxis tatsächlich verwendet... (nicht dass man keine ASM kenntnisse, grundlegende, haben sollte, das hilft sicher das ganze system zu verstehen, ... hab selber mal C64 usw. in ASM programmiert.. lang ist es her ;-)
:
Bearbeitet durch User
Robert L. schrieb: > versteh ich nicht warum man mit ASM anfangen soll Einfach weil es (für die meisten) das Verständniss des Systems µC erleichtert und so eine Basis schafft um später schnelle und effiziente C Programme zu schreiben. Auch wird dem einen oder anderen dadurch sicher klarer warum (auch in C) manches so ist wie es ist. Aber wie schon geschrieben, es ist heute für die meisten sicher nicht mehr nötig perfekt ASM zu können, aber zumindest mal selbst ein paar einfache "Hello Welt" Programme erstellt zu haben hilft beim Verständniss ungemein! Es ist einfach ein Schritt in der Mitte des Weges zu einem guten µC (Firmware)Entwickler. Es ist halt noch HArdwarenäher als C und erleichtert das Verständniss für die Hardware. Für konkrete Projekte mehr als evtl. ein paar Zeilen Inline ASM zu verwenden ist heute aber einfach nicht mehr Zeitgemäß. Oft ist aber selbst das schon obsolet. Gruß Carsten
Antimedial schrieb: > Das widerspricht sich doch nicht. Der Trend hat nichts mit dem > subjektiven Niveau zu tun. Es war eigentlich von Komplexität die Rede, nicht von irgendeinem Trend. Und dazu hast Du festgestellt: "Komplexität ist in erster Linie subjektiv. Für 99% der Ingenieure ist ein STM32 genauso einfach wie ein Atmega." Humbug hoch drei. Sorry. Antimedial schrieb: > Ich habe aber schon > Anwendungen auf einem simplen 3-Euro-M4 umgesetzt, für die man vor zehn > Jahren einen dicken DSP mit externen Flash und SRAM benötigt hat. Immer wieder das gleiche Muster: Eine datenintensive App erzwingt bei Dir gleich den Umstieg für alle anderen. In 5 Jahren 8-Bit in der Industrie ausgestorben? Haha. Antimedial schrieb: > Soll ich jetzt meine > Entwicklungen nicht normenkonform sagen, weil es deine Vorstellungskraft > übersteigt, Normenkonformität und all die Erfordernisse Deines Alltags vernebeln ein wenig Deine Vorstellungskraft, wie einfach sich vieles realisieren lässt. "Keep it simple" unmöglich- alte Ingenieurskrankheit.
Robert L. schrieb: > gibt es jetzt für hobby/privat bereich überhaupt "libraries" in ASM? guck doch mal in der Codesammlung nach unter Grundlagen nach...
Die Diskussion ist doch wirklich ziemlich sinnlos. Vielleicht sollte man sicher eher die Frage stellen, ob es überhaupt sinnvoll ist, mit dem Programmieren auf einem Mikrocontroller anzufangen? Asm hin oder her. In der Uni wird auch nicht im ersten Semester mit Assembler eingestiegen. Viel wichtiger sind Algorithmen, Datenstrukturen, Softwaredesign usw. Das sind Dinge die man im Beruf nicht so einfach nebenbei lernt. Assembler kommt maximal später in der Rechnerarchitekturvorlesung, sofern es im Studiengang eine gibt.
Moby schrieb: > Es war eigentlich von Komplexität die Rede, nicht von irgendeinem Trend. > Und dazu hast Du festgestellt: "Komplexität ist in erster Linie > subjektiv. Für 99% der Ingenieure ist ein STM32 genauso einfach wie ein > Atmega." Und das ist auch immer noch richtig. Trotzdem gilt folgende Aussage uneingeschränkt: Antimedial schrieb: > Die Komplexität steigt durch die Anforderungen. Moby schrieb: > Immer wieder das gleiche Muster: Eine datenintensive App erzwingt bei > Dir gleich den Umstieg für alle anderen. In 5 Jahren 8-Bit in der > Industrie ausgestorben? Haha. Das war jetzt ein Beispiel dafür, dass man Softwarekomplexität durch den Einsatz moderner Technik senken kann. Aber mich wundert es nicht, dass du dem Gedankengang nicht folgen kannst. Ich habe auch nie gesagt, dass 8 Bit sofort ausstirbt. Nur wird es in Neuprojekten nur noch selten verwendet. Moby schrieb: > Normenkonformität und all die Erfordernisse Deines Alltags vernebeln ein > wenig Deine Vorstellungskraft, wie einfach sich vieles realisieren > lässt. "Keep it simple" unmöglich- alte Ingenieurskrankheit. Normenkonformität ist der Alltag jeden Ingenieurs. 100% aller professionellen Anwendungen. Aber dein simples Bastlergemüt mag das ja nicht verstehen.
Robert L. schrieb: > gibt es jetzt für hobby/privat bereich überhaupt "libraries" in ASM? Nennt sich ganz einfach Routinen, Funktionen, Unterfunktionen mit dokumentierter Parameterübergabe. Robert L. schrieb: > dass man jetzt alles (jeder) von grund auf selber entwickelt ist doch > eher "utopisch" Kann man aber. Man muß ja nur entwickeln was man selber braucht. Und reichlich Beispielcode gibts in der Codesammlung. Robert L. schrieb: > vor allem Ethernet (hauptsächlich UDP..) Das ist in der Tat ein Argument gegen ASM- wenn man solche Aufgaben nicht auf was Externes auslagert (mach ich so, mit XPort). Ansonsten sollte man dafür entweder gleich einen Raspii/Beaglebone usw. nehmen oder eben mit C und irgendwelchen Libs arbeiten.
Antimedial schrieb: > Ich habe auch nie gesagt, dass 8 Bit sofort ausstirbt. Nur wird es in > Neuprojekten nur noch selten verwendet. leider muß ich hier meinem Vorschreiber (oder heißt das besser: Vorredner) Recht geben und das, obwohl ich die 8-Bitter "liebe". Die ganzen ARM 32-Bit Controller sind einfach derart preiswert, dass sie selbst dort eingesetzt werden, wo schon ein 8-Bitter (vielleicht sogar ein 8051er) hoffnungslos UNTERFORDERT ist. Mit dem LPC1114 steht dann auch für die Bastler-Hobby-Fraktion ein absolut handhabbarer Controller im DIP Gehäuse zur Verfügung. Aaaaaaaaaaber, so schnell (und schon gar nicht in 5 Jahren) sterben die 8 Bit Controller nicht aus. Die ganze Software und vor allem die Bibliotheken haben werden dort weiter genutzt werden, bei denen die Entwicklung neuer Tools viel teurer ist als der Einsatz relativ (Preis-Leistungs-Verhältnis) teurer Controller. Never change a running system...
Robert L. schrieb: > gibt es jetzt für hobby/privat bereich überhaupt "libraries" in ASM? Für was eine Library, wenn man die funktionsweise eines µC lernen will? Robert L. schrieb: > fängt ja schon (um mal aufzuzählen was ich so z.B. verwende) bei > softwareserial an für zusätzliche zb. rs485, oder 1-wire, CRC > berechnungen, rcSwitch und vorallem Ethernet (hauptsächlich UDP..) Es wurde hier oft gesagt, ASM nur für den einstieg, z.B. I/O, seriell, Display, ein paar Berechnungen. Mehr verlangt hier niemand, den rest kann man dan gerne in C programmieren, wenn man verstanden hat, wie ein µC funktioniert. Die Zeit die man dafür verwendet, kann man mit Lehrgeld gleich setzen. Als kleines Beispiel: Wenn ich aus ASM komme (AVR), dann weis ich/habe ich gelernt, dass sich der controller mit allem größer 8 bit schwer tut und float sehr komplex (ohne FPU) und resourcen fressend ist. Mit C merke ich das ersteinmal nicht. Da ist ein int, double oder word. Ich merke vielleicht, dass es mehr speicher braucht oder langsamer wird. bei anfangsprojekten aber eher unwahrscheinlich und gewöhne mir so von anfang an unter umständen einen schlechten programmierstil an. Das selbe gillt für C libraries, ich lade mir eine library runter und binde sie ein. Das hilft um schnell ein Ergebniss zu erhalten, aber nicht um das ganze zu verstehen. Wenn ich Erfahrung mit dem ganzen habe, dann spricht da nichts gegen, aber wenn mir wirklich etwas an der Materie liegt und man etwas lernen will, dann bitte mit ASM anfangen. Ruhig ein paar mal auf die schnauze fliegen und lernen wie es nicht geht, als es "falsch" zu lernen und keine konsequenzen zu spüren. Und falls mal eine peripherie in ASM nicht so will, wie man es gerne hätte, kann man sich auch eine C library anschauen und nachvollziehen, wie es dort gelöst wurde. Die sind in der Regel auch ohne große C kenntnisse zu verstehen. Aber das argument, ich habe keine Libraries deswegen ist ASM schlecht ist der größte Schwachsinn hier in diesem Thread, denn wie gesagt, es geht um das lernen von µC und nicht um das einbinden und nutzen von Libraries.
Antimedial schrieb: > simples Bastlergemüt Antimedial schrieb: > ber mich wundert es nicht, dass > du dem Gedankengang nicht folgen kannst. Anders kannst Du wohl nicht? Herablassung und Arroganz in jeder zweiten Zeile. Deinen Voraussagen glaube ich nicht. Bastlergemüt hin oder her. Damit mußt Du Dich leider abfinden. Antimedial schrieb: > Das war jetzt ein Beispiel dafür, dass man Softwarekomplexität durch den > Einsatz moderner Technik senken kann Sie sinkt aber nicht. Das ist eine Tatsache. Und die Ausrede die "erhöhten Anforderungen" seien an allem Schuld ist doch schlicht billig.
Moby schrieb: > Anders kannst Du wohl nicht? Herablassung und Arroganz in jeder zweiten > Zeile. Deinen Voraussagen glaube ich nicht. Bastlergemüt hin oder her. > Damit mußt Du Dich leider abfinden. Was soll ich denn sonst sagen, wenn du das Einhalten von Normen zu "Gesetzeshörigkeit" erklärst? Naiver geht es doch nicht. Das hat mit Vorhersagen nichts zu tun. Das ist die Gegenwart. Moby schrieb: > Sie sinkt aber nicht. Das ist eine Tatsache. Und die Ausrede die > "erhöhten Anforderungen" seien an allem Schuld ist doch schlicht billig. So ist es aber. Dass du das nicht wahrhaben kannst, wundert mich natürlich nicht. Schau dich doch einmal um in dieser Welt. Mach die Augen auf.
Tim schrieb: > Die Diskussion ist doch wirklich ziemlich sinnlos. > > Vielleicht sollte man sicher eher die Frage stellen, ob es überhaupt > sinnvoll ist, mit dem Programmieren auf einem Mikrocontroller > anzufangen? Asm hin oder her. In der Uni wird auch nicht im ersten > Semester mit Assembler eingestiegen. Viel wichtiger sind Algorithmen, > Datenstrukturen, Softwaredesign usw. Das sind Dinge die man im Beruf > nicht so einfach nebenbei lernt. > > Assembler kommt maximal später in der Rechnerarchitekturvorlesung, > sofern es im Studiengang eine gibt. Meiner Meinung nach, leider der Falsche Ansatz. Ich habe es an meinen Kommilitonen gesehen, sie werden mit C auf einen µC losgelassen und haben bis heute noch keine Ahnung, was das ding eigentlich ist und kann. Zu Beginn des studiums wird man mit einfachen C programmen "versaut". Es wird auf das Ergebnis geachtet, aber nicht, wie man dort hinkommt. Später werden dann µC vorgestellt, entweder mit ASM wo sich alle fragen, wo ist jetzt mein putchar oder mit C und alle fragen sich, was für includes brauche ich, damit die LED blinkt. Letztenendes bleibt dann entweder der Eindruck, das mit ASM auf die harte tour versucht wird einem etwas bei zubringen, was man ja schon viel einfacher in C gelernt hat und bei C wird es beigebracht ohne ein Verständnis für µC zu entwickeln. da gibt es aber mit Sicherheit auch unterschiede. Ist aber denke ich klar, worauf ich hinaus will.
Ralph S. schrieb: > Mit dem LPC1114 Soll das ein schlechter Scherz sein? Nur eine UART, keine 12 Bit ADC, kein EEPROM... Da braucht der Umstieg schon gewichtige Gründe.
Antimedial schrieb: > wenn du das Einhalten von Normen zu > "Gesetzeshörigkeit" erklärst Sollte es denn nicht so sein? Dumm ist es nur wenns zum Maßstab allen Denkens wird. Aber deshalb wird 8 Bit schon nicht aussterben. Du kannst hier nicht für die ganze Industrie sprechen- oder etwa doch?
Moby schrieb: > Sollte es denn nicht so sein? > Dumm ist es nur wenns zum Maßstab allen Denkens wird. Noch einmal langsam für dich: Normen sind einzuhalten! Punkt. Keine Diskussion. Das hat nichts mit Gesetzeshörig zu tun. Normen sind Stand der Technik. Noch einmal für dich: Stand der Technik. Ein Ingenieur hält sich an den Stand der Technik. So schwer zu kapieren? Moby schrieb: > Aber deshalb wird 8 Bit schon nicht aussterben. Du kannst hier nicht für > die ganze Industrie sprechen- oder etwa doch? Ich habe schon ziemlich weite Einblicke in die Industrietechnik und Automobiltechnik. Man unterhält sich mit Kollegen, man redet mit den Herstellern. Gerade die Halbleiterhersteller sind ein Spiegel für die ganze Welt. Und dort ist die Sprache im Moment eindeutig. Alle gehen in Richtung 32 Bit und ARM. Ich persönlich hoffe ja, dass noch jemand einen Gegenpart zu ARM schafft, aber im Moment sieht es wohl sehr stark nach einem Monopol aus.
Antimedial schrieb: > Stand der Technik. Ein Ingenieur hält > sich an den Stand der Technik Das kann man ja fast technik-hörig bezeichnen. Hätte ich aber nicht anders erwartet. Antimedial schrieb: > ber im Moment sieht es wohl sehr stark nach > einem Monopol aus. Im Moment. Sieht ... aus. Schön. Schaun mer mal. Deinen Eindruck kann/will ich Dir nicht ausreden. Ich habe einen anderen. Eine andere Meinung. Und die vertrete ich. Auf Kosten themafremder Threads sollten wir nicht mehr darüber streiten.
Moby schrieb: > Das kann man ja fast technik-hörig bezeichnen. > Hätte ich aber nicht anders erwartet. Ja natürlich. Ich will gute, hochqualitative Produkte entwickeln. Du nicht? Dachte ich mir schon. Moby schrieb: > Ich habe einen anderen. Eine andere Meinung. Und die vertrete ich. Ja, du hast aber auch null Einblick in die echte Welt.
Hi, Antimedial schrieb: > Alle gehen in Richtung 32 Bit und ARM. Also 32 Bit ist wohl für jeden ernsthaften µC HErsteller ein Thema, aber das alle nach ARM gehen ist nicht richtig. Eine ganze reihe ja - aber lange nicht alle. Antimedial schrieb: > Ich persönlich hoffe ja, dass noch jemand einen > Gegenpart zu ARM schafft, aber im Moment sieht es wohl sehr stark nach > einem Monopol aus. Einen "Gegenpol" zu ARM gibt es doch schon praktisch von Anfang an. Und zwar mit dem selben Geschäftsmodell (IP verkauf ohne eigene materielle Produkte oder gar eigene Werke) MIPS steht halt nicht immer nur für "Million Instructions per Second" Und praktisch von Anfang an lieferten sich die beiden Architekturen ein Kopf an Kopf rennen. Mal lag MIPS vorn, dann wieder ARM usw. Im Moment ist zumindest in den unteren Leistungsklassen (also "echte" µC) "GEFÜHLT" ARM dabei vorne zu liegen. Wie es aber in absoluten Zahlen aussieht weiß ich nicht. Es könnte anders sein oder auch nicht. An für den Hobbyisten relevanten HErstellern von µC mit MIPS Kern fällt mir aber gerade nur Microchip (Pic32) ein, die anderen mir bekannten MIPS derrivate bekommt man als Hobbyist nur mit Aufwand... Gruß Carsten
:
Bearbeitet durch User
Carsten Sch. schrieb: > Also 32 Bit ist wohl für jeden ernsthaften µC HErsteller ein Thema, aber > das alle nach ARM gehen ist nicht richtig. Eine ganze reihe ja - aber > lange nicht alle. Wer fehlt denn? Mir fällt nur Microchip und Renesas ein. Carsten Sch. schrieb: > Einen "Gegenpol" zu ARM gibt es doch schon praktisch von Anfang an. > Und zwar mit dem selben Geschäftsmodell (IP verkauf ohne eigene > materielle Produkte oder gar eigene Werke) > MIPS steht halt nicht immer nur für "Million Instructions per Second" Und mit welchem Marktanteil? Haben die inzwischen auch schon einen M0-Konkurrent? Welche Hersteller setzen auf MIPS bei Mikrocontrollern? Microchip ja, und weiter?
Antimedial schrieb: > Ja, du hast aber auch null Einblick in die echte Welt. Täusch Dich mal nicht zu sehr in den eigenen Fähigkeiten ;)
Ich täusche mich nicht in deinen nicht vorhandenen Fähigkeiten.
Hochmut kommt vor dem Fall, oder wie sagt man so schön? Kann es sein daß Dein beruflicher Erfolg irgendwie mit dem Verkauf der M0 Chips zu tun hat? Die Frage lag mir noch auf der Zunge!
Haha, guter Scherz, und du hälst dich für so wichtig, dass ich dir unbedingt die M0 verkaufen muss? Natürlich.
Antimedial schrieb: > Haha, guter Scherz, und du hälst dich für so wichtig, dass ich dir > unbedingt die M0 verkaufen muss? Natürlich. Ach und gleich noch eine: Hat so ein hochgebildeter gutvernetzter und standfester Ingenieur wie Du eigentlich nix besseres zu tun als einen halben Tag nur in diesem Forum abzuhängen? Bist Du etwa arbeitslos?
Moby schrieb: > Ach und gleich noch eine: Hat so ein hochgebildeter gutvernetzter und > standfester Ingenieur wie Du eigentlich nix besseres zu tun als einen > halben Tag nur in diesem Forum abzuhängen? Bist Du etwa arbeitslos? Na, offensichtlich bist du arbeitslos, wenn du schon das Gefühl für Zeit verloren hast. Zur Erinnerung: Heute ist Sonntag, und sonntags arbeitet ein Ingenieur üblicherweise nicht.
Leute! Nun lasst doch endlich diese Diskussion hier sein, oder geht in den 32Bit-Krieg-Fred! Langsam nervt es :-((
Antimedial schrieb: > Carsten Sch. schrieb: >> Also 32 Bit ist wohl für jeden ernsthaften µC HErsteller ein Thema, aber >> das alle nach ARM gehen ist nicht richtig. Eine ganze reihe ja - aber >> lange nicht alle. > > Wer fehlt denn? Mir fällt nur Microchip und Renesas ein. Och, das waren schon einige, wobei ich lieber erst nachschlage bevor ich etwas falsches schreibe, denn es ändert sich ja schnell. Wobei ich zugebe das es sich bei vielen dieser Hersteller nicht um Hersteller von "Universal-Use" Mikrocontrollern handelt sondern umAnbieter von Speziallösungen. Deshalb schrieb ich ja auch Carsten Sch. schrieb: > An für den Hobbyisten relevanten HErstellern von µC mit MIPS Kern fällt > mir aber gerade nur Microchip (Pic32) ein, die anderen mir bekannten > MIPS derrivate bekommt man als Hobbyist nur mit Aufwand... (Mit Nachschlagen meine ich jetzt überprüfen ob die nicht doch mittlerweile den einen oder µC mit ARM Kern im Programm haben, das die MIPS haben weiß ich) > > Carsten Sch. schrieb: >> Einen "Gegenpol" zu ARM gibt es doch schon praktisch von Anfang an. >> Und zwar mit dem selben Geschäftsmodell (IP verkauf ohne eigene >> materielle Produkte oder gar eigene Werke) >> MIPS steht halt nicht immer nur für "Million Instructions per Second" > > Und mit welchem Marktanteil? Haben die inzwischen auch schon einen > M0-Konkurrent? Welche Hersteller setzen auf MIPS bei Mikrocontrollern? > Microchip ja, und weiter? Ja, die Frage des MArktanteils wäre tatsächlich Interessant. Wobei die von dir oben genannten "ARM" Verweigerer Renesas und Microchip zusammen sicher einen größeren MArktanteil im µC Segement haben als die besten vier der verbleibenden Hersteller. Aber wie sich das jetzt dann auf die Registerbreiten oder gar die genauen CORE Technologien verteilt kann ich absolut nicht abschätzen. Aber da du nach HErstellern fragtest: Microchip ist ja klar, Maxim hat auch MIPS im Programm, und um ein paar Vertreter der "Special-Use" Branche zu nennen greife ich mal zu Broadcom und Sigma. Aber wie schon geschrieben: Ausser Microchip ist das alles nichts für "Bastler" da fast nicht zu bekommen. Aber das habe ich selbst ja explizit geschrieben. MIPS ist halt im Bereich der Speziallösungen sehr stark, das ist aber ein recht abgeschotteter Bereich und daher sind die Infos da nur spärlich, wenn man nicht zufällig mal direkt mit einem Derrivat in Kontakt kommt erfährt man fast nichts, wogegen ARM momentan eine massive MArketingkampagne am laufen zu haben scheint. Diese Speziallösungen übersieht man leicht, aber die machen einen großen Teil des µC Marktes aus... Wie gesagt: Im Moment schein ARM vorne zu liegen, aber ob es tatsächlich so ist kann ich einfach nicht sagen, genausowenig was vielleicht in drei oder fünf Jahren sein wird. Das einzige was ich sagen kann ist das es in der Vergangenheit immer ein Hin- und Her der beiden Firmen war. Wie es jetzt nach dem Verkauf von MIPS aussieht, was Imagination daraus macht wird man sehen... Aber das gehört alles gar nicht in diesem Thread, wenn überhaupt dann in den anderen, der aber auch schon völlig Zerschrieben ist... Hier ging es um die Frage C oder ASM und die durchaus vorhandenen sinnvollen Antworten dazu gehen leider im Müll unter! Gruß Carsten
Ich habe aufgegeben die Streitereien komplett durchzulesen. Die Frage war doch ob mit C oder ASM für einen Anfänger ein µC besser zu lernen/verstehen ist. Ganz klar mit ASM auf einem 8 Bitter. Was er dann in einem halben Jahr oder so macht, welchen der Hunderten µC er dann nimmt und in welcher der vielen Programmiersprachen er seine Superduper Anwendung schreibt? Danach hat er nicht gefragt. Hat man sich durch Datenblatt und Maschinensprachereferenz durchgekämpft hat, weis man, auf was sich alles andere aufbaut und ist Meiner Meinung nach für alles weitere gerüstet.
>Ganz klar mit ASM auf einem 8 Bitter.
Blödsinn..
Ganz klar muss man sich den 8Bitter erst selber aus Transistoren
Zusammenlöten!
:
Bearbeitet durch User
Kein Interesse gehabt, alles durchzulesen, Kindergarten... wie so oft. Ich möchte dem Treadhersteller trotzdem meine Meinung sagen: Ich habe vor 4 Jahren eine berufslehre zum Elektroniker begonnen. Ich hatte davor 0 Kentnisse mit ASM und C. In der Berufsschule haben wir die ersten zwei Jahre ASM Programmiert, erst dann C. Ich habe zu beginn meiner Berufsbildung aber aus eigenem Interesse ein wenig C im Internet gelernt. Fakt ist: C für uC habe ich erst richtig verstanden, als ich einen uC in ASM Programmieren konnte, da ich finde, dass ASM einem das innere der CPU viel näher bringt als C. Man versteht was vorgeht, und das finde ich wichtig, vor allem wenn man sich dafür interessiert. Ich denke, mit ASM hat man einen besseren Einstieg weil: - CPU wird einem näher gebracht - Keine verwirrenden Libs, welche einem sowieso nicht weiterhelfen sein wissen zu erweitern - Nur eine kleine Hand von Befehlssätzen -> Übersichtlich Ich hoffe, ich konnte dir meine Meinung etwas näher bringen. Und ans Forum: Hört doch auf, euch wegen solchen Fragen zu streiten. Jeder hat hier nun mal seine eigene Meinung. Nur weil das Internet Anonymität bietet, müsst ihr nicht euren Frust hier ablassen. Es gibt hier Menschen aller Altersklassen die versuchen ihr Wissen zu teilen und anderen Menschen bei interessanten Projekten zu helfen. Es interessiert absolut KEINEN welche Ausbildung ihr abgeschlossen habt oder wie gut ihr nun das und jeden könnt. Helft, oder schweigt. - Meinung eines 18 Jährigen Elektronik Lehrlings MfG
Abschluss schrieb: > Fakt ist: C für uC habe ich erst richtig verstanden, als ich einen uC in > ASM Programmieren konnte, da ich finde, dass ASM einem das innere der > CPU viel näher bringt als C. Man versteht was vorgeht, und das finde ich > wichtig, vor allem wenn man sich dafür interessiert. So habe ich das auch gemacht und ich halte das auch für den richtigen Weg. Der uP ist egal ...
Carsten Sch. schrieb: > (Für einen Hobbyisten der nur mal ein Projekt machen will mag es > natürlich anders aussehen, aber hier war ja nach dem Weg zu SOLIDEN > FACHKENNTNISSEN gefragt) Falsch, es ging um komplette Anfänger (keine Kenntnisse Mikrocontroller und keine Kenntnisse Programmierung) mit recht einfachem Projekt.
Hallo, ist schwer zu sagen was besser ist. Ich bin jedenfalls der Meinung das C das Ziel sein sollte egal wie man anfängt. Ich halte jedoch nichts davon C erst auf dem PC zu lernen, dann lieber gleich einen Controller verwenden für den es eine vernünftige Entwicklungsumgebung inclusive Debugger gibt. Eckhard
Antimedial schrieb: > da C doch etwas mehr Speicher braucht. > > Nicht wirklich. Vermutlich ist das auch subjektive Wahrnehmung ;) Abschluss schrieb: > Hört doch auf, euch wegen solchen Fragen zu streiten. Na es gibt schon ganz klar Pro und Kontra, für das Eine und das Andere. Die Entscheidung C vs. ASM ist aber nicht so einfach, vor allem weil sie empfindlich davon abhängt - was man lernen möchte - was man lernen muß und beruflich braucht - was einem persönlich liegt - was man womit entwickeln will
Moby schrieb: > - was man lernen möchte > - was man lernen muß und beruflich braucht > - was einem persönlich liegt > - was man womit entwickeln will Ergo vollkommen subjektiv und daher kein Grund zu diskutieren. Und bei Punkt zwei kann man eh nicht selbst entscheiden.
Abschluss schrieb: > > Fakt ist: C für uC habe ich erst richtig verstanden, als ich einen uC in > ASM Programmieren konnte, da ich finde, dass ASM einem das innere der > CPU viel näher bringt als C. Man versteht was vorgeht, und das finde ich > wichtig, vor allem wenn man sich dafür interessiert. > > Ich denke, mit ASM hat man einen besseren Einstieg weil: > - CPU wird einem näher gebracht > - Keine verwirrenden Libs, welche einem sowieso nicht weiterhelfen sein > wissen zu erweitern > - Nur eine kleine Hand von Befehlssätzen -> Übersichtlich > > > - Meinung eines 18 Jährigen Elektronik Lehrlings > So ist es. Wer niemals ASM gelernt hat, kann gar nicht wissen, wie sich diese Fähigkeit in seiner Programmierarbeit auswirken würde. Daher ist seine Meinung über ASM nichts wert. Natürlich kann man ohne viel Hardwarewissen seine Libs zusammenklicken und sich freuen, wenn das Compilat funktioniert. Je abstrakter die Sprache, um so hardwareferner. Trotzdem sehe ich Kenntnis des Assemblers als Bereicherung. Niemand muss dafür 130 Instruktionen lernen. Viele sind ähnlich, zum Beispiel weil sie sich auf das Statusregister beziehen. Der Rest ist fast Intuitiv zu verstehen, was ich von C überhaupt nicht sagen kann. Fazit: Nicht entweder-oder, sondern sowohlalsauch.
Nicht umsonst steht im Lehrplan der IHK für Elektroniker für Geräte und Systeme noch immer ASM! Ich stimme, der ASM-Fraktion soweit zu: Es ergibt definitiv Sinn, sich zu Beginn mal mit dem Maschinenbefehlssatz auseinderzusetzen und zu schauen, wie solch ein Code aufgebaut ist. Die wenigsten werden später mit C in die Situation kommen, dass sie ASM wirklich programmieren müssen, aber das Verständnis ist viel wert. Daher verstehe ich auch einfach nicht, aus welchem Grund Softwareker nie mal etwas hardwarenäher in der Ausbildung programmieren (zumindest bei uns nicht). Die haben nämlich nicht den leisesten Dunst, was ein einfacher µC alles schufften muss, wenn die sich in C ihre Divisionen und Wurzelberechnungen zusammenklicken... ;/
Krümel schrieb: > Die haben nämlich nicht den leisesten Dunst, was ein > einfacher µC alles schufften muss, wenn die sich in C ihre Divisionen > und Wurzelberechnungen zusammenklicken... ;/ Hier in der Schweiz genau das selbe. Man ist ihnen im Bereich uC und das wissen rund herum als Elektroniker Lehrling weit überlegen. TomToll schrieb: > Natürlich kann man ohne viel Hardwarewissen seine Libs zusammenklicken > und sich freuen, wenn das Compilat funktioniert. Stimme dir voll und ganz zu. Genau das sollte ja nicht das Ziel sein! Anderer denkansatz: Wenn ihr ein Auto kauft, interessiert euch wie das Teil funktioniert, wieviel Benzin es verbraucht oder gillt der Vorsatz: Alles egal, hauptsache es fährt. Wenn es nur Fahren muss und man diesen Vergleich auf die Mikrocontroller anwendet, dann nur zu, beginnt mit C! Aber ein verständniss wie das ganze funktioniert was ihr da erarbeitet habt, werdet ihr dadurch nicht kriegen. Man lernt auch nicht vom Autofahren wie ein Motor aufgebaut ist. Versteht ihr das erstmal, könnt ihr euch dann ruhig dem reinen Fahren witmen.
Alle, die das Programmieren schon vor längerer Zeit gelernt haben, haben mit Assembler begonnen. Der Grund war auch ganz einfach: Den Assembler gab es immer geschenkt, C Compiler kosteten zum Teil richtig Geld oder waren, wenn sie kein Geld kosteten, grottenschlecht. Ich habe den AVR damals auch in Assembler programmiert, in der Firma haben wir den damals zum ersten Mal eingesetzt und niemand wollte die 2500 DM für einen IAR-Compiler ausgeben, nur um hinterher dann vielleicht festzustellen, dass der Contoller für die eigenen Zwecke eigentlich nichts taugt.
Wenn Du den Controller verstehen willst, dann fang an in ASM, bring einfach mal eine LED zum blinken, dann lernst Du den Prozessor kennen (Zugriff auf register, was passiert bei einem Funktionsaufruf...). Wenn die LED blinkt, dann fang an mit C, und schau doch mal gelegentlich den erzeugten Assemlercode an, und versuch den zu verstehhen. Wenn Du nur schnell zu einem Ergebnis kommen willst, und dich nicht jedes bit interessiert dann lern C. Manche sachen gehen allerdings nur in ASM. Ich hab mal einen rudimentären bootloader für den Atmega16 in 256Byte Code gepackt, das ist der overhead den C mitbringt einfach zu groß.
Eckhard schrieb: > Ich halte jedoch nichts davon > C erst auf dem PC zu lernen, dann lieber gleich einen Controller > verwenden für den es eine vernünftige Entwicklungsumgebung inclusive > Debugger gibt. Super damit der Anfänger erst recht nicht durchsteigt. Gerade mit einer Blackbox C zu lernen, wo man sich auch noch mit solchen Dingen beschäftigen muss wie Linkerscripts, UART etc. (ARM) und wo es an sämtlichen Dingen haken kann (Flashen, Debuggen) ist ja besonders sinnvoll. Wir haben hier schon zuhauf Anfänger die ein LCD Display ansteuern wollen und nicht mal verstanden haben was ein String ist, dass er eine Nullterminierung braucht, was Zeiger sind und wozu sie gut sind. Mit Low-Level Programmierung anzufangen ohne ein mal die Grundlagen der Sprache zu verstehen ist einfach nur dämlich. Auf dem PC kann er sofort Strings/Zahlen ausgeben und einlesen, was das ganze sehr vereinfacht. Wie viele Anfänger gibt es die Probleme mit der UART haben und deshalb hier im Forum fragen müssen. Zudem ist der Debugger auf dem PC so einfach zu Bedienen und von Anfang an startklar. Außerdem merkt der Anfänger schnell wenn das Programm auf dem PC Amok läuft und das Programm versucht auf einen falschen Speicherbereich zuzugreifen, das Programm stürzt ab und das OS gibt eine Fehlermeldung aus. Der µC ist da nicht sehr gesprächig.
TomToll schrieb: > Trotzdem sehe ich Kenntnis des Assemblers als Bereicherung. In der letzten Firma sah ich die Jungs mit dem ARM9, die da ein Linux drauf implementierten. Interessenhalber unterhielt ich mich mit denen zwischendurch auch mal, und einer schenkte mir dann spontan einen Packen Papier mit Assemblerfunktionen für den ARM. Das waren Betriebssystemfunktionen für das Linux, z.B. sowas wie COPY32 oder MOVE32 oder COMPARE32, die Namen mal nur beispielhaft. Die Funktionen sind zwar getestet und mit den Schnittstellen dokumentiert, aber trotz dem denke ich, daß die Jungs da auch mal schauen, was sich da genau abspielt. Und zu guter Letzt? Wer schrieb die Funktionen mal? Bestimmt irgend einer, der es sinnreich oder notwendig fand. Auch jeder Compilerhersteller braucht ASM, das ist deren Brot.
Hallo, TriHexagon schrieb: >> Ich halte jedoch nichts davon >> C erst auf dem PC zu lernen, dann lieber gleich einen Controller >> verwenden für den es eine vernünftige Entwicklungsumgebung inclusive >> Debugger gibt. > > Super damit der Anfänger erst recht nicht durchsteigt. Gerade mit einer > Blackbox C zu lernen, wo man sich auch noch mit solchen Dingen > beschäftigen muss wie Linkerscripts, Gerde deshalb sprach ich von einer anständigen Entwicklungsumgebung, da muss man sich mit Sowas nicht herumschlagen. > UART etc. (ARM) und wo es an > sämtlichen Dingen haken kann (Flashen, Debuggen) ist ja besonders > sinnvoll. Wir haben hier schon zuhauf Anfänger die ein LCD Display > ansteuern wollen und nicht mal verstanden haben was ein String ist, dass > er eine Nullterminierung braucht, was Zeiger sind und wozu sie gut sind. > Mit Low-Level Programmierung anzufangen ohne ein mal die Grundlagen der > Sprache zu verstehen ist einfach nur dämlich. Die Anfänger mit den LC displays tun sich aber in ASM oder auch Bascom nicht leichter, was soll diese Aussage hier also wert sein ? Die Grundlagen der Programmierung muss man immer verstehen, dafür gibt es keinen Ersatz, aber wer Zeiger in C nicht versteht, der hat sie auch in Assembler nicht verstanden. > > Auf dem PC kann er sofort Strings/Zahlen ausgeben und einlesen, was das > ganze sehr vereinfacht. Wie viele Anfänger gibt es die Probleme mit der > UART haben und deshalb hier im Forum fragen müssen. Zudem ist der > Debugger auf dem PC so einfach zu Bedienen und von Anfang an startklar. > Außerdem merkt der Anfänger schnell wenn das Programm auf dem PC Amok > läuft und das Programm versucht auf einen falschen Speicherbereich > zuzugreifen, das Programm stürzt ab und das OS gibt eine Fehlermeldung > aus. Der µC ist da nicht sehr gesprächig. Wo ist das Problem, in einem anständigem Debugger, sehe ich meinen Code, Kann steppen, Break und Watchpoints setzen. Habe Fenster, die mir den Maschinencode und den Speicher zeigen. Ich kann mir Variablen anzeigen lassen und alles. Diesen altertümlichen kram mit Debug ausgaben via UART sollte man sich einfahc nicht mehr antun. Dann noch die Frage, was haben leute davon wenn sie auf dem PC schön Printf und co gelernt haben ? Sie versuchen das auch auf dem MC zu machen und dazu gibt es hier ebensoviel Beiträge wie zum Thema LCD. Eckhard
bei ASM habe ich nicht das Problem das ich vor einem Compiler niederknien muss nur weil er mal was für undefiniert halten könnte und tut was er will.
Eckhard schrieb: > Diesen altertümlichen kram mit Debug ausgaben via UART > sollte man sich einfahc nicht mehr antun. Es kostet aber nichts. Die Profi-Tools kosten einen Hobbyisten ja oft ein Schweinegeld, was nicht machbar ist. > Dann noch die Frage, was haben leute davon wenn sie auf dem PC schön > Printf und co gelernt haben ? Das weiß ein Profi auch, wie man sowas handhabt.
daWuehr schrieb: > C ist viel einfacher. ganz sicher nicht.....I2C lässt sich in ASM einfacher implementieren als mit C...
Eckhard schrieb: > Die Anfänger mit den LC displays tun sich aber in ASM oder auch Bascom > nicht leichter, was soll diese Aussage hier also wert sein ? > Die Grundlagen der Programmierung muss man immer verstehen, dafür gibt > es keinen Ersatz, aber wer Zeiger in C nicht versteht, der hat sie auch > in Assembler nicht verstanden. Nein das hast du falsch verstanden. Anfänger die Programmieren am µC anfangen, tendieren dazu nicht die Sprache zu lernen sondern lieber anfangen z.B. mit einem LCD zu experimentieren. Dass es dann bei der Stringübergabe kracht ist klar. Threads wo der Threadstarter klare Grundlagendefizite hat, sich weigert diese endlich mal auszumerzen und lieber weiter am LCD rumspielt gibs hier jeden Tag. Die Grundlagen sind aber weiterhin Plicht!
TriHexagon schrieb: > Nein das hast du falsch verstanden. Anfänger die Programmieren am µC > anfangen, tendieren dazu nicht die Sprache zu lernen sondern lieber > anfangen z.B. mit einem LCD zu experimentieren. Ja, und genau das ist ja da Bescheuerte an C. In ASM gibt es diese Sprachregeln nicht, sondern man spielt nur mit dem LCD und konzentriert sich auf den Prozessor. Bei Fehlern bleibt es eben dunkel, nur so schwer ist das nicht.
TriHexagon schrieb: > Die Grundlagen sind > aber weiterhin Plicht! Das ist leider bei jedem anders, und meistens nicht eine Schablone wie ein gleicher Kurs für alle und über alle Dinge. Erst sehr spät sah ich mir auch mal Transistorschaltungen an, was sich da im µC wirklich genau abspielt. Zum 6502 gibt es im Netz irgendwo ein Schaltbild, und das geht auch, solche Teile hatten mal was um die 6000 Transistoren. Ich mußte mit dem 8051 zwangsläufig mit ASM beginnen, weil es einfach für Bastler überhaupt keine Hochsprachencompiler gab. Um 1990 herum gab es noch µC mit einem BASIC-Interpreter drauf als Zwischenlösung. Ich hatte aber nie einen, und kam weiter mit ASM zurecht. Aber sowas war der richtige Weg, um stufenweise zu lernen, und nicht nach der Fahrprüfung mit einem Porsche zu beginnen.
Wenn der Code gut wartbar, portierbar und lesbar sein soll, würde ich c nutzen. Assambler nur dort, wo unbedingt nötig (also in 99,9% der Fälle nicht). Aus didaktischen Gründen bietet sich aber sicher Assembler an. Dadurch wird ein Grundverständnis geschaffen. Anschließend aber sollte man sich davon lösen und Zeitgemäßes verwenden (sowohl bez. Hardware als auch Hochsprache)
Eckhard schrieb: > Wo ist das Problem, in einem anständigem Debugger, sehe ich meinen Code, > Kann steppen, Break und Watchpoints setzen. Habe Fenster, die mir den > Maschinencode und den Speicher zeigen. Ich kann mir Variablen anzeigen > lassen und alles. Diesen altertümlichen kram mit Debug ausgaben via UART > sollte man sich einfahc nicht mehr antun. Du schreibst wie ein Theoretiker, der noch nie irgendetwas selbst debuggt hat - allenfalls seine eigenen Fehler, die man auch per Hingucken gefunden hätte. Kurzum, du liegst grottenfalsch. Probiere doch z.B. mal einen USB Anschluß zu debuggen. Da kappt dir die SIE bereits nach 3 ms das Interface und geht schlafen und obendrein hängt dich der Host ab, wenn dein im Debuggen befindlicher Code nicht in der rechten Zeit das tut, was der Host von ihm will. Das ist nur EIN Beispiel von vielen, wo man mit einem intrusiven Debugging überhaupt nicht weiter kommt. Egal wieviele Watchpoints und Fensterli du auf deinem Screen hast. Solche naseweisen Beiträge ärgern mich inzwischen. W.S.
lol Sinn-Erfassung von fremden Texten geht gegen Null, aber jeder hat eine Meinung. Ich mach gerade eine neue Schüssel Popcorn für die nicht betroffenen. rumreich BTW: Vielleicht ist ja ein BASIC-Derivat in Kombination mit Inline-Assembler für weiterreichende Projekte erfolgsversprechender...
W.S. schrieb: > Probiere doch z.B. mal einen USB Anschluß zu debuggen. Da kappt dir die > SIE bereits nach 3 ms das Interface und geht schlafen und obendrein > hängt dich der Host ab, wenn dein im Debuggen befindlicher Code nicht in > der rechten Zeit das tut, was der Host von ihm will. Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0 auf lernen"? Du schreibst wie ein Profi mit Null Verständnis für die Belange von Einsteigern. Natürlich ist ein Debugger ein wertvolles Hilfsmittel für den Anfang wie auch für später. Erst bei entsprechend anspruchsvolleren Projekten kommen dann weitere Werkzeuge zum Einsatz.
Moby schrieb: > Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0 > auf lernen"? Das hättest du dir im Laufe des Threads auch mal fragen können. Nur weil es kurz in Richtung OffTopic geht, braucht man niemanden daran zu erinnern.
Mit ersterem hast Du natürlich recht, zu diesem Streit gehörten jedoch zwei ;) Ansonsten ist USB-Debugging kein Problem für einen Einsteiger und macht einen Debugger nicht obsolet- nur soviel wollte ich zum Ausdruck bringen.
und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu lernen .. also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen, Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es überhaupt.. am PC dann ein wenig Grundlagen für den µC (was gibts es, warum hat das ding so viele Beinchen.., warum haben welche keine Beinchen.., was ist PWM, PullUp, UART usw. ) danach kann man Sich kann SELBER ein Bild machen, welche Hardware und welche (nicht nur) Sprache (sonder auch IDE usw) man verwenden will dann ist man, frei nach, "wer nichts weiß muss alles glauben" nicht auch SOLCHE Threads hier angewiesen ;-)
Robert L. schrieb: > und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu > lernen .. > > also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen, > Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es > überhaupt.. > > am PC Datentypen, typen, Strukturen und Klassen sind keine grundlagen/basics. gerade in assembler lernt man die grundlagen ohne die man nichts programmieren kann. Erst dann erkennt man die Vor- aber auch die Nachteile bei der Verwendung von Hochsprachen-sahne wie OOP, komplexe typen > > dann ein wenig Grundlagen für den µC (was gibts es, warum hat das ding > so viele Beinchen.., warum haben welche keine Beinchen.., was ist PWM, > PullUp, UART usw. ) > > > danach kann man Sich kann SELBER ein Bild machen, welche Hardware und > welche (nicht nur) Sprache (sonder auch IDE usw) man verwenden will Also üblicherweise wähltt man die Hardware danach ob sie bietet was man benötigt (x mal UARTs, y SPIs) und dann kann man schauen welche Hochsprache/IDE am besten qualitativ hochwertige Softwareentwicklung unterstützt. Schlecht wenn ich mich für Android wegen der tollen IDE etc entschieden habe, aber der 1 Euro controller in der Maschinensteuerung keine MMU/PMU für Speicherschutz und virtuellen Speicher etc. mitbringt ... MfG,
Robert L. schrieb: > und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu > lernen .. Im Grunde genommen nichts. Jedem das seine. Wie aber einige schon geschrieben haben, finde ich es schade wenn man nie einen Einblick in ASM gehabt hat, da es bei einer reinen C Programmierung doch wesentlich schwieriger ist zu verstehen, was der uC genau macht. Vorteil an ASM ist beispielsweise, man weiss genau welcher Befehl wie lange dauert. Klar, meist ist das absolut egal, trotzdem kann es interessant sein. Ein weiteres Problem mit C: Es mag am Anfang einfach sein, man arbeitet sich immer weiter hinein. Für irgendein Delay wird einfach eine vorhandene Lib verwendet, man Tippt je nach Compiler einfach mal DelayMS(500); ein und schon hat man seine halbe Sekunde Wartezeit. Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden und man nichtmehr auf eine Lib zurückgreiffen kann. Dann wenn es darum geht zu wissen, wie der uC genau arbeitet um den eigenen Ansprüchen gerecht zu werden. Wieso also nicht ein paar Tage mehr investieren, dafür die Grundlagen lernen? In der Elektronik lernt man auch zuersch das Ohmsche gesetz und nicht das berechnen von irgendwelchen Strömen durch Kondensatoren in einem Filter.
Robert L. schrieb: > und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu > lernen .. > > also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen, > Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es > überhaupt.. Funktionen, Strukturen, Typen, Klassen, Schleifen kennt der Controller nicht. Sind dem völlig egal. Er kennt nur Register und Speicherstellen. Deine "Grundlagen" haben also nichts mit der Controllerprogrammierung zu tun, um die es hier geht, sondern ausschließlich mit der Bedienung des Compilers. Wer in einer Hochsprache programmieren will, muss das natürlich anfangs erlernen, klar. Programmieren zu lernen heißt doch aber nicht primär die Syntax von C oder ASM Mnemoniks zu pauken, sondern seine Aufgabe zu strukturieren und Ablaufpläne zu entwickeln. Wenn das nicht schon mal 80% sind... Die restlichen 20% sind doch nur übersetzen und Werkzeugeinsatz.
>kennt der Controller >nicht. Tellerrand?? ich meinte Man(n) muss die Grundlagen der Programmierung verstehen.. die "Scheife" muss man sich dann in ASM eben selber basteln (cmp, jmp, was auch immer) und Strukturen im Speicher selber "definieren" (verkettete liste, was auch immer..) wie willst was Programmieren, wenn du von den Basics keine Ahnung hast.. >was der uC >genau macht. weil das ein Anfanger SO genau wissen muss.. >Also üblicherweise wähltt man die Hardware danach ob sie bietet was man >benötigt (x mal UARTs, y SPIs) und dann kann man schauen welche >Hochsprache/IDE am besten qualitativ hochwertige Softwareentwicklung >unterstützt. das stand weiter oben schon mal, dass es darum "nicht geht" (weil es um das erlernen, und nicht um ein konkretes ziel geht) ich bleib dabei: zuerst Grundlagen des Programmierens lernen (Verstehen) und das geht mit einer Hochsprache am PC nun mal einfacher
Robert L. schrieb: >>was der uC >>genau macht. Wie schon weiter oben erwähnt: San Lue schrieb: > Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden > und man nichtmehr auf eine Lib zurückgreiffen kann. Dann wenn es darum > geht zu wissen, wie der uC genau arbeitet um den eigenen Ansprüchen > gerecht zu werden. Klar, du kannst nun wieder sagen, einem Anfänger ist das egal. Stimmt soweit auch. Trotzdem, wer Programmieren lernt will selten lernen einen Digitalen Ausgang zu setzen und fertig. Im normalfall lernt man weiter und es ist nunmal so, dass man früher oder später nichtmehr um den Aufbau eines uC's herumkommt. Aus eigener Erfahrung muss ich sagen, ich war sehr froh darüber, zuerst ASM gelernt zu haben, hat mir dann bei C den einstieg stark erleichtert.
Hab ich oben ja schon mal geschrieben, ich sehe es wie San Lue. ASM ist für den Einstieg und das verstehen, was ein µC ist und wie er arbeitet besser mit ASM anzufangen. Hier lernt man, was so ein µC eignetlich alles kann und was manche Operationen für eine Last erzeugen (zB: Float, wobei ich das nicht in ASM programmieren wollen würde) Hat man die Basics mit ASM abgeklappert, spricht nichts dagegen eine Hochsprache seiner Wahl auf den µC los zu lassen, man muss nicht mal alles mit ASM programmieren können. Aber zumindest mal Peripherie initialisieren, ein bisschen I/O-Operationen (LEDs, 16*2 LCD, USART) und die ein oder andere Rechnung durchführen. Einfach, damit man im Fall eines AVRs merkt, was die 8-bit eigentlich bedeuten. In C ist einem Anfänger die Bus-breite und demnach die limitierungen der Hardware egal, da kann man auch munter ein float nutzen und merkt nicht, was man da eigentlich für einen misst gebaut hat. Klar gibt es auch noch die Fraktion, die einfach nur schnell ein Projekt beenden will und denen ist es egal, wie so ein µC funktioniert, solange er funktioniert. Dann kann man mit C anfangen und nur irgendwelche Libraries zusammen wurschteln (Arduino). Aber der will eben auch nicht µC lernen, sondern ein Projekt fertig stellen.
> Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden > und man nichtmehr auf eine Lib zurückgreifen kann. eigentlich ist es genau verkehrt, die meisten Problemstellungen sind so Komplex, dass man überhaupt nicht in der Lage ist ist alles bis ins letzte selber, neu und dann vielleicht auch noch in ASM zu erstellen.. (wie überall im Leben) basieren die Meisten Arbeiten, auf der Arbeit von Anderen wobei es ja nicht verboten ist, mal selber den Sourcecode dieser "Libraries" anzuschauen ändern verbessern.. aber um das gehts ja nicht, sondern ob man mit ASM anfangen soll vermutlich ist es eh egal.. wenn man in einen "C für total-Anfänger" und eine "ASM für total-Anfänger" Kurs gehen würde, wären die ersten 35 von 40 Stunden wohl ziemlich identisch..
:
Bearbeitet durch User
> wenn man in einen "C für total-Anfänger" und eine "ASM für > total-Anfänger" Kurs gehen würde, wären die ersten 35 von 40 Stunden > wohl ziemlich identisch.. ? Nur 5h von 40h für syntax/resp Mnemonic, Complieroptionen, Makrodirektiven, Code style, Grundbibliotheken, IDE-Menüs ... ? Wohl eher reziproke verhältnisse, 5h identisch, wobei wenn man 40h ASM gehört hat, braucht man nur noch 10h für C. Hatt man aber 40h C gehört braucht man immer noch 30h für assembler. MfG,
denke jeder µC bastler sollte mal eine LED mit Hilfe von ASM blinken lassen und dann das ganze nochmal in C :) P.S.(zur verwirrung) es gibt noch weitere Buchstaben im ProgrammierSprachenAlphabet wie wäre es mit D oder F? oder wenn es C sein muss warum nicht gleich C++ oder C# ... :)
benwilliam schrieb: > oder wenn es C sein muss warum nicht gleich C++ oder C# ... :) Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp # teil hoch-levelt. Erst C++ lernen und dann C ist irgendwie ... "weltfremd"?
nach der Antwort von Fpga Kuechle bin ICH mir jetzt zu 100% sicher , dass ich bei niemandem mit ASM anfangen würde...
benwilliam schrieb: > oder wenn es C sein muss warum nicht gleich C++ oder C# ... :) Weil C genau den richtigen Grad an Fallen, Einschränkungen, mangelnder Abstraktion und Tastaturabnutzung bietet den E-Techniker so lieben.
Fpga Kuechle schrieb: > Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp # > teil hoch-levelt. Das wäre ganz schön ungeschickt. Man lernt C++, C#, ... natürlich gleich richtig. > Erst C++ lernen und dann C ist irgendwie ... > "weltfremd"? Schlau, denn so vermeidet man alle schlechten C-Angewohnheiten wieder vergessen zu müssen, wenn man mit einer richtigen Sprache anfängt.
Kindergärtner schrieb: > benwilliam schrieb: >> oder wenn es C sein muss warum nicht gleich C++ oder C# ... :) > Weil C genau den richtigen Grad an Fallen, Einschränkungen, mangelnder > Abstraktion und Tastaturabnutzung bietet den E-Techniker so lieben. Ne, weill uC einfach nicht die Resourcen bieten um C++ einzusetzen. Ich erinnere mich da an ein FPGA-projekt mit Soft-Core auf dem Linux lief, bei dem nach einigen Wochen Rumgehacke feststand das C++ nicht einsetzbar ist. Wenn halt nur ein p kByte an RAM zur Verfügung stehen, kann man mal nicht 18k länger binaries unterbringen. Oder den Heap mal schnell hochsetzen: http://forums.xilinx.com/t5/Embedded-Development-Tools/MicroBlaze-C-tutorial/td-p/16916 C++ frisst eben ein mehrfaches an ressourcen. MfG,
Fpga Kuechle schrieb: > Ne, weill uC einfach nicht die Resourcen bieten um C++ einzusetzen. > C++ frisst eben ein mehrfaches an ressourcen. Wenn ich für jedes Mal, dass ich diesen Mythos hier sehe, eine Zeile Code schreiben würde, wäre mein Windows-Klon morgen fertig. Das ist natürlich Unsinn, man kann in C++ sehr effizient, teilweise effizienter als in C, programmieren, und dabei eine Menge Abstraktion, Wartbarkeit, Code-Wiederverwendbarkeit gegenüber C gewinnen. Man muss halt nur wissen, welche Dinge man nicht verwenden sollte (wie in C eben auch).
Kindergärtner schrieb: > Fpga Kuechle schrieb: >> Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp # >> teil hoch-levelt. > Das wäre ganz schön ungeschickt. Man lernt C++, C#, ... natürlich gleich > richtig. >> Erst C++ lernen und dann C ist irgendwie ... >> "weltfremd"? > Schlau, denn so vermeidet man alle schlechten C-Angewohnheiten wieder > vergessen zu müssen, wenn man mit einer richtigen Sprache anfängt. Mit C-lernen meine ich "if then for ++ =" .... mit C++ lernen virtuelle basisklassen, templates, Unterschied zwischen early und late name binding etc.. Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung auseinandersetzen sollte, bevor man die basic syntax drauf hat. Und diese Syntax ist bei C und C++ resp C# gleich (zumindest bis man overloading entdeckt hat ;-)) MfG,
Fpga Kuechle schrieb: > Mit C-lernen meine ich "if then for ++ =" .... Ach die absoluten Basics. Die kann man in C++ aber ganz exakt genauso lernen. > mit C++ lernen virtuelle basisklassen, templates, Unterschied zwischen > early und late name binding etc.. Ja, denn wenn man in C mit structs und Macros und solcher Frickelei anfängt, kann man in C++ direkt mit den entsprechenden richtigen Mechanismen anfangen. > Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung > auseinandersetzen sollte, bevor man die basic syntax drauf hat. Das habe ich auch nicht gesagt. Aber wenn man in C mit #define anfängt, kann man in C++ mit "const" anfangen; wenn man in C mit "void my_struct_init (struct MyStruct* s);" anfängt kann man in C++ mit "MyClass::MyClass()" anfangen etc., d.h. es gleich richtig machen. > Und diese Syntax ist > bei C und C++ resp C# gleich (zumindest bis man overloading entdeckt hat > ;-)) Nur braucht man für alles außer Hello World aber dann doch etwas mehr.
Robert L. schrieb: >> Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden >> und man nichtmehr auf eine Lib zurückgreifen kann. > > eigentlich ist es genau verkehrt, die meisten Problemstellungen sind so > Komplex, dass man überhaupt nicht in der Lage ist ist alles bis ins > letzte selber, neu und dann vielleicht auch noch in ASM zu erstellen.. > > (wie überall im Leben) basieren die Meisten Arbeiten, auf der Arbeit von > Anderen Das ist korrekt. Doch wer garantiert dir, dass für deine komplexe Anwendung eine Lib existiert? Gehen wir davon aus, du machst etwas total neues, wo dir auch keine Lib weiterhilft aber du wissen musst, wie ein uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich... Dann bist du mit C doof dran. Mir ist klar, solche Projekte trifft man in der Realität extrem selten an. Ich basiere mich wenn ich Programmiere auch immer auf vorhandene Sachen. Oder zumindest meistens. Trotzdem bin ich sehr froh darüber, dass ich die ersten 2 Jahre meiner Berufsbildung zum Elektroniker nicht einmal C angesehen habe sondern nur ASM programmiert habe. Vergleiche ich mein Verständniss mit demjenigen von Elektronik Lehrlingen aus dem Kanton Bern (Schweiz & ja, ich wohne in der Schweiz, Kanton Freiburg, direkt neben Bern), so ist mein Verständnis über uC's weitaus grösser, da in Bern direkt von Anfang an C programmiert wird. Als wir einmal Kurs hatten ging es darum, alle 500 mS ein Output zu Toggeln, Programmiersprache frei wählbar, allerdings durften Befehle wie DelayMs(500); (Je nach Compiler anders) nicht verwendet werden. Die Berner waren stunden lang beschäftigt mit ihrem Rumspielen, währenddem wir aus Freiburg für so eine Aufgabe ein paar Minuten hatten.
San Lue schrieb: > Gehen wir davon aus, du machst etwas total > neues, wo dir auch keine Lib weiterhilft aber du wissen musst, wie ein > uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich... > Dann bist du mit C doof dran. Sowas in der Art mache ich gerade, ich schreibe ein großes Projekt komplett in C++, schreibe meine eigenen Libraries, wo es noch keine fertigen gibt (zumindest keine benutzbaren bzw. bezahlbaren). Stimmt, C wäre doof, daher C++. Und tatsächlich gibt es eine handvoll inline ASM-Zeilen im Code. 99% sind aber C++, in Assembler wär das Projekt nicht fertig bevor die Sonne verglüht, und in allem was nicht C++ ist würde man eklige Code Generation brauchen. Auf "modernen" Architekturen braucht man praktisch kein Assembler mehr außer für ganz spezielle Dinge wie Kontext-Wechsel in Multitasking-Systemen oder Spezial-Instruktionen wie "WFI" (ARM), für die es aber garantiert Kapselungen durch Libraries des Herstellers gibt... San Lue schrieb: > Die > Berner waren stunden lang beschäftigt mit ihrem Rumspielen, währenddem > wir aus Freiburg für so eine Aufgabe ein paar Minuten hatten. Da würde ich in ein paar C++ Zeilen die Timer-Register beschreiben und hätte mein Toggeln superpräzise und effizient...
Hallo, Abschluss schrieb: > Ich denke, mit ASM hat man einen besseren Einstieg weil: > - CPU wird einem näher gebracht > - Keine verwirrenden Libs, welche einem sowieso nicht weiterhelfen sein > wissen zu erweitern > - Nur eine kleine Hand von Befehlssätzen -> Übersichtlich ich frage mich gerade, ob ich der einzige Mensch auf der Welt bin, der versteht, was ein "Anfänger" ist. Nämlich jemand, den die interne Funktion seiner CPU zunächst gar nicht interessiert, sondern der erstmal lernen muß, wie man einen Programmer an seinen Mikrocontroller anschließt und ihn mit dem Computer ansteuert, um ein Programm auf den uC zu schreiben. Schon damit haben Anfänger, die ich live erlebt habe, gewaltige Probleme gehabt. Die Leute in diesem Stadium -- wo es erstmal primär um handwerkliche Dinge und ein paar kleine Erfolgserlebnisse zur Motivation geht -- mit Wissen über die internen Funktionen der Hardware zu belasten, ist purer Wahnsinn! De facto muß man, um als Anfänger eine LED zum Blinken zu bringen, nicht wissen, wie die CPU intern funktioniert. Ich kenne viele professionelle und ausgesprochen fähige Entwickler mit jahrzehntelanger Erfahrung in der Entwicklung hochperformanter Anwendungen, die überhaupt keine Ahnung davon haben, wie ein Prozessor intern funktioniert und für die und deren Arbeit das auch vollkommen gleichgültig ist. Um Auto zu fahren, muß man auch nicht wissen, wie man einen Reifen wechselt. Das kann in bestimmten Situationen hilfreich sein, ist aber keine Voraussetzung. Und Fahranfänger werden mit auch nicht mit derlei überflüssigen Informationen belastet, und zwar aus guten Gründen: weil es nämlich überflüssig ist und sie nur von der eigentlichen Aufgabe ablenkt, ein Auto fahren zu lernen. Ich halte jemanden, der die C-Libraries für verwirrend hält, seinerseits für ein wenig verwirrt. Nein, mal im Ernst: Du hälst es (gerade auf einer uC-Plattform mit ihren äußerst eingeschränkten Debuggingmöglichkeiten) ernsthaft für weniger verwirrend, jeden popeligen Schritt von Hand machen zu müssen? Du glaubst wirklich, daß es für einen ANFÄNGER einfacher ist, eine sauber und korrekt funktionierende Delay-Routine in Assembler zu schreiben anstatt die betreffende Funktion aus util/delay.h zu verwenden? Das kann doch wohl nicht Dein Ernst sein. Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich ungefähr viermal leichter lernen als Assembler. Ich persönlich behaupte sogar, daß es sich mindestens achtmal leichter lernen läßt, nicht zuletzt weil es eine strukturierte und plattformunabhängige Programmiersprache ist und den Entwickler nicht zu unübersichtlichem Spaghetticode zwingt. Wie oben schon gesagt: es gibt Gründe, warum die Hochsprachen gewonnen haben. Beste Grüße, Karl
>wie ein >uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich... >Dann bist du mit C doof dran. nein, weil (auch wenn es keiner zugeben will) in ASM gleich mal schluss ist mit lustig, wenn es komplizierter wird man in ASM auch (erst recht) wieder mit "allgemeinen" wiederverwendbarem code arbeiten wird (macros) die (erst recht) wieder nicht optimiert sind usw.
Karl Käfer schrieb: > Ich halte jemanden, der die C-Libraries für verwirrend hält, seinerseits > für ein wenig verwirrt. Nein, mal im Ernst: Du hälst es (gerade auf > einer uC-Plattform mit ihren äußerst eingeschränkten > Debuggingmöglichkeiten) ernsthaft für weniger verwirrend, jeden > popeligen Schritt von Hand machen zu müssen? Du glaubst wirklich, daß es > für einen ANFÄNGER einfacher ist, eine sauber und korrekt > funktionierende Delay-Routine in Assembler zu schreiben anstatt die > betreffende Funktion aus util/delay.h zu verwenden? Das kann doch wohl > nicht Dein Ernst sein. Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern um µC und mit ASM versteht man die abläufe erst richtig. Und würdest du den thread hier verfolgen, es wurde mehrfach gesagt, das man mit ASM anfangen sollte (nicht dabei bleiben). Also bis zu einer Displayansteuerung, ein paar berechnungen und I/O geschichen (z.B. Blinklicht, USART, ADC und Timer). Dann sollte ein grundlegendes Verständniss aufgebaut sein von dem man aber auch in C profitiert. Dein Beispiel mit der Delay routine ist auch schön. Für jemanden der C lernen will sicherlich uninteressant, aber jemand der sich ernsthaft mit µC auseinander setzen will ein schönes Beispiel, was hinter so einer Funktion alles an überlegungen stecken (sofern das tutorial gut geschrieben ist).
Robin schrieb: > Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern > um µC und mit ASM versteht man die abläufe erst richtig. Und würdest du > den thread hier verfolgen, es wurde mehrfach gesagt, das man mit ASM > anfangen sollte (nicht dabei bleiben). Also bis zu einer Lies doch mal nicht nur immer die Titel sondern auch den Thread dazu denn genau um diese Fragestellung ging es den TO. Natürlich können wir jetzt erörtern ob der TO das besser formulieren könnte, aber wenn man seine Kollegen hier kennt würde auch bei einer besseren Formulierung nichts anderes hier herauskommen. C/ASM schrieb: > Mich würde die Meinung der Experten dazu interessieren: > Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? > Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? C/ASM schrieb: > Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber > nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich > zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche > Meinungen ansehen... C/ASM schrieb: > konrad M. schrieb: >> C parallel zur µC >> Hardware, etc. zu lernen stelle ich mir im Gegensatz zu ASM aufwändiger >> vor. > Das war ein Punkt meiner Überlegungen. Ein weiterer ist, dass IF, > Schleifen und Rechnungen >8bit in C einfacher sind als in ASM. Bei ASM > hat man nur eine Hand voll Befehle und bei C hat man Funktionen, > Pointer,... Also muss man erst C auf dem PC lernen, bevor man zum µC > übergeht, es kann also länger dauern bis zum Erfolgserlebnis (LED Blinkt > endlich), es könnte aber auch sein, dass ASM auf einen Anfänger komisch > und unlogisch wirkt. > > Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich > mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe > meiner Ausbildung gelernt. C/ASM schrieb: > Wenn ich einen anderen µC lerne würde ich in ASM anfangen, da ich wissen > will, was in der CPU so abgeht. Mick interessiert aber wie's für einen > kompletten Neueinsteiger aussieht. Was würde ihr einem anfänger > Empfehlen, der nach der Lösung für ein relativ einfache Projekt fragt?
Karl Käfer schrieb: > > Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise > für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich > also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen > lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich > ungefähr viermal leichter lernen als Assembler. Der war gut! Schon im C-Standardbeispiel hello_world.c reichen die 32 Schlüsselworte nicht aus, da muß man schon auf printf aus der Standard-IO library zurückgreifen. Ohne die Bibliotheken ist der C-programmierer auf dem selben Nivau wie ein assembler-programmiere ohne sys-calls resp BIOS-Einsprünge. Und um die man-page von printf durch trial und error komplett zu beherrschen, braucht ein Anfänger einige Stunden. Und die 130 Instruktionen gliedern sich in wenige Gruppen die sich nur durch die zu beachtenden Flags oder die Addressierungsart (direkt,regoster,mem,mem+offset,etc) unterscheiden. Abgesehen davon, das sich ein assembler-Befehl da wenig mächtig schneller verstehen lässt als ein for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--) Man kann den gesamten Befehlssatz und die Registerstruktur eines Z80 auf ein A4-Blatt im Normalfont erklären: http://www.didel.com/picg/calm/CalmZ80a.jpg Da lernt sich kein C viermal schneller als der Befehlssatz eines controllers. MfG
Fpga Kuechle schrieb: > for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--) Solche Beispiele sieht man ja immer wieder. Soll wohl demonstrieren wie kompliziert C im Vergleich zu ASM ist. Meine ASM Kenntnisse sind ein wenig eingerostet. Könnte vielleicht mal jemand eben dieses Beispiel in ASM Übersetzen? Sind ja bestimmt nur 5-6 Befehle.
Kindergärtner schrieb: > >> Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung >> auseinandersetzen sollte, bevor man die basic syntax drauf hat. > Das habe ich auch nicht gesagt. Aber wenn man in C mit #define anfängt, > kann man in C++ mit "const" anfangen; const gibt es auch in C; ANSI-C um korrekt zu sein. Ebenso inline, Zeilenkommentare etc. Was C schwer verständlich machen ist nicht die Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern als "cool". MfG
Moby schrieb: > Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0 > auf lernen"? Ja. unbedingt, siehe weiter unten. Also, lies doch erstmal den Text, bevor du in die Tasten haust. In besagtem Beitrag ging es um die herzlich falsche Ansicht von Eckhard, der da schrieb: "Diesen altertümlichen kram mit Debug ausgaben via UART sollte man sich einfahc nicht mehr antun." Und das ist tatsächlich ein Problem von Anfängern. Schau dich mal in diesem Forum um. Da siehst du massenweise Beiträge in der Art "Ich will mit µC anfangen und weiß noch garnix, also welche IDE muß ich jetzt lernen und wie kann ich damit debuggen?". Anstatt sich anzulesen, wie denn der auserwählte µC funktioniert, wird IMMER zu allererst nach IDE, Compiler, Debugger gefragt. Als ob DAS die Hauptsache wäre. Naja, mir ist schon klar, daß die meisten hier anwesenen C-Programmierer den Debugger brauchen, um wenigstens einigermaßen verstehen zu lernen, was sie denn da in C hingeschrieben haben und welchen Effekt das hat. Siehe Beiträge über mehrdimensionale Felder in C. Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den meisten Fällen viel erfolgversprechender. Er ist rein technisch auch der einfachere Weg - aber eben nur dann, wenn man nicht zu hochnäsig ist. So, du Moby, da hast du auf der falschen Kerbe herumgehackt. W.S.
W.S. schrieb: > Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum > Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den > meisten Fällen viel erfolgversprechender. Du wirst lachen, das habe ich auch schon empfohlen und mache es selber, wenn es mal was über einen gewissen Zeitraum zu überwachen gilt und eine LED nicht langt bzw. ein Display nicht in Frage kommt. Und dennoch, USB-Debugging- und welche anderen hochkarätigen Probleme Dir auch immer vorschweben mögen sind doch hier kein Thema. Nicht nur für den Anfänger ist ein Debugger mit viel umfangreicheren Möglichkeiten die klar bessere und elegantere Lösung, da hat der Eckhard doch recht.
Fpga Kuechle schrieb: > const gibt es auch in C; Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon), weswegen alle #define für Konstanten verwenden => hässlich & gefährlich > Was C schwer verständlich machen ist nicht die > Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern > als "cool". Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc resultieren unvermeidbar in unübersichtlichem langem Code.
Stefan schrieb: > Fpga Kuechle schrieb: >> for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--) > > Solche Beispiele sieht man ja immer wieder. Soll wohl demonstrieren wie > kompliziert C im Vergleich zu ASM ist. > > Meine ASM Kenntnisse sind ein wenig eingerostet. Könnte vielleicht mal > jemand eben dieses Beispiel in ASM Übersetzen? Sind ja bestimmt nur 5-6 > Befehle. Ja, in Assembler für einen VLIW-DSP wie den Texas Instruments TMS320C6400 schon. Instruction code zum Entrosten dort: http://www.ti.com/lit/ds/symlink/tms320dm642.pdf MfG,
Kindergärtner schrieb: > Fpga Kuechle schrieb: >> const gibt es auch in C; > Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon), > weswegen alle #define für Konstanten verwenden => hässlich & gefährlich >> Was C schwer verständlich machen ist nicht die >> Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern >> als "cool". > Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc > resultieren unvermeidbar in unübersichtlichem langem Code. Hm bei hardwarenahen Sachen die ich so in C zu schreiben hatte, ging es ohne C-Tretminen. Bspw. LCD-display an parallelport: http://www.mikrocontroller.net/articles/LCD_an_Parallelport
Fpga Kuechle schrieb: > Hm bei hardwarenahen Sachen die ich so in C zu schreiben hatte, ging es > ohne C-Tretminen. Bspw. LCD-display an parallelport: > http://www.mikrocontroller.net/articles/LCD_an_Parallelport Und was ist dann das da:
1 | #define Base 0x378
|
2 | #define Data Base
|
3 | #define Status Base+1
|
4 | #define Control Base+2
|
Wehe man kommt auf die Idee, in einer Funktion eine Variable namens "Data" zu definieren...! Sogar die Klammern hast du vergessen, wehe man schreibt 2*Control - das würde zu 2*0x378+2 werden (=0x6F2), und nicht 2*(0x378+2)=0x6F4 - d.h. 2*Control ist != 2*(Control). Ganz fatal ist das z.B. bei der CMSIS und der ST Standard Peripheral Library, die 1000000 #define's haben, und es so nur eine Frage der Zeit ist bis man versehentlich einen der Namen (wie z.B. "RCC") als Bezeichner (zB Variablennamen) nimmt und sich über obskure Fehlermeldungen wundert...
Hi, Kindergärtner schrieb: > Fpga Kuechle schrieb: >> const gibt es auch in C; > Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon), > weswegen alle #define für Konstanten verwenden => hässlich & gefährlich Man kann in C keine "const Arrays" anlegen? Wie gut das niemand das den "C Erfindern" & Compilerbauern gesagt hat! Sonst würden die ganzen Standadbibliotheken einen Fehler nach dem anderen schmeissen. (Const für Arrays ist etwas ganz übliches in C und wird vielfältig verwendet - auch und gerade in den ganzen Bibs) > Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc > resultieren unvermeidbar in unübersichtlichem langem Code. ICh lasse dir gerne deine Meinung, aber die werden nur wenige teilen. Das #define Argument ist ja hinfällig, das beruhte ja nur auf deinen mangelhaften Kenntnissen. Und ob für den großteil der üblichen µC Anwendungen ein Objektorientiertes Programm besser Lesbar ist wage ich mal zu bezweifeln. Wie gesagt, wir reden hier vom Einstieg in µC und nicht komplexen Datenbanksystemen auf dem PC. Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig verstanden haben. Und im Bezug auf µC sollte man vor dem sicher angebrachten Einstieg in C erst einmal etwas ASM getippt haben. Gruß Carsten
Carsten Sch. schrieb: > Man kann in C keine "const Arrays" anlegen? Keine Arrays mit "const" als Größe. Überzeuge dich selber: http://ideone.com/KQZiYu > Wie gut das niemand das den "C Erfindern" & Compilerbauern gesagt hat! Zumindest dem GCC wurde es gesagt. > Sonst würden die ganzen Standadbibliotheken einen Fehler nach dem > anderen schmeissen. Tun sie nicht, da sie #define verwenden. > ICh lasse dir gerne deine Meinung, aber die werden nur wenige teilen. > Das #define Argument ist ja hinfällig, das beruhte ja nur auf deinen > mangelhaften Kenntnissen. Oder vielleicht lassen dich deine mangelhaften Kenntnisse denken, dass das #define Argument hinfällig sei? > Und ob für den großteil der üblichen µC > Anwendungen ein Objektorientiertes Programm besser Lesbar ist wage ich > mal zu bezweifeln. Durchaus, denn Hardware-Einheiten wie z.B. GPIO-Pins lassen sich hervorragend als Objekte moddelieren. > Wie gesagt, wir reden hier vom Einstieg in µC und nicht komplexen > Datenbanksystemen auf dem PC. Auch da hilft OOP; auch wenn es die Anwendung selber gar nicht verwendet, sondern "nur" auf ein schönes OOP-API zugreift. > Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig > verstanden haben. Wie gesagt, besser nicht! Lieber gleich lernen wie es in C++ richtig geht, damit man nicht nachträglich die C-Angewohnheiten wieder vergessen muss. Wenn man erstmal C++ kann und dann aus irgendwelchen Gründen C verwenden muss, fragt man sich warum man sich damit noch abgibt... >Und im Bezug auf µC sollte man vor dem sicher > angebrachten Einstieg in C erst einmal etwas ASM getippt haben. Das bezweifle ich und eine Menge der Poster in diesem Thread auch.
Kindergärtner schrieb: > Carsten Sch. schrieb: >> Man kann in C keine "const Arrays" anlegen? > Keine Arrays mit "const" als Größe. Überzeuge dich selber: > http://ideone.com/KQZiYu Ach DAS meinst du... Ja - das geht nicht. Aber von der Tatsache das dies ein relativer Spezialfall ist der gerade den Anfängern eher selten über den WEg läuft ist dies auch ein gutes Beispiel für ein großes Missverständniss das aber wohl häufiger auftritt. Const als Modifier bezeichnet ja keinesfalls eine KONSTANTE sondern bedeutet nur das ein WErt vom Programm nicht verändert werden darf. Damit wird sichergestellt das kein Programm kompiliert wird wo die Variable nach der Definition noch einmal verändert wird. Das ist deshalb ein großer unterschied weil die Variable formal gesehen erst zur Laufzeit definiert wird und so dem Präprozesser welcher die Arraygröße kennen will nicht zur Verfügung steht. Aber auch das kann man umgehen - Auch ohne #define Wobei ich #define jetzt nicht so schlimm finde. Allerdings gebe ich zu das es manchmal aus gründen der gültigkeit (Define ist ja immer "global") in gewissen Situationen kontraproduktiv ist. Also wen das #define in dieser Situation stört, der nimmt einfach "enum". > Auch da hilft OOP; auch wenn es die Anwendung selber gar nicht > verwendet, sondern "nur" auf ein schönes OOP-API zugreift. Dieses Argument gilt aber nur wenn es eine OOP API gibt. Und das ist in der µC Welt zur Zeit einfach die Ausnahme! >> Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig >> verstanden haben. > Wie gesagt, besser nicht! Lieber gleich lernen wie es in C++ richtig > geht, damit man nicht nachträglich die C-Angewohnheiten wieder vergessen > muss. Und deshalb fängt fast jedes C++ Buch und so gut wie jeder C++ Kurs erst einmal mit C an? Genauso ist bei wohl fast allen Studiengängen (egal ob Inf. oder ET) im Bereich Programmiersprachen die Reihenfolge: erst C dann Objektorientiert (Java oder C++) > Wenn man erstmal C++ kann und dann aus irgendwelchen Gründen C > verwenden muss, fragt man sich warum man sich damit noch abgibt... Sehe ich anders... Ich kann beides und habe bevor ich mit C auf µC angefangen bin viel mehr C++ als reines C programmiert. Aber auf dem µC komme ich für die Projekte die ich üblicherweise bearbeite mit C besser und schneller zum Ziel. Wenn ich denn doch mal eine PC Anwendung selber schreiben muss dann verwende ich dort allerdings C++ (wobei PC Programmierung bei mir mittlerweile die Ausnahme ist, höchstens mal noch ein kleines Hilfstool, der Rest wird vergeben) Zudem kommt noch dazu das man sich mit der Festlegung auf C++ enorm einschränken würde. Im Moment ist C++ unter den µC noch kaum vertreten, bei den kleineren Exemplaren fast gar nicht vorhanden. Und da wo es C++ Compiler gibt sind die nicht selten noch im einen eher frühen Stadium. Man würde sich selbst also massivst die Auswahl beschränken. >>Und im Bezug auf µC sollte man vor dem sicher >> angebrachten Einstieg in C erst einmal etwas ASM getippt haben. > Das bezweifle ich und eine Menge der Poster in diesem Thread auch. Aber die Absolute Minderheit! Und von den ZWeiflern raten fast alle dann direkt zu C und nicht zu C++. Als letzte Anmerkung von mir noch: Weiter oben beschreibst du die HArdwarenähe von C als NACHTEIL. Da ist aber GERADE der große Vorteil. Wo es auf dem PC wirklich eher kontraproduktiv für die meisten Anwendungen ist, so braucht man das auf dem µC immer noch oft um halbwegs effektiven Code zu schreiben. Sicherlich kännte man immer zu den dicksten und Stromhungrigsten µC Greifen, aber selbst bei Cortex M3 oder PIC32 die durchaus auch mal 100Mhz Takt haben können ist man Leistungsmäßig schnell an einer Grenze wenn man all zu Abstrakt ohne Rücksicht auf die Hardware programmiert. Mir kommt es irgendwie so vor als wenn du beim Wort µC eher an etwas in Richtung Rasperry Pi als an einen AVR (Meinetwegen auch CortexM3) denkst... Gruß Carsten
:
Bearbeitet durch User
Carsten Sch. schrieb: > Ach DAS meinst du... > Ja - das geht nicht. Aber von der Tatsache das dies ein relativer > Spezialfall ist Ja. Aber das ist die einzige Rechtfertigung für #define-Minenfelder. Carsten Sch. schrieb: > Const als Modifier bezeichnet ja keinesfalls eine KONSTANTE sondern > bedeutet nur das ein WErt vom Programm nicht verändert werden darf. > Damit wird sichergestellt das kein Programm kompiliert wird wo die > Variable nach der Definition noch einmal verändert wird. In C ja; in C++ sind Konstanten konstant und zur Kompiletime bekannt und können daher für Arraygrößen verwendet werden. Carsten Sch. schrieb: > so dem Präprozesser welcher die > Arraygröße kennen will nicht zur Verfügung steht. Der Preprocessor kennt keine Arrays, das braucht nur der Compiler. Und in C++ stehen sie eben doch zur Verfügung. Carsten Sch. schrieb: > Aber auch das kann man umgehen - Auch ohne #define > Wobei ich #define jetzt nicht so schlimm finde Mich nervts tierisch, wenn von so Libraries wie die CMSIS 100000 Bezeichner global reserviert sind und die Scoping-Regeln und namespaces nicht greifen. Carsten Sch. schrieb: > Also wen das #define in dieser Situation stört, der nimmt einfach > "enum". Erzähl das mal ARM oder ST. Und das geht auch nur für Integer. Carsten Sch. schrieb: > Dieses Argument gilt aber nur wenn es eine OOP API gibt. Und das ist in > der µC Welt zur Zeit einfach die Ausnahme! Ja, warum auch immer. Denn wie gesagt könnte das sehr elegant und praktisch sein. Carsten Sch. schrieb: > Und deshalb fängt fast jedes C++ Buch und so gut wie jeder C++ Kurs erst > einmal mit C an? Das Galileo-Buch vielleicht, aber es gibt genug die sowas nicht machen. > Genauso ist bei wohl fast allen Studiengängen (egal ob Inf. oder ET) > im Bereich Programmiersprachen die Reihenfolge: erst C > dann Objektorientiert (Java oder C++) Nope. In Informatik wird aus gutem Grund C kaum noch gelehrt, sondern direkt z.B. Java. In den ganzen anderen Naturwissenschaften (inkl. ET) wird leider noch überall C gelehrt, wahrscheinlich weil die Lehrkräfte selber nichts anderes kennen und auch nicht die Motivation hatten, seit ihrer eigenen Studienzeit noch etwas anderes außer C zu lernen. Carsten Sch. schrieb: > Aber auf dem µC komme ich für die > Projekte die ich üblicherweise bearbeite mit C besser und schneller zum > Ziel. Dann kannst du es halt nicht :D Carsten Sch. schrieb: > Und da wo es C++ > Compiler gibt sind die nicht selten noch im einen eher frühen Stadium. > Man würde sich selbst also massivst die Auswahl beschränken. Auf allen Plattformen für die es einen GCC oder Clang gibt (und das sind einige) hat man somit einen sehr guten C++ Compiler. Eigentlich sind die beiden onehin die besten C++ Compiler überhaupt. Carsten Sch. schrieb: > Zudem kommt noch dazu das man sich mit der Festlegung auf C++ enorm > einschränken würde. Ja, kein PIC und 8051, wie... schade. Carsten Sch. schrieb: > Und von den ZWeiflern raten fast alle dann direkt zu C und nicht zu C++. Immer noch besser als ASM... Carsten Sch. schrieb: > Als letzte Anmerkung von mir noch: Weiter oben beschreibst du die > HArdwarenähe von C als NACHTEIL. Keineswegs. Ich beschreibe die mangelnden Möglichkeiten und so krude Dinge wie Textersetzung als Mittel zur Abstraktion als Nachteil. C++ ist genauso hardwarenah. > Wo es auf dem PC wirklich eher kontraproduktiv für die meisten > Anwendungen ist, so braucht man das auf dem µC immer noch oft um > halbwegs effektiven Code zu schreiben. Dafür ist C++ wunderbar geeignet. > Sicherlich kännte man immer zu > den dicksten und Stromhungrigsten µC Greifen, aber selbst bei Cortex M3 > oder PIC32 die durchaus auch mal 100Mhz Takt haben können ist man > Leistungsmäßig schnell an einer Grenze wenn man all zu Abstrakt ohne > Rücksicht auf die Hardware programmiert. Ineffizient programmieren kann man auch in C. Abstrakt und effizient aber nur in C++. Carsten Sch. schrieb: > Mir kommt es irgendwie so vor als wenn du beim Wort µC eher an etwas in > Richtung Rasperry Pi als an einen AVR (Meinetwegen auch CortexM3) > denkst... Nö, C++ kann man auch wunderbar auf Mega8 verwenden, nicht umsonst basiert z.B. Arduino darauf (wobei deren Libraries noch einiges Optimierungspotential haben).
µC von 0 auf lernen. ASM oder C? Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben: Natürlich ASM! Nur ASM! Mit C steigt man doch erst auf sehr viel späterer, abstrakterer Stufe ein!
Karl Käfer schrieb: > Um Auto zu fahren, muß man > auch nicht wissen, wie man einen Reifen wechselt. Das kann in bestimmten > Situationen hilfreich sein, ist aber keine Voraussetzung. Und > Fahranfänger werden mit auch nicht mit derlei überflüssigen > Informationen belastet, und zwar aus guten Gründen: weil es nämlich > überflüssig ist und sie nur von der eigentlichen Aufgabe ablenkt, ein > Auto fahren zu lernen. Hm. Und wie sieht es mit den Verkehrsregeln aus? Lenken die auch davon ab, Auto fahren zu lernen? ;) Im ernst, das beispiel ist nicht schlecht und ich Stimme dir zu, man kann auch ohne ASM Kentnisse Programmieren. Man kann aber auch ohne Theoriekentnisse Auto fahren, trotzdem wirst du mühe haben in grösseren Städten zu fahren, wenn du die Vortrittsregeln nicht kennst. Karl Käfer schrieb: > ich frage mich gerade, ob ich der einzige Mensch auf der Welt bin, der > versteht, was ein "Anfänger" ist. Nämlich jemand, den die interne > Funktion seiner CPU zunächst gar nicht interessiert, sondern der erstmal > lernen muß, wie man einen Programmer an seinen Mikrocontroller > anschließt und ihn mit dem Computer ansteuert, um ein Programm auf den > uC zu schreiben. Achja? Sind das Anfänger? Weiss ja nicht was du so gelernt hast,aber ich hätte in meiner Berufslehre zum Elektroniker die ersten 8 Monate zwar X-mal einen uC in der Hand, programmiert haben wir den aber nie. Wieso? Weil uns jeden Donnerstag Nachmittag beigebracht wurde, was ein uC ist, wie er funktioniert, welche Register er bietet, was er kann usw. Als es dann ums Programmieren ging, war das eine grosse hilfe, da sich dann Fragen von Beispielsweise "Wie initialisiere ich den Clock richtig?" erübrigten und man sich lediglich die ASM befehle aneignen musste. Karl Käfer schrieb: > Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise > für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Und aus diesen 130 Instruktionen lassen sich Gruppen bilden, und schwupp - schon sind es um einige weniger. Willst mir nicht sagen dass zwischen einem btfsc btfss ein riesen unterschied besteht? Zudem braucht man in ASM nur eine Hand voll von diesen Befehlen.
C/ASM schrieb: > Mich würde die Meinung der Experten dazu interessieren: > Was denkt ihr ist für einen Anfänger ... Reichlich Antworten und mich wundert immer wieder, was für "Experten" darunter sind. Deren Meinung ist auch nur von "Experten" zu verstehen. Da sind mir Anfänger mit einer gesunden Selbsteinschätzung lieber.
Hi Einfach Klasse, wie hier jeder seine Programmierkenntnisse in irgendeiner Sprache verteidigt und auch die Argumente, einfach handfest... Leute, der TO ist schon längst nicht mehr im Spiel. Er hat sich entweder voll zufrieden wieder mal ein Streitthema angestoßen zu haben zurückgelehnt oder ist eurer emsigen Erklärungswut überdrüssig. Ich kann auch nicht verstehen, was diese Diskussion bringen soll. Ein totaler Anfänger, also, einer der bei 0 anfängt, hat nicht nur das Problem, eine Sprache zu lernen, sondern muss sich auch ein wenig mit Elektrotechnik und Elektronik auseinander setzen. übrigens, es bringt ihm gar nichts, wenn er diese Frage beantwortet bekommt und er nicht in der Lage ist, eine Aufgabe in programmierbare Befehlssequenzen umzusetzen. Wenn er Probleme hat, eine einfache Aufgabe in Assembler umzusetzen, wird er dieselben Probleme in jeder anderen Sprache auch haben. Das belegen tausend Beiträge in diesem Forum. Aber diskutiert weiter völlig wertlose Thematik. Und bleibt schön beim erlernten eures Studieninhaltes. Behaltet gut den Tellerrand im Auge, denn dahinter geht es gnadenlos in den Abgrund. Weiterhin viel Spaß Gruß oldmax
Hallo Robin, Robin schrieb: > Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern > um µC und mit ASM versteht man die abläufe erst richtig. Lies bitte einmal das Posting zu dem Thread-Titel: genau das war nämlich die Frage, um die es hier geht. Und daß man nur mit einem Einstieg über ASM "die abläufe erst richtig versteht", ist nichts weiter als eine unbewiesene Behauptung, die durch ihre ständige Wiederholung weder bewiesen, noch wahrer wird. Anders gesagt: auch wer mit C anfängt kann die Abläufe verstehen, und auch wer mit ASM anfängt kann die Abläufe verpassen. Ob man die Abläufe versteht, liegt nicht an der Programmiersprache. Vermutlich ist die Wahrscheinlichkeit, daß ein ASM-Anfänger etwas verpaßt oder sich etwas Falsches zusammenreimt, aufgrund von ASMs unstrukturiertem Spaghetticode sogar höher, als wenn jemand die grobe Sache mit C erlernt und sich erst dann um die Feinheiten mit ASM kümmert. Den menschlichen Gehirn kommen klar erkennbare Strukturen sehr entgegen, was im Übrigen einer der Gründe dafür ist, daß sich Hochsprachen wie C gegenüber den Assemblersprachen durchgesetzt haben und man in Hochsprachen sehr viel produktiver arbeiten kann als in Assemblersprachen. Mir ist letztlich vollkommen schleierhaft, wie und warum Du (und andere) fortwährend die Ansprüche "Anfänger" und "abläufe erst richtig verstehen" vermengst. Das wesentliche Merkmal der Problemstellung "Anfänger" ist es doch, zunächst einmal die groben Abläufe lernen zu müssen -- von "richtig verstehen" könnte das ganze Konzept "Anfänger" nicht weiter entfernt sein. Selbst wenn es tatsächlich so wäre, daß man nur mit Assembler "die abläufe erst richtig verstehen" kann -- was diesseits bezweifelt wird --, wäre das noch keine Aussage im Zusammenhang mit dem Apkekt "Anfänger". "Anfänger" und "richtig verstehen" stehen also in direktem Widerspruch und schließen einander exklusiv aus , kurz: "Anfänger" XOR "richtig verstehen". > Und würdest du den thread hier verfolgen, es wurde mehrfach gesagt, das > man mit ASM anfangen sollte (nicht dabei bleiben). Würdest Du den Thread hier verfolgen: es wurde auch mehrfach gesagt, daß man mit C anfangen sollte und nicht dabei bleiben. Übrigens auch von mir. Insofern wäre es schön, wenn Du auf meine Argumente in der Sache eingehen könntest. Vielen Dank. Beste Grüße, Karl
Hallo Fpga, Fpga Kuechle schrieb: > Karl Käfer schrieb: >> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise >> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich >> also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen >> lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich >> ungefähr viermal leichter lernen als Assembler. > > Der war gut! Ja, aber leider nicht meiner. > Schon im C-Standardbeispiel hello_world.c reichen die 32 Schlüsselworte > nicht aus, da muß man schon auf printf aus der Standard-IO library > zurückgreifen. Ohne die Bibliotheken ist der C-programmierer auf dem > selben Nivau wie ein assembler-programmiere ohne sys-calls resp > BIOS-Einsprünge. Und um die man-page von printf durch trial und error > komplett zu beherrschen, braucht ein Anfänger einige Stunden. printf() auf einem Mikrocontroller? Also der war jetzt wirklich noch besser, aber leider wieder nicht meiner. Das "Hello world" auf uCs ist doch wohl, eine LED blinken zu lassen, zu C:
1 | #define F_CPU 1000000
|
2 | #include <avr/io.h> |
3 | #include <util/delay.h> |
4 | |
5 | int main(void) { |
6 | DDRB = 0b00000001; |
7 | while(1) { |
8 | PORTB ^= 0b00000001; |
9 | _delay_ms(500); |
10 | }
|
11 | }
|
So, und jetzt zeigst Du mir das bitte mal in Assembler. Wenn Du Dich das traust, werden wir sicher schnell sehen, welcher der beiden Quelltexte kürzer, übersichtlicher, verständlicher und anfängertauglicher ist. Ach so: schau bitte ehrlich, wie lange Du für Deinen Assembler-Code brauchst, den C-Code habe ich in 86 Sekunden heruntergetippt. > Abgesehen davon, das > sich ein assembler-Befehl da wenig mächtig schneller verstehen lässt als > ein > for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--) Die Standardversion sieht ein bisschen anders aus, nicht wahr? Es ist ein wenig lächerlich, sich hier eine willkürlich komplizierte Anweisung heraus zu suchen und dann über ihre Kompliziertheit zu moppern. Aber da Du gerade dieses Beispiel gebracht hast: poste hier doch bitte mal den äquivalenten Assemblercode. Vielen Dank. Beste Grüße, Karl
Hallo W.S., W.S. schrieb: > Und das ist tatsächlich ein Problem von Anfängern. Schau dich mal in > diesem Forum um. Da siehst du massenweise Beiträge in der Art "Ich > will mit µC anfangen und weiß noch garnix, also welche IDE muß ich jetzt > lernen und wie kann ich damit debuggen?". > > Anstatt sich anzulesen, wie denn der auserwählte µC funktioniert, wird > IMMER zu allererst nach IDE, Compiler, Debugger gefragt. Als ob DAS die > Hauptsache wäre. Für einen, Achtung: ANFÄNGER! ist das die Hauptsache. Denn der kann sich wochenlang anlesen, wie der auserwählte µC funktioniert, aber solange er weder weiß, wie er aus dem Quellcode etwas macht, das er auf den µC schreiben, noch, wie er das dann auf den µC schreiben und dort ausführen kann, hilft ihm sein ganzes Wissen über die interne Funktion des µC überhaupt gar nichts. > Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum > Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den > meisten Fällen viel erfolgversprechender. Müßte man dazu nicht erstmal einen Quelltext übersetzen und diesen auf den Mikrocontroller bringen? Ach, ja, genau. Da war doch was. Warum wird hier von der Assemblerfraktion ständig über das Verständnis der internen Funktionen geredet? Das geht doch an der diskutierten Thematik ("Anfänger") meilenweit vorbei. Beste Grüße, Karl
blink in ASM http://conelek.org/AVR_Assembler:_LED_blinkt >for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--) warum ist das komlex/kompliziert ? im gegensatz zu ASM weiß man hier ganz genau dass es eine schleife ist wo sie anfäng und wo sie aufhört {...} was am anfang passiert (j = i-1) was nach jedem durchlauf passiert (j--) das einzige "kompilzierte" ist jetzt die bedingung für mich ist es tatsächlich "schwierig" weil ich Klammern machen würde also (j>= 0) && (k[j] > k[j+1]) damit ist es wesentlich schneller erfassbar.. (vorallem wenn man normalerweise pascal programmiert, und dort die Rangfolge der Operatoren anders ist.. wie man das jetzt NOCH einfacher darstellen will?? mir fällt nix ein..
Ich denke das Problem vieler Anfaenger ist nicht wirklich, ob sie mit C oder Assembler anfangen, sondern, dass sie ohne jedes Grundwissen ueber Computer anfangen. Auch wenn verschiedene Zahlensysteme eigentlich Schulstoff sind, wissen doch viele der Anfaenger hier kaum was ein Bit ist, geschweige denn, was AND/OR/XOR tun. Da wird dann ein einfaches LED-Blinkbeispiel, egal in welcher Sprache, ploetzlich schwierig. Natuerlich wusste ich das auch nicht, als ich vor 3 Jahrzehnten angefangen habe. Damals stieg ich mit Basic ein. Fuer die ersten Wochen ging es noch ohne und viel mehr als kleine Rechenprogramme oder infantile Textausgaben sind auch erst Einmal nicht dabei heraus gekommen. Aber die Literatur die ich damals hatte, deckte dann doch auch die Grundlagen ab, wie der Computer ueberhaupt funktioniert, was Bits und Bytes sind und was Speicher eigentlich ist. Spaeter in der Schule war Pascal die Einstiegssprache und es hat mich schon da verwundert, dass solche Grundlagen dort keine Rolle gespielt haben. Der Anspruch an das Thema EDV war viel abstrakter und versuchte wohl wissenschaftlicher zu wirken, unter Auslassung solcher Details. Ein guter Teil der Informatik folgt diesem Trend und setzt ihn im Studium fort. Und in der Tat muss man in einem grossen Teil der Softwareentwicklung sehr wenig ueber die Maschine wissen, braucht kein C oder C++. Und das funktioniert auch problemlos ueber ein ganzes Berufsleben hinweg. Aber es ist eben immer die Frage, auf welches Umfeld man guckt: Waehrend der durchschnittliche Mikrocontroller-Entwickler dem Enterprise-Entwickler ob seiner Wissensluecken Inkompetenz vorwirft, ist er aus Sicht des Enterprise-Entwicklers ebenso Inkompetent. Als Grenzgaenger zwischen beiden Welten komme ich in den Genuss, ob der Scheuklappen beider Welten zu erschauern. Wichtiger als die Frage, ob nun Assembler auf dem Mikrocontroller oder C auf dem PC der bessere Einstieg ist (oder vielleicht doch besser Basic um ohne viel Ballast ein grundlegendes Verstaendnis fuer Algorithmen zu entwickeln), waere ein guter Buchtipp. In welchem Buch kann sich ein Laie heute ueberhaupt in die Grundlagen von Computersystemen einlesen? In Trivialitaeten wie "Was ist ein Bit und ein Byte", "Wie rechnet ein Computer", "Was sind Verknuepfungen", ...
Zum AVR kann ich nicht viel sagen, wir habe in der Schule mit PIC16 in ASM angefangen. Der hat nur 35 Befehle, von denen viele ähnlich aufgebaut sind: z.B. andwf, addwf, iorwf. ICh habe nachgeschaut, wir haben für das erste Programm nur 11 davon gebraucht. Diese 35/11 Befehle denk ich sind einfacher zu Lernen als C. Ich weiß es nicht mehr genau, aber nach ca. 6 Stunden Theorie ging‘s auf ins Labor und wir habe ein Lauflicht programmiert.
Um die Maschine zu verstehen muss man keine Zeile in Assembler programmiert haben. C ist eine schöne Möglichkeit strukturierte Programmierung zu lernen ohne zu sehr von der darunterliegenden Maschine abstrahiert zu sein. Falls es notwendig ist z.b. SIMD,DSP,FPU-Instruktionen zu verwenden die der Compiler nicht einsetzen kann, unterstützt jeder taugliche C-Compiler Inline-Assembly. Kontrollstrukturen in Assembler sind so sinnvoll wie Brainf***. Eine nette Denkübung, aber im Grunde ein vollkommen nutzloser Skill.
Hallo Lollipop, Lollipop schrieb: > µC von 0 auf lernen. ASM oder C? > > Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben: > > Natürlich ASM! Nur ASM! > Mit C steigt man doch erst auf sehr viel späterer, abstrakterer Stufe > ein! Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben: Natürlich C! Nur C! Mit ASM steigt man doch erst sehr viel später ein, wenn es um spezielle Optimierungen für eine bestimmte Plattform geht. Liebe Grüße, Karl PS: Solange Du Deine Aussage nicht sachlich begründest, bleibt sie wertlos. Wenn Du genau hinschaust, enthält meine Antwort sogar schon mehr sachliche Begründung als Deine.
>1 | > #define F_CPU 1000000 |
2 | > #include <avr/io.h> |
3 | > #include <util/delay.h> |
4 | >
|
5 | > int main(void) { |
6 | > DDRB = 0b00000001; |
7 | > while(1) { |
8 | > PORTB ^= 0b00000001; |
9 | > _delay_ms(500); |
10 | > } |
11 | > } |
12 | >
|
deine aufgabenbeschreibung ist mehrdeutig ?Was meint DDRB - alias für general - purpose register, Speicheraddresse RAM, Speicheradresse Flash, special function register, IO- data port??? ?was meint PORTB???? ?was tut _delay_ms: CPU-sleep, cycle-count?? ?wie soll es das tun:timer-irq, WDT-irq, dummy count, dummy port read ?wie sollen die paramter übergeben werden (register?, Stack?, Speicher?) Das ist ein Nachteil abstrakter C-programmierung. Außer einem allgemeinen "wert x wird zu zelle|register y geschrieben" ist die Funktion nicht erkennbar. Erst nach Studium der includierten .H, auflösen aller defines, und abchecken des linkers wird klar was wirklich passiert. Dazu ist es notwendig mal auf den assembler-code zu schauen. Der C-Schnipsel sieht zwar klar und knapp aus, verstanden werden kann er aber nur durch eine menge von impliziten wissen. Nach dem wie du die Fragen oben beantwortest, kann der Code so der so aussehen, beispielsweise : (pseudomnemnonic: 1.op destination, 2.op source, GPA is dataregister of Port B )
1 | main_entry: |
2 | ST $1234,x01 ;store x01 in memcell addr 1234 |
3 | |
4 | loop: |
5 | ;toogle line #0 at port B |
6 | LD R01,GPA ;got data register of PORTB |
7 | XOR R01,x01 ;toggle bit #0 only |
8 | LD GPA,R01 ;activate data out at PORTB |
9 | |
10 | ;wait 500 ms |
11 | LD R01,x01 |
12 | LD R02,xF4 ;parameter 500 |
13 | CALL sub_delay |
14 | JP loop ;endless loop |
15 | |
16 | |
17 | org main_entry 0x00 |
oder völlig anders, je nach dem was sich in den includes, symbol tables des linkers etc versteckt. wie gesagt, deine Beschreibung ist zu unvollständig als daraus eindeutig einen assemblercode zu genrieren. Auf die benutzung von parametrisierten Makros, beispielsweise zur vereinfachten Aufruf von Funktionen habe ich verzichtet, da für einen lernenden das vollständige verständnis der uc-funktionsweise im Vordergrund steht, nicht wie zu sehen entsteht die lesbarkeit und die beschreibung der Funktion nicht durch die beschreibungssprache sondern durch schreibstil und kommentare, bei C benötigt man noch einiges in Libs und defines verstecktes hintergrundwissen. Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell der Code (taktanzahl)ist und was er an Speicher (register, scratchpad) er benötigt. das sieht man im C-code nicht, und kann es u.U. dort garnicht sehen, weil der Compiler je Speichermodell, konvention f. paramterübergabe (register,Stack) etc anderen code generiert. Somit kann ein Lernender nur am assemblercode sehen, wie optimal sein programm ist. In C sieht man dergleichen nicht, dazu muss man einen Blick in den ASM-Code werfen. MfG
Hallo San Lue, San Lue schrieb: > Karl Käfer schrieb: >> Um Auto zu fahren, muß man auch nicht wissen, wie man einen Reifen >> wechselt. Das kann in bestimmten Situationen hilfreich sein, ist aber >> keine Voraussetzung. > > Hm. Und wie sieht es mit den Verkehrsregeln aus? Lenken die auch davon > ab, Auto fahren zu lernen? ;) Als ich damit angefangen habe, Autofahren zu lernen, kannte ich die Verkehrsregeln auch noch nicht. Erst während ich gelernt habe, Auto zu fahren, habe ich auch die Verkehrsregeln gelernt. Keine Ahnung, wie man heute Autofahren lernt: wird denn da auch erstmal die komplette Theorie gemacht, bevor die erste praktische Fahrstunde ansteht? Das war bei mir damals jedenfalls nicht so. > Im ernst, das beispiel ist nicht schlecht und ich Stimme dir zu, man > kann auch ohne ASM Kentnisse Programmieren. Man kann aber auch ohne > Theoriekentnisse Auto fahren, trotzdem wirst du mühe haben in grösseren > Städten zu fahren, wenn du die Vortrittsregeln nicht kennst. Wenn wir das Beispiel des Autofahrens auf größere Städte ausweiten, dann müssen wir für den uC-Bereich auch annehmen, daß unser Anfänger sofort aus dem Stand öffentlich ein Produkt anbietet und vor einer Programmiersprache erstmal die VDE lernen muß... Du kannst ein Beispiel nicht willkürlich verbiegen, nur damit es Dir in den Kram paßt. > Karl Käfer schrieb: > Achja? Sind das Anfänger? Weiss ja nicht was du so gelernt hast,aber ich > hätte in meiner Berufslehre zum Elektroniker die ersten 8 Monate zwar > X-mal einen uC in der Hand, programmiert haben wir den aber nie. Wieso? > Weil uns jeden Donnerstag Nachmittag beigebracht wurde, was ein uC ist, > wie er funktioniert, welche Register er bietet, was er kann usw. Aha. Du hast das also gelernt, weil Du mußtest und weil Du keine Wahl gehabt hast. Wenn Du gedurft hättest, wie Du sicherlich gerne wolltest, hättest Du erstmal so einen uC in die Hand genommen und eine LED damit blinken lassen. > Als es dann ums Programmieren ging, war das eine grosse hilfe, da sich > dann Fragen von Beispielsweise "Wie initialisiere ich den Clock > richtig?" erübrigten und man sich lediglich die ASM befehle aneignen > musste. Abstraktion scheint für viele der Assemblerfreunde hier ja wirklich ein großes Problem zu sein. Sonst würden sie nicht immer nur von ihrem eigenen kleinen Horizont ausgehen, sondern könnten von der eigenen Erfahrungen auf die Wünsche und Bedürfnisse von anderen Menschen abstrahieren. Oder anders gesagt: nur weil Du in Deiner Ausbildung dazu gezwungen worden bist, Dich zuerst einmal monatelang durch langweilige, weitestgehend unwichtige und theoretische Prozessorinterna zu quälen, macht das dieses Vorgehen noch lange nicht zu einer guten Idee und schon gar nicht empfehlenswert für andere Menschen. Weißt Du, ich habe Pneumatik in ähnlich langweiliger, demotivierender und quälender Weise gelernt wie Du die uC-Programmierung: erstmal monatelang theoretische Vorlesungen und Übungen, bis uns das Thema allen zum Halse heraus hing. Und erst, als wir alle keine Lust mehr auf das Ding hatten, durften wir an unsere ersten Schaltungen. Keine Frage, wir haben das sehr gründlich gelernt, aber die Art und Weise, wie wir es gelernt haben, war Scheiße und hat uns jede Freude daran genommen. Deswegen würde ich diesen Lernweg auch keinem Menschen empfehlen, außer, ich kann ihn nicht leiden. > Karl Käfer schrieb: >> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise >> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. > > Und aus diesen 130 Instruktionen lassen sich Gruppen bilden, und schwupp > - schon sind es um einige weniger. Willst mir nicht sagen dass zwischen > einem > btfsc > btfss > ein riesen unterschied besteht? Zudem braucht man in ASM nur eine Hand > voll von diesen Befehlen. Üblicherweise braucht man in C auch nur eine Handvoll von den 32 Schlüsselworten. Aber darum ging es ja nicht, und das war nicht mein Argument. Mir ging es nur darum, zu demonstrieren, wie dumm und falsch das Pseudoargument des angeblch größeren Sprachschatzes in C ist. Und, wie gesagt: menschliche Gehirne kommen mit Strukturierung und Abstraktion viel besser klar als mit hardwarenahem Spaghetticode. Beste Grüße, Karl
Hi, Karl Käfer schrieb: > Mit ASM steigt man doch erst sehr viel später ein, wenn es um spezielle > Optimierungen für eine bestimmte Plattform geht. JA - Und genau DAS, also Otimierungen für eine bestimmte Plattform, ist doch der UMSTIEG auf den µC. PROGRAMMIEREN als Vorgang, insbesondere das Methodische Vorgehen - aber auch das generelle Arbeiten mit Entwicklungsumgebungen sollte man Sinnigerweise doch zuerst auf dem PC erlernen. Erst wenn dieser Schritt getan ist macht der Umstieg auf den µC wirklich Sinn. Natürlich gibt es immer ein paar die meinen den Schritt der Übung am PC sei nicht notwendig. Aber sicher 99% von denen machen es sich nur unnötig schwer und werden ohne die Zeit am PC nachzuholen nie einen stand erreichen wo die wirklich gut sind. Die "auch" ASM Befürworter hier (zumindest die meisten) schreiben doch nicht das man mit ASM Anfangen soll zu Programmieren. Das empfohlene Vorgehen beim Ziel -Ich will µC beschreiben- ist: 1. Schritt: Lerne die Grundlagen von C am PC! 2. Schritt: Mache dich mit den BESONDERHEITEN der µC Programmierung vertraut, dazu sind einige ASM Übungen sehr Hilfreich. (Für die Ungeduldigen ggf. dieser Schritt parallel zu der C Phase am PC.) Teilweise wird für den einen oder anderen im Bezug auf Pointer usw. auch erst hier wirklich ein Licht aufgehen. 3. Schritt: if ((C_Grundlagen == VERSTANDEN) && (µC_Besonderheiten == VERSTANDEN)) { Einsteig_und weiteres_Arbeiten_mit_C_auf_µC(); } Gruß Carsten
> Warum wird hier von der Assemblerfraktion ständig über das Verständnis > der internen Funktionen geredet? Weil man genau das unter "uC (mikrocontroller - Anm. des Autors) von 0 lernen" im Unterschied zu "programmieren lernen" versteht. MfG
Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit dem Pinsel oder mit der Rolle an?" A1: "Mit dem Pinsel natürlich. Nur so lernst Du Farbe und Wand richtig kennen". A2: "So ein Unsinn. Mit der Rolle natürlich. Keiner braucht heute mehr einen Pinsel. Das ist für alte Leute." A3: "Wer eine Rolle benutzt, will einen Neger haben, der ihm die Ecke nachstreicht, um dann mit seiner tollen Leistung beim Chef zu glänzen." A4: "Für praktische Belange brauchst Du eh beides. Wer eine Ganze Wand mit dme Pinsel streicht ist ein Masochist"... Kerkerker, so eine Diskussion kann man sich nicht ausdenken, das muß man erleben. Und so sinnlos. Der TO will beides machen und fragt lediglich, womit man am besten anfängt. Und Antwort ist so einfach: Wenn man mit AVR anfängt, dann mit ASM, weil da das Tutorial hier auf µC.net besser ist. Dann kennt man schon alle Peripherie, wenn man mit C weitermacht. Wenn man mit ARM anfängt, dann mit C, weil da gute Tutorials existieren und man sich für den ASM-Teil mehr zusammensuchen muß, wobei es dann von Vorteil ist, den anderen Teil schon zu kennen. Wie kann man sich an der Frage so aufhängen, wo noch nicht einmal Freitag ist?
Hallo Fpga, Fpga Kuechle schrieb: > deine aufgabenbeschreibung ist mehrdeutig Nein, eigentlich nicht. Denn die Auswahl der Hardwareplattform geht allem anderen, auch der Auswahl eines Assemblers oder Compilers, ja voraus. Und spätestens wenn es darum geht, konkreten Code zu schreiben, sind all diese Mehrdeutigkeiten für unseren Anfänger dann natürlich längst beantwortet. Als erfahrener Entwickler kannst Du Dir jede Deiner konstruierten Fragen natürlich selbst beantworten, deshalb ging ich davon aus, Dir diese Dinge nicht erklären zu müssen. Du mußt Dich nicht künstlich dumm stellen, nur um zu versuchen, doch noch irgendwie Recht zu behalten. > Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell > der Code (taktanzahl)ist und was er an Speicher (register, scratchpad) > er benötigt. Diese Information ist für einen Anfänger ungefähr so hilfreich wie ein dritter Bauchnabel. Sogar für Fortgeschrittene und Profis ist das nur in relativ wenigen Situationen wirklich nötig. Dies ganz abgesehen davon, daß das, was Du da behauptest, natürlich wieder einmal in Deinem Sinne... sagen wir mal: etwas geschönt ist. Denn manche Assemblerinstruktionen benötigen mehr als einen Takt, einige sogar je nach Bedingung unterschiedliche Anzahlen von Takten. Ganz offensichtlich ist es also nicht direkt sichtbar, wieviele Takte der Code braucht. Beste Grüße, Karl
Walter Tarpan schrieb: > Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit > dem Pinsel oder mit der Rolle an?" Der Vergleich hinkt. Mit einer Rolle kannst du wie mit einem Pinsel direkt loslegen uns musst nicht die Rollen Syntax erst lernen. Carsten Sch. schrieb: > 1. Schritt: > Lerne die Grundlagen von C am PC! > > 2. Schritt: > Mache dich mit den BESONDERHEITEN der µC Programmierung vertraut, dazu > sind einige ASM Übungen sehr Hilfreich. > (Für die Ungeduldigen ggf. dieser Schritt parallel zu der C Phase am > PC.) Teilweise wird für den einen oder anderen im Bezug auf Pointer usw. > auch erst hier wirklich ein Licht aufgehen. > > 3. Schritt: > if ((C_Grundlagen == VERSTANDEN) && (µC_Besonderheiten == VERSTANDEN)) > { > Einsteig_und weiteres_Arbeiten_mit_C_auf_µC(); > } Wenn man mit ASM einsteigt, spart man sich den ersten Schritt… Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM Programmieren könnten und umgekehrt...
Hi Carsten, Carsten Sch. schrieb: > JA - Und genau DAS, also Otimierungen für eine bestimmte Plattform, ist > doch der UMSTIEG auf den µC. Und sogar auf uC ist ASM nur in wenigen, seltenen Fällen notwendig und C für Anfänger erstmal vollkommen ausreichend. > Die "auch" ASM Befürworter hier (zumindest die meisten) schreiben doch > nicht das man mit ASM Anfangen soll zu Programmieren. Mit den "auch ASM Befürwortern" habe ich auch kein Problem, schließlich bin ich selbst einer. Aber einige hier empfehlen einem Anfänger ohne jede Vorkenntnis von Mikrocontrollern und ohne Vorkenntnis von Programmierung, beides mit Assembler anzufangen. Genau um solche Anfänger geht es doch: C/ASM schrieb: > Wenn ich einen anderen µC lerne würde ich in ASM anfangen, da ich wissen > will, was in der CPU so abgeht. Mick interessiert aber wie's für einen > kompletten Neueinsteiger aussieht. Was würde ihr einem anfänger > Empfehlen, der nach der Lösung für ein relativ einfache Projekt fragt? Beste Grüße, Karl
Max H. schrieb: > Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM > Programmieren könnten und umgekehrt... Volltreffer ;) Ich mag beides (und habe noch mit Maschinencodes angefangen ;)
Hallo Max, Max H. schrieb: > Wenn man mit ASM einsteigt, spart man sich den ersten Schritt… Und den sollte man sich sparen, weil...? > Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM > Programmieren könnten und umgekehrt... Seit dem VC 20 selig. Kannst Du denn C? Beste Grüße, Karl
Karl Käfer schrieb: > #define F_CPU 1000000 > #include <avr/io.h> > #include <util/delay.h> > > int main(void) { > DDRB = 0b00000001; > while(1) { > PORTB ^= 0b00000001; > _delay_ms(500); > } > } include "m8def.inc" .def temp0 = r16 ; .def temp1 = r17 ; .def temp2 = r18 .def temp3 = r19 ; .def temp4 = r20 .cseg .org $0000 rjmp stack stack: ldi temp1,high(ramend) ;Stackpointer festlegen out sph, temp1 ldi temp1,low(ramend) ;Stackpointer festlegen out spl, temp1 sbi ddrd,0 start: sbi portd,0 rcall wait500ms cbi portd,0 rcall wait500ms rjmp start wait500ms: ldi temp1,$05 wait500ms1: ldi temp2,$63 wait500ms2: rcall wait1ms dec temp2 brne wait500ms2 dec temp1 brne wait500ms1 ret wait1ms:ldi temp3,$06 wait1ms1: ldi temp4,$df wait1ms2: dec temp4 brne wait1ms2 dec temp3 brne wait1ms1 ret so siehts in ASM aus ohne zu verheimmlichen das kleine helfer die libs in C auch erstellt haben. Würde man das in ASM tun, ich glaube dann kommt man auf das selbe raus.
Karl Käfer schrieb: > Und den sollte man sich sparen, weil man in ASM keine C-Kentnisse brauch Karl Käfer schrieb: > Kannst Du denn C? Ja Ob man mit C oder mit ASM schneller zum ersten Erfolgserlebnis (z.B. blinkende LED) kommt hängt davon ab wie man vorgeht. -Wenn man erst die C Grundlagen lernt und dann mit dem µC beginnt, ist man mit ASM natürlich schneller. -Wenn man die C-Grundlagen auf dem µC lernen will, wird man vllt. schneller zur blinkenden LED kommen. Danach kann es dazu kommen: TriHexagon schrieb: > Threads wo der Threadstarter klare > Grundlagendefizite hat, sich weigert diese endlich mal auszumerzen und > lieber weiter am LCD rumspielt gibs hier jeden Tag. Ich denke ob C oder ASM für die einstieg besser ist, hängt vom angepeilten Projekt ab. Wenn es ein Einfaches ist, kommt man mit ASM schneller zu Ziel, di wie bereits erwähnt, die C-Grundlagen wegfallen. Bei komplexeren Programmen kann man mit C viel Zeit sparen, die man in die C-Basics investieren kann.
Max H. schrieb: > Walter Tarpan schrieb: >> Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit >> dem Pinsel oder mit der Rolle an?" > Der Vergleich hinkt. Mit einer Rolle kannst du wie mit einem Pinsel > direkt loslegen uns musst nicht die Rollen Syntax erst lernen. > > [...] Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst. Macht aber nichts. Es soll sogar Leute geben, die nicht einmal kochen können.
Walter Tarpan schrieb: > Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst. Das kann sein, bin Elektroniker und kein Anstreicher. Ich habe vor ca. einem Monat ein Gehäuse angestrichen. Mit dem Pinsel ging‘s nicht so gut, dann habe ich mit eine Rolle gekauft und das Ergebnis des ersten Versuchs mit der Rolle war besser als, das Beste mit dem Pinsel. Noch ein vllt. passendes Beispiel: Wenn jemand ein anderes Land in den Urlaub fährt und nur an Stand liegen und nicht verhungern will, soll er erst die Sprache lernen oder versuchen sich mit Handzeichen usw. zu verständigen? Wenn er hingegen das Land und die Leute kennenlernen will, sollte er vorher die Sprache lernen.
:
Bearbeitet durch User
Walter Tarpan schrieb: > Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst. > Macht aber nichts. Es soll sogar Leute geben, die nicht einmal kochen > können. Walter 1 : 0 Max Ganz im ernst. Diese Diskussion führt ins endlose. Max H. schrieb: > Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM > Programmieren könnten und umgekehrt... Kannst davon ausgehen, nicht die hälfte der Leute die C können, könnten etwas in ASM Programmieren. Auch bei theoretischen Fragen um den uC, da es laut dem Autor nicht ums Programmieren geht, sondern um den Verständnissaufbau von uC's, kannst du daovn ausgehen dass Leute die ASM beherrschen den reinen C kennern meilenweit vorraus sind. Klar, viele Leute interessiert das wohl nicht. Aber wenn es darum geht, den uC an sich kennen zu lernen, wird man mit ASM besser bedient sein. Soll doch mal einer von den C Kennern schreiben, wie lange es dauert ein Bit eines Portes zu setzen, bei einem Takt von 20MHz mit einem PIC16F887. Datenblätter lesen solltet ihr ja können ;)
Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas anderes als kleine Progrämmchen, die einfache Aufgaben übernehmen, auf dem µC geschrieben. Schon mal einen FAT32 Treiber in ASM geschrieben? Nein? Warum sollte man sich so etwas auch antun? ASM für kleine und einfache Aufgaben völlig ausreichend, aber wenn es um komplexe und größere Programme geht, ist ASM einfach inakzeptabel. Dafür wurde C konzipiert und da sich kleine Programme genau so gut mit C schreiben lassen, warum nicht also auch dort benutzen? Das ist zwar so ziemlich OffTopic, musste aber unbedingt mal gesagt sein.
Karl Käfer schrieb: > Hallo Fpga, > > Fpga Kuechle schrieb: >> deine aufgabenbeschreibung ist mehrdeutig > > Nein, eigentlich nicht. Denn die Auswahl der Hardwareplattform geht > allem anderen, auch der Auswahl eines Assemblers oder Compilers, ja > voraus. Nein, bei der Produktentwicklung erst wird die Auswahl an uC anhand der elektrischen paramter/Funktionen eingeschränkt, dann zieht man die Aufwände und Nutzen einer SW-Entwicklungsumgebung als weiters Kriterium an. Auch im Hobbybereich wurdeen AVR und PIC eingesetzt bevor es C-Compiler für diese gab. > Und spätestens wenn es darum geht, konkreten Code zu schreiben, > sind all diese Mehrdeutigkeiten für unseren Anfänger dann natürlich > längst beantwortet. > > Als erfahrener Entwickler kannst Du Dir jede Deiner konstruierten Fragen > natürlich selbst beantworten, deshalb ging ich davon aus, Dir diese > Dinge nicht erklären zu müssen. Du mußt Dich nicht künstlich dumm > stellen, nur um zu versuchen, doch noch irgendwie Recht zu behalten. Nein, ich stell mich nicht dumm. Ich zeige dir nur auf, das dein kurz ausschauender Quelltext eine Menge implizititen Wissens zum Verständnis bedarf, was in einem Assemblercode sichtbar ist. Und all das implizite Wissen was man sich nicht aus dem C-Code erschliessen kann, bekommt man, fängt man Assembler an, auf den Silbertablett serviert. Als Erklärbeispiel fürs bit-toggeln ein wenig geeigneter Code-schnipsel. >> Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell >> der Code (taktanzahl)ist und was er an Speicher (register, scratchpad) >> er benötigt. > > Diese Information ist für einen Anfänger ungefähr so hilfreich wie ein > dritter Bauchnabel. Sogar für Fortgeschrittene und Profis ist das nur in > relativ wenigen Situationen wirklich nötig. Deine Behauptung - meine Erfahrung lehrt mich anderes. Gerade Anfängern sollte man ein Instrument an die Hand geben die Effizient des eigenen Codes bewerten zu können. > Dies ganz abgesehen davon, daß das, was Du da behauptest, natürlich > wieder einmal in Deinem Sinne... sagen wir mal: etwas geschönt ist. Denn > manche Assemblerinstruktionen benötigen mehr als einen Takt, einige > sogar je nach Bedingung unterschiedliche Anzahlen von Takten. Ganz > offensichtlich ist es also nicht direkt sichtbar, wieviele Takte der > Code braucht. Ich schöne nicht, Du unterstellst. Nimm die Anzahl der cyclen pro befehl und addiere sie zusammen- bei Sprüngen kommt noch etwas Sadistik dazu, ober ob nun der Sprungbefehl am Ende einer Schleife die 8chtmal durchlaufen wird insgesamt 8 oder 9 Cyclen in der CPU aktiv war ist bei Abschätzungen vernachlässigba.r Abgesehen davonn davon das die meisten Befehle eines uC nur einen Takt benötigen. In C sind die Assemblerbefehle nicht ersichtlich ist und zudem von commandlineoptionen etc abhängig. (bspw. Art der Parameterübergabe). MfG, BTW
1 | PORTB ^= 0b00000001; |
Ich glaube, das kein Anfänger hier erkennt, das dieses Konstrukt den logischen einzig ein Pin "wackeln" lässt. Erst im Assemblercode wird das klar, dem "^=" sieht man das nun wahrlich nicht an - das ist für Anfänger "obfuscated". Ein
1 | PORTB = PORTB ^ 0b00000001; //toggles bit 0 |
ist didaktisch empfehlenswerter. MfG,
TriHexagon schrieb: > Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas Es gibt keine Nur-ASM Fraktion, du sprichst ins Leere. MfG
Wie man bei diesem Thema ziemlich sicher immer vom Hundertsten ins Tausendste kommt! Genauso ziemlich sicher war das auch nicht der letzte der gefühlt 10000 Threads zu diesem Thema. Zu unterschiedlich sind die Bedürfnisse, Erwartungen, Empfindsamkeiten, Vorlieben, Interpretationsmöglichkeiten der Wortwahl der "Gegner", Vorkenntnisse, Erfordernisse im Beruf, Vorhaben und schließlich realisierte Projekte... Dazu hat jede Programmiersprache ihr Für und Wider und in einer Diskussion wie dieser gibts immer dann einen Konflikt, wenn das gegnerische Für und das eigene Wider im Blick durch die oben aufgezählten Gegebenheiten der individuellen Brille nicht ausreichend gewürdigt/ zur Kenntnis genommen wird.
Hi >Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas >anderes als kleine Progrämmchen,... Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay, Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der Größenordnung 12-13k Programm. Solche Kleinigkeiten Beitrag "Re: Zeigt her Eure Kunstwerke !" kommen mit wesentlich weniger aus. >Warum sollte man sich so etwas auch antun? Wo ist das Problem? Ich habe eine ganz Reihe eigener Libs (Text- Grafikdisplays, Sensoren, Kommunikation incl. Ethernet, Mathefunktionen, Zeit-/ Datumsfunktionen mit Oster-/Feiertagsberechnung, ....). Da hält sich der Aufwand für das eigentliche Programm stark in Grenzen. Das soll jetzt kein Pro oder Kontra für irgend eine Programmiersprache sein. ASM ist die persönliche Entscheidung für mich. Womit andere programmieren geht mir meilenweit an der hinteren Körperöffnung vorbei. Genauso wie Missionierungsversuche mit allein seligmachenden Programmiersprachen oder Controller. MfG Spess
Fpga Kuechle schrieb: > Es gibt keine Nur-ASM Fraktion, Falsch. Es mögen ja nicht sehr viele sein. Aber es gibt sie. Leute, die auch größere Programme in Asm schreiben. Das kann als Hobby durchaus Spaß machen. Wenn man ein sinnvolles, effizientes, funktionelles, einheitliches Programmsystem mit einem fertigen Fundus an Routinen für alles, was man so an Schnittstellen, Berechnungen usw. braucht entwickelt hat dann sinkt auch der Zeitbedarf. Allerdings beschränkt man sich für Asm sinnvollerweise auf wenige Controller-Typen einer Reihe. Das muß, je nach Art der Projekte, auch kein Nachteil sein.
Hallo Fpga, Fpga Kuechle schrieb: > Nein, bei der Produktentwicklung Anfänger und Produktentwicklung... finde den Fehler. ;-) > Auch im Hobbybereich wurdeen AVR und PIC eingesetzt bevor es C-Compiler > für diese gab. Niemand hat bestritten, daß man Mikrocontroller auch in ASM programmieren kann. Die hier diskutierte Frage ist aber eine andere. > Nein, ich stell mich nicht dumm. Ich zeige dir nur auf, das dein kurz > ausschauender Quelltext eine Menge implizititen Wissens zum Verständnis > bedarf, was in einem Assemblercode sichtbar ist. Findest Du? Trotz meiner Erfahrung mußte sogar ich den Assemblercode von chris aufmerksam lesen, um ihn zu verstehen. Jeder Anfänger wäre damit heillos überfordert -- aber meinen C-Code versteht auch ein Anfänger spätestens er den ^=-Operator nachgeschaut hat. Dabei ist mein C-Code nicht einmal äquivalent zum Assembler-Code, denn ich benutze ein OR und chris' ASM-Code nicht... > Deine Behauptung - meine Erfahrung lehrt mich anderes. Gerade Anfängern > sollte man ein Instrument an die Hand geben die Effizient des eigenen > Codes bewerten zu können. Ein typischer Anfänger kann das weder in ASM noch in C. Um die Effizienz beurteilen zu können, braucht man Erfahrung und genaue Messungen -- also genau das, was einem Anfänger gemeinhin abgeht. > Ich schöne nicht, Du unterstellst. Nimm die Anzahl der cyclen pro befehl > und addiere sie zusammen- bei Sprüngen kommt noch etwas Sadistik dazu, > ober ob nun der Sprungbefehl am Ende einer Schleife die 8chtmal > durchlaufen wird insgesamt 8 oder 9 Cyclen in der CPU aktiv war ist bei > Abschätzungen vernachlässigba.r Abgesehen davonn davon das die meisten > Befehle eines uC nur einen Takt benötigen. In C sind die > Assemblerbefehle nicht ersichtlich ist und zudem von commandlineoptionen > etc abhängig. (bspw. Art der Parameterübergabe). Man kann auch in C ganz gut abschätzen, wie viele Takte eine Operation braucht. Dies ganz davon abgesehen, daß das für die meisten Anfänger vollkommen irrelevant ist. Aber wenn das der große Vorteil von Assembler sein soll, ist es den Aufwand dem unstrukturierten Spaghetticode nicht wert -- und schon gar nicht für einen Anfänger. Erschwerend kommt hinzu, daß jeder Interrupt die ganze schöne Abschätzung sofort zunichte macht. Entschuldige, aber Du redest die ganze Zeit von Anforderungen, die sogar einem Profi vergleichsweise selten begegnen, um damit zu begründen, warum Anfänger mit Assembler anfangen sollten. Dabei bauen sogar die Profis ihre Software in C, und schreiben höchstens mal zeitkritische Teile in ASM -- wenn sie nicht einfach auf einen schnelleren Controller ausweichen, weil das nämlich häufig immer noch billiger als die Entwicklung und Wartung von Assembler-Code. >
1 | > PORTB ^= 0b00000001; |
2 | >
|
> > Ich glaube, das kein Anfänger hier erkennt, das dieses Konstrukt den > logischen einzig ein Pin "wackeln" lässt. Ich bin überzeugt, daß das jeder Anfänger versteht, der [+-*/%]= und den ^-Operator kennengelernt hat. Das ist ja nun wirklich keine große Magie -- jedenfalls weniger Magie als die Unterschiede zwischen jmp, rjmp, ijmp und eijmp. Wenn Du Magie sehen willst, schau Dir mal Perl an <eg>. Beste Grüße, Karl
Ich möchte dazu auch meine bescheidene Meinung abgeben. IMHO ist es für einen Anfänger auf jeden Fall leichter C zu lernen, zumindestens wenn er schon eine andere Hochsprache kennt. Bei mir war es so, dass ich mit Small Basic (ja, überhaupt keine Optimierung) angefangen habe. Dann kam der Umstieg auf OOP mit Java, um danach erst anzufangen in C/C++ Progrämmchen (Hello World und simplere Pointerarithmetik) zu schreiben. Dann kam relativ schnell (durch Hochhochsprachen wie Java kennt man schon recht viel, vor allen Dingen hat man jedoch ein allgemeines Verständnis für Programme und Informationsquellen) der Umstieg auf Arduino, um dann auf das Stellaris Launchpad umzusteigen. Bei dem CortexM4 war für mich eigentlich sofort klar, dass ich C benutzen werde, da die driverlib, die TI kostenlos mitgibt, wirklich seeeehr angenehm ist. Es ist mittlerweile tatsächlich so, dass ASM sehr selten verwendet wird, da es in größeren Softwareprojekten, die auch im Hobby irgendwann auftreten, nicht praktikabel ist, in absehbarer Zeit (die Entwicklung einer dafür nötigen ASM Library nimmt Monate in Anspruch) Fortschritt zu machen. Ich vermute mal, dass mir (fast) jeder zustimmen wird, dass C auf Dauer leichter ist als ASM, da man einfach utility Funktionen hat, die einem ungeheuer Arbeit abnehmen. (Ich vermisse ja schon die zigtausend Hilfsklassen in Java, von daher mache ich mich gar nicht an ASM ran ;) )
C/ASM schrieb: > Mich würde die Meinung der Experten dazu interessieren: > Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher? > Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen? Das ist die Steilvorlage für etwas das früher Flamewar genannt wurde und zu vielen Texten in Grossbuchstaben führte. Jeder hier wird versuchen "seinen Weg" als die einzig mögliche Lösung zu präsentieren. Schnupper hier und da mal rein und bleib da wo es gefällt. Du selbst must Entscheidungen treffen. Und das geht nicht nur auf Basis fremder Erfahrungen, da muß auch ein wenig "Eigenkapital" dabei sein. Viel Erfolg und auch viel Spass dabei!
Ich selber schließe mich ja keiner der Gruppen fest an, da ich denke, dass C im späteren Programmierleben unabdingbar ist, niemand will größere Projekte rein in ASM schreiben. Aber das ist doch für die Diskussion hier vollkommen irrelevant?! Es geht doch darum, dass heute ein GROßTEIL der Leute recht faul ist und schnell ans Ziel kommen will. Deshalb muss unbedingt mit leicht veständlichem C angefangen werden (Ja, in C ist die oberflächliche Programmfunktion leichter zu verstehen). Das führt dann eben dazu, dass alle unsere tollen Softwareentwickler keinen Dunst haben, was sie da eigentlich tun und was der µC bei manchen Befehlen im Hintergrund schwitzen muss. Bei uns gab es soooo viele Leute, die einfach nette Divisionen in ihren Code geballert haben (wieso, ist doch am Computer auch kein Problem!!??11) und sich gefragt haben, wieso denn das Programm im Ablauf nicht schnell genug hinterher kommt. Wenn man dann mit dem Wissen über die Funktionsweise eines µC (die man beim Programmieren mit ASM gelernt hat) aufzeigt, dass z.B. eine Division durch Potenzen von 2 durch einen Rechtsshift viiiel schneller gehen, dann schauen die Leute doof aus der Wäsche (das ist ja nur eines von vielen Beispielen, es geht mir hier ums Prinzip). Klar, C ist leichter. Aber wenn man immer nur den Weg des kleinsten Widerstandes geht und jegliche Mühe scheut, sich mal mit den Hintergründen zu beschäftigen, dann kann das ja nur in die Hose gehen... Also mein Tipp: Lieber zunächst ein wenig Zeit investieren und erstmal verstehen, wie so ein Prozessor funktioniert (was doch sowieso viel spannender ist als zeilenweise blöder Code) und DANN kann man auch anständig mit der Programmierung beginnen =)
spess53 schrieb: > Hi > ... > > Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay, > Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der > Größenordnung 12-13k Programm. > > Solche Kleinigkeiten > > Beitrag "Re: Zeigt her Eure Kunstwerke !" > > kommen mit wesentlich weniger aus. Zitat: > Eigentlich sollte die auf eine SD-Karte (Slot vorhanden). >Aber igendwie ist mir dann am Kartenstückeln die Lust ausgegangen. und "beweist" damit, alles was ich oben geschrieben habe.. der faule, dumme arduino zusammenstöppsler hätte das schreiben/lesen auf SD karte in 5 minuten erledigt.. (und er hätte ein farb-touch LCD, nur mal so am rande.. nicht so ein grausliches S/W ding) das für 20% der kosten, ;-) (jaja OT, und nicht ganz Ernst gemein!)
:
Bearbeitet durch User
Ohne alles gelesen zu haben: C/C++ ist eine wichtige Programmiersprache, auch in Zeiten von Java & Co. Ich habe damals C und µC "gleichzeitig" gelernt, auf einem AT908535 (heute: Mega32), unter Verwendung von einem Texteditor, makefiles und WinAVR, AVR Studio gab es noch nicht. Mittlerweile bin ich beruflich als auch privat auf ARM Cortex sowie Windows-Programmierung unterwegs.
Hi >> Eigentlich sollte die auf eine SD-Karte (Slot vorhanden). >>Aber igendwie ist mir dann am Kartenstückeln die Lust ausgegangen. >und "beweist" damit, alles was ich oben geschrieben habe.. >der faule, dumme arduiono zusammenstöppsler hätte das schreiben/lesen >auf SD karte in 5 minuten erledigt.. Das hast du falsch verstanden. Nicht das Schreiben oder Lesen der SD-Karte war das Problem. War schon längst gegessen. Das Problem lag einfach im verfügbaren Kartenmaterial. >(und er hätte ein farb-touch LCD, nur mal so am rande.. nicht so ein >grausliches S/W ding) Kann man 2014 leicht sagen. Das Teil ist ca. 2004 entstanden. MfG Spess
Hallo Freunde Dieser Thread ist so lang, dass ich vielleicht doch etwas überlesen habe. ich will jedoch meinen senf dazugeben. Annahme: uC von 0 lernen, ASM oder C? Der angesprochene der Fragestellung plant erstmals sich mit µC zu beschäftigen, weil: 1. Berufsanfänger oder junger Mensch 2. beruflich nutzbar 3. Hobby Elektroniker will auch µC in sein Spektrum aufnehmen, eigentlich hardware orientiert. 4. Hobby Elektroniker der "embedded" Syteme entwickeln will 5. Hobby Elektroniker oder Programmierer der kein Fokus auf "embedded" hat Der unter 5. genannte Typ ist nicht in meinen Fokus bei diesem Beitrag. Der unter 3. genannte Typ ist sicher mit ASM nicht verkehrt gelagert trtzdem könnten die Informationen von Nutzen sein;1 Der unter 1. genannte Typ kann zum typ 3. oder 5. gehören, dann trifft das auf ihn zu, kann aber auch unter die verbleibenden kategorien gehören die ich gezielt hiermit adressiere. Die µC sind durch die Folgen der Miniaturisierung in eine interessante Situatio geraten. Die größe des Siliziums in einem µC wird heute mehr durch den bedarf an Pins bestimmt, als durch den Inhalt, englisch statt "core limited", "pad limited". Die Kosten für eine Fertigung von ICs, bei angenommen vergleichbarer Anzahl von Prozessschritten, wird durch den Wafer, also der Scheibe des Silizium-Kristalls bestimmt und dadurch wieviele funktionsfäige ICs aus einem solchen wafer gewonnen werden. Als Folge dieser Kostenstruktur ergeben sich die möglichen Preise für ICs in einem wettbewerbsintensiven Marktumgebung. µC für die embedded Anwendung sind definitiv ein solcher Markt. Dadurch ergibt sich für den Fertiger das Problem, womit er das Silizium in einem IC füllt. Natürlich wird die Ausbeute größer, wenn der Kern nicht voll genutzt wird, aber das ist in erster Näherung betrachtet vernachlässigbar. Dadurch folgt aber, das der Kostenvorteil von µC mit 8 oder 16 Bit breiten Datenstrukturen früher ergab, als eben Designs "Core limited" und nicht "Pad limited" waren, verloren geht, wenn man diese mit modernen Architekturen, wie eben die ARM Cortex Mx mit ihrer 32 Bit Architektur, vergleicht. Die zusätzliche Chip-Fläche ist eh verfügbar und noch "frei" die sich aus der Folge der Vervierfachung oder Verdoppelung der Datenbusse und Datenstrukturen ergibt und damit quasi kostenlos! Die Vorteile aber sind bestechlich! Zuerst mal die höhere Leistungsfähigkeit moderner Architekturen, eben z. B. ARM Cortex Mx im Vergleich zu einem Avnet oder PIC mit 8 oder 16 bit Architektur und den schon in die jahre gekommenen Architekturen. Das hat aber eine Menge Konsequenzen und die möchte ich anghand der ARM Cortex Mx im Allgemeinen und der von NXP im besonderen betrachten, sowie die Konsequenzen der Fragestellung in diesem Thread! Grundsätzlich gibt es 2 Konsequenzen aus einem Wechsel von einer 8 oder 16 Bit Architektur zu einer 32 Bit Architektur: 1. Die Leistungsfähigkeit steigt. 2. Der Leistungsbedarf kann weiter sinken. Die höhere mögliche Leistungsfähigkeit einer 32 Bit Architektur und einer solchen modernen wie die von ARM Cortex µC ist evident. Nicht so evident ist der unter 2. genannte geringere Leistungsverbrauch! Lasst uns annehmen ein Avnet AVR mega8 oder ein entsprechender µC vom Typ PIC haben eine bestimmte Aufgabe zu bewältigen und die nehme 100% der Leistungsfähigkeit dieser µC in Anspruch. Diese µC sind also 100% der Zeit beschäftigt. Ein ARM Cortex Mx erledigt diese Aufgabe in einem Bruchteil der Zeit. Während ein µC aktiv ist, ist sein Leistungsbedarf hoch, wenn er aber nicht aktiv ist, so kann sein Leistungsbedarf massiv gesenkt werden. Betrachtet man also den Leistungsbedarf einer Schaltung, so ist der resultierende Leistungsverbrauch der modernen Architektur geringer. Aber auch wenn man Leistungsverbrauch senkende Elemente in die Designs einführt, so bleibt bei gleichen Annahmen der mögliche resultierende Leistungsbedarf der bei einem ARM Cortex Mx, hier besonders solche vom typ M0 oder sogar M0+, geringer. Zusammengefasst: Ohne höhere Kosten kann eine ARM Cortex Mx Implementation eines µC sowohl die Annahme unter 1. und ". erfüllen. Jetzt möchte ich mich der ursprünglichen Fragestellung von "C", gleich Hochsprache" versus ASM nähern und hierbei die ARM Cortex Mx und jene von NXP heranziehen, trifft aber eigentlich auf alle ARM Cortex Mx Lieferanten zu! Bei den traditionellen Architekturen, z. B. Avnet AVR oder PIC, hat man mit Systemen auf Silizium zu tun, welche die verfügbaren Ressourcen sehr begrenzt bereitstellen und die daher sehr davon profitieren, wenn der Programmierer "seinen µC" bis zum letzten Bit und Register beherrscht, kennt und versteht. Man möge sich an die frühen Zeiten der Rechner erinnern, wo man wegen begrenzter Ressourcen "Spagetti Kode" schrieb und z. B. beim Datum mit nur 2 Stellen beim Jahr in das Millenium Problem geriet! Das trifft auf moderne ARM Cortex Mx Implementationen so nicht mehr zu! Betonung für Puristen unter den Lesern auf das Wort "so"! Auch ich kann mir Dinge vorstellen wo das so nicht gilt! Der embedded Markt durchläuft immernoch eine Revolution, die Konsequenz der Möglichkeiten dieser modernen Architekturen im Allgemeinen und der ARM im Besonderen. Er wird immer komplexer, immer umfangreicher! Betrachtet man jetzt die ARM Cortex Mx µC, so gibt es eine Reihe von Faktoren und daraus resultierender Folgen die für unsere Fragestellung eindeutig für die Hochsprache sprechen und die Vorteile der profunden und detaillierten Kenntnis der Bits und Register in einem µC, wie sie automatisch bei einer ASM Programmierung erforderlich sind, in eine geringere Bedeutung und wodurch solche detallierten kenntnisse einen geringeren Nutzen bringen! Alle ARM Cortex Mx µC, egal von welchem Hersteller, stammen aus der IP Schmiede von ARM. Und alle Lizenznehmer müssen die Lizenzbedingungen von ARM für seine ARM Cortex Mx Kerne erfüllen! Die Folge ist die Vergleichbarkeit und auch der relativ einfache Wechsel von einem Lieferanten zu einem Anderen, wenn der Systemdesigner bestimmte Regeln einhält. Ein Faktor für unsere Fragestellung ist die gemeinsame API die im CMSIS Bibliotheken realisiert wird. Greift ein Programmierer auf die Peripherie in einem ARM Cortex Mx über CMSIS zu, so kann sein Programm mit geringem Aufwand auf den ARM Cortex Mx eines anderen Herstellers portiert werden, solange dort die verwendeten Peripherie-Funktionen ebenfalls verfügbar sind! Eine Hersteller unabhängige API, vom Lizenzgeber ARM vorgegeben und in der verpflichtend vom Hersteller bereitzustellenden API für die auf dem jeweiligen µC vorhandenen Peripherie-Funktionen macht die Notwendigkeit die profunde und detaillierte Kenntnis der Bits und Register zu haben für den Programmierer weniger wichtig. Damit ein starkes Argument für die Hochsprache und gegen ASM. Wieder für die Puristen! Eine profunde und detaillierte Kenntnis eines µC ist immer von Vorteil und je nach den oben genannten Typen von Personen die sich mit einem µC für eingebettete Systeme interesieren mehr oder eben weniger wichtig! Sicher ist aber, dass eine abstrahiertere Beschäftigung den Lernvorgang für einen Anfänger beschleunigt und die Effizienz des Programmieres erhöht und viel weniger Fehler bei der Entwicklung der immer komplexer werdenden eingebetteten Systeme auftreten, höhere Komplexitäten realisiert werden können und solche Projekte schneller realisiert werden können. Wegen der Bedeutung für das Verständnis des Marktes und der Anbieter von ARM Cortex Mx µC, sowie auch für die Begründung warum auch effiziente und kostengünstige Lösungen in Hochsprache eben eher und effizienter möglich sind, möchte ich folgende Auswirkungen der Situation vorstellen. Da alle Lieferanten und Fertiger von ARM Cortex Mx µC vergleichbare Produkte anbieten und wenn die Systemrealisierer sich z. B. an CMSIS halten, so bedingt die Suche nach Alleinstellungsmerkmalen der diversen Anbieter Folgen die ich kurz vorstellen möchte und die ebenfalls eine Begründung pro Hochsprache und gegen ASM sprechen. Der erste Pfad zur Suche nach Alleinstellungsmerkmalen von Anbietern von ARM Cortex Mx µC ist die Konfiguration ihrer Produkte mit solchen Peripherie-Modulen, die für eine Zielanwendung möglichst Vorteilhaft sind. Das bedingt das Entstehen von Familien von Produkten die durch die anvisierten Anwendungsfelder Vorteile gegenüber Wettbewerbern haben, wodurch die Anzahl der Wettbewerbsprodukte reduziert wird auf eben solche die ebenfalls diese Zielanwendungen anpeilen. Die Qualität und Leistungsparameter werden durch den Wettbewerb der durch das relativ einfache Wechseln des Anbieters erzwungen wird, fördert die Qualität, nicht nur bei der Implementation in Hardware, sondern auch die Qualität der CMSIS Bibliotheken, da ineffiziente Implementierungen der CMSIS Bibliothekn eventuelle Vorteile einer guten Hardware Implementierung auffressen würden. Auch ein Argument pro Hochsprache! Jeder erfahrene Programmierer weiss, dass die Leistungsfähigkeit seiner Software nicht nur durch die Qualitäten der Hardware, der Qualität seiner Kodierung bestimmt wird, sondern auch von der Qualität und Effizienz der verwendeten Bibliothekn, der vertwendeten IDE und der dort zum Einsatz kommenden Compiler bestimmt wird. Auch ein Argument pro Hochsprache, da die Anbieter von ARM Cortex Mx µC durch die Vergleichbarkeit und innerhalb bestimmter Grenzen gegebenen Austauschbarkeit seiner Produkte hier auf die Qualität achten muss, da sonst seine Bemühungen bei der Hardware konterkariert werden! Ohne auf die Qualität der CMSIS-Implementationen der diversen Anbieter einzugehen möchte ich folgendes am Beispiel der ARM Cortex Mx von NXP schreiben, die oben gesagtes zu bestätigen scheinen! NXP hat mit "Embedded Artists" die LPCXpresso Karten zu extrem günstigen Konditionen verfügbar gemacht. NXP hat mit dem IDE-Anbieter "Code Red" eine auf ihre ARM Cortex Mx µC optimierte IDE kostenlos bereitgestellt und das mit nur der Beschränkung auf 256 kByte Kodegrüße. Da die IDE ein strategisches Element von NXP für das Bemühen um Alleinstellungsmerkmale ist, so vermute ich, hat NXP Code Red erworben, die Limitierung auf 512 kByte erweitert und auch C++ verfügbar gemacht. Die LPCXpresso-Karten, ich habe mit der LPCXpresso1769 begonnen, eine Karte mit dem ARM Cortex M3 LPC1769, ist zweigeteilt. Die eine Seite ist das JTAG-I/F über welche die IDE auf die andere Seite zugreifen kann, welche eine eigenständige LPC1769 µC Karte ist, so klein von seinen Abmessungen und so preiswert zu beziehen, dass die eigene Entwicklung und Fertigung einer µC Karte mit dem LPC1769 in vielen Fällen hinfällig wird. Die IDE von NXP "kennt" alle verfügbaren LPCXpresso-Karten und konfiguriert die Tool-Chain voll automatisch. Zusammenfassend: Bei NXP kann man mit der Kombination einer LPCXpresso-Karte mit dem ARM Cortex Mx µC der eigene Wahl, dabei kommt dort immer gleich die Leistungsfähigste Variante des µC zum Einsatz und der IDE Entwicklungen durchführen und profitiert von den Vorzügen moderner Entwicklungswerkzeuge für einen "Nettobetrag" von unter 20.- Euro in Einzelstückzahlen. Bei den ARM Cortex M4 µC sind die Karten teuerer, da hier mehr dazugehört. Zuletzt möchte ich noch darauf verweisen, hier sind die produkte von TI ein gutes Beispiel, wird die Möglichkeit geboten eine Variante des µC mit fest "eingebrannten Kode" für bestimmte Anwendungen und Funktionen für einen geringen Mehrbetrag zu erwerben. TI nutzt also den auf dem Silizium verfügbaren Raum z. B. auch dazu. Diese Entwicklung steht noch am Anfang und ihre effizientre Nutzung ist eigentlich nur durch die Verwendung von Hochsprachen möglich. Geht also der anfangende Fragesteller von der Frage aus, ob er ASM oder C benutzen soll, so ist je nach einem der eingangs genannten Typen von Nutzern in dem meisten Fällen die Hochsprache zu empfehlen!
Fpga Kuechle schrieb: > Es gibt keine Nur-ASM Fraktion, du sprichst ins Leere. Oh doch die gibt es! Es ist Jene, die argumentiert, dass C zu kompliziert, zu aufwändig zu lernen und zu ineffizient sei. Diese Aussagen in diesem Thread und in Anderen über dieses Thema darfst du dir selber suchen. spess53 schrieb: >>Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas >>anderes als kleine Progrämmchen,... > > Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay, > Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der > Größenordnung 12-13k Programm. > > Solche Kleinigkeiten > > Beitrag "Re: Zeigt her Eure Kunstwerke !" > > kommen mit wesentlich weniger aus. > >>Warum sollte man sich so etwas auch antun? > > Wo ist das Problem? Ich habe eine ganz Reihe eigener Libs (Text- > Grafikdisplays, Sensoren, Kommunikation incl. Ethernet, Mathefunktionen, > Zeit-/ Datumsfunktionen mit Oster-/Feiertagsberechnung, ....). Da hält > sich der Aufwand für das eigentliche Programm stark in Grenzen. Ja natürlich, es ist eine Herausforderung, macht Spaß und man lernt viel, wenn man so etwas mit geringsten Mitteln erschafft (ASM und vermutlich auch mit so wenig RAM und kleinsten µC wie nur möglich). Aber nicht immer ist der Weg das Ziel, auch bei Bastler, sondern das Erreichen des Ziels mit relativ wenig Arbeit/Zeitverbrauch. Es muss also jeder selbst entscheiden welches Werkzeug für ein Projekt passender erscheint. Aber eins ist sicher: als Anfänger sollte man sich mit ASM und C beschäftigen.
Hellmut schrieb: > AVR oder PIC, hat man > mit Systemen auf Silizium zu tun, welche die verfügbaren Ressourcen sehr > begrenzt bereitstellen und die daher sehr davon profitieren, wenn der > Programmierer "seinen µC" bis zum letzten Bit und Register beherrscht, Da muß ich widersprechen. Der Hauptgrund für Assembler war früher, daß es für Hobbyanwender keine bezahlbaren Compiler gab. Der Siegeszug des AVR begann auch erst dann, als es mit dem WINAVR einen leicht zu benutzenden und ausreichend optimierenden Compiler gab. Anwendungen, die Ressourcen forden, mit GUI, Touch, Ethernet usw. kann man ja von der Stange kaufen. Aber kleine Steuerungsaufgaben lohnen sich für die Industrie nicht, die muß sich der Bastler selber programmieren und da ist weder Leistung noch Effizienz gefordert. Der Reiz am Programieren als Hobby liegt ja darin, sich Aufgaben zu programmieren, für die es nichts kaufbares gibt. Das sind dann meistens einfache Ablaufsteuerungen für ein ganz spezielles Problem. Und für den bequemen Einstieg empfiehlt sich dann Bascom oder C auf nem 8-Bitter.
TriHexagon schrieb: > Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas > anderes als kleine Progrämmchen, die einfache Aufgaben übernehmen, auf > dem µC geschrieben. Schon mal einen FAT32 Treiber in ASM geschrieben? > Nein? Warum sollte man sich so etwas auch antun? ASM für kleine und > einfache Aufgaben völlig ausreichend, aber wenn es um komplexe und > größere Programme geht, ist ASM einfach inakzeptabel. Dafür wurde C > konzipiert und da sich kleine Programme genau so gut mit C schreiben > lassen, warum nicht also auch dort benutzen? Weil Anfänger ja auch einen Treiber für einen FAT32 schreiben. Ich gehöre laut deiner Meinung wohl zur "ASM Fraktion" (Programmiere selber mittlerweile seit rund 2 Jahren nurnoch in C). In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind in C übersichtlicher und einfacher zum schreiben. ASM benutze ich heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich mir beim besten willen nicht vorstellen wie man sowas mit C einfacher lernen soll als mit ASM.
San Lue schrieb: > Weil Anfänger ja auch einen Treiber für einen FAT32 schreiben. Ich > gehöre laut deiner Meinung wohl zur "ASM Fraktion" (Programmiere selber > mittlerweile seit rund 2 Jahren nurnoch in C). Lies doch bitte den ganzen Post, da habe ich doch extra noch geschrieben: TriHexagon schrieb: > Das ist zwar so ziemlich OffTopic, musste aber unbedingt mal gesagt > sein. Außerdem gehörst du nicht zur "NUR ASM Fraktion", da du ja kein C Verweigerer bist. San Lue schrieb: > In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind > in C übersichtlicher und einfacher zum schreiben. ASM benutze ich > heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu > lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich > mir beim besten willen nicht vorstellen wie man sowas mit C einfacher > lernen soll als mit ASM. Da gebe ich dir natürlich recht, bei ASM lernt man den µC wirklich besser kennen, deshalb sollte man sich einmal mit ASM und C beschäftigt haben, allerdings habe ich auch nie etwas anderes behauptet.
TriHexagon schrieb: > San Lue schrieb: >> In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind >> in C übersichtlicher und einfacher zum schreiben. ASM benutze ich >> heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu >> lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich >> mir beim besten willen nicht vorstellen wie man sowas mit C einfacher >> lernen soll als mit ASM. > > Da gebe ich dir natürlich recht, bei ASM lernt man den µC wirklich > besser kennen, deshalb sollte man sich einmal mit ASM und C beschäftigt > haben, allerdings habe ich auch nie etwas anderes behauptet. Du vllt. nicht, aber die ASM-verweigerer :D
In einem Fach, wo Kommilitonen noch gar keine Ahnung von µC hatten, hatten wir einen Prof., der alle 10 Minuten immer wie ein Rosenkranz wiederholte, daß C so easy wäre, und Assembler 1:1 übersetzt, und man den nicht braucht. Na ja. Spätestens beim printf() fluchten sie. Hmmm, verstehe das nicht, so ein Befehl hat doch nur einen Maschinenzyklus... Wie der Prof. sagte, C zu Assembler 1:1. ;-)
Wilhelm F. schrieb: > Hmmm, verstehe das nicht.. Ach, du Scherzkeks. Zu meiner Studententenzeit war Fortran und Algol angesagt - und Übungen zu beidem: alos Lochkarten stanzen, Job (= flacher Blechkasten mit allen Lochkarten drin) am Fensterl der Rechenstaton abgeben und nächsten Tag wieder abholen. Ich hatte mir damals - weil mir nix besseres einfiel - eine Wickeltabelle für Netztrafos mit M-Schnitt programmiert. Die hatte ich viele jahre lang! Hat was genützt beim Basteln... Aber der Sinn deiner Bemerkung ist klar: Viele Ausbilder, vom Berufsschul-Lehrer über die gymnasialen Mathe- und Informatik-Lehrer bis hin zu einem erheblichen Teil der Uni-Professoren sind selbst nur Hasenschüler ohne jegliche echte Erfahrung und ohne echtes Wissen. Und ihr gediegenes Halbwissen geben sie dann fleißig an die Studenten ab, die es dann wie ihr persönliches Evangelium halten. Aus solchen Hasenschulen kommen dann Eggschberden (Experten), die sich über ein "goto" aufregen, weil sie eben NICHT das eigene Denken gelernt haben. Du wist sehen, in einigen Jahren wird es NUR NOCH solche Pseudo-Ingenieure geben. Sollen oder wollen wir das lustig finden? W.S.
Im Schatten des allgemeinen Hypes rund um das Schlagwort „Web 2.0“ hat sich in der Webentwicklung die Verwendung von Javascript-Frameworks, mehr und mehr etabliert. Mittlerweile verwenden ca. 39% (Stand Januar 2011) aller Webseiten ein oder mehrere dieser JS-Bibliotheken. Diese bieten dem Benutzer eine umfangreiche Sammlung an Javascript-Funktionen, die die vielfältigen Möglichkeiten der Programmiersprache einfacher und übersichtlicher zur Verfügung stellen als in der herkömmlichen Code-Schreibweise. Allerdings stellt sich dem scriptfreudigen Designer bei der schieren Anzahl an verfügbaren JS-Bibliotheken die Frage, welche es sein soll. Und warum. Diese Frage kann man sicherlich nicht vollständig beantworten, da die vielen verschiedenen Frameworks teils sehr unterschiedliche Aufgaben erfüllen. Möchte man seiner Webseite durch interaktive Elemente neues Leben einhauchen, bietet sich jQuery an, die sicherlich am meisten verwendete JS-Bibliothek. 29% ALLER Webseiten (75% Marktanteil bei JS-Bibliotheken) nutzen es bereits, darunter auch viele bekannte Namen wie z.B. Google, Amazon oder IBM. Nicht nur wegen seiner enormen Verbreitung ist das 2006 von John Resig entwickelte jQuery gut dafür geeignet, einer Webseite Leben einzuhauchen. Die Grundphilosphie des OpenSource-Projekts beruht auf einer simplen Aussage: „write less, do more“. Und genau das tut es. Mithilfe des Frameworks kann Code erzeugt werden, der sich im Vergleich zu herkömmlichen Javascript-Aufrufen um ein vielfaches leichter lesen lässt. Auch kann der einmal erschaffene Code leicht für andere Projekte angepasst und somit wiederverwertet werden. Damit gestaltet jQuery viele Programmierabläufe deutlich komfortabler. Gleichzeitig ermöglicht es auch Webdesignern mit beschränkten JS-Kenntnissen den Zugang zu mächtigen Werkzeugen. Die generelle Syntax von jQuery ist an die Handhabung von CSS-Selektoren angelehnt. Besonders die Flexibilität der zahlreichen Selektoren bietet schier endlose Möglichkeiten, das Erleben der Webseite auf einfache und nachvollziehbare Weise interaktiver und lebendiger zu gestalten. Im Gepäck hat das beliebte Framework ebenfalls zahlreiche vorimplementierte Funktionen, die sich verwenden lassen, um Effekte wie z.B. das Ein- und Ausblenden von Elementen schnell zur Verfügung zu stellen. Diese Funktionen fassen zwar nur mehrere Javascriptbefehle zusammen, die auch ohne jQuery umzusetzen sind – wer sich allerdings einmal an den stark reduzierten und gut lesbaren Code der JS-Bibliothek gewöhnt hat, wird nicht mehr darauf verzichten wollen. Einen weiteren Pluspunkt verzeichnet jQuery durch Plugins – und natürlich die starke Community dahinter, die stetig neue Scripts überarbeitet und veröffentlicht. Ob für eine Lightbox, mehrstufige Navigationen oder einen Textslider – für nahezu jeden Zweck gibt es eine vielzahl an Plugins, die fertige Code-Snippets übersichtlich zusammenfassen. Diese können in der Regel auch von Personen ohne umfangreiches JavaScript-Vorwissen angepasst und verwendet werden.
Go macht keine falschen Versprechungen. Vielleicht ist es gerade das, was die Sprache längerfristig interessant macht. Im Jahr 2007 haben Robert Griesemer, Ken Thompson und Rob Pike sie erfunden, weil sie mit den existierenden Sprachen zur Systemprogrammierung unzufrieden waren. Dabei bedienen sie keinen der aktuellen Trends um asynchrone Webprogrammierung oder Cloud Computing. Vielmehr haben sie aus 30 Jahren Erfahrung mit C gelernt und eine Programmiersprache geschaffen, die deren Nachfolge antreten könnte. Wie C zeigt auch Go [1] seine Stärken bei der Systemprogrammierung, wenngleich sich die Sprache natürlich für nahezu alle Zwecke einsetzen lässt. Die Spracherfinder sind bei Google angestellt, deshalb hat Go neben Java und Python auch seinen Weg auf die Google App Engine gefunden, die Go derzeit im experimentellen Stadium unterstützt [2]. Zukunftsträchtig Anfang 2008 hatte Ken Thompson einen ersten experimentellen Compiler fertiggestellt, der C-Code erzeugt. Ian Tyler begann etwas später mit der Arbeit an einem Go-Frontend für den GCC-Compiler. Gegen Ende des Jahres stieg Russ Cox in das Go-Projekt ein, und die Arbeit ging etwas schneller voran. Im November 2009 präsentierte das Team dann endlich das erste öffentliche Release des Go-Compilers. Im März 2012 erschien Version 1.0 von Compiler und Spezifikation, die Kompatibilität für die kommenden Go-Releases verspricht [3]. Damit eignet sich Go jetzt auch für richtige Software-Projekte, nicht nur für Experimente. Die ausgesprochenen Ziele des Go-Projekts sind effiziente Übersetzung, schnelle Ausführung und einfache Programmierung. Bei existierenden Sprachen seien alle drei Zeile zusammen nicht zu haben, meinen die Go-Erfinder. Go soll das simple Programmieren in den immer beliebteren Sprachen wie Python und Ruby mit der Effizienz und Zuverlässigkeit von Sprachen wie C, C++ und Java kombinieren. Dabei soll die Übersetzung aber nicht so lange dauern wie etwa bei Java-Projekten. Außerdem will Go besser mit Abhängigkeiten zwischen externen Bibliotheken umgehen. Einfachheit ist eines der hervorstechenden Merkmale von Go. Ihr zuliebe haben die Spracherfinder auf viele Konstrukte verzichtet. In erster Linie soll Go eine konsistente und unzweideutige Syntax besitzen. Das kann man von Sprachen wie etwa Perl, Ruby oder Scala nicht behaupten, die für ein und denselben Zweck eine Vielzahl syntaktischer Konstrukte oder Methoden besitzen. Go orientiert sich an C, lässt aber viele Sprachelemente weg, beispielsweise solche, die redundant den gleichen Zweck erfüllen. Zum Beispiel gibt es vom Inkrement-Operator »++« nur noch die Postfix-Variante, die hinter der Variable steht. Gleichzeitig ist dies nur eine Anweisung, aber kein Ausdruck, der gleich weiterverwendet werden kann. Das führt zwar zu etwas mehr Schreibarbeit, aber zu eindeutiger Semantik und weniger Verwirrung. Etwas klarer werden Go-Programme noch durch Anleihen bei strukturierten Sprachen wie Pascal, Modula und Oberon. Teilweise war die Go-Syntax schon in Newsqueak und Limbo verwirklicht. Letztere ist die Programmiersprache des Inferno-Betriebssystems, das wiederum ein Ableger des Plan9-Systems ist, an dem Thompson und Pike früher arbeiteten.
W.S. schrieb: > Aus solchen > Hasenschulen kommen dann Eggschberden (Experten), die sich über ein > "goto" aufregen, weil sie eben NICHT das eigene Denken gelernt haben. Mal ganz abgesehen davon, daß ein Assemblerprogramm hauptsächlich von Sprüngen lebt. Im auf gesetzten C sieht man sie zwar nicht, aber sie sind ja immer noch da, weil der Zwischenschritt vor dem reinen Maschinencode immer noch ASM ist. Apropos ASM oder C: Keines von beiden. In der Anfangszeit programmierte ich auf dem 8051 sogar nur direkt Maschinencode, weil einen PC mit Assembler hatte ich ja noch gar nicht. Den Stack beim 8032 ins indirekt adressierte RAM legen, hieß bei mir nicht: MOV SP, #7Fh sondern immer gleich 75 81 7F alles andere ebenso. Ich konnte die Befehle und Register mal alle fast in Zahlen auswendig. Es ging auch. Den Maschinencode möchte ich nicht unbedingt mehr, ASM hingegen schon. Die ersten 8051 codete ich noch ganz ohne PC. Einfach, weil es die Anfangszeit war, als sich der PC erst langsam verbreitete. Der erste Assembler war dann ein richtiges Highlight. C-Compiler gab es gar nicht. Und das ist noch gar nicht lange her, erst 1990. Noch heute zieren sie sich ja wie verrückt mit den C-Compilern: Wenn man nicht gerade Geld wie Sau hat und eine Profi-Vollversion, da ist vieles für Hobbybastler nach wie vor immer noch sehr arg kastriert. Bei Assemblern nicht. ;-)
Ja, vielleicht sollte man, um einen µC im Detail zu verstehen, weder mit C noch mit Asm, sondern tatsächlich mit Hex oder noch besser mit Bin beginnen. Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur auf die Hälfte der 32 Datenregister anwendbar ist.
Yalu X. schrieb: > Ja, vielleicht sollte man, um einen µC im Detail zu verstehen, weder mit > C noch mit Asm, sondern tatsächlich mit Hex oder noch besser mit Bin > beginnen. Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur > auf die Hälfte der 32 Datenregister anwendbar ist. Ok. Habe ich auch so gemacht. echt Hardcore. Danach kann Dich keine Programmiersprache mehr schrecken ...
Hallo Wilhelm, Wilhelm F. schrieb: > Mal ganz abgesehen davon, daß ein Assemblerprogramm hauptsächlich von > Sprüngen lebt. Im auf gesetzten C sieht man sie zwar nicht, Ich schon. So schwer ist das ja nun wirklich nicht. Und zur Not, wenn ich sie wirklich ganz genau sehen will, hat mein Compiler (siehe unten) da so spezielle Schalter... ;-) > Noch heute zieren sie sich ja wie verrückt mit den C-Compilern: Wenn man > nicht gerade Geld wie Sau hat und eine Profi-Vollversion, da ist vieles > für Hobbybastler nach wie vor immer noch sehr arg kastriert. Probier' doch mal die GNU Compiler Collection aus. In einem Test, den ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem Paket nicht nur Clang, sondern sogar den Intel-Compiler aus. Liebe Grüße, Karl
Karl Käfer schrieb: > Probier' doch mal die GNU Compiler Collection aus. In einem Test, den > ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem > Paket nicht nur Clang, sondern sogar den Intel-Compiler aus. Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim Assembler oder beschnittenen C Compiler bleiben.
Dr. Sommer schrieb: > Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben > unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim > Assembler oder beschnittenen C Compiler bleiben. Blödsinn - Zumindest im Bezug auf die PIC. 1. Für die größeren PIC gibt es GCC basierende Compiler. (Wobei es ja auch geschmackssache ist ob jemand gcc favorisiert oder nicht. Nicht für jeden ist das der Nabel der Welt) 2. Die freien Compiler von Microchip sind -nach ablauf einer Zeit mit vollen Funktionsumfang- nur in der maximalen Optimierungsstufe eingeschränkt. Für Hobbyisten in wohl 99% der Fälle irrelevant. Gruß Carsten
Yalu X. schrieb: > Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur > auf die Hälfte der 32 Datenregister anwendbar ist. Ist doch ganz easy, bei 16 Bit Befehlsbreite: 8 Bit für das Datenwort 4 Bit der Ladebefehl bleiben noch 4 Bit für das Zielregister übrig, also 16 Möglichkeiten.
Hallo Herr Dr., Dr. Sommer schrieb: > Karl Käfer schrieb: >> Probier' doch mal die GNU Compiler Collection aus. In einem Test, den >> ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem >> Paket nicht nur Clang, sondern sogar den Intel-Compiler aus. > > Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben > unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim > Assembler oder beschnittenen C Compiler bleiben. Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich auch eine Plattform, auf der der GCC läuft. Wenn er wirklich keine Plattform hat, der arme Mensch, dann würde ich gerne eine Spendenaktion starten. Ich werfe einen RasPi-B in den Topf. Wer spendet eine alte SD-Karte, idealerweise >= Class 6? Wer spendet Kabel und eventuell Adapter? Ich kann da noch für einen 17"-Röhrenmonitor einspringen oder einen HDMI-<->VGA-Adapter. Liebe Grüße, Karl
Carsten Sch. schrieb: > Blödsinn - Zumindest im Bezug auf die PIC. > 1. Für die größeren PIC gibt es GCC basierende Compiler. Die benutzt aber keiner, weil da könnten ja eventuell ein paar Bytes Speicher übrig bleiben, wenn das Projekt winzig ist! > (Wobei es ja auch geschmackssache ist ob jemand gcc favorisiert oder > nicht. Nicht für jeden ist das der Nabel der Welt) Stimmt, gibt ja auch noch Clang. > 2. Die freien Compiler von Microchip sind -nach ablauf einer Zeit mit > vollen Funktionsumfang- nur in der maximalen Optimierungsstufe > eingeschränkt. > Für Hobbyisten in wohl 99% der Fälle irrelevant. Optimierungen sind schon sehr hilfreich - Wenn die Code-Größe auf einen Bruchteil reduziert wird, kann das schon nocht entscheiden ob das Programm auf einen µC passt oder nicht. Wobei man es aber auch erstmal schaffen muss die richtig großen µC's vollzukriegen... Karl Käfer schrieb: > Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich > auch eine Plattform, auf der der GCC läuft. Es geht nicht um auf, sondern für... Auf einem AVR läuft auch kein GCC, aber der GCC kann AVR-Code generieren. > Wenn er wirklich keine Plattform hat, der arme Mensch... Es gibt ja auch Menschen die Assembler verwenden :-D Es kann ja nicht jeder ARM verwenden, für das es einen wunderbar funktionierenden, optimierenden, kostenlosen unbeschränkten GCC gibt. Irgendwer muss sich ja auch mit den 8051 etc. quälen, die sind sonst traurig!
Dr. Sommer schrieb: > Irgendwer muss sich ja auch mit den 8051 etc. quälen Darfst Dir sicher sein, das ist ein Genuß. Denn die sind einfach und man kann sich für sehr sehr viele Apps sicher sein: Der Aufwand den ich hier treibe ist genau der den es braucht und nicht mehr... STM32 & Co samt deren komplexen Dickichts der Toolchains und Libs sind die eigentliche Quälerei. Aber: Die 32-Bitter sind was neues, haben technischen Unterhaltungswert und geben das schöne Gefühl: Ich bin vorn mit dabei und kann auf die 8-Bitter so schön gefällig herabschauen... Hat auch was. Zugegeben.
Dr. Sommer schrieb: > Irgendwer muss sich ja auch mit den 8051 etc. quälen Nö, ist keine Qual. Ich kann mit dem Keil C51 sämtliche >500 Typen des 8051 programmieren. Dem Compiler ist das wurscht. Auch neuere Typen sind kein Problem, mein C51 ist noch von 1995. Beim ARM muß dagegen die Toolchain jeden Typ, den ich verwenden will, explizit unterstützen. Für neuere Typen brauche ich ein Update. Und die Toolchains sind jeweils verschieden für ARMs von Atmel, NXP, ST, TI.
Peter Dannegger schrieb: > Nö, ist keine Qual. > Ich kann mit dem Keil C51 sämtliche >500 Typen des 8051 programmieren. > Dem Compiler ist das wurscht. Auch neuere Typen sind kein Problem, mein > C51 ist noch von 1995. Kann das denn auch moderne Dinge wie C++11? Mir gefällt jedenfalls die Argumentation - kein ARM kann zu viel, kein C++11 weil 8051 Compiler kann das nicht. > Beim ARM muß dagegen die Toolchain jeden Typ, den ich verwenden will, > explizit unterstützen. Für neuere Typen brauche ich ein Update. > Und die Toolchains sind jeweils verschieden für ARMs von Atmel, NXP, ST, > TI. Nope. Der z.B. GCC-ARM-Embedded unterstützt nur die Corex-M* Cores und 0 Mikrocontroller. Mit Linkerscript&Startupcode (gibts vom Hersteller oder kann man auch leicht selber schrieben) kann man damit aber für alle Cortex-M* Controller programmieren. Und zumindest explizit von/für ST gibt es überhaupt keine Toolchain.
Moby schrieb: > Dr. Sommer schrieb: >> Irgendwer muss sich ja auch mit den 8051 etc. quälen > > Darfst Dir sicher sein, das ist ein Genuß. Denn die sind einfach und man > kann sich für sehr sehr viele Apps sicher sein: Der Aufwand den ich hier > treibe ist genau der den es braucht und nicht mehr... Naja, der 8051 hatte auch seine Zeit. Aber es ist heute schlichtweg nicht mehr nötig sich dauernd mit den Einschränkungen im Programmiermodell, der Arithmetik und den Adressräumen zu befassen. Code Banking, SFR Paging, IDATA, DATA, XDATA, PDATA, Registerbänke, 16-bittige Integer... das ist alles fürs Museum. Welchen ehrlichen Vorteil habe ich heute mit einem 8051 für ein Projekt bei dem es nicht relevant ist ob die MCU 0,80 oder 1,50 EUR kostet?
Dr. M. schrieb: > Welchen ehrlichen Vorteil habe ich heute mit einem 8051 für ein Projekt > bei dem es nicht relevant ist ob die MCU 0,80 oder 1,50 EUR kostet? Wenn’s nur fürs Hobby ist könnte es sein, dass der derjenige nur Wissen und Hardware (Programmer usw.) für den 8051 hat. Ich würde sagen fürs Hobby ist die Diskussion C vs. ASM sinnlos, außer wie die eigentlich Frage war finde ich die Frage für einen Einsteiger der noch kein C-Kenntnisse hat berechtigt. Jeder soll das nehmen was ihm besser gefällt, er besser beherrscht und besser für sein Project geeignet ist. Und bei der Wahl des µCs ist es das gleiche.
Dr. Sommer schrieb: > Kann das denn auch moderne Dinge wie C++11? Ich würde mal vermuten, das ist nach 1995 entstanden. Ich kenne keinen Compiler, der in die Zukunft schauen kann. Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich besser implementieren lassen.
vlt gibts ja irgendwann µPC's mit os, interpreter und allem drum und dran
beal schrieb: > vlt gibts ja irgendwann µPC's mit os, interpreter und allem drum und > dran Raspberry Pi
Karl Käfer schrieb: > Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich > auch eine Plattform, auf der der GCC läuft. Wenn er wirklich keine > Plattform hat, der arme Mensch, dann würde ich gerne eine Spendenaktion > starten. Oh Mann, ich hab halt mal ganz klein angefangen, und meine ersten 8051-Programme bekam ich ganz alleine ohne PC und ohne ein Internet-Frageforum hin. Für meine 8051-Derivate habe ich den SDCC-Compiler, der ist nicht luxuriös aber reicht. Als Oberfläche Geany, finde ich auch ganz brauchbar. Und für den seriellen Programmdownload Tera Term, auch ganz brauchbar, weil das Windows HyperTerminal gibt es unter Vista nicht mehr. Ohne Debugger geht es auch. Aber Hobby, Zeit spielt keine Rolle, nur Spaß, keine Projekt-Deadline und nichts dergleichen. Nur Spaß. Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt Maschinencodierung: Damit half ich einigen Kommilitonen durch die Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet, und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem Studium raus geflogen. Klausuraufgaben wollten das wissen. Denn dort sollte man als Hauptaufgabe mit der höchsten Punktzahl ein kleines Progrämmchen mit 10 Zeilen und mit einer Verzweigung drin schreiben. Z.B. Lampe an einem Pin leuchtet je nach Tastendruck an einem anderen Pin. Für den Sprung reichten nicht alleine die Befehle, sondern auch die Byteanzahlen der Befehle, und dafür mußte man den Maschinencode neben den Befehl schreiben, und für Sprünge genau diese Bytes zählen.
Guten Tag! Zuerst einmal lernen, was eine Schalttransistor ist und wie so etwas funktioniert. Most of the time das Rest ergibt sich von selbst. Zuerst Etwas diskret aufbauen. Without Controllers. Und verstehen lernen, was so ein µC able is to do. Ohne Kenntnisse der Grundlagen-Elektronik programmieren wollen, is like a rowboat on den Ozean: Ohne Help! Good luck, Stuart
Hi, Wilhelm F. schrieb: > Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt > Maschinencodierung: Hihi, das musste ich in meiner Abschlussprüfung anno ´01 auch noch machen. Erst ein fertiges Programm "analysieren", also erkennen was es macht - dann ein weiteres Programm schreiben. Jeweils nur die nackten Hex Codes auf dem Bildschirm mit der Übersetzungsliste neben der Tastatur. (Auf den MFA Mikrocomputer) ISt natürlich noch ein Schritt weiter in Richtung Hintergrundverständniss - allerdings muss man irgendwo auch eine Sinnvolle Untergrenze setzen womit sich ein (Nichtberuflicher) Einsteiger heute befassen sollte. Das man allerdings zumindest mal gesehen/gehört/gelesen haben sollte das ein Assembler in der Regel nicht viel mehr macht als die gerade noch einigermaßen Menschenverständlichen MNEMONICS des Assemblercodes 1-1 in eine Zahlenreihe umzuwandeln -und das die Bedeutung der jeweiligen Zahlen ganz verschieden sein kann - je nach Position... das denke ich zwar heute noch. Aber mehr als 1-2h Gesamtzeit braucht sich auch gründlicher -an tiefen Verständniss interessierter- Einsteiger damit nicht mehr befassen. Gehört für mich mit zum Themenbereich "Mal ein paar ASM Übungen machen". Das erhöht im Übrigen ja auch das Verständniss für den ganzen Ablauf in der Toolchain. Der Code wird in C geschrieben, der C Code wird zu ASM Compiliert und das ASM Listing wird dann erst zu einem Bytestrom umgesetzt der in den µC geschrieben wird. Für alte Hasen ist das eine absolute Selbstverständlichkeit, aber ein Einsteiger hat da nicht selten schon erste Verständnissprobleme bei den Abhängigkeiten. Was ich bei den ASM Totalverweigerern nicht verstehe ist die Tatsache, das die so energisch dagegen wettern als würde die Mehrzahl der "auch ASM" Beführworter hier fordern das ein Einsteiger ASM wirklich noch in vollendung Lernen soll. Wenn man von ein bis zwei Aussenseitermeinungen absieht ist das doch gar nicht der Fall. Den Syntax einer Programmiersprache -fast egal welcher- lernt man sehr schnell. Die Grundlagen sollten selbst bei Normalbegabten nach 1-2 Nachmittagen da sein. Das was Zeit, ja sehr viel Zeit, braucht ist die Erfahrung und Routine um mit dem Werkzeug Programmiersprache schnell zu hervorragenden Ergebnissen zu kommen. Und das ein Einsteiger die dafür nötige Zeit noch in die Vertiefung des ASM -Wissens reinsteckt halte selbst ich, als wehemennter "auch ASM" Befürworter, für absolut verschwendete Zeit. Aber ein paar Stunden in grundlegendste Übungen zu stecken wird bei nicht wenigen sicherlich das ein oder ander "Licht" beim Arbeiten mit höheren Sprachen deutlich schneller aufgehen lassen. Peter Dannegger schrieb: > Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich > besser implementieren lassen. Sehe ich auch so. C++ hat seine Berechtigung und ohne C++ (oder allgemeiner gesagt: Objektorientierten Sprachen) wäre das Leben in vielen Bereichen der Softwareentwicklung deutlich schwieriger. Aber gerade in den einfacheren Anwendungen realisiert man mit dem µC doch nur eine mehr oder weniger "gedopte" FSM. Und da ist man mit C meist deutlich schneller und Übersichtlicher. Und wenn hier Statements wie "Unübersichtlichen Spaghetticode" im Bezug auf C Quelltext lesse, dann kann ich mir das einfach nur so erklären das derjenige einfach niemals gelernt hat vernünftig Strukturiert in C zu programmieren und so seine eigenen, sehr begrenzten Fähigkeiten als Vergleichsmaßstab für die Aussage "C++ ist auch auf µC immer die bessere Wahl" nimmt. Für "ihn Persöhnlich" wird das in einem solchen Fall sogar absolut zutreffen, aber lange nicht für die Mehrheit! Allerdings muss man mittlerweile auch immer im Hinterkopf haben das die Schreiber hier beim Terminus "µC Programmierung" ganz andere Vorstellungen im Kopf haben könnten. Während ich (und vermutlich wohl auch PeDa)auch wenn wir selbst schon sehr komplexe Projekte realisiert haben trotzdem erst einmal unwillkürlich an eher einfache Schaltungen denken die man auch noch bequem in einen mittleren 8Bitter unterbringen könnte - so haben andere vielleicht eher einen "Quasi-Einplatinencomputer" wie den RasperryPi im Sinn. Und genauso verhält es sich dann auch mit dem Begriff "einfache Anwendung". Gruß Carsten
>Der Code wird in C geschrieben, der C Code wird zu ASM >Compiliert und das ASM Listing wird dann erst zu einem Bytestrom >umgesetzt der in den µC geschrieben wird. das ist jetzt schon der 2. der das schreibt, aber das stimmt doch nicht (oder ist unglücklich formuliert) ich kenn keinen compiler der als zwischenschrit ASM (als lesbaren text) erstellen würde.. edit: ok, der GCC macht das scheinbar tatsächlich so ähnnlich (aber nicht asm sonder RTL?), sachen gibts... ist aber wohl eher die ausnahme..
:
Bearbeitet durch User
Wilhelm F. schrieb: > Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt > Maschinencodierung: Damit half ich einigen Kommilitonen durch die > Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich > übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet, > und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem > Studium raus geflogen. Klausuraufgaben wollten das wissen. Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und andere Menschen bezichtigt bei Prüfungen betrogen zu haben? Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine Ehrlichkeit bekommst Du ein Sternchen von mir.
Klaus I. schrieb: > Wilhelm F. schrieb: >> Ich >> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet, >> und zwar Maschinencode. > > Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal > vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und > andere Menschen bezichtigt bei Prüfungen betrogen zu haben? Wenn Übungen vor einer Prüfung Betrug sind, habe ich bei den meisten Prüfungen betrogen...
Klaus I. schrieb:2 > Wilhelm F. schrieb: >> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt >> Maschinencodierung: Damit half ich einigen Kommilitonen durch die >> Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich >> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet, >> und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem >> Studium raus geflogen. Klausuraufgaben wollten das wissen. > > Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal > vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und > andere Menschen bezichtigt bei Prüfungen betrogen zu haben? > > Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen > Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine > Ehrlichkeit bekommst Du ein Sternchen von mir. Ich bin ein hilfsbereiter Mensch oft auch ohne Gegenleistung, und habe es bestimmt 10 Studenten verholfen, nicht dreimal durch Mikroprozessor durch zu fallen, und das Studium zu werfen. Was gibt es daran auszusetzen?
Peter Dannegger schrieb: > Ich würde mal vermuten, das ist nach 1995 entstanden. Ich kenne keinen > Compiler, der in die Zukunft schauen kann. Wir haben aber 2014 (bald kommt C++14 raus!), und es geht darum was man jetzt verwenden kann/soll/darf. > Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich > besser implementieren lassen. Durchaus. So eine schöne CANopen-Implementierung zur Ansteuerung diverser Aktoren & Sensoren kann davon eine Menge profitieren. Und schöne Hardware-API's könnte man damit auch machen...
Wilhelm F. schrieb: > Was gibt es daran auszusetzen? Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu bestehen.
;-) schrieb: > Wilhelm F. schrieb: >> Was gibt es daran auszusetzen? > Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht > mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu > bestehen. Oh, da ist jemand übel angegriffen. ;-)
Wilhelm F. schrieb: > ;-) schrieb: > > Wilhelm F. schrieb: > Was gibt es daran auszusetzen? > > Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht > mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu > bestehen. > > Oh, da ist jemand übel angegriffen. ;-) Das war natürlich nicht ernst gemeint..
Dr. Sommer schrieb: > Und > schöne Hardware-API's könnte man damit auch machen... Ach du wieder.. Du wolltest doch erstmal beginnen, die Lernbetty zu verstehen, gelle? Und jetzt redest du von "So eine schöne CANopen-Implementierung.." und Konsorten.. Mach erstmal was Einfaches vor dem Höhenflug und zeig uns deine grandiosen Ergebnisse ;-) So, die Flasche Riesling von der Mosel ist fast alle, GUT NACHT ZUSAMMEN! W.S.
W.S. schrieb: > Dr. Sommer schrieb: >> Und >> schöne Hardware-API's könnte man damit auch machen... > > Ach du wieder.. > Du wolltest doch erstmal beginnen, die Lernbetty zu verstehen, gelle? Du wolltest doch mal ein Projekt mit gutem Code schreiben, oder? > Und jetzt redest du von "So eine schöne CANopen-Implementierung.." und > Konsorten.. Mach erstmal was Einfaches vor dem Höhenflug und zeig uns > deine grandiosen Ergebnisse ;-) Nö, das wäre Perlen vor die Säue. oder Trolle. CANopen läuft, und nein es ist kein Quick & Dirty mit fix hingerotzter FSM. Ich weiß ja immerhin wie sowas ordentlich geht. Mal schauen für wie viel ich das dann verkaufe. > So, die Flasche Riesling von der Mosel ist fast alle, GUT NACHT > ZUSAMMEN! Musst du was kompensieren oder vergessen? Alkoholiker...
Wilhelm F. schrieb: > Klaus I. schrieb:2 > >> Wilhelm F. schrieb: >>> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt >>> Maschinencodierung: Damit half ich einigen Kommilitonen durch die >>> Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich >>> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet, >>> und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem >>> Studium raus geflogen. Klausuraufgaben wollten das wissen. >> >> Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal >> vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und >> andere Menschen bezichtigt bei Prüfungen betrogen zu haben? >> >> Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen >> Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine >> Ehrlichkeit bekommst Du ein Sternchen von mir. > > Ich bin ein hilfsbereiter Mensch oft auch ohne Gegenleistung, und habe > es bestimmt 10 Studenten verholfen, nicht dreimal durch Mikroprozessor > durch zu fallen, und das Studium zu werfen. > > Was gibt es daran auszusetzen? Wenn Du nur mit Ihnen allgmeine Aufgabenstellungen geübt hast und du nichts spezielles von den Prüfungsaufgaben gewusst hast, habe ich Dir in der Tat etwas falsches unterstellt. Sorry. Das ist bei mir falsch angekommen.
Hallo Carsten Sch. Carsten, mir graut vor dir... Irgendwie erzählst du mächtig viel, ohne viel zu sagen. Weist du denn wirklich wovon du sprichst?
So siehts aus, wenn man zwar C kann, nur den µC nicht kennt. Beitrag ""Universelle Tastenabfrage" auf Attiny2313" Was sagt uns das? Lerne zuerst mal den µC kennen. Egal ob in C oder Assembler.
Hi, mathe schrieb: > Programmieren lernt man am besten, wenn man eine relevante Sprache > nutzt. > > Am besten fängst Du mit Javascript an und lernst jquery zu nutzen. Zur > Not können es auch Python oder Ruby sein. > > Wenn Du die beherrscht, kannst Du Dich an die elitären Sprachen wie Go > und Haskell wagen. > > C und ASM soll Opi weiter programmieren. Das benötigt man nur für > Treiber. Hahahahahaha, danach habe ich nicht mehr weiter gelesen, das reicht als Lachflash für die Nacht.... :-)))) Eventuell steigt der Herr Mathe Prof ja mal in die Industrie oder in Firmen ein, die Ahnung haben. Glaube ich zwar nicht, aber .... Just my 2 Cents :-))) Gruss Fabi.
Jean Player schrieb: > Eventuell steigt der Herr Mathe Prof ja mal in die Industrie oder > in Firmen ein, die Ahnung haben. Dann muss er sein alt-gelerntes C leider einpacken und das nehmen was in der Industrie tatsächlich verwendet wird - Java, ruby, C#...
Ich denke, gerade in „Embedded” Bereich ist eine solide Kenntnis eines µC und der Implementationen der Peripherie von großer Bedeutung, wie auch ein solides Verständnis über die Peripherie-Funktion. Gerade das unterscheidet ja „Embedded” Programmierung von sonstigen Programmieranwendungen. Diese Frage, sollte eigentlich klar sein, ist aber nicht Bestandteil des eigentlichen Themas dieses Thread. Das Thema ist C oder ASM, genauer, Hochsprache vs ASM. Viele der letztens veröffentlichten Beiträge haben ja mit dem Thema nichts mehr zu tun oder erzeugen Dissenz und „Diskussionsbedarf” aus der Durchmischung des Themas damit ob Kenntnis und Verständnis der Hardware und seiner Funktion und die Wahl der Programmiersprache. Wenn das hier nicht zu einer Nabelschau ausarten soll, dann sollte man über den Tellerrand sehen. Viel interessanter ist die Frage der Bedeutung zur Wahl der Entwicklungswerkzeuge wie sie in US Foren geführt wird und die mit dem Thema dieses Threads verwandter ist, so meine Meinung, als die hier geführte Egoshow!
Dr. Sommer schrieb: > Dann muss er sein alt-gelerntes C leider einpacken und das nehmen was in > der Industrie tatsächlich verwendet wird - Java, ruby, C#... Ja, das sind die Zugpferde im Embedded-Bereich... :D
Dr. M. schrieb: > Ja, das sind die Zugpferde im Embedded-Bereich... :D Die Industrie besteht nicht nur aus Embedded...
Hi >Die Industrie besteht nicht nur aus Embedded... Threadtitel vergessen: µC von 0 auf lernen. ASM oder C? Bleib bei deinem Stammgeschäft: http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC8QFjAA&url=http%3A%2F%2Fwww.bravo.de%2Fdr-sommer&ei=e24CU-_bOpDEtAaxnoDgCA&usg=AFQjCNHSlfx7UOvp3DPieBJuD4-RUmHKzw&bvm=bv.61535280,d.Yms MfG Spess
spess53 schrieb: > Threadtitel vergessen: µC von 0 auf lernen. ASM oder C? In Internetforen ist es leider hin und wieder so, dass die Diskussion nicht mehr 100% zum Thread-Titel passt. Wenn die Rede von Mathematikern ist besteht eine gewisse Wahrscheinlichkeit, dass es nicht um Embedded ging.
Dr. Sommer schrieb: > Wenn die Rede von Mathematikern > ist besteht eine gewisse Wahrscheinlichkeit, dass es nicht um Embedded > ging. Du brauchst dich nicht zu grämen. Sexualität ist eines der wichtigsten Themen überhaupt. Also von der Wahrscheinlichket her sicherlich weit bedeutender als Ruby oder C#. Kopf hoch, du machst da einen tollen Job!
Hi Dr. Sommer schrieb: > spess53 schrieb: >> Threadtitel vergessen: µC von 0 auf lernen. ASM oder C? > In Internetforen ist es leider hin und wieder so, dass die Diskussion > nicht mehr 100% zum Thread-Titel passt. Das ist zwar richtig, aber gerade hier in diesem Thread ist die Diskussion noch sehr stark ON TOPIC. Alles andere macht ja auch überhaupt keinen Sinn, wenn man diesen Thread über die µC Sparte hinaus ausdehnen würde könnte man die ganze Diskussion gleich löschen, ausserhalb der µC Welt gelten völlig andere Randbedingungen. Dann kommen wir von einer Frage die sich nach einem Rundblick in die gelebte Wirklichkeit der Entwicklungsabteilungen und nach den Erfahrungen der alten Hasen in diesem Bereich auch noch sehr genau beantworten lässt zu einer reinen Diskusion "Welche Programmiersprache ist überhaupt die Beste" ohne Rücksicht auf den Einsatzzweck. Es ist halt einfach so das die Frage nach der sinnvollsten Programmiersprache sich einfach am gewünschten Einsatzzweck orientiert. Als Beispiel schon meine mal weiter oben gemachte Aussage: Für die Plattform µC: Gute C Fähigkeiten sind auf dem µC für alles was über ein wenig Hobbycoden hinausgeht heute das absolute "Must Have". ASM Fähigkeiten sind auf dem µC nicht zwingend Erforderlich, helfen aber extrem beim Verständniss der Besonderheiten der Plattform und ermöglichen es so auch viel schneller zum nötigen Wissenstand zu kommen um effektiven C code für den µC schreiben zu können. Von der Unterstützung beim Debuggen mal ganz zu schweigen. Zumindest als beruflich mit dem Thema besfasster sollte man also mindestens einen oder zwei ASM Dialekte mal kennengelernt haben, als Hobbyist ist es ein "Nice to Have" das aber den Einstieg in µC für viele erleichtert. Die Fähigkeit umfangreiche und komplexe ASM Programme selbst entwerfen zu können wird aber nur noch bei wenigen Firmen benötigt, ist also auch für berufliche Belange immer irrelevanter. Maximal die Pflege von Altcode spielt noch eine überhaupt nennenswerte Rolle. C++ Fähigkeiten auf dem µC sind heute ein "Nice to Have" aber wirklich Erforderlich sind diese im Moment nur in wenigen Bereichen. Allerdings gibt es auch in relevanten Anwendungen mittlerweile erste überwiegend in C++ geschriebene Projekte. In der Zukunft wird es sicher noch im bereich der komplexen Anwendungen dem reinen C mehr Marktanteile abnehmen. Es ist also sicher empfehlenswert sich auch mit C++ zu beschäftigen. Aber: Für (berufliche) µC Entwickler ohne C++ Kentnisse gibt es heute noch massig Stellen, aber µC Entwickler die nur mit C++ aber nicht vernüftig mit nativen C umgehen können werden nur sehr wenige bis überhaupt niemand einstellen. Andere Programmiersprachen, egal ob Basic oder JAVA spielen auf dem µC ausserhalb der Hobbywelt oder von "Proof of Conzept" Projekten derzeit keinerlei Rolle! Auf dem PC gelten aber ganz andere Vorraussetzungen: (wobei auch hier nochmals unterteilt werden könnte) Natives C spielt nur noch für die HArdwarenahe Programmmierung, also bei Dingen wie Treiberprogrammierung oder bei Betriebssystemen eine nennenswerte Rolle. Die ASM Programmierung auf dem PC ist nur noch für absolute Spezialfälle relevant. Wer nicht gerade ein BIOS schreiben muss wird damit heute kaum noch in Kontakt kommen. Sicher der Großteil der heutigen PC Anwendungsentwickler wird kaum noch überhaupt einen Berührungspunkte zu ASM haben. Die ganzen Anwendungsprogramme werden heute Sinnvollerweise Objektorientiert geschrieben, C++ ist ein Muss, C# und besonders JAVA werden immer wichtiger. In einigen Fällen kann man z.B. JAVA sicher schon mit zu den nötigen Einstiegsvorraussetzungen zählen. JAVASCRIPT ISt für Webentwickler heute sicher eine Vorraussetzung, aber auch ausserhalb des Webbereiches schadet es sicher nicht zumindest die Grundzüge zu kennen. Natürlich gibt es dann noch weitere Spezialbereiche die weitere Spezialkenntnisse erfordern. Man sieht, es gelten für die verschiedenen Plattformen also völlig verschiedene Vorraussetzungen. Einen an der PC (Anwendungs-)Programmierung interessierten der auch auf der PC Plattform bleiben will kann man ohne Skrupel auch den Einstieg direkt in Objektorientierte Programmierung empfehlen. (Wobei ICH C vom Verständniss, also für den Erstkontakt, für leichter halte - das ist aber wohl Individuell verschieden und damit Geschmackssache) Wer aber einem µC Interessierten denselben Rat gibt, der katapultiert den damit -zumindest derzeit- direkt ins Abseits! DAHER: Diese ganzen "Programmiersprachenbetrachtungen" machen nur im direkten Bezug zur Plattform Sinn. Universell Sinnvolle Antworten gibt es nicht, weshalb gar nichts anderes übrig bleibt als bei solchen Themen -OnTopic- zu bleiben. Gruß Carsten
:
Bearbeitet durch User
Carsten Sch. schrieb: > aber µC Entwickler die nur mit C++ aber nicht > vernüftig mit nativen C umgehen können werden nur sehr wenige bis > überhaupt niemand einstellen. Gut dass es so etwas nicht gibt, jeder der C++ kann kann natürlich mit Leichtigkeit die Untermenge von C++ verwenden, die C ist. Und wird kotzen weil das in C alles so umständlich ist. Carsten Sch. schrieb: > Natives C spielt nur noch für die HArdwarenahe Programmmierung, also bei > Dingen wie Treiberprogrammierung oder bei Betriebssystemen eine > nennenswerte Rolle. Wenns mal so wäre :/ ... Vermutlich sind 98% der "normalen" Linux-Software die man so auf seinem 08/15-Ubuntu hat in C geschrieben; weil die Leute keine Lust haben C++ zu lernen vermute ich. Carsten Sch. schrieb: > Die ganzen Anwendungsprogramme werden heute Sinnvollerweise > Objektorientiert geschrieben, C++ ist ein Muss, C# und besonders JAVA > werden immer wichtiger. In einigen Fällen kann man z.B. JAVA sicher Ja, 1995 war das so. Heutzutage braucht kaum ein "normaler" Anwendungsprogrammierer C++, und Java oder C# sind vermutlich fast immer die Einstellungsvorraussetzung. Kaum einer der normalen Anwendungsprogrammierer oder Informatiker kann heute noch C++, es wird extrem viel in Java oder C# gemacht. Carsten Sch. schrieb: > Einen an der PC > (Anwendungs-)Programmierung interessierten der auch auf der PC Plattform > bleiben will kann man ohne Skrupel auch den Einstieg direkt in > Objektorientierte Programmierung empfehlen. Es ist dringend Java oder C# (-> OOP) zu empfehlen, aus o.g. Gründen. Und da natürlich extrem viel OOP programmiert wird außerhalb von Embedded wäre es auch schlau, das zu beherrschen. > (Wobei ICH C vom Verständniss, also für den Erstkontakt, für leichter > halte - das ist aber wohl Individuell verschieden und damit > Geschmackssache) Da bin ich gegen... Wenn schon dann C++, aber Java, C#, ruby, Python... sind für den Einstieg doch wesentlich besser geeignet, da einfacher zu verstehen, weniger Fallstricke und kürzere Wege zu größeren Erfolgserlebnissen...
Hi, Dr. Sommer schrieb: > Carsten Sch. schrieb: >> aber µC Entwickler die nur mit C++ aber nicht >> vernüftig mit nativen C umgehen können werden nur sehr wenige bis >> überhaupt niemand einstellen. > Gut dass es so etwas nicht gibt, jeder der C++ kann kann natürlich mit > Leichtigkeit die Untermenge von C++ verwenden, die C ist. Und wird > kotzen weil das in C alles so umständlich ist. Das würde ich etwas differenzierter sehen, deshalb schrieb ich ja auch: "Vernünftig mit nativen C UMGEHEN" Es gehört halt schon ein wenig mehr dazu als nur den Syntax zu kennen bis man ein guter SW-Entwickler ist. Und jemand der gut in C++ kann zwar sicher Programme schreiben die per definition als C Programme durchgehen könnten, genauso wie praktisch jeder der C Beherrscht auch nach kurzer Recherche ein formales C++ schreiben könnte ABER das heisst noch lange nicht das dies gut strukturierte und vor allem effektive Programme sind. (Natürlich gibt es Leute die BEIDE Sprachen gut bis sehr gut können, aber die haben halt einfach Erfahrung mit beiden Sprachen) Da kommt halt der Unterschied zwischen Strukturierter und Objekorientierter Programmierung zum Tragen. Das sind zwei verschiedene Philosophien. Zum Rest deines Beitrages möchte ich dir nicht wiedersprechen. An der Welt der PC Anwendungsentwicklung bist du vermutlich näher dran als ich. Wenn, dann schreibe ich vielleicht maximal eine Minianwendung zur Parametrierung von externen Schaltungen an denen ich mitgewirkt habe. Oder auch mal eine kleine Testapplikation. (Beides Üblicherweise dann in C++/.Net, soll halt einfach sein ohne weitere besondere Anforderungen) Aber alles was darüber hinaus geht, das dürfen andere machen die da weit Fitter am PC sind als ich. Da muss ich mir dann selbst sagen: "Schuster bleib bei deinen Leisten" Mit der spezifischen PC Programmierung habe ich bestimmt vor ca. 10 Jahren aufgehört mich da weiter mit zu befassen. (Nachdem ich aber bereits 10 Jahre Erfahrung darin hatte) Seit dem habe ich nur mal ein paar Tage in ein .Net Buch geschaut aber sonst... Gruß Carsten
Carsten Sch. schrieb: > ABER das heisst noch lange > nicht das dies gut strukturierte und vor allem effektive Programme sind. Ein C++ Programmierer der sich mit den diversen Strukturierungsmöglichkeiten von C++ wie OOP auskennt, wird sich vermutlich überlegen wie er das in C genauso strukturieren kann; mit structs statt Klassen, manueller Funktionspointerei statt virtual etc. Das könnte dann durchaus in besser strukturierten C Programmen resultieren als die typischen Frickel-C-Programme... Ein effektives d.h. funktionsfähiges Programm in C zu schreiben sollte wirklich zu schaffen sein. Allerdings ist diese Diskussion wirklich müßig, denn warum sollte man schon von C++ auf C wechseln :-D
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.