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