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 ;-)
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.