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?
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??
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
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.
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
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.
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.
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.
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!
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.
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.
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ßtWilhelm 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.
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.
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.pdfhttp://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.
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 ;-)
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ütAntimedial 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
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?
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!
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.
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.
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
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.
Eckhard schrieb:> Die Anfänger mit den LC displays tun sich aber in ASM oder auch Bascom> nicht leichter, was soll diese Aussage hier also wert sein ?> Die Grundlagen der Programmierung muss man immer verstehen, dafür gibt> es keinen Ersatz, aber wer Zeiger in C nicht versteht, der hat sie auch> in Assembler nicht verstanden.
Nein das hast du falsch verstanden. Anfänger die Programmieren am µC
anfangen, tendieren dazu nicht die Sprache zu lernen sondern lieber
anfangen z.B. mit einem LCD zu experimentieren. Dass es dann bei der
Stringübergabe kracht ist klar. Threads wo der Threadstarter klare
Grundlagendefizite hat, sich weigert diese endlich mal auszumerzen und
lieber weiter am LCD rumspielt gibs hier jeden Tag. Die Grundlagen sind
aber weiterhin Plicht!
TriHexagon schrieb:> Nein das hast du falsch verstanden. Anfänger die Programmieren am µC> anfangen, tendieren dazu nicht die Sprache zu lernen sondern lieber> anfangen z.B. mit einem LCD zu experimentieren.
Ja, und genau das ist ja da Bescheuerte an C. In ASM gibt es diese
Sprachregeln nicht, sondern man spielt nur mit dem LCD und konzentriert
sich auf den Prozessor. Bei Fehlern bleibt es eben dunkel, nur so schwer
ist das nicht.
TriHexagon schrieb:> Die Grundlagen sind> aber weiterhin Plicht!
Das ist leider bei jedem anders, und meistens nicht eine Schablone wie
ein gleicher Kurs für alle und über alle Dinge. Erst sehr spät sah ich
mir auch mal Transistorschaltungen an, was sich da im µC wirklich genau
abspielt. Zum 6502 gibt es im Netz irgendwo ein Schaltbild, und das geht
auch, solche Teile hatten mal was um die 6000 Transistoren.
Ich mußte mit dem 8051 zwangsläufig mit ASM beginnen, weil es einfach
für Bastler überhaupt keine Hochsprachencompiler gab. Um 1990 herum gab
es noch µC mit einem BASIC-Interpreter drauf als Zwischenlösung. Ich
hatte aber nie einen, und kam weiter mit ASM zurecht.
Aber sowas war der richtige Weg, um stufenweise zu lernen, und nicht
nach der Fahrprüfung mit einem Porsche zu beginnen.
Wenn der Code gut wartbar, portierbar und lesbar sein soll, würde ich c
nutzen. Assambler nur dort, wo unbedingt nötig (also in 99,9% der Fälle
nicht).
Aus didaktischen Gründen bietet sich aber sicher Assembler an. Dadurch
wird ein Grundverständnis geschaffen. Anschließend aber sollte man sich
davon lösen und Zeitgemäßes verwenden (sowohl bez. Hardware als auch
Hochsprache)
Eckhard schrieb:> Wo ist das Problem, in einem anständigem Debugger, sehe ich meinen Code,> Kann steppen, Break und Watchpoints setzen. Habe Fenster, die mir den> Maschinencode und den Speicher zeigen. Ich kann mir Variablen anzeigen> lassen und alles. Diesen altertümlichen kram mit Debug ausgaben via UART> sollte man sich einfahc nicht mehr antun.
Du schreibst wie ein Theoretiker, der noch nie irgendetwas selbst
debuggt hat - allenfalls seine eigenen Fehler, die man auch per
Hingucken gefunden hätte. Kurzum, du liegst grottenfalsch.
Probiere doch z.B. mal einen USB Anschluß zu debuggen. Da kappt dir die
SIE bereits nach 3 ms das Interface und geht schlafen und obendrein
hängt dich der Host ab, wenn dein im Debuggen befindlicher Code nicht in
der rechten Zeit das tut, was der Host von ihm will.
Das ist nur EIN Beispiel von vielen, wo man mit einem intrusiven
Debugging überhaupt nicht weiter kommt. Egal wieviele Watchpoints und
Fensterli du auf deinem Screen hast.
Solche naseweisen Beiträge ärgern mich inzwischen.
W.S.
lol Sinn-Erfassung von fremden Texten geht gegen Null, aber jeder hat
eine Meinung.
Ich mach gerade eine neue Schüssel Popcorn für die nicht betroffenen.
rumreich
BTW: Vielleicht ist ja ein BASIC-Derivat in Kombination mit
Inline-Assembler für weiterreichende Projekte erfolgsversprechender...
W.S. schrieb:> Probiere doch z.B. mal einen USB Anschluß zu debuggen. Da kappt dir die> SIE bereits nach 3 ms das Interface und geht schlafen und obendrein> hängt dich der Host ab, wenn dein im Debuggen befindlicher Code nicht in> der rechten Zeit das tut, was der Host von ihm will.
Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0
auf lernen"? Du schreibst wie ein Profi mit Null Verständnis für die
Belange von Einsteigern. Natürlich ist ein Debugger ein wertvolles
Hilfsmittel für den Anfang wie auch für später. Erst bei entsprechend
anspruchsvolleren Projekten kommen dann weitere Werkzeuge zum Einsatz.
Moby schrieb:> Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0> auf lernen"?
Das hättest du dir im Laufe des Threads auch mal fragen können. Nur weil
es kurz in Richtung OffTopic geht, braucht man niemanden daran zu
erinnern.
Mit ersterem hast Du natürlich recht, zu diesem Streit gehörten jedoch
zwei ;) Ansonsten ist USB-Debugging kein Problem für einen Einsteiger
und macht einen Debugger nicht obsolet- nur soviel wollte ich zum
Ausdruck bringen.
und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu
lernen ..
also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen,
Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es
überhaupt..
am PC
dann ein wenig Grundlagen für den µC (was gibts es, warum hat das ding
so viele Beinchen.., warum haben welche keine Beinchen.., was ist PWM,
PullUp, UART usw. )
danach kann man Sich kann SELBER ein Bild machen, welche Hardware und
welche (nicht nur) Sprache (sonder auch IDE usw) man verwenden will
dann ist man, frei nach, "wer nichts weiß muss alles glauben" nicht auch
SOLCHE Threads hier angewiesen ;-)
Robert L. schrieb:> und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu> lernen ..>> also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen,> Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es> überhaupt..>> am PC
Datentypen, typen, Strukturen und Klassen sind keine grundlagen/basics.
gerade in assembler lernt man die grundlagen ohne die man nichts
programmieren kann. Erst dann erkennt man die Vor- aber auch die
Nachteile
bei der Verwendung von Hochsprachen-sahne wie OOP, komplexe typen
>> dann ein wenig Grundlagen für den µC (was gibts es, warum hat das ding> so viele Beinchen.., warum haben welche keine Beinchen.., was ist PWM,> PullUp, UART usw. )>>> danach kann man Sich kann SELBER ein Bild machen, welche Hardware und> welche (nicht nur) Sprache (sonder auch IDE usw) man verwenden will
Also üblicherweise wähltt man die Hardware danach ob sie bietet was man
benötigt (x mal UARTs, y SPIs) und dann kann man schauen welche
Hochsprache/IDE am besten qualitativ hochwertige Softwareentwicklung
unterstützt.
Schlecht wenn ich mich für Android wegen der tollen IDE etc entschieden
habe, aber der 1 Euro controller in der Maschinensteuerung keine MMU/PMU
für Speicherschutz und virtuellen Speicher etc. mitbringt ...
MfG,
Robert L. schrieb:> und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu> lernen ..
Im Grunde genommen nichts. Jedem das seine.
Wie aber einige schon geschrieben haben, finde ich es schade wenn man
nie einen Einblick in ASM gehabt hat, da es bei einer reinen C
Programmierung doch wesentlich schwieriger ist zu verstehen, was der uC
genau macht.
Vorteil an ASM ist beispielsweise, man weiss genau welcher Befehl wie
lange dauert. Klar, meist ist das absolut egal, trotzdem kann es
interessant sein.
Ein weiteres Problem mit C:
Es mag am Anfang einfach sein, man arbeitet sich immer weiter hinein.
Für irgendein Delay wird einfach eine vorhandene Lib verwendet, man
Tippt je nach Compiler einfach mal DelayMS(500); ein und schon hat man
seine halbe Sekunde Wartezeit.
Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden
und man nichtmehr auf eine Lib zurückgreiffen kann. Dann wenn es darum
geht zu wissen, wie der uC genau arbeitet um den eigenen Ansprüchen
gerecht zu werden.
Wieso also nicht ein paar Tage mehr investieren, dafür die Grundlagen
lernen?
In der Elektronik lernt man auch zuersch das Ohmsche gesetz und nicht
das berechnen von irgendwelchen Strömen durch Kondensatoren in einem
Filter.
Robert L. schrieb:> und was spricht jetzt wirklich dagegen zuerst mal Programmieren zu> lernen ..>> also Grundlagen (Datentypen, Zahlensysteme, Schleifen, Bedingungen,> Funktionen, Strukturen, Typen, Klassen..) und welche Sprachen gibt es> überhaupt..
Funktionen, Strukturen, Typen, Klassen, Schleifen kennt der Controller
nicht.
Sind dem völlig egal. Er kennt nur Register und Speicherstellen.
Deine "Grundlagen" haben also nichts mit der Controllerprogrammierung zu
tun, um die es hier geht, sondern ausschließlich mit der Bedienung des
Compilers.
Wer in einer Hochsprache programmieren will, muss das natürlich anfangs
erlernen, klar.
Programmieren zu lernen heißt doch aber nicht primär die Syntax von C
oder ASM Mnemoniks zu pauken, sondern seine Aufgabe zu strukturieren und
Ablaufpläne zu entwickeln. Wenn das nicht schon mal 80% sind...
Die restlichen 20% sind doch nur übersetzen und Werkzeugeinsatz.
>kennt der Controller>nicht.
Tellerrand??
ich meinte Man(n) muss die Grundlagen der Programmierung verstehen..
die "Scheife" muss man sich dann in ASM eben selber basteln (cmp, jmp,
was auch immer)
und Strukturen im Speicher selber "definieren"
(verkettete liste, was auch immer..)
wie willst was Programmieren, wenn du von den Basics keine Ahnung hast..
>was der uC>genau macht.
weil das ein Anfanger SO genau wissen muss..
>Also üblicherweise wähltt man die Hardware danach ob sie bietet was man>benötigt (x mal UARTs, y SPIs) und dann kann man schauen welche>Hochsprache/IDE am besten qualitativ hochwertige Softwareentwicklung>unterstützt.
das stand weiter oben schon mal, dass es darum "nicht geht" (weil es um
das erlernen, und nicht um ein konkretes ziel geht)
ich bleib dabei: zuerst Grundlagen des Programmierens lernen (Verstehen)
und das geht mit einer Hochsprache am PC nun mal einfacher
Robert L. schrieb:>>was der uC>>genau macht.
Wie schon weiter oben erwähnt:
San Lue schrieb:> Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden> und man nichtmehr auf eine Lib zurückgreiffen kann. Dann wenn es darum> geht zu wissen, wie der uC genau arbeitet um den eigenen Ansprüchen> gerecht zu werden.
Klar, du kannst nun wieder sagen, einem Anfänger ist das egal. Stimmt
soweit auch. Trotzdem, wer Programmieren lernt will selten lernen einen
Digitalen Ausgang zu setzen und fertig. Im normalfall lernt man weiter
und es ist nunmal so, dass man früher oder später nichtmehr um den
Aufbau eines uC's herumkommt. Aus eigener Erfahrung muss ich sagen, ich
war sehr froh darüber, zuerst ASM gelernt zu haben, hat mir dann bei C
den einstieg stark erleichtert.
Hab ich oben ja schon mal geschrieben, ich sehe es wie San Lue. ASM ist
für den Einstieg und das verstehen, was ein µC ist und wie er arbeitet
besser mit ASM anzufangen. Hier lernt man, was so ein µC eignetlich
alles kann und was manche Operationen für eine Last erzeugen (zB: Float,
wobei ich das nicht in ASM programmieren wollen würde)
Hat man die Basics mit ASM abgeklappert, spricht nichts dagegen eine
Hochsprache seiner Wahl auf den µC los zu lassen, man muss nicht mal
alles mit ASM programmieren können. Aber zumindest mal Peripherie
initialisieren, ein bisschen I/O-Operationen (LEDs, 16*2 LCD, USART) und
die ein oder andere Rechnung durchführen. Einfach, damit man im Fall
eines AVRs merkt, was die 8-bit eigentlich bedeuten. In C ist einem
Anfänger die Bus-breite und demnach die limitierungen der Hardware egal,
da kann man auch munter ein float nutzen und merkt nicht, was man da
eigentlich für einen misst gebaut hat.
Klar gibt es auch noch die Fraktion, die einfach nur schnell ein Projekt
beenden will und denen ist es egal, wie so ein µC funktioniert, solange
er funktioniert. Dann kann man mit C anfangen und nur irgendwelche
Libraries zusammen wurschteln (Arduino). Aber der will eben auch nicht
µC lernen, sondern ein Projekt fertig stellen.
> Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden> und man nichtmehr auf eine Lib zurückgreifen kann.
eigentlich ist es genau verkehrt, die meisten Problemstellungen sind so
Komplex, dass man überhaupt nicht in der Lage ist ist alles bis ins
letzte selber, neu und dann vielleicht auch noch in ASM zu erstellen..
(wie überall im Leben) basieren die Meisten Arbeiten, auf der Arbeit von
Anderen
wobei es ja nicht verboten ist, mal selber den Sourcecode dieser
"Libraries" anzuschauen ändern verbessern..
aber um das gehts ja nicht, sondern ob man mit ASM anfangen soll
vermutlich ist es eh egal..
wenn man in einen "C für total-Anfänger" und eine "ASM für
total-Anfänger" Kurs gehen würde, wären die ersten 35 von 40 Stunden
wohl ziemlich identisch..
> wenn man in einen "C für total-Anfänger" und eine "ASM für> total-Anfänger" Kurs gehen würde, wären die ersten 35 von 40 Stunden> wohl ziemlich identisch..
? Nur 5h von 40h für syntax/resp Mnemonic, Complieroptionen,
Makrodirektiven, Code style, Grundbibliotheken, IDE-Menüs ... ?
Wohl eher reziproke verhältnisse, 5h identisch, wobei wenn man 40h ASM
gehört hat, braucht man nur noch 10h für C. Hatt man aber 40h C gehört
braucht man immer noch 30h für assembler.
MfG,
denke jeder µC bastler sollte mal
eine LED mit Hilfe von ASM blinken lassen
und dann das ganze nochmal in C :)
P.S.(zur verwirrung)
es gibt noch weitere Buchstaben im ProgrammierSprachenAlphabet
wie wäre es mit D oder F?
oder wenn es C sein muss warum nicht gleich C++ oder C# ... :)
benwilliam schrieb:> oder wenn es C sein muss warum nicht gleich C++ oder C# ... :)
Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp #
teil hoch-levelt. Erst C++ lernen und dann C ist irgendwie ...
"weltfremd"?
benwilliam schrieb:> oder wenn es C sein muss warum nicht gleich C++ oder C# ... :)
Weil C genau den richtigen Grad an Fallen, Einschränkungen, mangelnder
Abstraktion und Tastaturabnutzung bietet den E-Techniker so lieben.
Fpga Kuechle schrieb:> Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp #> teil hoch-levelt.
Das wäre ganz schön ungeschickt. Man lernt C++, C#, ... natürlich gleich
richtig.
> Erst C++ lernen und dann C ist irgendwie ...> "weltfremd"?
Schlau, denn so vermeidet man alle schlechten C-Angewohnheiten wieder
vergessen zu müssen, wenn man mit einer richtigen Sprache anfängt.
Kindergärtner schrieb:> benwilliam schrieb:>> oder wenn es C sein muss warum nicht gleich C++ oder C# ... :)> Weil C genau den richtigen Grad an Fallen, Einschränkungen, mangelnder> Abstraktion und Tastaturabnutzung bietet den E-Techniker so lieben.
Ne, weill uC einfach nicht die Resourcen bieten um C++ einzusetzen.
Ich erinnere mich da an ein FPGA-projekt mit Soft-Core auf dem Linux
lief, bei dem nach einigen Wochen Rumgehacke feststand das C++ nicht
einsetzbar ist. Wenn halt nur ein p kByte an RAM zur Verfügung stehen,
kann man mal nicht 18k länger binaries unterbringen. Oder den Heap mal
schnell hochsetzen:
http://forums.xilinx.com/t5/Embedded-Development-Tools/MicroBlaze-C-tutorial/td-p/16916
C++ frisst eben ein mehrfaches an ressourcen.
MfG,
Fpga Kuechle schrieb:> Ne, weill uC einfach nicht die Resourcen bieten um C++ einzusetzen.> C++ frisst eben ein mehrfaches an ressourcen.
Wenn ich für jedes Mal, dass ich diesen Mythos hier sehe, eine Zeile
Code schreiben würde, wäre mein Windows-Klon morgen fertig.
Das ist natürlich Unsinn, man kann in C++ sehr effizient, teilweise
effizienter als in C, programmieren, und dabei eine Menge Abstraktion,
Wartbarkeit, Code-Wiederverwendbarkeit gegenüber C gewinnen. Man muss
halt nur wissen, welche Dinge man nicht verwenden sollte (wie in C eben
auch).
Kindergärtner schrieb:> Fpga Kuechle schrieb:>> Weil, wer C++ oder C# eh erst die C-Teilmenge lernt und zum ++ resp #>> teil hoch-levelt.> Das wäre ganz schön ungeschickt. Man lernt C++, C#, ... natürlich gleich> richtig.>> Erst C++ lernen und dann C ist irgendwie ...>> "weltfremd"?> Schlau, denn so vermeidet man alle schlechten C-Angewohnheiten wieder> vergessen zu müssen, wenn man mit einer richtigen Sprache anfängt.
Mit C-lernen meine ich "if then for ++ =" ....
mit C++ lernen virtuelle basisklassen, templates, Unterschied zwischen
early und late name binding etc..
Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung
auseinandersetzen sollte, bevor man die basic syntax drauf hat. Und
diese Syntax ist
bei C und C++ resp C# gleich (zumindest bis man overloading entdeckt hat
;-))
MfG,
Fpga Kuechle schrieb:> Mit C-lernen meine ich "if then for ++ =" ....
Ach die absoluten Basics. Die kann man in C++ aber ganz exakt genauso
lernen.
> mit C++ lernen virtuelle basisklassen, templates, Unterschied zwischen> early und late name binding etc..
Ja, denn wenn man in C mit structs und Macros und solcher Frickelei
anfängt, kann man in C++ direkt mit den entsprechenden richtigen
Mechanismen anfangen.
> Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung> auseinandersetzen sollte, bevor man die basic syntax drauf hat.
Das habe ich auch nicht gesagt. Aber wenn man in C mit #define anfängt,
kann man in C++ mit "const" anfangen; wenn man in C mit "void
my_struct_init (struct MyStruct* s);" anfängt kann man in C++ mit
"MyClass::MyClass()" anfangen etc., d.h. es gleich richtig machen.
> Und diese Syntax ist> bei C und C++ resp C# gleich (zumindest bis man overloading entdeckt hat> ;-))
Nur braucht man für alles außer Hello World aber dann doch etwas mehr.
Robert L. schrieb:>> Problematisch wird es dann, wenn die eigenen Projekte Komplexer werden>> und man nichtmehr auf eine Lib zurückgreifen kann.>> eigentlich ist es genau verkehrt, die meisten Problemstellungen sind so> Komplex, dass man überhaupt nicht in der Lage ist ist alles bis ins> letzte selber, neu und dann vielleicht auch noch in ASM zu erstellen..>> (wie überall im Leben) basieren die Meisten Arbeiten, auf der Arbeit von> Anderen
Das ist korrekt. Doch wer garantiert dir, dass für deine komplexe
Anwendung eine Lib existiert? Gehen wir davon aus, du machst etwas total
neues, wo dir auch keine Lib weiterhilft aber du wissen musst, wie ein
uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich...
Dann bist du mit C doof dran.
Mir ist klar, solche Projekte trifft man in der Realität extrem selten
an. Ich basiere mich wenn ich Programmiere auch immer auf vorhandene
Sachen. Oder zumindest meistens. Trotzdem bin ich sehr froh darüber,
dass ich die ersten 2 Jahre meiner Berufsbildung zum Elektroniker nicht
einmal C angesehen habe sondern nur ASM programmiert habe. Vergleiche
ich mein Verständniss mit demjenigen von Elektronik Lehrlingen aus dem
Kanton Bern (Schweiz & ja, ich wohne in der Schweiz, Kanton Freiburg,
direkt neben Bern),
so ist mein Verständnis über uC's weitaus grösser, da in Bern direkt von
Anfang an C programmiert wird.
Als wir einmal Kurs hatten ging es darum, alle 500 mS ein Output zu
Toggeln, Programmiersprache frei wählbar, allerdings durften Befehle wie
DelayMs(500); (Je nach Compiler anders) nicht verwendet werden. Die
Berner waren stunden lang beschäftigt mit ihrem Rumspielen, währenddem
wir aus Freiburg für so eine Aufgabe ein paar Minuten hatten.
San Lue schrieb:> Gehen wir davon aus, du machst etwas total> neues, wo dir auch keine Lib weiterhilft aber du wissen musst, wie ein> uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich...> Dann bist du mit C doof dran.
Sowas in der Art mache ich gerade, ich schreibe ein großes Projekt
komplett in C++, schreibe meine eigenen Libraries, wo es noch keine
fertigen gibt (zumindest keine benutzbaren bzw. bezahlbaren). Stimmt, C
wäre doof, daher C++. Und tatsächlich gibt es eine handvoll inline
ASM-Zeilen im Code. 99% sind aber C++, in Assembler wär das Projekt
nicht fertig bevor die Sonne verglüht, und in allem was nicht C++ ist
würde man eklige Code Generation brauchen.
Auf "modernen" Architekturen braucht man praktisch kein Assembler mehr
außer für ganz spezielle Dinge wie Kontext-Wechsel in
Multitasking-Systemen oder Spezial-Instruktionen wie "WFI" (ARM), für
die es aber garantiert Kapselungen durch Libraries des Herstellers
gibt...
San Lue schrieb:> Die> Berner waren stunden lang beschäftigt mit ihrem Rumspielen, währenddem> wir aus Freiburg für so eine Aufgabe ein paar Minuten hatten.
Da würde ich in ein paar C++ Zeilen die Timer-Register beschreiben und
hätte mein Toggeln superpräzise und effizient...
Hallo,
Abschluss schrieb:> Ich denke, mit ASM hat man einen besseren Einstieg weil:> - CPU wird einem näher gebracht> - Keine verwirrenden Libs, welche einem sowieso nicht weiterhelfen sein> wissen zu erweitern> - Nur eine kleine Hand von Befehlssätzen -> Übersichtlich
ich frage mich gerade, ob ich der einzige Mensch auf der Welt bin, der
versteht, was ein "Anfänger" ist. Nämlich jemand, den die interne
Funktion seiner CPU zunächst gar nicht interessiert, sondern der erstmal
lernen muß, wie man einen Programmer an seinen Mikrocontroller
anschließt und ihn mit dem Computer ansteuert, um ein Programm auf den
uC zu schreiben. Schon damit haben Anfänger, die ich live erlebt habe,
gewaltige Probleme gehabt. Die Leute in diesem Stadium -- wo es erstmal
primär um handwerkliche Dinge und ein paar kleine Erfolgserlebnisse zur
Motivation geht -- mit Wissen über die internen Funktionen der Hardware
zu belasten, ist purer Wahnsinn!
De facto muß man, um als Anfänger eine LED zum Blinken zu bringen, nicht
wissen, wie die CPU intern funktioniert. Ich kenne viele professionelle
und ausgesprochen fähige Entwickler mit jahrzehntelanger Erfahrung in
der Entwicklung hochperformanter Anwendungen, die überhaupt keine Ahnung
davon haben, wie ein Prozessor intern funktioniert und für die und deren
Arbeit das auch vollkommen gleichgültig ist. Um Auto zu fahren, muß man
auch nicht wissen, wie man einen Reifen wechselt. Das kann in bestimmten
Situationen hilfreich sein, ist aber keine Voraussetzung. Und
Fahranfänger werden mit auch nicht mit derlei überflüssigen
Informationen belastet, und zwar aus guten Gründen: weil es nämlich
überflüssig ist und sie nur von der eigentlichen Aufgabe ablenkt, ein
Auto fahren zu lernen.
Ich halte jemanden, der die C-Libraries für verwirrend hält, seinerseits
für ein wenig verwirrt. Nein, mal im Ernst: Du hälst es (gerade auf
einer uC-Plattform mit ihren äußerst eingeschränkten
Debuggingmöglichkeiten) ernsthaft für weniger verwirrend, jeden
popeligen Schritt von Hand machen zu müssen? Du glaubst wirklich, daß es
für einen ANFÄNGER einfacher ist, eine sauber und korrekt
funktionierende Delay-Routine in Assembler zu schreiben anstatt die
betreffende Funktion aus util/delay.h zu verwenden? Das kann doch wohl
nicht Dein Ernst sein.
Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise
für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich
also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen
lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich
ungefähr viermal leichter lernen als Assembler. Ich persönlich behaupte
sogar, daß es sich mindestens achtmal leichter lernen läßt, nicht
zuletzt weil es eine strukturierte und plattformunabhängige
Programmiersprache ist und den Entwickler nicht zu unübersichtlichem
Spaghetticode zwingt. Wie oben schon gesagt: es gibt Gründe, warum die
Hochsprachen gewonnen haben.
Beste Grüße,
Karl
>wie ein>uC arbeitet weil das Programm sehr Zeitabhängigist oder was weiss ich...>Dann bist du mit C doof dran.
nein, weil (auch wenn es keiner zugeben will) in ASM gleich mal schluss
ist mit lustig, wenn es komplizierter wird
man in ASM auch (erst recht) wieder mit "allgemeinen" wiederverwendbarem
code arbeiten wird (macros) die (erst recht) wieder nicht optimiert sind
usw.
Karl Käfer schrieb:> Ich halte jemanden, der die C-Libraries für verwirrend hält, seinerseits> für ein wenig verwirrt. Nein, mal im Ernst: Du hälst es (gerade auf> einer uC-Plattform mit ihren äußerst eingeschränkten> Debuggingmöglichkeiten) ernsthaft für weniger verwirrend, jeden> popeligen Schritt von Hand machen zu müssen? Du glaubst wirklich, daß es> für einen ANFÄNGER einfacher ist, eine sauber und korrekt> funktionierende Delay-Routine in Assembler zu schreiben anstatt die> betreffende Funktion aus util/delay.h zu verwenden? Das kann doch wohl> nicht Dein Ernst sein.
Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern
um µC und mit ASM versteht man die abläufe erst richtig. Und würdest du
den thread hier verfolgen, es wurde mehrfach gesagt, das man mit ASM
anfangen sollte (nicht dabei bleiben). Also bis zu einer
Displayansteuerung, ein paar berechnungen und I/O geschichen (z.B.
Blinklicht, USART, ADC und Timer). Dann sollte ein grundlegendes
Verständniss aufgebaut sein von dem man aber auch in C profitiert.
Dein Beispiel mit der Delay routine ist auch schön. Für jemanden der C
lernen will sicherlich uninteressant, aber jemand der sich ernsthaft mit
µC auseinander setzen will ein schönes Beispiel, was hinter so einer
Funktion alles an überlegungen stecken (sofern das tutorial gut
geschrieben ist).
Robin schrieb:> Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern> um µC und mit ASM versteht man die abläufe erst richtig. Und würdest du> den thread hier verfolgen, es wurde mehrfach gesagt, das man mit ASM> anfangen sollte (nicht dabei bleiben). Also bis zu einer
Lies doch mal nicht nur immer die Titel sondern auch den Thread dazu
denn genau um diese Fragestellung ging es den TO. Natürlich können wir
jetzt erörtern ob der TO das besser formulieren könnte, aber wenn man
seine Kollegen hier kennt würde auch bei einer besseren Formulierung
nichts anderes hier herauskommen.
C/ASM schrieb:> Mich würde die Meinung der Experten dazu interessieren:> Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher?> Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen?C/ASM schrieb:> Ich beherrsche AVR in C und in ASM. Ich habe nur mal darüber> nachgedacht, was für einen Anfänger einfacher ist und bin nicht wirklich> zu einem Ergebnis gekommen und wollte mir deshalb ein paar zusätzliche> Meinungen ansehen...C/ASM schrieb:> konrad M. schrieb:>> C parallel zur µC>> Hardware, etc. zu lernen stelle ich mir im Gegensatz zu ASM aufwändiger>> vor.> Das war ein Punkt meiner Überlegungen. Ein weiterer ist, dass IF,> Schleifen und Rechnungen >8bit in C einfacher sind als in ASM. Bei ASM> hat man nur eine Hand voll Befehle und bei C hat man Funktionen,> Pointer,... Also muss man erst C auf dem PC lernen, bevor man zum µC> übergeht, es kann also länger dauern bis zum Erfolgserlebnis (LED Blinkt> endlich), es könnte aber auch sein, dass ASM auf einen Anfänger komisch> und unlogisch wirkt.>> Ich kann das nicht so beurteilen, da ich C bereits beherrschte wenn ich> mich erschlossen habe µCs zu proggen um habe ASM erst später in Laufe> meiner Ausbildung gelernt.C/ASM schrieb:> Wenn ich einen anderen µC lerne würde ich in ASM anfangen, da ich wissen> will, was in der CPU so abgeht. Mick interessiert aber wie's für einen> kompletten Neueinsteiger aussieht. Was würde ihr einem anfänger> Empfehlen, der nach der Lösung für ein relativ einfache Projekt fragt?
Karl Käfer schrieb:>> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich> also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen> lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich> ungefähr viermal leichter lernen als Assembler.
Der war gut!
Schon im C-Standardbeispiel hello_world.c reichen die 32 Schlüsselworte
nicht aus, da muß man schon auf printf aus der Standard-IO library
zurückgreifen. Ohne die Bibliotheken ist der C-programmierer auf dem
selben Nivau wie ein assembler-programmiere ohne sys-calls resp
BIOS-Einsprünge. Und um die man-page von printf durch trial und error
komplett zu beherrschen, braucht ein Anfänger einige Stunden.
Und die 130 Instruktionen gliedern sich in wenige Gruppen die sich nur
durch die zu beachtenden Flags oder die Addressierungsart
(direkt,regoster,mem,mem+offset,etc) unterscheiden. Abgesehen davon, das
sich ein assembler-Befehl da wenig mächtig schneller verstehen lässt als
ein
for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--)
Man kann den gesamten Befehlssatz und die Registerstruktur eines Z80 auf
ein A4-Blatt im Normalfont erklären:
http://www.didel.com/picg/calm/CalmZ80a.jpg
Da lernt sich kein C viermal schneller als der Befehlssatz eines
controllers.
MfG
Fpga Kuechle schrieb:> for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--)
Solche Beispiele sieht man ja immer wieder. Soll wohl demonstrieren wie
kompliziert C im Vergleich zu ASM ist.
Meine ASM Kenntnisse sind ein wenig eingerostet. Könnte vielleicht mal
jemand eben dieses Beispiel in ASM Übersetzen? Sind ja bestimmt nur 5-6
Befehle.
Kindergärtner schrieb:>>> Ich glaube nicht, das man sich zuerst mit Polymorphismus und vererbung>> auseinandersetzen sollte, bevor man die basic syntax drauf hat.> Das habe ich auch nicht gesagt. Aber wenn man in C mit #define anfängt,> kann man in C++ mit "const" anfangen;
const gibt es auch in C; ANSI-C um korrekt zu sein. Ebenso inline,
Zeilenkommentare etc. Was C schwer verständlich machen ist nicht die
Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern
als "cool".
MfG
Moby schrieb:> Ist das ein typisches Problem von Bedeutung für diesen Thread "µC von 0> auf lernen"?
Ja. unbedingt, siehe weiter unten.
Also, lies doch erstmal den Text, bevor du in die Tasten haust.
In besagtem Beitrag ging es um die herzlich falsche Ansicht von Eckhard,
der da schrieb:
"Diesen altertümlichen kram mit Debug ausgaben via UART sollte man sich
einfahc nicht mehr antun."
Und das ist tatsächlich ein Problem von Anfängern. Schau dich mal in
diesem Forum um. Da siehst du massenweise Beiträge in der Art "Ich
will mit µC anfangen und weiß noch garnix, also welche IDE muß ich jetzt
lernen und wie kann ich damit debuggen?".
Anstatt sich anzulesen, wie denn der auserwählte µC funktioniert, wird
IMMER zu allererst nach IDE, Compiler, Debugger gefragt. Als ob DAS die
Hauptsache wäre. Naja, mir ist schon klar, daß die meisten hier
anwesenen C-Programmierer den Debugger brauchen, um wenigstens
einigermaßen verstehen zu lernen, was sie denn da in C hingeschrieben
haben und welchen Effekt das hat. Siehe Beiträge über mehrdimensionale
Felder in C.
Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum
Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den
meisten Fällen viel erfolgversprechender. Er ist rein technisch auch der
einfachere Weg - aber eben nur dann, wenn man nicht zu hochnäsig ist.
So, du Moby, da hast du auf der falschen Kerbe herumgehackt.
W.S.
W.S. schrieb:> Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum> Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den> meisten Fällen viel erfolgversprechender.
Du wirst lachen, das habe ich auch schon empfohlen und mache es selber,
wenn es mal was über einen gewissen Zeitraum zu überwachen gilt und eine
LED nicht langt bzw. ein Display nicht in Frage kommt.
Und dennoch, USB-Debugging- und welche anderen hochkarätigen Probleme
Dir auch immer vorschweben mögen sind doch hier kein Thema. Nicht nur
für den Anfänger ist ein Debugger mit viel umfangreicheren Möglichkeiten
die klar bessere und elegantere Lösung, da hat der Eckhard doch recht.
Fpga Kuechle schrieb:> const gibt es auch in C;
Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon),
weswegen alle #define für Konstanten verwenden => hässlich & gefährlich
> Was C schwer verständlich machen ist nicht die> Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern> als "cool".
Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc
resultieren unvermeidbar in unübersichtlichem langem Code.
Stefan schrieb:> Fpga Kuechle schrieb:>> for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--)>> Solche Beispiele sieht man ja immer wieder. Soll wohl demonstrieren wie> kompliziert C im Vergleich zu ASM ist.>> Meine ASM Kenntnisse sind ein wenig eingerostet. Könnte vielleicht mal> jemand eben dieses Beispiel in ASM Übersetzen? Sind ja bestimmt nur 5-6> Befehle.
Ja, in Assembler für einen VLIW-DSP wie den Texas Instruments
TMS320C6400
schon. Instruction code zum Entrosten dort:
http://www.ti.com/lit/ds/symlink/tms320dm642.pdf
MfG,
Kindergärtner schrieb:> Fpga Kuechle schrieb:>> const gibt es auch in C;> Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon),> weswegen alle #define für Konstanten verwenden => hässlich & gefährlich>> Was C schwer verständlich machen ist nicht die>> Sprache selbst sondern das "obfuscated" nicht als Sünde gilt, sondern>> als "cool".> Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc> resultieren unvermeidbar in unübersichtlichem langem Code.
Hm bei hardwarenahen Sachen die ich so in C zu schreiben hatte, ging es
ohne C-Tretminen. Bspw. LCD-display an parallelport:
http://www.mikrocontroller.net/articles/LCD_an_Parallelport
Wehe man kommt auf die Idee, in einer Funktion eine Variable namens
"Data" zu definieren...! Sogar die Klammern hast du vergessen, wehe man
schreibt 2*Control - das würde zu 2*0x378+2 werden (=0x6F2), und nicht
2*(0x378+2)=0x6F4 - d.h. 2*Control ist != 2*(Control).
Ganz fatal ist das z.B. bei der CMSIS und der ST Standard Peripheral
Library, die 1000000 #define's haben, und es so nur eine Frage der Zeit
ist bis man versehentlich einen der Namen (wie z.B. "RCC") als
Bezeichner (zB Variablennamen) nimmt und sich über obskure
Fehlermeldungen wundert...
Hi,
Kindergärtner schrieb:> Fpga Kuechle schrieb:>> const gibt es auch in C;> Aber man kann keine Arrays mit "const"-Größe machen (in C++ schon),> weswegen alle #define für Konstanten verwenden => hässlich & gefährlich
Man kann in C keine "const Arrays" anlegen?
Wie gut das niemand das den "C Erfindern" & Compilerbauern gesagt hat!
Sonst würden die ganzen Standadbibliotheken einen Fehler nach dem
anderen schmeissen. (Const für Arrays ist etwas ganz übliches in C und
wird vielfältig verwendet - auch und gerade in den ganzen Bibs)
> Das auch. Aber die #define-Tretminen, mangelnde Abstraktion, etc> resultieren unvermeidbar in unübersichtlichem langem Code.
ICh lasse dir gerne deine Meinung, aber die werden nur wenige teilen.
Das #define Argument ist ja hinfällig, das beruhte ja nur auf deinen
mangelhaften Kenntnissen. Und ob für den großteil der üblichen µC
Anwendungen ein Objektorientiertes Programm besser Lesbar ist wage ich
mal zu bezweifeln.
Wie gesagt, wir reden hier vom Einstieg in µC und nicht komplexen
Datenbanksystemen auf dem PC.
Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig
verstanden haben. Und im Bezug auf µC sollte man vor dem sicher
angebrachten Einstieg in C erst einmal etwas ASM getippt haben.
Gruß
Carsten
Carsten Sch. schrieb:> Man kann in C keine "const Arrays" anlegen?
Keine Arrays mit "const" als Größe. Überzeuge dich selber:
http://ideone.com/KQZiYu> Wie gut das niemand das den "C Erfindern" & Compilerbauern gesagt hat!
Zumindest dem GCC wurde es gesagt.
> Sonst würden die ganzen Standadbibliotheken einen Fehler nach dem> anderen schmeissen.
Tun sie nicht, da sie #define verwenden.
> ICh lasse dir gerne deine Meinung, aber die werden nur wenige teilen.> Das #define Argument ist ja hinfällig, das beruhte ja nur auf deinen> mangelhaften Kenntnissen.
Oder vielleicht lassen dich deine mangelhaften Kenntnisse denken, dass
das #define Argument hinfällig sei?
> Und ob für den großteil der üblichen µC> Anwendungen ein Objektorientiertes Programm besser Lesbar ist wage ich> mal zu bezweifeln.
Durchaus, denn Hardware-Einheiten wie z.B. GPIO-Pins lassen sich
hervorragend als Objekte moddelieren.
> Wie gesagt, wir reden hier vom Einstieg in µC und nicht komplexen> Datenbanksystemen auf dem PC.
Auch da hilft OOP; auch wenn es die Anwendung selber gar nicht
verwendet, sondern "nur" auf ein schönes OOP-API zugreift.
> Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig> verstanden haben.
Wie gesagt, besser nicht! Lieber gleich lernen wie es in C++ richtig
geht, damit man nicht nachträglich die C-Angewohnheiten wieder vergessen
muss. Wenn man erstmal C++ kann und dann aus irgendwelchen Gründen C
verwenden muss, fragt man sich warum man sich damit noch abgibt...
>Und im Bezug auf µC sollte man vor dem sicher> angebrachten Einstieg in C erst einmal etwas ASM getippt haben.
Das bezweifle ich und eine Menge der Poster in diesem Thread auch.
Kindergärtner schrieb:> Carsten Sch. schrieb:>> Man kann in C keine "const Arrays" anlegen?> Keine Arrays mit "const" als Größe. Überzeuge dich selber:> http://ideone.com/KQZiYu
Ach DAS meinst du...
Ja - das geht nicht. Aber von der Tatsache das dies ein relativer
Spezialfall ist der gerade den Anfängern eher selten über den WEg läuft
ist dies auch ein gutes Beispiel für ein großes Missverständniss das
aber wohl häufiger auftritt.
Const als Modifier bezeichnet ja keinesfalls eine KONSTANTE sondern
bedeutet nur das ein WErt vom Programm nicht verändert werden darf.
Damit wird sichergestellt das kein Programm kompiliert wird wo die
Variable nach der Definition noch einmal verändert wird.
Das ist deshalb ein großer unterschied weil die Variable formal gesehen
erst zur Laufzeit definiert wird und so dem Präprozesser welcher die
Arraygröße kennen will nicht zur Verfügung steht.
Aber auch das kann man umgehen - Auch ohne #define
Wobei ich #define jetzt nicht so schlimm finde. Allerdings gebe ich zu
das es manchmal aus gründen der gültigkeit (Define ist ja immer
"global") in gewissen Situationen kontraproduktiv ist.
Also wen das #define in dieser Situation stört, der nimmt einfach
"enum".
> Auch da hilft OOP; auch wenn es die Anwendung selber gar nicht> verwendet, sondern "nur" auf ein schönes OOP-API zugreift.
Dieses Argument gilt aber nur wenn es eine OOP API gibt. Und das ist in
der µC Welt zur Zeit einfach die Ausnahme!
>> Zudem sollte man bevor man mit C++ anfängt erst einmal C richtig>> verstanden haben.> Wie gesagt, besser nicht! Lieber gleich lernen wie es in C++ richtig> geht, damit man nicht nachträglich die C-Angewohnheiten wieder vergessen> muss.
Und deshalb fängt fast jedes C++ Buch und so gut wie jeder C++ Kurs erst
einmal mit C an? Genauso ist bei wohl fast allen Studiengängen (egal ob
Inf. oder ET) im Bereich Programmiersprachen die Reihenfolge: erst C
dann Objektorientiert (Java oder C++)
> Wenn man erstmal C++ kann und dann aus irgendwelchen Gründen C> verwenden muss, fragt man sich warum man sich damit noch abgibt...
Sehe ich anders...
Ich kann beides und habe bevor ich mit C auf µC angefangen bin viel mehr
C++ als reines C programmiert. Aber auf dem µC komme ich für die
Projekte die ich üblicherweise bearbeite mit C besser und schneller zum
Ziel.
Wenn ich denn doch mal eine PC Anwendung selber schreiben muss dann
verwende ich dort allerdings C++ (wobei PC Programmierung bei mir
mittlerweile die Ausnahme ist, höchstens mal noch ein kleines Hilfstool,
der Rest wird vergeben)
Zudem kommt noch dazu das man sich mit der Festlegung auf C++ enorm
einschränken würde. Im Moment ist C++ unter den µC noch kaum vertreten,
bei den kleineren Exemplaren fast gar nicht vorhanden. Und da wo es C++
Compiler gibt sind die nicht selten noch im einen eher frühen Stadium.
Man würde sich selbst also massivst die Auswahl beschränken.
>>Und im Bezug auf µC sollte man vor dem sicher>> angebrachten Einstieg in C erst einmal etwas ASM getippt haben.> Das bezweifle ich und eine Menge der Poster in diesem Thread auch.
Aber die Absolute Minderheit!
Und von den ZWeiflern raten fast alle dann direkt zu C und nicht zu C++.
Als letzte Anmerkung von mir noch: Weiter oben beschreibst du die
HArdwarenähe von C als NACHTEIL. Da ist aber GERADE der große Vorteil.
Wo es auf dem PC wirklich eher kontraproduktiv für die meisten
Anwendungen ist, so braucht man das auf dem µC immer noch oft um
halbwegs effektiven Code zu schreiben. Sicherlich kännte man immer zu
den dicksten und Stromhungrigsten µC Greifen, aber selbst bei Cortex M3
oder PIC32 die durchaus auch mal 100Mhz Takt haben können ist man
Leistungsmäßig schnell an einer Grenze wenn man all zu Abstrakt ohne
Rücksicht auf die Hardware programmiert.
Mir kommt es irgendwie so vor als wenn du beim Wort µC eher an etwas in
Richtung Rasperry Pi als an einen AVR (Meinetwegen auch CortexM3)
denkst...
Gruß
Carsten
Carsten Sch. schrieb:> Ach DAS meinst du...> Ja - das geht nicht. Aber von der Tatsache das dies ein relativer> Spezialfall ist
Ja. Aber das ist die einzige Rechtfertigung für #define-Minenfelder.
Carsten Sch. schrieb:> Const als Modifier bezeichnet ja keinesfalls eine KONSTANTE sondern> bedeutet nur das ein WErt vom Programm nicht verändert werden darf.> Damit wird sichergestellt das kein Programm kompiliert wird wo die> Variable nach der Definition noch einmal verändert wird.
In C ja; in C++ sind Konstanten konstant und zur Kompiletime bekannt und
können daher für Arraygrößen verwendet werden.
Carsten Sch. schrieb:> so dem Präprozesser welcher die> Arraygröße kennen will nicht zur Verfügung steht.
Der Preprocessor kennt keine Arrays, das braucht nur der Compiler. Und
in C++ stehen sie eben doch zur Verfügung.
Carsten Sch. schrieb:> Aber auch das kann man umgehen - Auch ohne #define> Wobei ich #define jetzt nicht so schlimm finde
Mich nervts tierisch, wenn von so Libraries wie die CMSIS 100000
Bezeichner global reserviert sind und die Scoping-Regeln und namespaces
nicht greifen.
Carsten Sch. schrieb:> Also wen das #define in dieser Situation stört, der nimmt einfach> "enum".
Erzähl das mal ARM oder ST. Und das geht auch nur für Integer.
Carsten Sch. schrieb:> Dieses Argument gilt aber nur wenn es eine OOP API gibt. Und das ist in> der µC Welt zur Zeit einfach die Ausnahme!
Ja, warum auch immer. Denn wie gesagt könnte das sehr elegant und
praktisch sein.
Carsten Sch. schrieb:> Und deshalb fängt fast jedes C++ Buch und so gut wie jeder C++ Kurs erst> einmal mit C an?
Das Galileo-Buch vielleicht, aber es gibt genug die sowas nicht machen.
> Genauso ist bei wohl fast allen Studiengängen (egal ob Inf. oder ET)> im Bereich Programmiersprachen die Reihenfolge: erst C> dann Objektorientiert (Java oder C++)
Nope. In Informatik wird aus gutem Grund C kaum noch gelehrt, sondern
direkt z.B. Java. In den ganzen anderen Naturwissenschaften (inkl. ET)
wird leider noch überall C gelehrt, wahrscheinlich weil die Lehrkräfte
selber nichts anderes kennen und auch nicht die Motivation hatten, seit
ihrer eigenen Studienzeit noch etwas anderes außer C zu lernen.
Carsten Sch. schrieb:> Aber auf dem µC komme ich für die> Projekte die ich üblicherweise bearbeite mit C besser und schneller zum> Ziel.
Dann kannst du es halt nicht :D
Carsten Sch. schrieb:> Und da wo es C++> Compiler gibt sind die nicht selten noch im einen eher frühen Stadium.> Man würde sich selbst also massivst die Auswahl beschränken.
Auf allen Plattformen für die es einen GCC oder Clang gibt (und das sind
einige) hat man somit einen sehr guten C++ Compiler. Eigentlich sind die
beiden onehin die besten C++ Compiler überhaupt.
Carsten Sch. schrieb:> Zudem kommt noch dazu das man sich mit der Festlegung auf C++ enorm> einschränken würde.
Ja, kein PIC und 8051, wie... schade.
Carsten Sch. schrieb:> Und von den ZWeiflern raten fast alle dann direkt zu C und nicht zu C++.
Immer noch besser als ASM...
Carsten Sch. schrieb:> Als letzte Anmerkung von mir noch: Weiter oben beschreibst du die> HArdwarenähe von C als NACHTEIL.
Keineswegs. Ich beschreibe die mangelnden Möglichkeiten und so krude
Dinge wie Textersetzung als Mittel zur Abstraktion als Nachteil. C++ ist
genauso hardwarenah.
> Wo es auf dem PC wirklich eher kontraproduktiv für die meisten> Anwendungen ist, so braucht man das auf dem µC immer noch oft um> halbwegs effektiven Code zu schreiben.
Dafür ist C++ wunderbar geeignet.
> Sicherlich kännte man immer zu> den dicksten und Stromhungrigsten µC Greifen, aber selbst bei Cortex M3> oder PIC32 die durchaus auch mal 100Mhz Takt haben können ist man> Leistungsmäßig schnell an einer Grenze wenn man all zu Abstrakt ohne> Rücksicht auf die Hardware programmiert.
Ineffizient programmieren kann man auch in C. Abstrakt und effizient
aber nur in C++.
Carsten Sch. schrieb:> Mir kommt es irgendwie so vor als wenn du beim Wort µC eher an etwas in> Richtung Rasperry Pi als an einen AVR (Meinetwegen auch CortexM3)> denkst...
Nö, C++ kann man auch wunderbar auf Mega8 verwenden, nicht umsonst
basiert z.B. Arduino darauf (wobei deren Libraries noch einiges
Optimierungspotential haben).
µC von 0 auf lernen. ASM oder C?
Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben:
Natürlich ASM! Nur ASM!
Mit C steigt man doch erst auf sehr viel späterer, abstrakterer Stufe
ein!
Karl Käfer schrieb:> Um Auto zu fahren, muß man> auch nicht wissen, wie man einen Reifen wechselt. Das kann in bestimmten> Situationen hilfreich sein, ist aber keine Voraussetzung. Und> Fahranfänger werden mit auch nicht mit derlei überflüssigen> Informationen belastet, und zwar aus guten Gründen: weil es nämlich> überflüssig ist und sie nur von der eigentlichen Aufgabe ablenkt, ein> Auto fahren zu lernen.
Hm. Und wie sieht es mit den Verkehrsregeln aus? Lenken die auch davon
ab, Auto fahren zu lernen? ;)
Im ernst, das beispiel ist nicht schlecht und ich Stimme dir zu, man
kann auch ohne ASM Kentnisse Programmieren. Man kann aber auch ohne
Theoriekentnisse Auto fahren, trotzdem wirst du mühe haben in grösseren
Städten zu fahren, wenn du die Vortrittsregeln nicht kennst.
Karl Käfer schrieb:> ich frage mich gerade, ob ich der einzige Mensch auf der Welt bin, der> versteht, was ein "Anfänger" ist. Nämlich jemand, den die interne> Funktion seiner CPU zunächst gar nicht interessiert, sondern der erstmal> lernen muß, wie man einen Programmer an seinen Mikrocontroller> anschließt und ihn mit dem Computer ansteuert, um ein Programm auf den> uC zu schreiben.
Achja? Sind das Anfänger? Weiss ja nicht was du so gelernt hast,aber ich
hätte in meiner Berufslehre zum Elektroniker die ersten 8 Monate zwar
X-mal einen uC in der Hand, programmiert haben wir den aber nie. Wieso?
Weil uns jeden Donnerstag Nachmittag beigebracht wurde, was ein uC ist,
wie er funktioniert, welche Register er bietet, was er kann usw.
Als es dann ums Programmieren ging, war das eine grosse hilfe, da sich
dann Fragen von Beispielsweise "Wie initialisiere ich den Clock
richtig?" erübrigten und man sich lediglich die ASM befehle aneignen
musste.
Karl Käfer schrieb:> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele.
Und aus diesen 130 Instruktionen lassen sich Gruppen bilden, und schwupp
- schon sind es um einige weniger. Willst mir nicht sagen dass zwischen
einem
btfsc
btfss
ein riesen unterschied besteht? Zudem braucht man in ASM nur eine Hand
voll von diesen Befehlen.
C/ASM schrieb:> Mich würde die Meinung der Experten dazu interessieren:> Was denkt ihr ist für einen Anfänger ...
Reichlich Antworten und mich wundert immer wieder, was für "Experten"
darunter sind. Deren Meinung ist auch nur von "Experten" zu verstehen.
Da sind mir Anfänger mit einer gesunden Selbsteinschätzung lieber.
Hi
Einfach Klasse, wie hier jeder seine Programmierkenntnisse in
irgendeiner Sprache verteidigt und auch die Argumente, einfach
handfest...
Leute, der TO ist schon längst nicht mehr im Spiel. Er hat sich entweder
voll zufrieden wieder mal ein Streitthema angestoßen zu haben
zurückgelehnt oder ist eurer emsigen Erklärungswut überdrüssig.
Ich kann auch nicht verstehen, was diese Diskussion bringen soll. Ein
totaler Anfänger, also, einer der bei 0 anfängt, hat nicht nur das
Problem, eine Sprache zu lernen, sondern muss sich auch ein wenig mit
Elektrotechnik und Elektronik auseinander setzen. übrigens, es bringt
ihm gar nichts, wenn er diese Frage beantwortet bekommt und er nicht in
der Lage ist, eine Aufgabe in programmierbare Befehlssequenzen
umzusetzen. Wenn er Probleme hat, eine einfache Aufgabe in Assembler
umzusetzen, wird er dieselben Probleme in jeder anderen Sprache auch
haben.
Das belegen tausend Beiträge in diesem Forum.
Aber diskutiert weiter völlig wertlose Thematik. Und bleibt schön beim
erlernten eures Studieninhaltes. Behaltet gut den Tellerrand im Auge,
denn dahinter geht es gnadenlos in den Abgrund.
Weiterhin viel Spaß
Gruß oldmax
Hallo Robin,
Robin schrieb:> Lies bitte einmal den thread titel. Es geht nicht um C lernen, sondern> um µC und mit ASM versteht man die abläufe erst richtig.
Lies bitte einmal das Posting zu dem Thread-Titel: genau das war nämlich
die Frage, um die es hier geht.
Und daß man nur mit einem Einstieg über ASM "die abläufe erst richtig
versteht", ist nichts weiter als eine unbewiesene Behauptung, die durch
ihre ständige Wiederholung weder bewiesen, noch wahrer wird. Anders
gesagt: auch wer mit C anfängt kann die Abläufe verstehen, und auch wer
mit ASM anfängt kann die Abläufe verpassen. Ob man die Abläufe versteht,
liegt nicht an der Programmiersprache.
Vermutlich ist die Wahrscheinlichkeit, daß ein ASM-Anfänger etwas
verpaßt oder sich etwas Falsches zusammenreimt, aufgrund von ASMs
unstrukturiertem Spaghetticode sogar höher, als wenn jemand die grobe
Sache mit C erlernt und sich erst dann um die Feinheiten mit ASM
kümmert. Den menschlichen Gehirn kommen klar erkennbare Strukturen sehr
entgegen, was im Übrigen einer der Gründe dafür ist, daß sich
Hochsprachen wie C gegenüber den Assemblersprachen durchgesetzt haben
und man in Hochsprachen sehr viel produktiver arbeiten kann als in
Assemblersprachen.
Mir ist letztlich vollkommen schleierhaft, wie und warum Du (und andere)
fortwährend die Ansprüche "Anfänger" und "abläufe erst richtig
verstehen" vermengst. Das wesentliche Merkmal der Problemstellung
"Anfänger" ist es doch, zunächst einmal die groben Abläufe lernen zu
müssen -- von "richtig verstehen" könnte das ganze Konzept "Anfänger"
nicht weiter entfernt sein. Selbst wenn es tatsächlich so wäre, daß man
nur mit Assembler "die abläufe erst richtig verstehen" kann -- was
diesseits bezweifelt wird --, wäre das noch keine Aussage im
Zusammenhang mit dem Apkekt "Anfänger". "Anfänger" und "richtig
verstehen" stehen also in direktem Widerspruch und schließen einander
exklusiv aus , kurz: "Anfänger" XOR "richtig verstehen".
> Und würdest du den thread hier verfolgen, es wurde mehrfach gesagt, das> man mit ASM anfangen sollte (nicht dabei bleiben).
Würdest Du den Thread hier verfolgen: es wurde auch mehrfach gesagt, daß
man mit C anfangen sollte und nicht dabei bleiben. Übrigens auch von
mir. Insofern wäre es schön, wenn Du auf meine Argumente in der Sache
eingehen könntest. Vielen Dank.
Beste Grüße,
Karl
Hallo Fpga,
Fpga Kuechle schrieb:> Karl Käfer schrieb:>> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise>> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele. Wenn ich>> also Deiner Logik folge, daß sich weniger Instruktionen leichter lernen>> lassen -- Deine Prämisse, nicht meine -- dann läßt sich C offensichtlich>> ungefähr viermal leichter lernen als Assembler.>> Der war gut!
Ja, aber leider nicht meiner.
> Schon im C-Standardbeispiel hello_world.c reichen die 32 Schlüsselworte> nicht aus, da muß man schon auf printf aus der Standard-IO library> zurückgreifen. Ohne die Bibliotheken ist der C-programmierer auf dem> selben Nivau wie ein assembler-programmiere ohne sys-calls resp> BIOS-Einsprünge. Und um die man-page von printf durch trial und error> komplett zu beherrschen, braucht ein Anfänger einige Stunden.
printf() auf einem Mikrocontroller? Also der war jetzt wirklich noch
besser, aber leider wieder nicht meiner. Das "Hello world" auf uCs ist
doch wohl, eine LED blinken zu lassen, zu C:
1
#define F_CPU 1000000
2
#include<avr/io.h>
3
#include<util/delay.h>
4
5
intmain(void){
6
DDRB=0b00000001;
7
while(1){
8
PORTB^=0b00000001;
9
_delay_ms(500);
10
}
11
}
So, und jetzt zeigst Du mir das bitte mal in Assembler. Wenn Du Dich das
traust, werden wir sicher schnell sehen, welcher der beiden Quelltexte
kürzer, übersichtlicher, verständlicher und anfängertauglicher ist. Ach
so: schau bitte ehrlich, wie lange Du für Deinen Assembler-Code
brauchst, den C-Code habe ich in 86 Sekunden heruntergetippt.
> Abgesehen davon, das> sich ein assembler-Befehl da wenig mächtig schneller verstehen lässt als> ein> for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--)
Die Standardversion sieht ein bisschen anders aus, nicht wahr? Es ist
ein wenig lächerlich, sich hier eine willkürlich komplizierte Anweisung
heraus zu suchen und dann über ihre Kompliziertheit zu moppern. Aber da
Du gerade dieses Beispiel gebracht hast: poste hier doch bitte mal den
äquivalenten Assemblercode. Vielen Dank.
Beste Grüße,
Karl
Hallo W.S.,
W.S. schrieb:> Und das ist tatsächlich ein Problem von Anfängern. Schau dich mal in> diesem Forum um. Da siehst du massenweise Beiträge in der Art "Ich> will mit µC anfangen und weiß noch garnix, also welche IDE muß ich jetzt> lernen und wie kann ich damit debuggen?".>> Anstatt sich anzulesen, wie denn der auserwählte µC funktioniert, wird> IMMER zu allererst nach IDE, Compiler, Debugger gefragt. Als ob DAS die> Hauptsache wäre.
Für einen, Achtung: ANFÄNGER! ist das die Hauptsache. Denn der kann sich
wochenlang anlesen, wie der auserwählte µC funktioniert, aber solange er
weder weiß, wie er aus dem Quellcode etwas macht, das er auf den µC
schreiben, noch, wie er das dann auf den µC schreiben und dort ausführen
kann, hilft ihm sein ganzes Wissen über die interne Funktion des µC
überhaupt gar nichts.
> Da ist mir der ach so altertümliche Ansatz, erst mal ne Serielle zum> Laufen zu bringen und dann selbige für Debugausgaben zu benutzen, in den> meisten Fällen viel erfolgversprechender.
Müßte man dazu nicht erstmal einen Quelltext übersetzen und diesen auf
den Mikrocontroller bringen? Ach, ja, genau. Da war doch was.
Warum wird hier von der Assemblerfraktion ständig über das Verständnis
der internen Funktionen geredet? Das geht doch an der diskutierten
Thematik ("Anfänger") meilenweit vorbei.
Beste Grüße,
Karl
blink in ASM
http://conelek.org/AVR_Assembler:_LED_blinkt>for ( j =i-1;j>= 0 && k[j] > k[j+1]; j--)
warum ist das komlex/kompliziert ?
im gegensatz zu ASM weiß man hier ganz genau
dass es eine schleife ist
wo sie anfäng und wo sie aufhört {...}
was am anfang passiert (j = i-1)
was nach jedem durchlauf passiert (j--)
das einzige "kompilzierte" ist jetzt die bedingung
für mich ist es tatsächlich "schwierig" weil ich Klammern machen würde
also (j>= 0) && (k[j] > k[j+1]) damit ist es wesentlich schneller
erfassbar..
(vorallem wenn man normalerweise pascal programmiert, und dort die
Rangfolge der Operatoren anders ist..
wie man das jetzt NOCH einfacher darstellen will?? mir fällt nix ein..
Ich denke das Problem vieler Anfaenger ist nicht wirklich, ob sie mit C
oder Assembler anfangen, sondern, dass sie ohne jedes Grundwissen ueber
Computer anfangen. Auch wenn verschiedene Zahlensysteme eigentlich
Schulstoff sind, wissen doch viele der Anfaenger hier kaum was ein Bit
ist, geschweige denn, was AND/OR/XOR tun. Da wird dann ein einfaches
LED-Blinkbeispiel, egal in welcher Sprache, ploetzlich schwierig.
Natuerlich wusste ich das auch nicht, als ich vor 3 Jahrzehnten
angefangen habe. Damals stieg ich mit Basic ein. Fuer die ersten Wochen
ging es noch ohne und viel mehr als kleine Rechenprogramme oder
infantile Textausgaben sind auch erst Einmal nicht dabei heraus
gekommen. Aber die Literatur die ich damals hatte, deckte dann doch auch
die Grundlagen ab, wie der Computer ueberhaupt funktioniert, was Bits
und Bytes sind und was Speicher eigentlich ist.
Spaeter in der Schule war Pascal die Einstiegssprache und es hat mich
schon da verwundert, dass solche Grundlagen dort keine Rolle gespielt
haben. Der Anspruch an das Thema EDV war viel abstrakter und versuchte
wohl wissenschaftlicher zu wirken, unter Auslassung solcher Details. Ein
guter Teil der Informatik folgt diesem Trend und setzt ihn im Studium
fort. Und in der Tat muss man in einem grossen Teil der
Softwareentwicklung sehr wenig ueber die Maschine wissen, braucht kein C
oder C++. Und das funktioniert auch problemlos ueber ein ganzes
Berufsleben hinweg.
Aber es ist eben immer die Frage, auf welches Umfeld man guckt: Waehrend
der durchschnittliche Mikrocontroller-Entwickler dem
Enterprise-Entwickler ob seiner Wissensluecken Inkompetenz vorwirft, ist
er aus Sicht des Enterprise-Entwicklers ebenso Inkompetent. Als
Grenzgaenger zwischen beiden Welten komme ich in den Genuss, ob der
Scheuklappen beider Welten zu erschauern.
Wichtiger als die Frage, ob nun Assembler auf dem Mikrocontroller oder C
auf dem PC der bessere Einstieg ist (oder vielleicht doch besser Basic
um ohne viel Ballast ein grundlegendes Verstaendnis fuer Algorithmen zu
entwickeln), waere ein guter Buchtipp. In welchem Buch kann sich ein
Laie heute ueberhaupt in die Grundlagen von Computersystemen einlesen?
In Trivialitaeten wie "Was ist ein Bit und ein Byte", "Wie rechnet ein
Computer", "Was sind Verknuepfungen", ...
Zum AVR kann ich nicht viel sagen, wir habe in der Schule mit PIC16 in
ASM angefangen. Der hat nur 35 Befehle, von denen viele ähnlich
aufgebaut sind: z.B. andwf, addwf, iorwf. ICh habe nachgeschaut, wir
haben für das erste Programm nur 11 davon gebraucht. Diese 35/11 Befehle
denk ich sind einfacher zu Lernen als C. Ich weiß es nicht mehr genau,
aber nach ca. 6 Stunden Theorie ging‘s auf ins Labor und wir habe ein
Lauflicht programmiert.
Um die Maschine zu verstehen muss man keine Zeile in Assembler
programmiert haben. C ist eine schöne Möglichkeit strukturierte
Programmierung zu lernen ohne zu sehr von der darunterliegenden Maschine
abstrahiert zu sein.
Falls es notwendig ist z.b. SIMD,DSP,FPU-Instruktionen zu verwenden die
der Compiler nicht einsetzen kann, unterstützt jeder taugliche
C-Compiler Inline-Assembly. Kontrollstrukturen in Assembler sind so
sinnvoll wie Brainf***. Eine nette Denkübung, aber im Grunde ein
vollkommen nutzloser Skill.
Hallo Lollipop,
Lollipop schrieb:> µC von 0 auf lernen. ASM oder C?>> Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben:>> Natürlich ASM! Nur ASM!> Mit C steigt man doch erst auf sehr viel späterer, abstrakterer Stufe> ein!
Wenn es ums Programmieren geht kann es doch hier nur eine Antwort geben:
Natürlich C! Nur C!
Mit ASM steigt man doch erst sehr viel später ein, wenn es um spezielle
Optimierungen für eine bestimmte Plattform geht.
Liebe Grüße,
Karl
PS: Solange Du Deine Aussage nicht sachlich begründest, bleibt sie
wertlos. Wenn Du genau hinschaust, enthält meine Antwort sogar schon
mehr sachliche Begründung als Deine.
deine aufgabenbeschreibung ist mehrdeutig
?Was meint DDRB - alias für general - purpose register, Speicheraddresse
RAM, Speicheradresse Flash, special function register, IO- data port???
?was meint PORTB????
?was tut _delay_ms: CPU-sleep, cycle-count??
?wie soll es das tun:timer-irq, WDT-irq, dummy count, dummy port read
?wie sollen die paramter übergeben werden (register?, Stack?, Speicher?)
Das ist ein Nachteil abstrakter C-programmierung. Außer einem
allgemeinen "wert x wird zu zelle|register y geschrieben" ist die
Funktion nicht erkennbar. Erst nach Studium der includierten .H,
auflösen aller defines, und abchecken des linkers wird klar was wirklich
passiert. Dazu ist es notwendig mal auf den assembler-code zu schauen.
Der C-Schnipsel sieht zwar klar und knapp aus, verstanden werden kann er
aber nur durch eine menge von impliziten wissen. Nach dem wie du die
Fragen oben beantwortest, kann der Code so der so aussehen,
beispielsweise :
(pseudomnemnonic: 1.op destination, 2.op source, GPA is dataregister of
Port B )
1
main_entry:
2
ST $1234,x01 ;store x01 in memcell addr 1234
3
4
loop:
5
;toogle line #0 at port B
6
LD R01,GPA ;got data register of PORTB
7
XOR R01,x01 ;toggle bit #0 only
8
LD GPA,R01 ;activate data out at PORTB
9
10
;wait 500 ms
11
LD R01,x01
12
LD R02,xF4 ;parameter 500
13
CALL sub_delay
14
JP loop ;endless loop
15
16
17
org main_entry 0x00
oder völlig anders, je nach dem was sich in den includes, symbol tables
des linkers etc versteckt.
wie gesagt, deine Beschreibung ist zu unvollständig als daraus eindeutig
einen assemblercode zu genrieren. Auf die benutzung von parametrisierten
Makros, beispielsweise zur vereinfachten Aufruf von Funktionen habe ich
verzichtet, da für einen lernenden das vollständige verständnis der
uc-funktionsweise im Vordergrund steht, nicht
wie zu sehen entsteht die lesbarkeit und die beschreibung der Funktion
nicht durch die beschreibungssprache sondern durch schreibstil und
kommentare, bei C benötigt man noch einiges in Libs und defines
verstecktes hintergrundwissen.
Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell
der Code (taktanzahl)ist und was er an Speicher (register, scratchpad)
er benötigt. das sieht man im C-code nicht, und kann es u.U. dort
garnicht sehen, weil der Compiler je Speichermodell, konvention f.
paramterübergabe (register,Stack) etc anderen code generiert. Somit kann
ein Lernender nur am assemblercode sehen, wie optimal sein programm ist.
In C sieht man dergleichen nicht, dazu muss man einen Blick in den
ASM-Code werfen.
MfG
Hallo San Lue,
San Lue schrieb:> Karl Käfer schrieb:>> Um Auto zu fahren, muß man auch nicht wissen, wie man einen Reifen>> wechselt. Das kann in bestimmten Situationen hilfreich sein, ist aber>> keine Voraussetzung.>> Hm. Und wie sieht es mit den Verkehrsregeln aus? Lenken die auch davon> ab, Auto fahren zu lernen? ;)
Als ich damit angefangen habe, Autofahren zu lernen, kannte ich die
Verkehrsregeln auch noch nicht. Erst während ich gelernt habe, Auto zu
fahren, habe ich auch die Verkehrsregeln gelernt. Keine Ahnung, wie man
heute Autofahren lernt: wird denn da auch erstmal die komplette Theorie
gemacht, bevor die erste praktische Fahrstunde ansteht? Das war bei mir
damals jedenfalls nicht so.
> Im ernst, das beispiel ist nicht schlecht und ich Stimme dir zu, man> kann auch ohne ASM Kentnisse Programmieren. Man kann aber auch ohne> Theoriekentnisse Auto fahren, trotzdem wirst du mühe haben in grösseren> Städten zu fahren, wenn du die Vortrittsregeln nicht kennst.
Wenn wir das Beispiel des Autofahrens auf größere Städte ausweiten, dann
müssen wir für den uC-Bereich auch annehmen, daß unser Anfänger sofort
aus dem Stand öffentlich ein Produkt anbietet und vor einer
Programmiersprache erstmal die VDE lernen muß... Du kannst ein Beispiel
nicht willkürlich verbiegen, nur damit es Dir in den Kram paßt.
> Karl Käfer schrieb:> Achja? Sind das Anfänger? Weiss ja nicht was du so gelernt hast,aber ich> hätte in meiner Berufslehre zum Elektroniker die ersten 8 Monate zwar> X-mal einen uC in der Hand, programmiert haben wir den aber nie. Wieso?> Weil uns jeden Donnerstag Nachmittag beigebracht wurde, was ein uC ist,> wie er funktioniert, welche Register er bietet, was er kann usw.
Aha. Du hast das also gelernt, weil Du mußtest und weil Du keine Wahl
gehabt hast. Wenn Du gedurft hättest, wie Du sicherlich gerne wolltest,
hättest Du erstmal so einen uC in die Hand genommen und eine LED damit
blinken lassen.
> Als es dann ums Programmieren ging, war das eine grosse hilfe, da sich> dann Fragen von Beispielsweise "Wie initialisiere ich den Clock> richtig?" erübrigten und man sich lediglich die ASM befehle aneignen> musste.
Abstraktion scheint für viele der Assemblerfreunde hier ja wirklich ein
großes Problem zu sein. Sonst würden sie nicht immer nur von ihrem
eigenen kleinen Horizont ausgehen, sondern könnten von der eigenen
Erfahrungen auf die Wünsche und Bedürfnisse von anderen Menschen
abstrahieren. Oder anders gesagt: nur weil Du in Deiner Ausbildung dazu
gezwungen worden bist, Dich zuerst einmal monatelang durch langweilige,
weitestgehend unwichtige und theoretische Prozessorinterna zu quälen,
macht das dieses Vorgehen noch lange nicht zu einer guten Idee und schon
gar nicht empfehlenswert für andere Menschen.
Weißt Du, ich habe Pneumatik in ähnlich langweiliger, demotivierender
und quälender Weise gelernt wie Du die uC-Programmierung: erstmal
monatelang theoretische Vorlesungen und Übungen, bis uns das Thema allen
zum Halse heraus hing. Und erst, als wir alle keine Lust mehr auf das
Ding hatten, durften wir an unsere ersten Schaltungen. Keine Frage, wir
haben das sehr gründlich gelernt, aber die Art und Weise, wie wir es
gelernt haben, war Scheiße und hat uns jede Freude daran genommen.
Deswegen würde ich diesen Lernweg auch keinem Menschen empfehlen, außer,
ich kann ihn nicht leiden.
> Karl Käfer schrieb:>> Übrigens hat C lediglich 32 Schlüsselworte, AVR-Assembler beispielsweise>> für den ATmega8 hat 130 Instruktionen, also vier Mal so viele.>> Und aus diesen 130 Instruktionen lassen sich Gruppen bilden, und schwupp> - schon sind es um einige weniger. Willst mir nicht sagen dass zwischen> einem> btfsc> btfss> ein riesen unterschied besteht? Zudem braucht man in ASM nur eine Hand> voll von diesen Befehlen.
Üblicherweise braucht man in C auch nur eine Handvoll von den 32
Schlüsselworten. Aber darum ging es ja nicht, und das war nicht mein
Argument. Mir ging es nur darum, zu demonstrieren, wie dumm und falsch
das Pseudoargument des angeblch größeren Sprachschatzes in C ist. Und,
wie gesagt: menschliche Gehirne kommen mit Strukturierung und
Abstraktion viel besser klar als mit hardwarenahem Spaghetticode.
Beste Grüße,
Karl
Hi,
Karl Käfer schrieb:> Mit ASM steigt man doch erst sehr viel später ein, wenn es um spezielle> Optimierungen für eine bestimmte Plattform geht.
JA - Und genau DAS, also Otimierungen für eine bestimmte Plattform, ist
doch der UMSTIEG auf den µC.
PROGRAMMIEREN als Vorgang, insbesondere das Methodische Vorgehen - aber
auch das generelle Arbeiten mit Entwicklungsumgebungen sollte man
Sinnigerweise doch zuerst auf dem PC erlernen. Erst wenn dieser Schritt
getan ist macht der Umstieg auf den µC wirklich Sinn.
Natürlich gibt es immer ein paar die meinen den Schritt der Übung am PC
sei nicht notwendig. Aber sicher 99% von denen machen es sich nur
unnötig schwer und werden ohne die Zeit am PC nachzuholen nie einen
stand erreichen wo die wirklich gut sind.
Die "auch" ASM Befürworter hier (zumindest die meisten) schreiben doch
nicht
das man mit ASM Anfangen soll zu Programmieren.
Das empfohlene Vorgehen beim Ziel -Ich will µC beschreiben- ist:
1. Schritt:
Lerne die Grundlagen von C am PC!
2. Schritt:
Mache dich mit den BESONDERHEITEN der µC Programmierung vertraut, dazu
sind einige ASM Übungen sehr Hilfreich.
(Für die Ungeduldigen ggf. dieser Schritt parallel zu der C Phase am
PC.) Teilweise wird für den einen oder anderen im Bezug auf Pointer usw.
auch erst hier wirklich ein Licht aufgehen.
3. Schritt:
if ((C_Grundlagen == VERSTANDEN) && (µC_Besonderheiten == VERSTANDEN))
{
Einsteig_und weiteres_Arbeiten_mit_C_auf_µC();
}
Gruß
Carsten
> Warum wird hier von der Assemblerfraktion ständig über das Verständnis> der internen Funktionen geredet?
Weil man genau das unter "uC (mikrocontroller - Anm. des Autors) von 0
lernen" im Unterschied zu "programmieren lernen" versteht.
MfG
Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit
dem Pinsel oder mit der Rolle an?"
A1: "Mit dem Pinsel natürlich. Nur so lernst Du Farbe und Wand richtig
kennen".
A2: "So ein Unsinn. Mit der Rolle natürlich. Keiner braucht heute mehr
einen Pinsel. Das ist für alte Leute."
A3: "Wer eine Rolle benutzt, will einen Neger haben, der ihm die Ecke
nachstreicht, um dann mit seiner tollen Leistung beim Chef zu glänzen."
A4: "Für praktische Belange brauchst Du eh beides. Wer eine Ganze Wand
mit dme Pinsel streicht ist ein Masochist"...
Kerkerker, so eine Diskussion kann man sich nicht ausdenken, das muß man
erleben. Und so sinnlos. Der TO will beides machen und fragt lediglich,
womit man am besten anfängt.
Und Antwort ist so einfach: Wenn man mit AVR anfängt, dann mit ASM, weil
da das Tutorial hier auf µC.net besser ist. Dann kennt man schon alle
Peripherie, wenn man mit C weitermacht. Wenn man mit ARM anfängt, dann
mit C, weil da gute Tutorials existieren und man sich für den ASM-Teil
mehr zusammensuchen muß, wobei es dann von Vorteil ist, den anderen Teil
schon zu kennen.
Wie kann man sich an der Frage so aufhängen, wo noch nicht einmal
Freitag ist?
Hallo Fpga,
Fpga Kuechle schrieb:> deine aufgabenbeschreibung ist mehrdeutig
Nein, eigentlich nicht. Denn die Auswahl der Hardwareplattform geht
allem anderen, auch der Auswahl eines Assemblers oder Compilers, ja
voraus. Und spätestens wenn es darum geht, konkreten Code zu schreiben,
sind all diese Mehrdeutigkeiten für unseren Anfänger dann natürlich
längst beantwortet.
Als erfahrener Entwickler kannst Du Dir jede Deiner konstruierten Fragen
natürlich selbst beantworten, deshalb ging ich davon aus, Dir diese
Dinge nicht erklären zu müssen. Du mußt Dich nicht künstlich dumm
stellen, nur um zu versuchen, doch noch irgendwie Recht zu behalten.
> Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell> der Code (taktanzahl)ist und was er an Speicher (register, scratchpad)> er benötigt.
Diese Information ist für einen Anfänger ungefähr so hilfreich wie ein
dritter Bauchnabel. Sogar für Fortgeschrittene und Profis ist das nur in
relativ wenigen Situationen wirklich nötig.
Dies ganz abgesehen davon, daß das, was Du da behauptest, natürlich
wieder einmal in Deinem Sinne... sagen wir mal: etwas geschönt ist. Denn
manche Assemblerinstruktionen benötigen mehr als einen Takt, einige
sogar je nach Bedingung unterschiedliche Anzahlen von Takten. Ganz
offensichtlich ist es also nicht direkt sichtbar, wieviele Takte der
Code braucht.
Beste Grüße,
Karl
Walter Tarpan schrieb:> Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit> dem Pinsel oder mit der Rolle an?"
Der Vergleich hinkt. Mit einer Rolle kannst du wie mit einem Pinsel
direkt loslegen uns musst nicht die Rollen Syntax erst lernen.
Carsten Sch. schrieb:> 1. Schritt:> Lerne die Grundlagen von C am PC!>> 2. Schritt:> Mache dich mit den BESONDERHEITEN der µC Programmierung vertraut, dazu> sind einige ASM Übungen sehr Hilfreich.> (Für die Ungeduldigen ggf. dieser Schritt parallel zu der C Phase am> PC.) Teilweise wird für den einen oder anderen im Bezug auf Pointer usw.> auch erst hier wirklich ein Licht aufgehen.>> 3. Schritt:> if ((C_Grundlagen == VERSTANDEN) && (µC_Besonderheiten == VERSTANDEN))> {> Einsteig_und weiteres_Arbeiten_mit_C_auf_µC();> }
Wenn man mit ASM einsteigt, spart man sich den ersten Schritt…
Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM
Programmieren könnten und umgekehrt...
Hi Carsten,
Carsten Sch. schrieb:> JA - Und genau DAS, also Otimierungen für eine bestimmte Plattform, ist> doch der UMSTIEG auf den µC.
Und sogar auf uC ist ASM nur in wenigen, seltenen Fällen notwendig und C
für Anfänger erstmal vollkommen ausreichend.
> Die "auch" ASM Befürworter hier (zumindest die meisten) schreiben doch> nicht das man mit ASM Anfangen soll zu Programmieren.
Mit den "auch ASM Befürwortern" habe ich auch kein Problem, schließlich
bin ich selbst einer. Aber einige hier empfehlen einem Anfänger ohne
jede Vorkenntnis von Mikrocontrollern und ohne Vorkenntnis von
Programmierung, beides mit Assembler anzufangen. Genau um solche
Anfänger geht es doch:
C/ASM schrieb:
> Wenn ich einen anderen µC lerne würde ich in ASM anfangen, da ich wissen> will, was in der CPU so abgeht. Mick interessiert aber wie's für einen> kompletten Neueinsteiger aussieht. Was würde ihr einem anfänger> Empfehlen, der nach der Lösung für ein relativ einfache Projekt fragt?
Beste Grüße,
Karl
Max H. schrieb:> Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM> Programmieren könnten und umgekehrt...
Volltreffer ;)
Ich mag beides (und habe noch mit Maschinencodes angefangen ;)
Hallo Max,
Max H. schrieb:> Wenn man mit ASM einsteigt, spart man sich den ersten Schritt…
Und den sollte man sich sparen, weil...?
> Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM> Programmieren könnten und umgekehrt...
Seit dem VC 20 selig. Kannst Du denn C?
Beste Grüße,
Karl
Karl Käfer schrieb:> #define F_CPU 1000000> #include <avr/io.h>> #include <util/delay.h>>> int main(void) {> DDRB = 0b00000001;> while(1) {> PORTB ^= 0b00000001;> _delay_ms(500);> }> }
include "m8def.inc"
.def temp0 = r16 ;
.def temp1 = r17 ;
.def temp2 = r18
.def temp3 = r19 ;
.def temp4 = r20
.cseg
.org $0000
rjmp stack
stack: ldi temp1,high(ramend) ;Stackpointer festlegen
out sph, temp1
ldi temp1,low(ramend) ;Stackpointer festlegen
out spl, temp1
sbi ddrd,0
start: sbi portd,0
rcall wait500ms
cbi portd,0
rcall wait500ms
rjmp start
wait500ms:
ldi temp1,$05
wait500ms1:
ldi temp2,$63
wait500ms2:
rcall wait1ms
dec temp2
brne wait500ms2
dec temp1
brne wait500ms1
ret
wait1ms:ldi temp3,$06
wait1ms1:
ldi temp4,$df
wait1ms2:
dec temp4
brne wait1ms2
dec temp3
brne wait1ms1
ret
so siehts in ASM aus ohne zu verheimmlichen das kleine helfer die libs
in C auch erstellt haben. Würde man das in ASM tun, ich glaube dann
kommt man auf das selbe raus.
Karl Käfer schrieb:> Und den sollte man sich sparen, weil
man in ASM keine C-Kentnisse brauch
Karl Käfer schrieb:> Kannst Du denn C?
Ja
Ob man mit C oder mit ASM schneller zum ersten Erfolgserlebnis (z.B.
blinkende LED) kommt hängt davon ab wie man vorgeht.
-Wenn man erst die C Grundlagen lernt und dann mit dem µC beginnt, ist
man mit ASM natürlich schneller.
-Wenn man die C-Grundlagen auf dem µC lernen will, wird man vllt.
schneller zur blinkenden LED kommen. Danach kann es dazu kommen:
TriHexagon schrieb:
> Threads wo der Threadstarter klare
> Grundlagendefizite hat, sich weigert diese endlich mal auszumerzen
und
> lieber weiter am LCD rumspielt gibs hier jeden Tag.
Ich denke ob C oder ASM für die einstieg besser ist, hängt vom
angepeilten Projekt ab. Wenn es ein Einfaches ist, kommt man mit ASM
schneller zu Ziel, di wie bereits erwähnt, die C-Grundlagen wegfallen.
Bei komplexeren Programmen kann man mit C viel Zeit sparen, die man in
die C-Basics investieren kann.
Max H. schrieb:> Walter Tarpan schrieb:>> Q: "Hallo, ich will gerne streichen lernen! Fange ich da am besten mit>> dem Pinsel oder mit der Rolle an?"> Der Vergleich hinkt. Mit einer Rolle kannst du wie mit einem Pinsel> direkt loslegen uns musst nicht die Rollen Syntax erst lernen.>> [...]
Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst.
Macht aber nichts. Es soll sogar Leute geben, die nicht einmal kochen
können.
Walter Tarpan schrieb:> Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst.
Das kann sein, bin Elektroniker und kein Anstreicher. Ich habe vor ca.
einem Monat ein Gehäuse angestrichen. Mit dem Pinsel ging‘s nicht so
gut, dann habe ich mit eine Rolle gekauft und das Ergebnis des ersten
Versuchs mit der Rolle war besser als, das Beste mit dem Pinsel.
Noch ein vllt. passendes Beispiel:
Wenn jemand ein anderes Land in den Urlaub fährt und nur an Stand liegen
und nicht verhungern will, soll er erst die Sprache lernen oder
versuchen sich mit Handzeichen usw. zu verständigen?
Wenn er hingegen das Land und die Leute kennenlernen will, sollte er
vorher die Sprache lernen.
Walter Tarpan schrieb:> Womit erst einmal bewiesen ist, daß Du nicht richtig anstreichen kannst.> Macht aber nichts. Es soll sogar Leute geben, die nicht einmal kochen> können.
Walter 1 : 0 Max
Ganz im ernst. Diese Diskussion führt ins endlose.
Max H. schrieb:> Mich würde mal interessieren, wie viele der ASM-Gegner, in ASM> Programmieren könnten und umgekehrt...
Kannst davon ausgehen, nicht die hälfte der Leute die C können, könnten
etwas in ASM Programmieren.
Auch bei theoretischen Fragen um den uC, da es laut dem Autor nicht ums
Programmieren geht, sondern um den Verständnissaufbau von uC's, kannst
du daovn ausgehen dass Leute die ASM beherrschen den reinen C kennern
meilenweit vorraus sind.
Klar, viele Leute interessiert das wohl nicht. Aber wenn es darum geht,
den uC an sich kennen zu lernen, wird man mit ASM besser bedient sein.
Soll doch mal einer von den C Kennern schreiben, wie lange es dauert ein
Bit eines Portes zu setzen, bei einem Takt von 20MHz mit einem
PIC16F887.
Datenblätter lesen solltet ihr ja können ;)
Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas
anderes als kleine Progrämmchen, die einfache Aufgaben übernehmen, auf
dem µC geschrieben. Schon mal einen FAT32 Treiber in ASM geschrieben?
Nein? Warum sollte man sich so etwas auch antun? ASM für kleine und
einfache Aufgaben völlig ausreichend, aber wenn es um komplexe und
größere Programme geht, ist ASM einfach inakzeptabel. Dafür wurde C
konzipiert und da sich kleine Programme genau so gut mit C schreiben
lassen, warum nicht also auch dort benutzen?
Das ist zwar so ziemlich OffTopic, musste aber unbedingt mal gesagt
sein.
Karl Käfer schrieb:> Hallo Fpga,>> Fpga Kuechle schrieb:>> deine aufgabenbeschreibung ist mehrdeutig>> Nein, eigentlich nicht. Denn die Auswahl der Hardwareplattform geht> allem anderen, auch der Auswahl eines Assemblers oder Compilers, ja> voraus.
Nein, bei der Produktentwicklung erst wird die Auswahl an uC anhand der
elektrischen paramter/Funktionen eingeschränkt, dann zieht man die
Aufwände und Nutzen einer SW-Entwicklungsumgebung als weiters Kriterium
an.
Auch im Hobbybereich wurdeen AVR und PIC eingesetzt bevor es C-Compiler
für diese gab.
> Und spätestens wenn es darum geht, konkreten Code zu schreiben,> sind all diese Mehrdeutigkeiten für unseren Anfänger dann natürlich> längst beantwortet.>> Als erfahrener Entwickler kannst Du Dir jede Deiner konstruierten Fragen> natürlich selbst beantworten, deshalb ging ich davon aus, Dir diese> Dinge nicht erklären zu müssen. Du mußt Dich nicht künstlich dumm> stellen, nur um zu versuchen, doch noch irgendwie Recht zu behalten.
Nein, ich stell mich nicht dumm. Ich zeige dir nur auf, das dein kurz
ausschauender Quelltext eine Menge implizititen Wissens zum Verständnis
bedarf, was in einem Assemblercode sichtbar ist. Und all das implizite
Wissen was man sich nicht aus dem C-Code erschliessen kann, bekommt man,
fängt man Assembler an, auf den Silbertablett serviert. Als
Erklärbeispiel fürs bit-toggeln ein wenig geeigneter Code-schnipsel.
>> Aber auch ohne die Kommentar wird im assemblercode sichtbar wie schnell>> der Code (taktanzahl)ist und was er an Speicher (register, scratchpad)>> er benötigt.>> Diese Information ist für einen Anfänger ungefähr so hilfreich wie ein> dritter Bauchnabel. Sogar für Fortgeschrittene und Profis ist das nur in> relativ wenigen Situationen wirklich nötig.
Deine Behauptung - meine Erfahrung lehrt mich anderes. Gerade Anfängern
sollte man ein Instrument an die Hand geben die Effizient des eigenen
Codes bewerten zu können.
> Dies ganz abgesehen davon, daß das, was Du da behauptest, natürlich> wieder einmal in Deinem Sinne... sagen wir mal: etwas geschönt ist. Denn> manche Assemblerinstruktionen benötigen mehr als einen Takt, einige> sogar je nach Bedingung unterschiedliche Anzahlen von Takten. Ganz> offensichtlich ist es also nicht direkt sichtbar, wieviele Takte der> Code braucht.
Ich schöne nicht, Du unterstellst. Nimm die Anzahl der cyclen pro befehl
und addiere sie zusammen- bei Sprüngen kommt noch etwas Sadistik dazu,
ober ob nun der Sprungbefehl am Ende einer Schleife die 8chtmal
durchlaufen wird insgesamt 8 oder 9 Cyclen in der CPU aktiv war ist bei
Abschätzungen vernachlässigba.r Abgesehen davonn davon das die meisten
Befehle eines uC nur einen Takt benötigen. In C sind die
Assemblerbefehle nicht ersichtlich ist und zudem von commandlineoptionen
etc abhängig. (bspw. Art der Parameterübergabe).
MfG,
BTW
1
PORTB^=0b00000001;
Ich glaube, das kein Anfänger hier erkennt, das dieses Konstrukt den
logischen einzig ein Pin "wackeln" lässt. Erst im Assemblercode wird das
klar, dem "^=" sieht man das nun wahrlich nicht an - das ist für
Anfänger "obfuscated". Ein
TriHexagon schrieb:> Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas
Es gibt keine Nur-ASM Fraktion, du sprichst ins Leere.
MfG
Wie man bei diesem Thema ziemlich sicher immer vom Hundertsten ins
Tausendste kommt! Genauso ziemlich sicher war das auch nicht der letzte
der gefühlt 10000 Threads zu diesem Thema. Zu unterschiedlich sind die
Bedürfnisse, Erwartungen, Empfindsamkeiten, Vorlieben,
Interpretationsmöglichkeiten der Wortwahl der "Gegner", Vorkenntnisse,
Erfordernisse im Beruf, Vorhaben und schließlich realisierte Projekte...
Dazu hat jede Programmiersprache ihr Für und Wider und in einer
Diskussion wie dieser gibts immer dann einen Konflikt, wenn das
gegnerische Für und das eigene Wider im Blick durch die oben
aufgezählten Gegebenheiten der individuellen Brille nicht ausreichend
gewürdigt/ zur Kenntnis genommen wird.
Hi
>Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas>anderes als kleine Progrämmchen,...
Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay,
Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der
Größenordnung 12-13k Programm.
Solche Kleinigkeiten
Beitrag "Re: Zeigt her Eure Kunstwerke !"
kommen mit wesentlich weniger aus.
>Warum sollte man sich so etwas auch antun?
Wo ist das Problem? Ich habe eine ganz Reihe eigener Libs (Text-
Grafikdisplays, Sensoren, Kommunikation incl. Ethernet, Mathefunktionen,
Zeit-/ Datumsfunktionen mit Oster-/Feiertagsberechnung, ....). Da hält
sich der Aufwand für das eigentliche Programm stark in Grenzen.
Das soll jetzt kein Pro oder Kontra für irgend eine Programmiersprache
sein. ASM ist die persönliche Entscheidung für mich. Womit andere
programmieren geht mir meilenweit an der hinteren Körperöffnung vorbei.
Genauso wie Missionierungsversuche mit allein seligmachenden
Programmiersprachen oder Controller.
MfG Spess
Fpga Kuechle schrieb:> Es gibt keine Nur-ASM Fraktion,
Falsch. Es mögen ja nicht sehr viele sein.
Aber es gibt sie. Leute, die auch größere Programme in Asm schreiben.
Das kann als Hobby durchaus Spaß machen. Wenn man ein sinnvolles,
effizientes, funktionelles, einheitliches Programmsystem mit einem
fertigen Fundus an Routinen für alles, was man so an Schnittstellen,
Berechnungen usw. braucht entwickelt hat dann sinkt auch der Zeitbedarf.
Allerdings beschränkt man sich für Asm sinnvollerweise auf wenige
Controller-Typen einer Reihe. Das muß, je nach Art der Projekte, auch
kein Nachteil sein.
Hallo Fpga,
Fpga Kuechle schrieb:> Nein, bei der Produktentwicklung
Anfänger und Produktentwicklung... finde den Fehler. ;-)
> Auch im Hobbybereich wurdeen AVR und PIC eingesetzt bevor es C-Compiler> für diese gab.
Niemand hat bestritten, daß man Mikrocontroller auch in ASM
programmieren kann. Die hier diskutierte Frage ist aber eine andere.
> Nein, ich stell mich nicht dumm. Ich zeige dir nur auf, das dein kurz> ausschauender Quelltext eine Menge implizititen Wissens zum Verständnis> bedarf, was in einem Assemblercode sichtbar ist.
Findest Du? Trotz meiner Erfahrung mußte sogar ich den Assemblercode von
chris aufmerksam lesen, um ihn zu verstehen. Jeder Anfänger wäre damit
heillos überfordert -- aber meinen C-Code versteht auch ein Anfänger
spätestens er den ^=-Operator nachgeschaut hat. Dabei ist mein C-Code
nicht einmal äquivalent zum Assembler-Code, denn ich benutze ein OR und
chris' ASM-Code nicht...
> Deine Behauptung - meine Erfahrung lehrt mich anderes. Gerade Anfängern> sollte man ein Instrument an die Hand geben die Effizient des eigenen> Codes bewerten zu können.
Ein typischer Anfänger kann das weder in ASM noch in C. Um die Effizienz
beurteilen zu können, braucht man Erfahrung und genaue Messungen -- also
genau das, was einem Anfänger gemeinhin abgeht.
> Ich schöne nicht, Du unterstellst. Nimm die Anzahl der cyclen pro befehl> und addiere sie zusammen- bei Sprüngen kommt noch etwas Sadistik dazu,> ober ob nun der Sprungbefehl am Ende einer Schleife die 8chtmal> durchlaufen wird insgesamt 8 oder 9 Cyclen in der CPU aktiv war ist bei> Abschätzungen vernachlässigba.r Abgesehen davonn davon das die meisten> Befehle eines uC nur einen Takt benötigen. In C sind die> Assemblerbefehle nicht ersichtlich ist und zudem von commandlineoptionen> etc abhängig. (bspw. Art der Parameterübergabe).
Man kann auch in C ganz gut abschätzen, wie viele Takte eine Operation
braucht. Dies ganz davon abgesehen, daß das für die meisten Anfänger
vollkommen irrelevant ist. Aber wenn das der große Vorteil von Assembler
sein soll, ist es den Aufwand dem unstrukturierten Spaghetticode nicht
wert -- und schon gar nicht für einen Anfänger. Erschwerend kommt hinzu,
daß jeder Interrupt die ganze schöne Abschätzung sofort zunichte macht.
Entschuldige, aber Du redest die ganze Zeit von Anforderungen, die sogar
einem Profi vergleichsweise selten begegnen, um damit zu begründen,
warum Anfänger mit Assembler anfangen sollten. Dabei bauen sogar die
Profis ihre Software in C, und schreiben höchstens mal zeitkritische
Teile in ASM -- wenn sie nicht einfach auf einen schnelleren Controller
ausweichen, weil das nämlich häufig immer noch billiger als die
Entwicklung und Wartung von Assembler-Code.
>
1
>PORTB^=0b00000001;
2
>
>> Ich glaube, das kein Anfänger hier erkennt, das dieses Konstrukt den> logischen einzig ein Pin "wackeln" lässt.
Ich bin überzeugt, daß das jeder Anfänger versteht, der [+-*/%]= und den
^-Operator kennengelernt hat. Das ist ja nun wirklich keine große Magie
-- jedenfalls weniger Magie als die Unterschiede zwischen jmp, rjmp,
ijmp und eijmp. Wenn Du Magie sehen willst, schau Dir mal Perl an <eg>.
Beste Grüße,
Karl
Ich möchte dazu auch meine bescheidene Meinung abgeben.
IMHO ist es für einen Anfänger auf jeden Fall leichter C zu lernen,
zumindestens wenn er schon eine andere Hochsprache kennt. Bei mir war es
so, dass ich mit Small Basic (ja, überhaupt keine Optimierung)
angefangen habe. Dann kam der Umstieg auf OOP mit Java, um danach erst
anzufangen in C/C++ Progrämmchen (Hello World und simplere
Pointerarithmetik) zu schreiben. Dann kam relativ schnell (durch
Hochhochsprachen wie Java kennt man schon recht viel, vor allen Dingen
hat man jedoch ein allgemeines Verständnis für Programme und
Informationsquellen) der Umstieg auf Arduino, um dann auf das Stellaris
Launchpad umzusteigen. Bei dem CortexM4 war für mich eigentlich sofort
klar, dass ich C benutzen werde, da die driverlib, die TI kostenlos
mitgibt, wirklich seeeehr angenehm ist. Es ist mittlerweile tatsächlich
so, dass ASM sehr selten verwendet wird, da es in größeren
Softwareprojekten, die auch im Hobby irgendwann auftreten, nicht
praktikabel ist, in absehbarer Zeit (die Entwicklung einer dafür nötigen
ASM Library nimmt Monate in Anspruch) Fortschritt zu machen. Ich vermute
mal, dass mir (fast) jeder zustimmen wird, dass C auf Dauer leichter ist
als ASM, da man einfach utility Funktionen hat, die einem ungeheuer
Arbeit abnehmen. (Ich vermisse ja schon die zigtausend Hilfsklassen in
Java, von daher mache ich mich gar nicht an ASM ran ;) )
C/ASM schrieb:> Mich würde die Meinung der Experten dazu interessieren:> Was denkt ihr ist für einen Anfänger der µC von 0 auf lernt einfacher?> Direkt mit ASM starten oder erst C lernen und dann den µC in C proggen?
Das ist die Steilvorlage für etwas das früher Flamewar genannt wurde und
zu vielen Texten in Grossbuchstaben führte.
Jeder hier wird versuchen "seinen Weg" als die einzig mögliche Lösung zu
präsentieren.
Schnupper hier und da mal rein und bleib da wo es gefällt. Du selbst
must Entscheidungen treffen. Und das geht nicht nur auf Basis fremder
Erfahrungen, da muß auch ein wenig "Eigenkapital" dabei sein.
Viel Erfolg und auch viel Spass dabei!
Ich selber schließe mich ja keiner der Gruppen fest an, da ich denke,
dass C im späteren Programmierleben unabdingbar ist, niemand will
größere Projekte rein in ASM schreiben. Aber das ist doch für die
Diskussion hier vollkommen irrelevant?!
Es geht doch darum, dass heute ein GROßTEIL der Leute recht faul ist und
schnell ans Ziel kommen will. Deshalb muss unbedingt mit leicht
veständlichem C angefangen werden (Ja, in C ist die oberflächliche
Programmfunktion leichter zu verstehen). Das führt dann eben dazu, dass
alle unsere tollen Softwareentwickler keinen Dunst haben, was sie da
eigentlich tun und was der µC bei manchen Befehlen im Hintergrund
schwitzen muss.
Bei uns gab es soooo viele Leute, die einfach nette Divisionen in ihren
Code geballert haben (wieso, ist doch am Computer auch kein
Problem!!??11) und sich gefragt haben, wieso denn das Programm im Ablauf
nicht schnell genug hinterher kommt.
Wenn man dann mit dem Wissen über die Funktionsweise eines µC (die man
beim Programmieren mit ASM gelernt hat) aufzeigt, dass z.B. eine
Division durch Potenzen von 2 durch einen Rechtsshift viiiel schneller
gehen, dann schauen die Leute doof aus der Wäsche (das ist ja nur eines
von vielen Beispielen, es geht mir hier ums Prinzip).
Klar, C ist leichter. Aber wenn man immer nur den Weg des kleinsten
Widerstandes geht und jegliche Mühe scheut, sich mal mit den
Hintergründen zu beschäftigen, dann kann das ja nur in die Hose gehen...
Also mein Tipp: Lieber zunächst ein wenig Zeit investieren und erstmal
verstehen, wie so ein Prozessor funktioniert (was doch sowieso viel
spannender ist als zeilenweise blöder Code) und DANN kann man auch
anständig mit der Programmierung beginnen =)
spess53 schrieb:> Hi>
...
>> Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay,> Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der> Größenordnung 12-13k Programm.>> Solche Kleinigkeiten>> Beitrag "Re: Zeigt her Eure Kunstwerke !">> kommen mit wesentlich weniger aus.
Zitat:
> Eigentlich sollte die auf eine SD-Karte (Slot vorhanden).>Aber igendwie ist mir dann am Kartenstückeln die Lust ausgegangen.
und "beweist" damit, alles was ich oben geschrieben habe..
der faule, dumme arduino zusammenstöppsler hätte das schreiben/lesen auf
SD karte in 5 minuten erledigt..
(und er hätte ein farb-touch LCD, nur mal so am rande.. nicht so ein
grausliches S/W ding)
das für 20% der kosten, ;-)
(jaja OT, und nicht ganz Ernst gemein!)
Ohne alles gelesen zu haben:
C/C++ ist eine wichtige Programmiersprache, auch in Zeiten von Java &
Co. Ich habe damals C und µC "gleichzeitig" gelernt, auf einem AT908535
(heute: Mega32), unter Verwendung von einem Texteditor, makefiles und
WinAVR, AVR Studio gab es noch nicht.
Mittlerweile bin ich beruflich als auch privat auf ARM Cortex sowie
Windows-Programmierung unterwegs.
Hi
>> Eigentlich sollte die auf eine SD-Karte (Slot vorhanden).>>Aber igendwie ist mir dann am Kartenstückeln die Lust ausgegangen.>und "beweist" damit, alles was ich oben geschrieben habe..>der faule, dumme arduiono zusammenstöppsler hätte das schreiben/lesen>auf SD karte in 5 minuten erledigt..
Das hast du falsch verstanden. Nicht das Schreiben oder Lesen der
SD-Karte war das Problem. War schon längst gegessen. Das Problem lag
einfach im verfügbaren Kartenmaterial.
>(und er hätte ein farb-touch LCD, nur mal so am rande.. nicht so ein>grausliches S/W ding)
Kann man 2014 leicht sagen. Das Teil ist ca. 2004 entstanden.
MfG Spess
Hallo Freunde
Dieser Thread ist so lang, dass ich vielleicht doch etwas überlesen
habe. ich will jedoch meinen senf dazugeben.
Annahme:
uC von 0 lernen, ASM oder C?
Der angesprochene der Fragestellung plant erstmals sich mit µC zu
beschäftigen, weil:
1. Berufsanfänger oder junger Mensch
2. beruflich nutzbar
3. Hobby Elektroniker will auch µC in sein Spektrum aufnehmen,
eigentlich hardware orientiert.
4. Hobby Elektroniker der "embedded" Syteme entwickeln will
5. Hobby Elektroniker oder Programmierer der kein Fokus auf "embedded"
hat
Der unter 5. genannte Typ ist nicht in meinen Fokus bei diesem Beitrag.
Der unter 3. genannte Typ ist sicher mit ASM nicht verkehrt gelagert
trtzdem könnten die Informationen von Nutzen sein;1
Der unter 1. genannte Typ kann zum typ 3. oder 5. gehören, dann trifft
das auf ihn zu, kann aber auch unter die verbleibenden kategorien
gehören die ich gezielt hiermit adressiere.
Die µC sind durch die Folgen der Miniaturisierung in eine interessante
Situatio geraten. Die größe des Siliziums in einem µC wird heute mehr
durch den bedarf an Pins bestimmt, als durch den Inhalt, englisch statt
"core limited", "pad limited".
Die Kosten für eine Fertigung von ICs, bei angenommen vergleichbarer
Anzahl von Prozessschritten, wird durch den Wafer, also der Scheibe des
Silizium-Kristalls bestimmt und dadurch wieviele funktionsfäige ICs aus
einem solchen wafer gewonnen werden. Als Folge dieser Kostenstruktur
ergeben sich die möglichen Preise für ICs in einem wettbewerbsintensiven
Marktumgebung. µC für die embedded Anwendung sind definitiv ein solcher
Markt.
Dadurch ergibt sich für den Fertiger das Problem, womit er das Silizium
in einem IC füllt. Natürlich wird die Ausbeute größer, wenn der Kern
nicht voll genutzt wird, aber das ist in erster Näherung betrachtet
vernachlässigbar.
Dadurch folgt aber, das der Kostenvorteil von µC mit 8 oder 16 Bit
breiten Datenstrukturen früher ergab, als eben Designs "Core limited"
und nicht "Pad limited" waren, verloren geht, wenn man diese mit
modernen Architekturen, wie eben die ARM Cortex Mx mit ihrer 32 Bit
Architektur, vergleicht.
Die zusätzliche Chip-Fläche ist eh verfügbar und noch "frei" die sich
aus der Folge der Vervierfachung oder Verdoppelung der Datenbusse und
Datenstrukturen ergibt und damit quasi kostenlos! Die Vorteile aber sind
bestechlich! Zuerst mal die höhere Leistungsfähigkeit moderner
Architekturen, eben z. B. ARM Cortex Mx im Vergleich zu einem Avnet oder
PIC mit 8 oder 16 bit Architektur und den schon in die jahre gekommenen
Architekturen. Das hat aber eine Menge Konsequenzen und die möchte ich
anghand der ARM Cortex Mx im Allgemeinen und der von NXP im besonderen
betrachten, sowie die Konsequenzen der Fragestellung in diesem Thread!
Grundsätzlich gibt es 2 Konsequenzen aus einem Wechsel von einer 8 oder
16 Bit Architektur zu einer 32 Bit Architektur:
1. Die Leistungsfähigkeit steigt.
2. Der Leistungsbedarf kann weiter sinken.
Die höhere mögliche Leistungsfähigkeit einer 32 Bit Architektur und
einer solchen modernen wie die von ARM Cortex µC ist evident.
Nicht so evident ist der unter 2. genannte geringere Leistungsverbrauch!
Lasst uns annehmen ein Avnet AVR mega8 oder ein entsprechender µC vom
Typ PIC haben eine bestimmte Aufgabe zu bewältigen und die nehme 100%
der Leistungsfähigkeit dieser µC in Anspruch. Diese µC sind also 100%
der Zeit beschäftigt. Ein ARM Cortex Mx erledigt diese Aufgabe in einem
Bruchteil der Zeit. Während ein µC aktiv ist, ist sein Leistungsbedarf
hoch, wenn er aber nicht aktiv ist, so kann sein Leistungsbedarf massiv
gesenkt werden. Betrachtet man also den Leistungsbedarf einer Schaltung,
so ist der resultierende Leistungsverbrauch der modernen Architektur
geringer. Aber auch wenn man Leistungsverbrauch senkende Elemente in die
Designs einführt, so bleibt bei gleichen Annahmen der mögliche
resultierende Leistungsbedarf der bei einem ARM Cortex Mx, hier
besonders solche vom typ M0 oder sogar M0+, geringer.
Zusammengefasst: Ohne höhere Kosten kann eine ARM Cortex Mx
Implementation eines µC sowohl die Annahme unter 1. und ". erfüllen.
Jetzt möchte ich mich der ursprünglichen Fragestellung von "C", gleich
Hochsprache" versus ASM nähern und hierbei die ARM Cortex Mx und jene
von NXP heranziehen, trifft aber eigentlich auf alle ARM Cortex Mx
Lieferanten zu!
Bei den traditionellen Architekturen, z. B. Avnet AVR oder PIC, hat man
mit Systemen auf Silizium zu tun, welche die verfügbaren Ressourcen sehr
begrenzt bereitstellen und die daher sehr davon profitieren, wenn der
Programmierer "seinen µC" bis zum letzten Bit und Register beherrscht,
kennt und versteht. Man möge sich an die frühen Zeiten der Rechner
erinnern, wo man wegen begrenzter Ressourcen "Spagetti Kode" schrieb und
z. B. beim Datum mit nur 2 Stellen beim Jahr in das Millenium Problem
geriet!
Das trifft auf moderne ARM Cortex Mx Implementationen so nicht mehr zu!
Betonung für Puristen unter den Lesern auf das Wort "so"! Auch ich kann
mir Dinge vorstellen wo das so nicht gilt!
Der embedded Markt durchläuft immernoch eine Revolution, die Konsequenz
der Möglichkeiten dieser modernen Architekturen im Allgemeinen und der
ARM im Besonderen. Er wird immer komplexer, immer umfangreicher!
Betrachtet man jetzt die ARM Cortex Mx µC, so gibt es eine Reihe von
Faktoren und daraus resultierender Folgen die für unsere Fragestellung
eindeutig für die Hochsprache sprechen und die Vorteile der profunden
und detaillierten Kenntnis der Bits und Register in einem µC, wie sie
automatisch bei einer ASM Programmierung erforderlich sind, in eine
geringere Bedeutung und wodurch solche detallierten kenntnisse einen
geringeren Nutzen bringen!
Alle ARM Cortex Mx µC, egal von welchem Hersteller, stammen aus der IP
Schmiede von ARM. Und alle Lizenznehmer müssen die Lizenzbedingungen von
ARM für seine ARM Cortex Mx Kerne erfüllen! Die Folge ist die
Vergleichbarkeit und auch der relativ einfache Wechsel von einem
Lieferanten zu einem Anderen, wenn der Systemdesigner bestimmte Regeln
einhält. Ein Faktor für unsere Fragestellung ist die gemeinsame API die
im CMSIS Bibliotheken realisiert wird. Greift ein Programmierer auf die
Peripherie in einem ARM Cortex Mx über CMSIS zu, so kann sein Programm
mit geringem Aufwand auf den ARM Cortex Mx eines anderen Herstellers
portiert werden, solange dort die verwendeten Peripherie-Funktionen
ebenfalls verfügbar sind! Eine Hersteller unabhängige API, vom
Lizenzgeber ARM vorgegeben und in der verpflichtend vom Hersteller
bereitzustellenden API für die auf dem jeweiligen µC vorhandenen
Peripherie-Funktionen macht die Notwendigkeit die profunde und
detaillierte Kenntnis der Bits und Register zu haben für den
Programmierer weniger wichtig. Damit ein starkes Argument für die
Hochsprache und gegen ASM. Wieder für die Puristen! Eine profunde und
detaillierte Kenntnis eines µC ist immer von Vorteil und je nach den
oben genannten Typen von Personen die sich mit einem µC für eingebettete
Systeme interesieren mehr oder eben weniger wichtig! Sicher ist aber,
dass eine abstrahiertere Beschäftigung den Lernvorgang für einen
Anfänger beschleunigt und die Effizienz des Programmieres erhöht und
viel weniger Fehler bei der Entwicklung der immer komplexer werdenden
eingebetteten Systeme auftreten, höhere Komplexitäten realisiert werden
können und solche Projekte schneller realisiert werden können.
Wegen der Bedeutung für das Verständnis des Marktes und der Anbieter von
ARM Cortex Mx µC, sowie auch für die Begründung warum auch effiziente
und kostengünstige Lösungen in Hochsprache eben eher und effizienter
möglich sind, möchte ich folgende Auswirkungen der Situation vorstellen.
Da alle Lieferanten und Fertiger von ARM Cortex Mx µC vergleichbare
Produkte anbieten und wenn die Systemrealisierer sich z. B. an CMSIS
halten, so bedingt die Suche nach Alleinstellungsmerkmalen der diversen
Anbieter Folgen die ich kurz vorstellen möchte und die ebenfalls eine
Begründung pro Hochsprache und gegen ASM sprechen.
Der erste Pfad zur Suche nach Alleinstellungsmerkmalen von Anbietern von
ARM Cortex Mx µC ist die Konfiguration ihrer Produkte mit solchen
Peripherie-Modulen, die für eine Zielanwendung möglichst Vorteilhaft
sind.
Das bedingt das Entstehen von Familien von Produkten die durch die
anvisierten Anwendungsfelder Vorteile gegenüber Wettbewerbern haben,
wodurch die Anzahl der Wettbewerbsprodukte reduziert wird auf eben
solche die ebenfalls diese Zielanwendungen anpeilen. Die Qualität und
Leistungsparameter werden durch den Wettbewerb der durch das relativ
einfache Wechseln des Anbieters erzwungen wird, fördert die Qualität,
nicht nur bei der Implementation in Hardware, sondern auch die Qualität
der CMSIS Bibliotheken, da ineffiziente Implementierungen der CMSIS
Bibliothekn eventuelle Vorteile einer guten Hardware Implementierung
auffressen würden. Auch ein Argument pro Hochsprache!
Jeder erfahrene Programmierer weiss, dass die Leistungsfähigkeit seiner
Software nicht nur durch die Qualitäten der Hardware, der Qualität
seiner Kodierung bestimmt wird, sondern auch von der Qualität und
Effizienz der verwendeten Bibliothekn, der vertwendeten IDE und der dort
zum Einsatz kommenden Compiler bestimmt wird. Auch ein Argument pro
Hochsprache, da die Anbieter von ARM Cortex Mx µC durch die
Vergleichbarkeit und innerhalb bestimmter Grenzen gegebenen
Austauschbarkeit seiner Produkte hier auf die Qualität achten muss, da
sonst seine Bemühungen bei der Hardware konterkariert werden!
Ohne auf die Qualität der CMSIS-Implementationen der diversen Anbieter
einzugehen möchte ich folgendes am Beispiel der ARM Cortex Mx von NXP
schreiben, die oben gesagtes zu bestätigen scheinen!
NXP hat mit "Embedded Artists" die LPCXpresso Karten zu extrem günstigen
Konditionen verfügbar gemacht. NXP hat mit dem IDE-Anbieter "Code Red"
eine auf ihre ARM Cortex Mx µC optimierte IDE kostenlos bereitgestellt
und das mit nur der Beschränkung auf 256 kByte Kodegrüße. Da die IDE ein
strategisches Element von NXP für das Bemühen um Alleinstellungsmerkmale
ist, so vermute ich, hat NXP Code Red erworben, die Limitierung auf 512
kByte erweitert und auch C++ verfügbar gemacht. Die LPCXpresso-Karten,
ich habe mit der LPCXpresso1769 begonnen, eine Karte mit dem ARM Cortex
M3 LPC1769, ist zweigeteilt. Die eine Seite ist das JTAG-I/F über welche
die IDE auf die andere Seite zugreifen kann, welche eine eigenständige
LPC1769 µC Karte ist, so klein von seinen Abmessungen und so preiswert
zu beziehen, dass die eigene Entwicklung und Fertigung einer µC Karte
mit dem LPC1769 in vielen Fällen hinfällig wird. Die IDE von NXP "kennt"
alle verfügbaren LPCXpresso-Karten und konfiguriert die Tool-Chain voll
automatisch. Zusammenfassend: Bei NXP kann man mit der Kombination einer
LPCXpresso-Karte mit dem ARM Cortex Mx µC der eigene Wahl, dabei kommt
dort immer gleich die Leistungsfähigste Variante des µC zum Einsatz und
der IDE Entwicklungen durchführen und profitiert von den Vorzügen
moderner Entwicklungswerkzeuge für einen "Nettobetrag" von unter 20.-
Euro in Einzelstückzahlen. Bei den ARM Cortex M4 µC sind die Karten
teuerer, da hier mehr dazugehört.
Zuletzt möchte ich noch darauf verweisen, hier sind die produkte von TI
ein gutes Beispiel, wird die Möglichkeit geboten eine Variante des µC
mit fest "eingebrannten Kode" für bestimmte Anwendungen und Funktionen
für einen geringen Mehrbetrag zu erwerben. TI nutzt also den auf dem
Silizium verfügbaren Raum z. B. auch dazu. Diese Entwicklung steht noch
am Anfang und ihre effizientre Nutzung ist eigentlich nur durch die
Verwendung von Hochsprachen möglich. Geht also der anfangende
Fragesteller von der Frage aus, ob er ASM oder C benutzen soll, so ist
je nach einem der eingangs genannten Typen von Nutzern in dem meisten
Fällen die Hochsprache zu empfehlen!
Fpga Kuechle schrieb:> Es gibt keine Nur-ASM Fraktion, du sprichst ins Leere.
Oh doch die gibt es! Es ist Jene, die argumentiert, dass C zu
kompliziert, zu aufwändig zu lernen und zu ineffizient sei. Diese
Aussagen in diesem Thread und in Anderen über dieses Thema darfst du dir
selber suchen.
spess53 schrieb:>>Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas>>anderes als kleine Progrämmchen,...>> Meinst du? Ich habe Gerätesteuerungen mit ATMega1281 (Grafikdisplay,> Touchscreen ,teilweise mit Ethernetanbindung) die liegen in der> Größenordnung 12-13k Programm.>> Solche Kleinigkeiten>> Beitrag "Re: Zeigt her Eure Kunstwerke !">> kommen mit wesentlich weniger aus.>>>Warum sollte man sich so etwas auch antun?>> Wo ist das Problem? Ich habe eine ganz Reihe eigener Libs (Text-> Grafikdisplays, Sensoren, Kommunikation incl. Ethernet, Mathefunktionen,> Zeit-/ Datumsfunktionen mit Oster-/Feiertagsberechnung, ....). Da hält> sich der Aufwand für das eigentliche Programm stark in Grenzen.
Ja natürlich, es ist eine Herausforderung, macht Spaß und man lernt
viel, wenn man so etwas mit geringsten Mitteln erschafft (ASM und
vermutlich auch mit so wenig RAM und kleinsten µC wie nur möglich). Aber
nicht immer ist der Weg das Ziel, auch bei Bastler, sondern das
Erreichen des Ziels mit relativ wenig Arbeit/Zeitverbrauch.
Es muss also jeder selbst entscheiden welches Werkzeug für ein Projekt
passender erscheint. Aber eins ist sicher: als Anfänger sollte man sich
mit ASM und C beschäftigen.
Hellmut schrieb:> AVR oder PIC, hat man> mit Systemen auf Silizium zu tun, welche die verfügbaren Ressourcen sehr> begrenzt bereitstellen und die daher sehr davon profitieren, wenn der> Programmierer "seinen µC" bis zum letzten Bit und Register beherrscht,
Da muß ich widersprechen.
Der Hauptgrund für Assembler war früher, daß es für Hobbyanwender keine
bezahlbaren Compiler gab.
Der Siegeszug des AVR begann auch erst dann, als es mit dem WINAVR einen
leicht zu benutzenden und ausreichend optimierenden Compiler gab.
Anwendungen, die Ressourcen forden, mit GUI, Touch, Ethernet usw. kann
man ja von der Stange kaufen. Aber kleine Steuerungsaufgaben lohnen sich
für die Industrie nicht, die muß sich der Bastler selber programmieren
und da ist weder Leistung noch Effizienz gefordert.
Der Reiz am Programieren als Hobby liegt ja darin, sich Aufgaben zu
programmieren, für die es nichts kaufbares gibt. Das sind dann meistens
einfache Ablaufsteuerungen für ein ganz spezielles Problem.
Und für den bequemen Einstieg empfiehlt sich dann Bascom oder C auf nem
8-Bitter.
TriHexagon schrieb:> Ganz ehrlich, diese NUR ASM und Anti-C Fraktion hat wohl noch nie etwas> anderes als kleine Progrämmchen, die einfache Aufgaben übernehmen, auf> dem µC geschrieben. Schon mal einen FAT32 Treiber in ASM geschrieben?> Nein? Warum sollte man sich so etwas auch antun? ASM für kleine und> einfache Aufgaben völlig ausreichend, aber wenn es um komplexe und> größere Programme geht, ist ASM einfach inakzeptabel. Dafür wurde C> konzipiert und da sich kleine Programme genau so gut mit C schreiben> lassen, warum nicht also auch dort benutzen?
Weil Anfänger ja auch einen Treiber für einen FAT32 schreiben. Ich
gehöre laut deiner Meinung wohl zur "ASM Fraktion" (Programmiere selber
mittlerweile seit rund 2 Jahren nurnoch in C).
In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind
in C übersichtlicher und einfacher zum schreiben. ASM benutze ich
heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu
lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich
mir beim besten willen nicht vorstellen wie man sowas mit C einfacher
lernen soll als mit ASM.
San Lue schrieb:> Weil Anfänger ja auch einen Treiber für einen FAT32 schreiben. Ich> gehöre laut deiner Meinung wohl zur "ASM Fraktion" (Programmiere selber> mittlerweile seit rund 2 Jahren nurnoch in C).
Lies doch bitte den ganzen Post, da habe ich doch extra noch
geschrieben:
TriHexagon schrieb:> Das ist zwar so ziemlich OffTopic, musste aber unbedingt mal gesagt> sein.
Außerdem gehörst du nicht zur "NUR ASM Fraktion", da du ja kein C
Verweigerer bist.
San Lue schrieb:> In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind> in C übersichtlicher und einfacher zum schreiben. ASM benutze ich> heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu> lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich> mir beim besten willen nicht vorstellen wie man sowas mit C einfacher> lernen soll als mit ASM.
Da gebe ich dir natürlich recht, bei ASM lernt man den µC wirklich
besser kennen, deshalb sollte man sich einmal mit ASM und C beschäftigt
haben, allerdings habe ich auch nie etwas anderes behauptet.
TriHexagon schrieb:> San Lue schrieb:>> In einigen Punkten geb ich der C Fraktion recht. Grössere Programme sind>> in C übersichtlicher und einfacher zum schreiben. ASM benutze ich>> heutzutage auch nicht. Wenn es aber darum geht, einen uC kennen zu>> lernen, und darunter versteh ich nunmal auch wie er arbeitet, kann ich>> mir beim besten willen nicht vorstellen wie man sowas mit C einfacher>> lernen soll als mit ASM.>> Da gebe ich dir natürlich recht, bei ASM lernt man den µC wirklich> besser kennen, deshalb sollte man sich einmal mit ASM und C beschäftigt> haben, allerdings habe ich auch nie etwas anderes behauptet.
Du vllt. nicht, aber die ASM-verweigerer :D
In einem Fach, wo Kommilitonen noch gar keine Ahnung von µC hatten,
hatten wir einen Prof., der alle 10 Minuten immer wie ein Rosenkranz
wiederholte, daß C so easy wäre, und Assembler 1:1 übersetzt, und man
den nicht braucht.
Na ja. Spätestens beim printf() fluchten sie. Hmmm, verstehe das nicht,
so ein Befehl hat doch nur einen Maschinenzyklus... Wie der Prof. sagte,
C zu Assembler 1:1.
;-)
Wilhelm F. schrieb:> Hmmm, verstehe das nicht..
Ach, du Scherzkeks.
Zu meiner Studententenzeit war Fortran und Algol angesagt - und Übungen
zu beidem: alos Lochkarten stanzen, Job (= flacher Blechkasten mit allen
Lochkarten drin) am Fensterl der Rechenstaton abgeben und nächsten Tag
wieder abholen.
Ich hatte mir damals - weil mir nix besseres einfiel - eine
Wickeltabelle für Netztrafos mit M-Schnitt programmiert. Die hatte ich
viele jahre lang! Hat was genützt beim Basteln...
Aber der Sinn deiner Bemerkung ist klar: Viele Ausbilder, vom
Berufsschul-Lehrer über die gymnasialen Mathe- und Informatik-Lehrer bis
hin zu einem erheblichen Teil der Uni-Professoren sind selbst nur
Hasenschüler ohne jegliche echte Erfahrung und ohne echtes Wissen. Und
ihr gediegenes Halbwissen geben sie dann fleißig an die Studenten ab,
die es dann wie ihr persönliches Evangelium halten. Aus solchen
Hasenschulen kommen dann Eggschberden (Experten), die sich über ein
"goto" aufregen, weil sie eben NICHT das eigene Denken gelernt haben.
Du wist sehen, in einigen Jahren wird es NUR NOCH solche
Pseudo-Ingenieure geben. Sollen oder wollen wir das lustig finden?
W.S.
Im Schatten des allgemeinen Hypes rund um das Schlagwort „Web 2.0“ hat
sich in der Webentwicklung die Verwendung von Javascript-Frameworks,
mehr und mehr etabliert. Mittlerweile verwenden ca. 39% (Stand Januar
2011) aller Webseiten ein oder mehrere dieser JS-Bibliotheken. Diese
bieten dem Benutzer eine umfangreiche Sammlung an Javascript-Funktionen,
die die vielfältigen Möglichkeiten der Programmiersprache einfacher und
übersichtlicher zur Verfügung stellen als in der herkömmlichen
Code-Schreibweise.
Allerdings stellt sich dem scriptfreudigen Designer bei der schieren
Anzahl an verfügbaren JS-Bibliotheken die Frage, welche es sein soll.
Und warum.
Diese Frage kann man sicherlich nicht vollständig beantworten, da die
vielen verschiedenen Frameworks teils sehr unterschiedliche Aufgaben
erfüllen.
Möchte man seiner Webseite durch interaktive Elemente neues Leben
einhauchen, bietet sich jQuery an, die sicherlich am meisten verwendete
JS-Bibliothek. 29% ALLER Webseiten (75% Marktanteil bei JS-Bibliotheken)
nutzen es bereits, darunter auch viele bekannte Namen wie z.B. Google,
Amazon oder IBM.
Nicht nur wegen seiner enormen Verbreitung ist das 2006 von John Resig
entwickelte jQuery gut dafür geeignet, einer Webseite Leben
einzuhauchen. Die Grundphilosphie des OpenSource-Projekts beruht auf
einer simplen Aussage: „write less, do more“. Und genau das tut es.
Mithilfe des Frameworks kann Code erzeugt werden, der sich im Vergleich
zu herkömmlichen Javascript-Aufrufen um ein vielfaches leichter lesen
lässt. Auch kann der einmal erschaffene Code leicht für andere Projekte
angepasst und somit wiederverwertet werden. Damit gestaltet jQuery viele
Programmierabläufe deutlich komfortabler.
Gleichzeitig ermöglicht es auch Webdesignern mit beschränkten
JS-Kenntnissen den Zugang zu mächtigen Werkzeugen.
Die generelle Syntax von jQuery ist an die Handhabung von CSS-Selektoren
angelehnt. Besonders die Flexibilität der zahlreichen Selektoren bietet
schier endlose Möglichkeiten, das Erleben der Webseite auf einfache und
nachvollziehbare Weise interaktiver und lebendiger zu gestalten.
Im Gepäck hat das beliebte Framework ebenfalls zahlreiche
vorimplementierte Funktionen, die sich verwenden lassen, um Effekte wie
z.B. das Ein- und Ausblenden von Elementen schnell zur Verfügung zu
stellen. Diese Funktionen fassen zwar nur mehrere Javascriptbefehle
zusammen, die auch ohne jQuery umzusetzen sind – wer sich allerdings
einmal an den stark reduzierten und gut lesbaren Code der JS-Bibliothek
gewöhnt hat, wird nicht mehr darauf verzichten wollen.
Einen weiteren Pluspunkt verzeichnet jQuery durch Plugins – und
natürlich die starke Community dahinter, die stetig neue Scripts
überarbeitet und veröffentlicht. Ob für eine Lightbox, mehrstufige
Navigationen oder einen Textslider – für nahezu jeden Zweck gibt es eine
vielzahl an Plugins, die fertige Code-Snippets übersichtlich
zusammenfassen. Diese können in der Regel auch von Personen ohne
umfangreiches JavaScript-Vorwissen angepasst und verwendet werden.
Go macht keine falschen Versprechungen. Vielleicht ist es gerade das,
was die Sprache längerfristig interessant macht. Im Jahr 2007 haben
Robert Griesemer, Ken Thompson und Rob Pike sie erfunden, weil sie mit
den existierenden Sprachen zur Systemprogrammierung unzufrieden waren.
Dabei bedienen sie keinen der aktuellen Trends um asynchrone
Webprogrammierung oder Cloud Computing. Vielmehr haben sie aus 30 Jahren
Erfahrung mit C gelernt und eine Programmiersprache geschaffen, die
deren Nachfolge antreten könnte.
Wie C zeigt auch Go [1] seine Stärken bei der Systemprogrammierung,
wenngleich sich die Sprache natürlich für nahezu alle Zwecke einsetzen
lässt. Die Spracherfinder sind bei Google angestellt, deshalb hat Go
neben Java und Python auch seinen Weg auf die Google App Engine
gefunden, die Go derzeit im experimentellen Stadium unterstützt [2].
Zukunftsträchtig
Anfang 2008 hatte Ken Thompson einen ersten experimentellen Compiler
fertiggestellt, der C-Code erzeugt. Ian Tyler begann etwas später mit
der Arbeit an einem Go-Frontend für den GCC-Compiler. Gegen Ende des
Jahres stieg Russ Cox in das Go-Projekt ein, und die Arbeit ging etwas
schneller voran. Im November 2009 präsentierte das Team dann endlich das
erste öffentliche Release des Go-Compilers. Im März 2012 erschien
Version 1.0 von Compiler und Spezifikation, die Kompatibilität für die
kommenden Go-Releases verspricht [3]. Damit eignet sich Go jetzt auch
für richtige Software-Projekte, nicht nur für Experimente.
Die ausgesprochenen Ziele des Go-Projekts sind effiziente Übersetzung,
schnelle Ausführung und einfache Programmierung. Bei existierenden
Sprachen seien alle drei Zeile zusammen nicht zu haben, meinen die
Go-Erfinder. Go soll das simple Programmieren in den immer beliebteren
Sprachen wie Python und Ruby mit der Effizienz und Zuverlässigkeit von
Sprachen wie C, C++ und Java kombinieren. Dabei soll die Übersetzung
aber nicht so lange dauern wie etwa bei Java-Projekten. Außerdem will Go
besser mit Abhängigkeiten zwischen externen Bibliotheken umgehen.
Einfachheit ist eines der hervorstechenden Merkmale von Go. Ihr zuliebe
haben die Spracherfinder auf viele Konstrukte verzichtet. In erster
Linie soll Go eine konsistente und unzweideutige Syntax besitzen. Das
kann man von Sprachen wie etwa Perl, Ruby oder Scala nicht behaupten,
die für ein und denselben Zweck eine Vielzahl syntaktischer Konstrukte
oder Methoden besitzen.
Go orientiert sich an C, lässt aber viele Sprachelemente weg,
beispielsweise solche, die redundant den gleichen Zweck erfüllen. Zum
Beispiel gibt es vom Inkrement-Operator »++« nur noch die
Postfix-Variante, die hinter der Variable steht. Gleichzeitig ist dies
nur eine Anweisung, aber kein Ausdruck, der gleich weiterverwendet
werden kann. Das führt zwar zu etwas mehr Schreibarbeit, aber zu
eindeutiger Semantik und weniger Verwirrung.
Etwas klarer werden Go-Programme noch durch Anleihen bei strukturierten
Sprachen wie Pascal, Modula und Oberon. Teilweise war die Go-Syntax
schon in Newsqueak und Limbo verwirklicht. Letztere ist die
Programmiersprache des Inferno-Betriebssystems, das wiederum ein Ableger
des Plan9-Systems ist, an dem Thompson und Pike früher arbeiteten.
W.S. schrieb:> Aus solchen> Hasenschulen kommen dann Eggschberden (Experten), die sich über ein> "goto" aufregen, weil sie eben NICHT das eigene Denken gelernt haben.
Mal ganz abgesehen davon, daß ein Assemblerprogramm hauptsächlich von
Sprüngen lebt. Im auf gesetzten C sieht man sie zwar nicht, aber sie
sind ja immer noch da, weil der Zwischenschritt vor dem reinen
Maschinencode immer noch ASM ist.
Apropos ASM oder C:
Keines von beiden. In der Anfangszeit programmierte ich auf dem 8051
sogar nur direkt Maschinencode, weil einen PC mit Assembler hatte ich ja
noch gar nicht.
Den Stack beim 8032 ins indirekt adressierte RAM legen, hieß bei mir
nicht:
MOV SP, #7Fh
sondern immer gleich
75 81 7F
alles andere ebenso.
Ich konnte die Befehle und Register mal alle fast in Zahlen auswendig.
Es ging auch. Den Maschinencode möchte ich nicht unbedingt mehr, ASM
hingegen schon.
Die ersten 8051 codete ich noch ganz ohne PC. Einfach, weil es die
Anfangszeit war, als sich der PC erst langsam verbreitete. Der erste
Assembler war dann ein richtiges Highlight. C-Compiler gab es gar nicht.
Und das ist noch gar nicht lange her, erst 1990.
Noch heute zieren sie sich ja wie verrückt mit den C-Compilern: Wenn man
nicht gerade Geld wie Sau hat und eine Profi-Vollversion, da ist vieles
für Hobbybastler nach wie vor immer noch sehr arg kastriert. Bei
Assemblern nicht.
;-)
Ja, vielleicht sollte man, um einen µC im Detail zu verstehen, weder mit
C noch mit Asm, sondern tatsächlich mit Hex oder noch besser mit Bin
beginnen. Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur
auf die Hälfte der 32 Datenregister anwendbar ist.
Yalu X. schrieb:> Ja, vielleicht sollte man, um einen µC im Detail zu verstehen, weder mit> C noch mit Asm, sondern tatsächlich mit Hex oder noch besser mit Bin> beginnen. Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur> auf die Hälfte der 32 Datenregister anwendbar ist.
Ok. Habe ich auch so gemacht. echt Hardcore. Danach kann Dich keine
Programmiersprache mehr schrecken ...
Hallo Wilhelm,
Wilhelm F. schrieb:> Mal ganz abgesehen davon, daß ein Assemblerprogramm hauptsächlich von> Sprüngen lebt. Im auf gesetzten C sieht man sie zwar nicht,
Ich schon. So schwer ist das ja nun wirklich nicht. Und zur Not, wenn
ich sie wirklich ganz genau sehen will, hat mein Compiler (siehe unten)
da so spezielle Schalter... ;-)
> Noch heute zieren sie sich ja wie verrückt mit den C-Compilern: Wenn man> nicht gerade Geld wie Sau hat und eine Profi-Vollversion, da ist vieles> für Hobbybastler nach wie vor immer noch sehr arg kastriert.
Probier' doch mal die GNU Compiler Collection aus. In einem Test, den
ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem
Paket nicht nur Clang, sondern sogar den Intel-Compiler aus.
Liebe Grüße,
Karl
Karl Käfer schrieb:> Probier' doch mal die GNU Compiler Collection aus. In einem Test, den> ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem> Paket nicht nur Clang, sondern sogar den Intel-Compiler aus.
Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben
unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim
Assembler oder beschnittenen C Compiler bleiben.
Dr. Sommer schrieb:> Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben> unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim> Assembler oder beschnittenen C Compiler bleiben.
Blödsinn - Zumindest im Bezug auf die PIC.
1. Für die größeren PIC gibt es GCC basierende Compiler.
(Wobei es ja auch geschmackssache ist ob jemand gcc favorisiert oder
nicht. Nicht für jeden ist das der Nabel der Welt)
2. Die freien Compiler von Microchip sind -nach ablauf einer Zeit mit
vollen Funktionsumfang- nur in der maximalen Optimierungsstufe
eingeschränkt.
Für Hobbyisten in wohl 99% der Fälle irrelevant.
Gruß
Carsten
Yalu X. schrieb:> Nur dann erfährt man, warum bspw. der LDI-Befehl des AVR nur> auf die Hälfte der 32 Datenregister anwendbar ist.
Ist doch ganz easy, bei 16 Bit Befehlsbreite:
8 Bit für das Datenwort
4 Bit der Ladebefehl
bleiben noch 4 Bit für das Zielregister übrig, also 16 Möglichkeiten.
Hallo Herr Dr.,
Dr. Sommer schrieb:> Karl Käfer schrieb:>> Probier' doch mal die GNU Compiler Collection aus. In einem Test, den>> ich jüngst auf Slashdot gelesen habe, stach der C++-Compiler aus diesem>> Paket nicht nur Clang, sondern sogar den Intel-Compiler aus.>> Den Luxus, eine Plattform zu verwenden, für die es einen GCC gibt, haben> unsere armen 8051 und PIC Menschen leider nicht. Die müssen leider beim> Assembler oder beschnittenen C Compiler bleiben.
Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich
auch eine Plattform, auf der der GCC läuft. Wenn er wirklich keine
Plattform hat, der arme Mensch, dann würde ich gerne eine Spendenaktion
starten. Ich werfe einen RasPi-B in den Topf. Wer spendet eine alte
SD-Karte, idealerweise >= Class 6? Wer spendet Kabel und eventuell
Adapter? Ich kann da noch für einen 17"-Röhrenmonitor einspringen oder
einen HDMI-<->VGA-Adapter.
Liebe Grüße,
Karl
Carsten Sch. schrieb:> Blödsinn - Zumindest im Bezug auf die PIC.> 1. Für die größeren PIC gibt es GCC basierende Compiler.
Die benutzt aber keiner, weil da könnten ja eventuell ein paar Bytes
Speicher übrig bleiben, wenn das Projekt winzig ist!
> (Wobei es ja auch geschmackssache ist ob jemand gcc favorisiert oder> nicht. Nicht für jeden ist das der Nabel der Welt)
Stimmt, gibt ja auch noch Clang.
> 2. Die freien Compiler von Microchip sind -nach ablauf einer Zeit mit> vollen Funktionsumfang- nur in der maximalen Optimierungsstufe> eingeschränkt.> Für Hobbyisten in wohl 99% der Fälle irrelevant.
Optimierungen sind schon sehr hilfreich - Wenn die Code-Größe auf einen
Bruchteil reduziert wird, kann das schon nocht entscheiden ob das
Programm auf einen µC passt oder nicht. Wobei man es aber auch erstmal
schaffen muss die richtig großen µC's vollzukriegen...
Karl Käfer schrieb:> Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich> auch eine Plattform, auf der der GCC läuft.
Es geht nicht um auf, sondern für... Auf einem AVR läuft auch kein
GCC, aber der GCC kann AVR-Code generieren.
> Wenn er wirklich keine Plattform hat, der arme Mensch...
Es gibt ja auch Menschen die Assembler verwenden :-D
Es kann ja nicht jeder ARM verwenden, für das es einen wunderbar
funktionierenden, optimierenden, kostenlosen unbeschränkten GCC gibt.
Irgendwer muss sich ja auch mit den 8051 etc. quälen, die sind sonst
traurig!
Dr. Sommer schrieb:> Irgendwer muss sich ja auch mit den 8051 etc. quälen
Darfst Dir sicher sein, das ist ein Genuß. Denn die sind einfach und man
kann sich für sehr sehr viele Apps sicher sein: Der Aufwand den ich hier
treibe ist genau der den es braucht und nicht mehr... STM32 & Co samt
deren komplexen Dickichts der Toolchains und Libs sind die eigentliche
Quälerei. Aber: Die 32-Bitter sind was neues, haben technischen
Unterhaltungswert und geben das schöne Gefühl: Ich bin vorn mit dabei
und kann auf die 8-Bitter so schön gefällig herabschauen... Hat auch
was. Zugegeben.
Dr. Sommer schrieb:> Irgendwer muss sich ja auch mit den 8051 etc. quälen
Nö, ist keine Qual.
Ich kann mit dem Keil C51 sämtliche >500 Typen des 8051 programmieren.
Dem Compiler ist das wurscht. Auch neuere Typen sind kein Problem, mein
C51 ist noch von 1995.
Beim ARM muß dagegen die Toolchain jeden Typ, den ich verwenden will,
explizit unterstützen. Für neuere Typen brauche ich ein Update.
Und die Toolchains sind jeweils verschieden für ARMs von Atmel, NXP, ST,
TI.
Peter Dannegger schrieb:> Nö, ist keine Qual.> Ich kann mit dem Keil C51 sämtliche >500 Typen des 8051 programmieren.> Dem Compiler ist das wurscht. Auch neuere Typen sind kein Problem, mein> C51 ist noch von 1995.
Kann das denn auch moderne Dinge wie C++11?
Mir gefällt jedenfalls die Argumentation - kein ARM kann zu viel, kein
C++11 weil 8051 Compiler kann das nicht.
> Beim ARM muß dagegen die Toolchain jeden Typ, den ich verwenden will,> explizit unterstützen. Für neuere Typen brauche ich ein Update.> Und die Toolchains sind jeweils verschieden für ARMs von Atmel, NXP, ST,> TI.
Nope. Der z.B. GCC-ARM-Embedded unterstützt nur die Corex-M* Cores und 0
Mikrocontroller. Mit Linkerscript&Startupcode (gibts vom Hersteller oder
kann man auch leicht selber schrieben) kann man damit aber für alle
Cortex-M* Controller programmieren. Und zumindest explizit von/für ST
gibt es überhaupt keine Toolchain.
Moby schrieb:> Dr. Sommer schrieb:>> Irgendwer muss sich ja auch mit den 8051 etc. quälen>> Darfst Dir sicher sein, das ist ein Genuß. Denn die sind einfach und man> kann sich für sehr sehr viele Apps sicher sein: Der Aufwand den ich hier> treibe ist genau der den es braucht und nicht mehr...
Naja, der 8051 hatte auch seine Zeit. Aber es ist heute schlichtweg
nicht mehr nötig sich dauernd mit den Einschränkungen im
Programmiermodell, der Arithmetik und den Adressräumen zu befassen.
Code Banking, SFR Paging, IDATA, DATA, XDATA, PDATA, Registerbänke,
16-bittige Integer... das ist alles fürs Museum.
Welchen ehrlichen Vorteil habe ich heute mit einem 8051 für ein Projekt
bei dem es nicht relevant ist ob die MCU 0,80 oder 1,50 EUR kostet?
Dr. M. schrieb:> Welchen ehrlichen Vorteil habe ich heute mit einem 8051 für ein Projekt> bei dem es nicht relevant ist ob die MCU 0,80 oder 1,50 EUR kostet?
Wenn’s nur fürs Hobby ist könnte es sein, dass der derjenige nur Wissen
und Hardware (Programmer usw.) für den 8051 hat.
Ich würde sagen fürs Hobby ist die Diskussion C vs. ASM sinnlos, außer
wie die eigentlich Frage war finde ich die Frage für einen Einsteiger
der noch kein C-Kenntnisse hat berechtigt. Jeder soll das nehmen was ihm
besser gefällt, er besser beherrscht und besser für sein Project
geeignet ist. Und bei der Wahl des µCs ist es das gleiche.
Dr. Sommer schrieb:> Kann das denn auch moderne Dinge wie C++11?
Ich würde mal vermuten, das ist nach 1995 entstanden. Ich kenne keinen
Compiler, der in die Zukunft schauen kann.
Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich
besser implementieren lassen.
Karl Käfer schrieb:> Also wenn Wilhelm am Internet teilnehmen kann, dann hat er sicherlich> auch eine Plattform, auf der der GCC läuft. Wenn er wirklich keine> Plattform hat, der arme Mensch, dann würde ich gerne eine Spendenaktion> starten.
Oh Mann, ich hab halt mal ganz klein angefangen, und meine ersten
8051-Programme bekam ich ganz alleine ohne PC und ohne ein
Internet-Frageforum hin.
Für meine 8051-Derivate habe ich den SDCC-Compiler, der ist nicht
luxuriös aber reicht. Als Oberfläche Geany, finde ich auch ganz
brauchbar. Und für den seriellen Programmdownload Tera Term, auch ganz
brauchbar, weil das Windows HyperTerminal gibt es unter Vista nicht
mehr.
Ohne Debugger geht es auch.
Aber Hobby, Zeit spielt keine Rolle, nur Spaß, keine Projekt-Deadline
und nichts dergleichen. Nur Spaß.
Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt
Maschinencodierung: Damit half ich einigen Kommilitonen durch die
Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich
übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet,
und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem
Studium raus geflogen. Klausuraufgaben wollten das wissen. Denn dort
sollte man als Hauptaufgabe mit der höchsten Punktzahl ein kleines
Progrämmchen mit 10 Zeilen und mit einer Verzweigung drin schreiben.
Z.B. Lampe an einem Pin leuchtet je nach Tastendruck an einem anderen
Pin. Für den Sprung reichten nicht alleine die Befehle, sondern auch die
Byteanzahlen der Befehle, und dafür mußte man den Maschinencode neben
den Befehl schreiben, und für Sprünge genau diese Bytes zählen.
Guten Tag!
Zuerst einmal lernen, was eine Schalttransistor ist und wie so etwas
funktioniert. Most of the time das Rest ergibt sich von selbst.
Zuerst Etwas diskret aufbauen. Without Controllers. Und verstehen
lernen, was so ein µC able is to do. Ohne Kenntnisse der
Grundlagen-Elektronik programmieren wollen, is like a rowboat on den
Ozean: Ohne Help!
Good luck,
Stuart
Hi,
Wilhelm F. schrieb:> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt> Maschinencodierung:
Hihi, das musste ich in meiner Abschlussprüfung anno ´01 auch noch
machen.
Erst ein fertiges Programm "analysieren", also erkennen was es macht -
dann ein weiteres Programm schreiben. Jeweils nur die nackten Hex Codes
auf dem Bildschirm mit der Übersetzungsliste neben der Tastatur.
(Auf den MFA Mikrocomputer)
ISt natürlich noch ein Schritt weiter in Richtung
Hintergrundverständniss - allerdings muss man irgendwo auch eine
Sinnvolle Untergrenze setzen womit sich ein (Nichtberuflicher)
Einsteiger heute befassen sollte.
Das man allerdings zumindest mal gesehen/gehört/gelesen haben sollte das
ein Assembler in der Regel nicht viel mehr macht als die gerade noch
einigermaßen Menschenverständlichen MNEMONICS des Assemblercodes 1-1 in
eine Zahlenreihe umzuwandeln -und das die Bedeutung der jeweiligen
Zahlen ganz verschieden sein kann - je nach Position... das denke ich
zwar heute noch. Aber mehr als 1-2h Gesamtzeit braucht sich auch
gründlicher -an tiefen Verständniss interessierter- Einsteiger damit
nicht mehr befassen.
Gehört für mich mit zum Themenbereich "Mal ein paar ASM Übungen machen".
Das erhöht im Übrigen ja auch das Verständniss für den ganzen Ablauf in
der Toolchain. Der Code wird in C geschrieben, der C Code wird zu ASM
Compiliert und das ASM Listing wird dann erst zu einem Bytestrom
umgesetzt der in den µC geschrieben wird. Für alte Hasen ist das eine
absolute Selbstverständlichkeit, aber ein Einsteiger hat da nicht selten
schon erste Verständnissprobleme bei den Abhängigkeiten.
Was ich bei den ASM Totalverweigerern nicht verstehe ist die Tatsache,
das die so energisch dagegen wettern als würde die Mehrzahl der "auch
ASM" Beführworter hier fordern das ein Einsteiger ASM wirklich noch in
vollendung Lernen soll. Wenn man von ein bis zwei Aussenseitermeinungen
absieht ist das doch gar nicht der Fall.
Den Syntax einer Programmiersprache -fast egal welcher- lernt man sehr
schnell. Die Grundlagen sollten selbst bei Normalbegabten nach 1-2
Nachmittagen da sein. Das was Zeit, ja sehr viel Zeit, braucht ist die
Erfahrung und Routine um mit dem Werkzeug Programmiersprache schnell zu
hervorragenden Ergebnissen zu kommen.
Und das ein Einsteiger die dafür nötige Zeit noch in die Vertiefung des
ASM -Wissens reinsteckt halte selbst ich, als wehemennter "auch ASM"
Befürworter, für absolut verschwendete Zeit.
Aber ein paar Stunden in grundlegendste Übungen zu stecken wird bei
nicht wenigen sicherlich das ein oder ander "Licht" beim Arbeiten mit
höheren Sprachen deutlich schneller aufgehen lassen.
Peter Dannegger schrieb:> Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich> besser implementieren lassen.
Sehe ich auch so. C++ hat seine Berechtigung und ohne C++ (oder
allgemeiner gesagt: Objektorientierten Sprachen) wäre das Leben in
vielen Bereichen der Softwareentwicklung deutlich schwieriger.
Aber gerade in den einfacheren Anwendungen realisiert man mit dem µC
doch nur eine mehr oder weniger "gedopte" FSM. Und da ist man mit C
meist deutlich schneller und Übersichtlicher.
Und wenn hier Statements wie "Unübersichtlichen Spaghetticode" im Bezug
auf C Quelltext lesse, dann kann ich mir das einfach nur so erklären das
derjenige einfach niemals gelernt hat vernünftig Strukturiert in C zu
programmieren und so seine eigenen, sehr begrenzten Fähigkeiten als
Vergleichsmaßstab für die Aussage "C++ ist auch auf µC immer die bessere
Wahl" nimmt. Für "ihn Persöhnlich" wird das in einem solchen Fall sogar
absolut zutreffen, aber lange nicht für die Mehrheit!
Allerdings muss man mittlerweile auch immer im Hinterkopf haben das die
Schreiber hier beim Terminus "µC Programmierung" ganz andere
Vorstellungen im Kopf haben könnten. Während ich (und vermutlich wohl
auch PeDa)auch wenn wir selbst schon sehr komplexe Projekte realisiert
haben trotzdem erst einmal unwillkürlich an eher einfache Schaltungen
denken die man auch noch bequem in einen mittleren 8Bitter unterbringen
könnte - so haben andere vielleicht eher einen
"Quasi-Einplatinencomputer" wie den RasperryPi im Sinn. Und genauso
verhält es sich dann auch mit dem Begriff "einfache Anwendung".
Gruß
Carsten
>Der Code wird in C geschrieben, der C Code wird zu ASM>Compiliert und das ASM Listing wird dann erst zu einem Bytestrom>umgesetzt der in den µC geschrieben wird.
das ist jetzt schon der 2. der das schreibt, aber das stimmt doch nicht
(oder ist unglücklich formuliert)
ich kenn keinen compiler der als zwischenschrit ASM (als lesbaren text)
erstellen würde..
edit: ok, der GCC macht das scheinbar tatsächlich so ähnnlich (aber
nicht asm sonder RTL?), sachen gibts...
ist aber wohl eher die ausnahme..
Wilhelm F. schrieb:> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt> Maschinencodierung: Damit half ich einigen Kommilitonen durch die> Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet,> und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem> Studium raus geflogen. Klausuraufgaben wollten das wissen.
Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal
vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und
andere Menschen bezichtigt bei Prüfungen betrogen zu haben?
Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen
Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine
Ehrlichkeit bekommst Du ein Sternchen von mir.
Klaus I. schrieb:> Wilhelm F. schrieb:>> Ich>> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet,>> und zwar Maschinencode.>> Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal> vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und> andere Menschen bezichtigt bei Prüfungen betrogen zu haben?
Wenn Übungen vor einer Prüfung Betrug sind, habe ich bei den meisten
Prüfungen betrogen...
Klaus I. schrieb:2
> Wilhelm F. schrieb:>> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt>> Maschinencodierung: Damit half ich einigen Kommilitonen durch die>> Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich>> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet,>> und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem>> Studium raus geflogen. Klausuraufgaben wollten das wissen.>> Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal> vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und> andere Menschen bezichtigt bei Prüfungen betrogen zu haben?>> Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen> Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine> Ehrlichkeit bekommst Du ein Sternchen von mir.
Ich bin ein hilfsbereiter Mensch oft auch ohne Gegenleistung, und habe
es bestimmt 10 Studenten verholfen, nicht dreimal durch Mikroprozessor
durch zu fallen, und das Studium zu werfen.
Was gibt es daran auszusetzen?
Peter Dannegger schrieb:> Ich würde mal vermuten, das ist nach 1995 entstanden. Ich kenne keinen> Compiler, der in die Zukunft schauen kann.
Wir haben aber 2014 (bald kommt C++14 raus!), und es geht darum was man
jetzt verwenden kann/soll/darf.
> Ich glaub auch nicht, daß sich Steuerungsaufgaben in C++11 erheblich> besser implementieren lassen.
Durchaus. So eine schöne CANopen-Implementierung zur Ansteuerung
diverser Aktoren & Sensoren kann davon eine Menge profitieren. Und
schöne Hardware-API's könnte man damit auch machen...
Wilhelm F. schrieb:> Was gibt es daran auszusetzen?
Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht
mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu
bestehen.
;-) schrieb:> Wilhelm F. schrieb:>> Was gibt es daran auszusetzen?> Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht> mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu> bestehen.
Oh, da ist jemand übel angegriffen. ;-)
Wilhelm F. schrieb:> ;-) schrieb:>> Wilhelm F. schrieb:> Was gibt es daran auszusetzen?>> Übungen bzw. Nachhilfe vor der Prüfung ist eindeutig Betrug. Wer nicht> mit dem Wissen geboren wurde hat es nicht verdient die Prüfung zu> bestehen.>> Oh, da ist jemand übel angegriffen. ;-)
Das war natürlich nicht ernst gemeint..
Dr. Sommer schrieb:> Und> schöne Hardware-API's könnte man damit auch machen...
Ach du wieder..
Du wolltest doch erstmal beginnen, die Lernbetty zu verstehen, gelle?
Und jetzt redest du von "So eine schöne CANopen-Implementierung.." und
Konsorten.. Mach erstmal was Einfaches vor dem Höhenflug und zeig uns
deine grandiosen Ergebnisse ;-)
So, die Flasche Riesling von der Mosel ist fast alle, GUT NACHT
ZUSAMMEN!
W.S.
W.S. schrieb:> Dr. Sommer schrieb:>> Und>> schöne Hardware-API's könnte man damit auch machen...>> Ach du wieder..> Du wolltest doch erstmal beginnen, die Lernbetty zu verstehen, gelle?
Du wolltest doch mal ein Projekt mit gutem Code schreiben, oder?
> Und jetzt redest du von "So eine schöne CANopen-Implementierung.." und> Konsorten.. Mach erstmal was Einfaches vor dem Höhenflug und zeig uns> deine grandiosen Ergebnisse ;-)
Nö, das wäre Perlen vor die Säue. oder Trolle. CANopen läuft, und nein
es ist kein Quick & Dirty mit fix hingerotzter FSM. Ich weiß ja
immerhin wie sowas ordentlich geht. Mal schauen für wie viel ich das
dann verkaufe.
> So, die Flasche Riesling von der Mosel ist fast alle, GUT NACHT> ZUSAMMEN!
Musst du was kompensieren oder vergessen? Alkoholiker...
Wilhelm F. schrieb:> Klaus I. schrieb:2
>>> Wilhelm F. schrieb:>>> Übrigens, was ich ein paar Beiträge vorhin nannte, Hardcore direkt>>> Maschinencodierung: Damit half ich einigen Kommilitonen durch die>>> Mikroprozessor-Klausur, und genau deswegen, weil ich das konnte. Ich>>> übte mit denen, wie man bei Schleifen Sprungadressen richtig rechnet,>>> und zwar Maschinencode. Ganz im Ernst, die wären sonst deswegen aus dem>>> Studium raus geflogen. Klausuraufgaben wollten das wissen.>>>> Sorry, aber sogar das Bedürfnis zur Selbstdarstellung sollte doch mal>> vernünftige Grenzen haben. Du hast doch jetzt nicht ernsthaft Dich und>> andere Menschen bezichtigt bei Prüfungen betrogen zu haben?>>>> Wie behämmert muß man eigentlich sein um soetwas in einem öffentlichen>> Board zuzugeben. Bist Du jetzt die Wulff-Kanaille No 2? Naja für Deine>> Ehrlichkeit bekommst Du ein Sternchen von mir.>> Ich bin ein hilfsbereiter Mensch oft auch ohne Gegenleistung, und habe> es bestimmt 10 Studenten verholfen, nicht dreimal durch Mikroprozessor> durch zu fallen, und das Studium zu werfen.>> Was gibt es daran auszusetzen?
Wenn Du nur mit Ihnen allgmeine Aufgabenstellungen geübt hast und du
nichts spezielles von den Prüfungsaufgaben gewusst hast, habe ich Dir in
der Tat etwas falsches unterstellt. Sorry.
Das ist bei mir falsch angekommen.
Hi,
mathe schrieb:> Programmieren lernt man am besten, wenn man eine relevante Sprache> nutzt.>> Am besten fängst Du mit Javascript an und lernst jquery zu nutzen. Zur> Not können es auch Python oder Ruby sein.>> Wenn Du die beherrscht, kannst Du Dich an die elitären Sprachen wie Go> und Haskell wagen.>> C und ASM soll Opi weiter programmieren. Das benötigt man nur für> Treiber.
Hahahahahaha,
danach habe ich nicht mehr weiter gelesen,
das reicht als Lachflash für die Nacht.... :-))))
Eventuell steigt der Herr Mathe Prof ja mal in die Industrie oder
in Firmen ein, die Ahnung haben.
Glaube ich zwar nicht, aber ....
Just my 2 Cents :-)))
Gruss Fabi.
Jean Player schrieb:> Eventuell steigt der Herr Mathe Prof ja mal in die Industrie oder> in Firmen ein, die Ahnung haben.
Dann muss er sein alt-gelerntes C leider einpacken und das nehmen was in
der Industrie tatsächlich verwendet wird - Java, ruby, C#...
Ich denke, gerade in „Embedded” Bereich ist eine solide Kenntnis eines
µC und der Implementationen der Peripherie von großer Bedeutung, wie
auch ein solides Verständnis über die Peripherie-Funktion. Gerade das
unterscheidet ja „Embedded” Programmierung von sonstigen
Programmieranwendungen. Diese Frage, sollte eigentlich klar sein, ist
aber nicht Bestandteil des eigentlichen Themas dieses Thread. Das Thema
ist C oder ASM, genauer, Hochsprache vs ASM. Viele der letztens
veröffentlichten Beiträge haben ja mit dem Thema nichts mehr zu tun oder
erzeugen Dissenz und „Diskussionsbedarf” aus der Durchmischung des
Themas damit ob Kenntnis und Verständnis der Hardware und seiner
Funktion und die Wahl der Programmiersprache. Wenn das hier nicht zu
einer Nabelschau ausarten soll, dann sollte man über den Tellerrand
sehen. Viel interessanter ist die Frage der Bedeutung zur Wahl der
Entwicklungswerkzeuge wie sie in US Foren geführt wird und die mit dem
Thema dieses Threads verwandter ist, so meine Meinung, als die hier
geführte Egoshow!
Dr. Sommer schrieb:> Dann muss er sein alt-gelerntes C leider einpacken und das nehmen was in> der Industrie tatsächlich verwendet wird - Java, ruby, C#...
Ja, das sind die Zugpferde im Embedded-Bereich... :D
spess53 schrieb:> Threadtitel vergessen: µC von 0 auf lernen. ASM oder C?
In Internetforen ist es leider hin und wieder so, dass die Diskussion
nicht mehr 100% zum Thread-Titel passt. Wenn die Rede von Mathematikern
ist besteht eine gewisse Wahrscheinlichkeit, dass es nicht um Embedded
ging.
Dr. Sommer schrieb:> Wenn die Rede von Mathematikern> ist besteht eine gewisse Wahrscheinlichkeit, dass es nicht um Embedded> ging.
Du brauchst dich nicht zu grämen. Sexualität ist eines der wichtigsten
Themen überhaupt. Also von der Wahrscheinlichket her sicherlich weit
bedeutender als Ruby oder C#. Kopf hoch, du machst da einen tollen Job!
Hi
Dr. Sommer schrieb:> spess53 schrieb:>> Threadtitel vergessen: µC von 0 auf lernen. ASM oder C?> In Internetforen ist es leider hin und wieder so, dass die Diskussion> nicht mehr 100% zum Thread-Titel passt.
Das ist zwar richtig, aber gerade hier in diesem Thread ist die
Diskussion noch sehr stark ON TOPIC.
Alles andere macht ja auch überhaupt keinen Sinn, wenn man diesen Thread
über die µC Sparte hinaus ausdehnen würde könnte man die ganze
Diskussion gleich löschen, ausserhalb der µC Welt gelten völlig andere
Randbedingungen.
Dann kommen wir von einer Frage die sich nach einem Rundblick in die
gelebte Wirklichkeit der Entwicklungsabteilungen und nach den
Erfahrungen der alten Hasen in diesem Bereich auch noch sehr genau
beantworten lässt zu einer reinen Diskusion "Welche Programmiersprache
ist überhaupt die Beste" ohne Rücksicht auf den Einsatzzweck.
Es ist halt einfach so das die Frage nach der sinnvollsten
Programmiersprache sich einfach am gewünschten Einsatzzweck orientiert.
Als Beispiel schon meine mal weiter oben gemachte Aussage:
Für die Plattform µC:
Gute C Fähigkeiten sind auf dem µC für alles was über ein wenig
Hobbycoden hinausgeht heute das absolute "Must Have".
ASM Fähigkeiten sind auf dem µC nicht zwingend Erforderlich, helfen aber
extrem beim Verständniss der Besonderheiten der Plattform und
ermöglichen es so auch viel schneller zum nötigen Wissenstand zu kommen
um effektiven C code für den µC schreiben zu können. Von der
Unterstützung beim Debuggen mal ganz zu schweigen. Zumindest als
beruflich mit dem Thema besfasster sollte man also mindestens einen oder
zwei ASM Dialekte mal kennengelernt haben, als Hobbyist ist es ein "Nice
to Have" das aber den Einstieg in µC für viele erleichtert.
Die Fähigkeit umfangreiche und komplexe ASM Programme selbst entwerfen
zu können wird aber nur noch bei wenigen Firmen benötigt, ist also auch
für berufliche Belange immer irrelevanter. Maximal die Pflege von
Altcode spielt noch eine überhaupt nennenswerte Rolle.
C++ Fähigkeiten auf dem µC sind heute ein "Nice to Have" aber wirklich
Erforderlich sind diese im Moment nur in wenigen Bereichen. Allerdings
gibt es auch in relevanten Anwendungen mittlerweile erste überwiegend in
C++ geschriebene Projekte. In der Zukunft wird es sicher noch im bereich
der komplexen Anwendungen dem reinen C mehr Marktanteile abnehmen. Es
ist also sicher empfehlenswert sich auch mit C++ zu beschäftigen.
Aber: Für (berufliche) µC Entwickler ohne C++ Kentnisse gibt es heute
noch massig Stellen, aber µC Entwickler die nur mit C++ aber nicht
vernüftig mit nativen C umgehen können werden nur sehr wenige bis
überhaupt niemand einstellen.
Andere Programmiersprachen, egal ob Basic oder JAVA spielen auf dem µC
ausserhalb der Hobbywelt oder von "Proof of Conzept" Projekten derzeit
keinerlei Rolle!
Auf dem PC gelten aber ganz andere Vorraussetzungen:
(wobei auch hier nochmals unterteilt werden könnte)
Natives C spielt nur noch für die HArdwarenahe Programmmierung, also bei
Dingen wie Treiberprogrammierung oder bei Betriebssystemen eine
nennenswerte Rolle.
Die ASM Programmierung auf dem PC ist nur noch für absolute Spezialfälle
relevant. Wer nicht gerade ein BIOS schreiben muss wird damit heute kaum
noch in Kontakt kommen. Sicher der Großteil der heutigen PC
Anwendungsentwickler wird kaum noch überhaupt einen Berührungspunkte zu
ASM haben.
Die ganzen Anwendungsprogramme werden heute Sinnvollerweise
Objektorientiert geschrieben, C++ ist ein Muss, C# und besonders JAVA
werden immer wichtiger. In einigen Fällen kann man z.B. JAVA sicher
schon mit zu den nötigen Einstiegsvorraussetzungen zählen.
JAVASCRIPT ISt für Webentwickler heute sicher eine Vorraussetzung, aber
auch ausserhalb des Webbereiches schadet es sicher nicht zumindest die
Grundzüge zu kennen.
Natürlich gibt es dann noch weitere Spezialbereiche die weitere
Spezialkenntnisse erfordern.
Man sieht, es gelten für die verschiedenen Plattformen also völlig
verschiedene Vorraussetzungen. Einen an der PC
(Anwendungs-)Programmierung interessierten der auch auf der PC Plattform
bleiben will kann man ohne Skrupel auch den Einstieg direkt in
Objektorientierte Programmierung empfehlen.
(Wobei ICH C vom Verständniss, also für den Erstkontakt, für leichter
halte - das ist aber wohl Individuell verschieden und damit
Geschmackssache)
Wer aber einem µC Interessierten denselben Rat gibt, der katapultiert
den damit -zumindest derzeit- direkt ins Abseits!
DAHER: Diese ganzen "Programmiersprachenbetrachtungen" machen nur im
direkten Bezug zur Plattform Sinn. Universell Sinnvolle Antworten gibt
es nicht, weshalb gar nichts anderes übrig bleibt als bei solchen Themen
-OnTopic- zu bleiben.
Gruß
Carsten
Carsten Sch. schrieb:> aber µC Entwickler die nur mit C++ aber nicht> vernüftig mit nativen C umgehen können werden nur sehr wenige bis> überhaupt niemand einstellen.
Gut dass es so etwas nicht gibt, jeder der C++ kann kann natürlich mit
Leichtigkeit die Untermenge von C++ verwenden, die C ist. Und wird
kotzen weil das in C alles so umständlich ist.
Carsten Sch. schrieb:> Natives C spielt nur noch für die HArdwarenahe Programmmierung, also bei> Dingen wie Treiberprogrammierung oder bei Betriebssystemen eine> nennenswerte Rolle.
Wenns mal so wäre :/ ... Vermutlich sind 98% der "normalen"
Linux-Software die man so auf seinem 08/15-Ubuntu hat in C geschrieben;
weil die Leute keine Lust haben C++ zu lernen vermute ich.
Carsten Sch. schrieb:> Die ganzen Anwendungsprogramme werden heute Sinnvollerweise> Objektorientiert geschrieben, C++ ist ein Muss, C# und besonders JAVA> werden immer wichtiger. In einigen Fällen kann man z.B. JAVA sicher
Ja, 1995 war das so. Heutzutage braucht kaum ein "normaler"
Anwendungsprogrammierer C++, und Java oder C# sind vermutlich fast immer
die Einstellungsvorraussetzung. Kaum einer der normalen
Anwendungsprogrammierer oder Informatiker kann heute noch C++, es wird
extrem viel in Java oder C# gemacht.
Carsten Sch. schrieb:> Einen an der PC> (Anwendungs-)Programmierung interessierten der auch auf der PC Plattform> bleiben will kann man ohne Skrupel auch den Einstieg direkt in> Objektorientierte Programmierung empfehlen.
Es ist dringend Java oder C# (-> OOP) zu empfehlen, aus o.g. Gründen.
Und da natürlich extrem viel OOP programmiert wird außerhalb von
Embedded wäre es auch schlau, das zu beherrschen.
> (Wobei ICH C vom Verständniss, also für den Erstkontakt, für leichter> halte - das ist aber wohl Individuell verschieden und damit> Geschmackssache)
Da bin ich gegen... Wenn schon dann C++, aber Java, C#, ruby, Python...
sind für den Einstieg doch wesentlich besser geeignet, da einfacher zu
verstehen, weniger Fallstricke und kürzere Wege zu größeren
Erfolgserlebnissen...
Hi,
Dr. Sommer schrieb:> Carsten Sch. schrieb:>> aber µC Entwickler die nur mit C++ aber nicht>> vernüftig mit nativen C umgehen können werden nur sehr wenige bis>> überhaupt niemand einstellen.> Gut dass es so etwas nicht gibt, jeder der C++ kann kann natürlich mit> Leichtigkeit die Untermenge von C++ verwenden, die C ist. Und wird> kotzen weil das in C alles so umständlich ist.
Das würde ich etwas differenzierter sehen, deshalb schrieb ich ja auch:
"Vernünftig mit nativen C UMGEHEN"
Es gehört halt schon ein wenig mehr dazu als nur den Syntax zu kennen
bis man ein guter SW-Entwickler ist. Und jemand der gut in C++ kann zwar
sicher Programme schreiben die per definition als C Programme durchgehen
könnten, genauso wie praktisch jeder der C Beherrscht auch nach kurzer
Recherche ein formales C++ schreiben könnte ABER das heisst noch lange
nicht das dies gut strukturierte und vor allem effektive Programme sind.
(Natürlich gibt es Leute die BEIDE Sprachen gut bis sehr gut können,
aber die haben halt einfach Erfahrung mit beiden Sprachen)
Da kommt halt der Unterschied zwischen Strukturierter und
Objekorientierter Programmierung zum Tragen. Das sind zwei verschiedene
Philosophien.
Zum Rest deines Beitrages möchte ich dir nicht wiedersprechen. An der
Welt der PC Anwendungsentwicklung bist du vermutlich näher dran als ich.
Wenn, dann schreibe ich vielleicht maximal eine Minianwendung zur
Parametrierung von externen Schaltungen an denen ich mitgewirkt habe.
Oder auch mal eine kleine Testapplikation. (Beides Üblicherweise dann in
C++/.Net, soll halt einfach sein ohne weitere besondere Anforderungen)
Aber alles was darüber hinaus geht, das dürfen andere machen die da weit
Fitter am PC sind als ich.
Da muss ich mir dann selbst sagen: "Schuster bleib bei deinen Leisten"
Mit der spezifischen PC Programmierung habe ich bestimmt vor ca. 10
Jahren aufgehört mich da weiter mit zu befassen. (Nachdem ich aber
bereits 10 Jahre Erfahrung darin hatte) Seit dem habe ich nur mal ein
paar Tage in ein .Net Buch geschaut aber sonst...
Gruß
Carsten
Carsten Sch. schrieb:> ABER das heisst noch lange> nicht das dies gut strukturierte und vor allem effektive Programme sind.
Ein C++ Programmierer der sich mit den diversen
Strukturierungsmöglichkeiten von C++ wie OOP auskennt, wird sich
vermutlich überlegen wie er das in C genauso strukturieren kann; mit
structs statt Klassen, manueller Funktionspointerei statt virtual etc.
Das könnte dann durchaus in besser strukturierten C Programmen
resultieren als die typischen Frickel-C-Programme...
Ein effektives d.h. funktionsfähiges Programm in C zu schreiben sollte
wirklich zu schaffen sein. Allerdings ist diese Diskussion wirklich
müßig, denn warum sollte man schon von C++ auf C wechseln :-D
Thread beobachten
Seitenaufteilung abschalten
