Guten Abend, Ich suche zum Experimentieren ein gutes Mikrocontroller Board und bin auf folgendes Angebot gestoßen: http://www.reichelt.de/?ARTICLE=125561&PROVID=2257&wt_mc=amc136152448016369&ref=adwords_pla&&gclid=CNvlnYvgxrkCFebJtAod0EkA5A Was meint ihr dazu? Ist es kompatibel mit den gängigsten Mikrocontrollern bzw. welche darf ich daran anschließen? Ich habe mir dazu das Datenblatt angesehen und ehrlich gesagt, kann ich nicht viel relevantes daran ablesen^^ Das was ich an Vorkenntnissen mitbringe ist auch nur ein wenig Assemblerprogrammierung eines Atmel mikrocontrollers. LG David
Hallo David, das ist so ein typisches Anfänger-Board. Da ist erstmal alles drauf, was man so etwa braucht. Was kannst du daran anschließen? Naja, theoretisch kannst du da jeden anderen Mikrocontroller auf dieser Welt anschließen, solange du bestimmst, welche Sprache zum Kommunizieren benutzt wird.
Da ist ein Atmel Mikrocontroller fest integriert ;) Das Board ist nicht viel anderes als der reine µC + Spannungsversorgung + Programmierinterface. Man kann die Dinger auch mit Assembler programmieren aber besser ist es, sie - wie vorgesehen - in C zu programmieren. Arduino-Klone gibts übrigens für unter 10€ schon bei eBay. Für den Anfang ist ein "originaler" vielleicht aber etwas sicherer. Hast du denn schon anderes Equipment zum Basteln?
Vielen Dank für die schnelle Antwort, also an Equipment habe ich ein Multimeter und ein paar Kondensatoren und Widerstände. Sensoren habe ich auch ein paar, aus kaputer Elektronik.
David schrieb: > also an Equipment habe ich ein Multimeter und ein paar Kondensatoren und > Widerstände. Sensoren habe ich auch ein paar, aus kaputer Elektronik. Also was du brauchen wirst, ist ein Bread Board und ein paar Verbindungskabel. Dann kannst du mit dem Board eigentlich schon loslegen. Was soll bei dir das Ziel sein? Was möchtest du denn programmieren?
:
Bearbeitet durch Admin
Ich will erst mal nur etwas ausprobieren, später aber, wenn ich mehr Ahnung hab und Idee dann z.b eine geeignete Motorsteuerung bauen...Womit ich gerne anfangen würde, wäre Spannungsmessung mit den Controller und am PC auf Graphen anzeigen lassen usw.
David schrieb: > Womit > ich gerne anfangen würde, wäre Spannungsmessung mit den Controller und > am PC auf Graphen anzeigen lassen usw. Was für Spannungen möchtest du denn messen? Auf dem Board ist da eigentlich alles drauf, was du brauchst. Und mal vorab gefragt, dürfen wir Spoilern oder möchtest du deine Erfahrungen selbst sammeln?
:
Bearbeitet durch Admin
Ja klar könnt ihr Spoilern- Ich hab zwar ein Multimeter, aber der kann die Spannungen halt nicht als Graph darstellen. Beispielweise würde ich die Spannung an einen Lichtsensor messen, oder den Strom durch einen Motor bei Last
Angehängte Dateien:
-
Foto.JPG
150 KB
Ich bin damit recht zufrieden: Arduino Pro Mini für ca. 10,00 EUR FTDI RS232 Board für ca. 12,00 EUR Auf den Arduino habe ich eine 5 pol. Sockelleiste für die Programmierung gelötet. Programme schreibe ich in C/C++ mit AVR Studio 4.
Also Spannungen zu messen ist mit dem Mikrocontroller kein Problem, allerdings darf die Spannung nicht höher sein, als die Betriebsspannung des Mikrocontrollers. Entsprechend müsste man elektronisch nachhelfen. Ströme lassen sich aber nicht so einfach messen. Entweder verwendet man einen Shunt oder INA138, wobei ich den INA138 bevorzugen würde. Wäre auch eine kleine Herausforderung statt einfach das ohmsche Gesetzt auszunutzen. Ich würde dir aber für den Anfang ein anderes Board empfehlen. Und zwar das hier: http://arduino.cc/en/Main/arduinoBoardUno Es hat einen großen Vorteil: Der Mikrocontroller ist auf dem Board einfach nur aufgesteckt. Damit könntest du den Mikrocontroller z.B. vom Board ziehen und auf ein Bread Board mit etwas Elektronik draufstecken. Sollte der Chip bei dir kaputtgehen, könntest du ihn problemlos ersetzen.
Hi Werner P. schrieb: > Ich bin damit recht zufrieden: Wenn du lieber etwas fertig gebautes willst, dann kannst du auch http://www.ebay.de/itm/171042081397?ru=http%3A%2F%2Fwww.ebay.de%2Fsch%2Fi.html%3F_sacat%3D0%26_nkw%3D171042081397%26_rdc%3D1 nehmen. Da machst du dir einen USB-Bootloader drauf (z.B. USBaspLoader - https://github.com/baerwolf/USBaspLoader) und hast ein schoenes, preiswertes Spielzeug g. Siehe Beitrag "ATMEGA32 Minimum System Board" MfG Stephan
OK vielen dank für die zahlreiche Tips. Gleich gehts ans Bestellen ^^ Eine Frage hab ich aber noch und zwar ob ich treiber und software für jeden mikrocontroller leicht kriege bzw. obs kostenlos ist?
David schrieb: > ob ich treiber und software für > jeden mikrocontroller leicht kriege bzw. obs kostenlos ist? Bei Atmel AVR eigentlich kein Problem.
:
Bearbeitet durch Admin
David schrieb: > Eine Frage hab ich aber noch und zwar ob ich treiber und software für > jeden mikrocontroller leicht kriege bzw. obs kostenlos ist? Nicht für jeden. Aber für einige. Ich möchte jetzt kein neues Riesen-Thema aufmachen, aber das von dir z.B. ausgesuchte Board bzw. der Mikrocontroller hat einen USB / Arduino Bootloader, damit kannst du das Ding per USB programmieren. Sonst musst du den Mikrocontroller mit einem Programmer programmieren. Bei AVR kostet das Ding zwischen 40-800€. Bei anderen Mikrocontrollern kann es auch gerne mal in die tausende gehen.
:
Bearbeitet durch Admin
Angehängte Dateien:
-
Atmega32U4_Breakout-Board.jpg
170 KB -
04-vswr_meter-bargraph.jpg
60 KB
Hallo, nur zur Vollständigkeit kann dieses Board auch in ein Breadboard atMega32u4 gesteckt werden. Oder auch direkt eine LCD oder OLED Anzeige installiert werden. http://www.ehajo.de/themes/kategorie/detail.php?artikelid=152 http://www.ehajo.de/themes/kategorie/detail.php?artikelid=116 Anbei ein Bild von meinem Aufbau, bzw. mit Expansionssteckern und ein Bild von meinem SWR Meter für kleine Leistung (QRP). Man sieht die Ausgangsleistung zur Antenne und ein Bargraph skaliert bis max. 10 Watt und das gemessene VSWR incl. Bargraph von bis 3 mit Unterteilungen bei VSWR: 1,0; 1,1; 1,2; 1,5; 1,75 und 2,0 . Nachtrag seit kurzen ist auch eine TUT bei LunaAVR online. http://avr.myluna.de/doku.php?id=de:tutorials
Paul Hamacher schrieb: > Das Board ist nicht viel anderes als der reine µC + Spannungsversorgung... > Man kann die Dinger auch mit Assembler programmieren aber besser ist es, > sie - wie vorgesehen - in C zu programmieren. Ich weiß, die Diskussion ist müßig und wahrscheinlich OT, aber erlaube mir bitte zwei fragen: 1.) Warum ist es besser, einen Mikrocontroller in C zu programmieren? "Besser" bedeutet ja "nicht so schlecht als", ich verstehe jedoch nicht warum C besser als BASCOM, Assembler, Hex-code oder $_you_name_it seibn soll. 2.) Inwiefern ist es vorgesehen, einen Controller in C zu programmieren, wo doch eine Digitalschaltung sowiso nur Binärdaten versteht, also schon der Assembler eine nicht zu unterschätzende Abstraktionsebene zwischen Mensch und Maschine darstellt? Von wem ist die Programmierung in C vorgesehen und bedeutet das, daß der Mikrocontroller eben nicht dafür vorgesehen ist, mit Assembler, BASCOM oder HEX-Code programmiert zu werden? Wird er gar kaputt, wenn ich eine "nichtvorgesehene" Programmiersprache zu nutzen gedenke oder funktioniert er bei Programmierung mit Assembler nur schlechter bzw. langsamer? Im Datenblatt steht jedenfalls nichts davon, daß er mit C besser läuft. Und bitte keinen Falmewar ASM vs. C vs. $_foo vom Zaun brechen! David schrieb: > Eine Frage hab ich aber noch und zwar ob ich treiber und software für > jeden mikrocontroller leicht kriege bzw. obs kostenlos ist? Einen Mikrocontroller steckt man nicht in den PC, daher braucht man auch keine Treiber dafür.
:
Bearbeitet durch Admin
Die Idee mit dem Arduino Uno und wechselbarem uC ist gut. Schau mal bei ladyada.net, dort gibt es auch verschiedene Tutorials. Der dort vorgeschlagene Boarduino ist vergleichbar mit dem Uno und trotzdem sehr kompakt. Ich mach mal Werbung: siehe Watterott. Oder halt China-Mann.
Norbert M. schrieb: > 1.) Warum ist es besser, einen Mikrocontroller in C zu programmieren? 1) Weil du in C für eine Aufgabe ein paar Zeilen Text brauchst und bei Assembler in der Regel wesentlich mehr. 2) Weil du in C die Optimierungsmechanismen des C Compilers nutzen kannst, sonst musst du selbst alles optimieren. 3) Weil es imho absolut keinen Spaß macht, ASM zu debuggen. Norbert M. schrieb: > Wird er gar kaputt, wenn ich eine "nichtvorgesehene" > Programmiersprache zu nutzen gedenke oder funktioniert > er bei Programmierung mit Assembler nur schlechter bzw. langsamer? Ob du jetzt Asm, C oder den Hexeditor verwendest... es ist egal... Der Controller wird das ausführen, was programmiert wurde. Und je nach Compiler kann da auch mal ein Overhead vorhanden sein und der Mikrocontroller somit nicht mit vollspeed laufen. Hier mal ein Video des EEV Blogs, in dem der Overhead gezeigt wird. http://www.youtube.com/watch?v=DBftApUQ8QI Ich habe nur kurz reingeschaut, ich hoffe, dass ich das richtige Video verlinkt habe.
Norbert M. schrieb: > 1.) Warum ist es besser, einen Mikrocontroller in C zu programmieren? Es geht schneller.
1 | if (a < 7 && b >= 23 && (foo (z) || bar (y)) { |
ist viel schneller geschrieben als der entsprechende Assembler -oder gar Maschinencode. Außerdem ist C sehr weit verbreitet, es können sehr viele, es läuft fast überall, daher tut man gut daran das zu verwenden. Norbert M. schrieb: > also schon der Assembler eine nicht zu unterschätzende Abstraktionsebene > zwischen Mensch und Maschine darstellt? Tut er überhaupt nicht, der macht praktisch nur eine dumme Textersetzung. Norbert M. schrieb: > Von wem ist die Programmierung in C vorgesehen Von Leuten, die C aus o.g. Gründen gut finden und sogar CPU's extra so bauen, dass sie C/C++ effizient ausführen können, zB x86 oder ARM (AVR eher nicht so). > und bedeutet das, daß der Mikrocontroller eben nicht dafür vorgesehen ist, > mit Assembler, ARM zB ist kaum für manuelle Assembler-Programmierung vorgesehen, er ist explizit für C/C++ gedacht. Norbert M. schrieb: > Wird er gar kaputt, wenn ich eine "nichtvorgesehene" > Programmiersprache zu nutzen Nein, du wirst eine nicht unterstützte Programmiersprache gar nicht erst compiliert kriegen... Eine sub-optimale aber funktionierende Sprache wird auf einem Controller höchstens langsamer laufen. Norbert M. schrieb: > Im Datenblatt steht jedenfalls nichts davon, daß er mit C besser läuft. Da jeder weiß, dass C viel schneller&einfache zu programmieren ist als Assembler... Da aber dort meistens die Mnemonics der Assembler-Instruktionen drinstehen, ist offenbar die Programmierung in Maschinencode ("Hex") gar nicht wirklich vorhergesehen, sondern wenn schon Assembler. Norbert M. schrieb: > Einen Mikrocontroller steckt man nicht in den PC, daher braucht man auch > keine Treiber dafür. Ach nicht, auch nicht die im Computer selbst (für zB ACPI) Mäusen, Tastaturen, und Millionen anderer Zusatzgadgets?
Dimitri Roschkowski schrieb: > Hier mal ein Video des EEV Blogs, in dem der Overhead gezeigt wird. > Youtube-Video "EEVblog #63 - Microchip PIC vs Atmel AVR" Ist anscheinend doch das falsche Video. Das richtige finde ich gerade nicht. Ich weiß nur, dass es im Video irgendwie um AVR und Microchip Mikrocontroller ging, und zwar darum, den Digitalausgang schnellstmöglich zu schalten.
Kindergärtner schrieb: > Norbert M. schrieb: >> 1.) Warum ist es besser, einen Mikrocontroller in C zu programmieren? > Es geht schneller. >
1 | if (a < 7 && b >= 23 && (foo (z) || bar (y)) { |
> ist viel schneller geschrieben als der entsprechende Assembler -oder gar > Maschinencode. Ich bin mir sicher, daß sich das nicht viel schenkt, falls man einen guten Assemblerprogrammierer gegen einen guten C-Programmierer antreten lässt. > Außerdem ist C sehr weit verbreitet, es können sehr viele, es läuft fast > überall, daher tut man gut daran das zu verwenden. Ich sehe da gar kein Argument. Im Controllerbereich ist Assmbler ebenfalls "weit verbreitet" und es gibt ebenfalls "viele Leute, die das können". Und das Argument, das es "fast überall läuft" ist ebenfalls nichtig, denn der Code ist auch in C plattformspezifisch (oder schon mal erfolgreich versucht, eine ncurses-Anwendung von Linux auf einen uC mit LCD zu portieren), daß man mit Wechsel der Architektur das Meiste neu schreiben muß. >> der Assembler eine nicht zu unterschätzende Abstraktionsebene >> zwischen Mensch und Maschine darstellt? > Tut er überhaupt nicht, der macht praktisch nur eine dumme > Textersetzung. Komisch, daß der Assembler immer den richtigen Opcode generiert, unabhängig vom verwndeten Addressierungsmodus, die da zum Beispiel wären absolut, indirekt, relativ, ... Wenns nur eine einfache Textersetzung wäre, dann bräuchte man ja nicht nur z.B. MOV, sondern hätte MOV_abs, MOV_ind, MOV_rel,... Macht aber alles der Assembler, ganz automagisch[tm] >> Von wem ist die Programmierung in C vorgesehen > Von Leuten, die C aus o.g. Gründen gut finden und sogar CPU's extra so > bauen, dass sie C/C++ effizient ausführen können, zB x86 oder ARM Und diese CPUs laufen mit Assembler schlechter? >> Wird er gar kaputt, wenn ich eine "nichtvorgesehene" >> Programmiersprache zu nutzen > Nein, du wirst eine nicht unterstützte Programmiersprache gar nicht erst > compiliert kriegen... Pseudoargument, denn wenn es keinen Compiler kann ich ja gar nicht compilieren. > Eine sub-optimale aber funktionierende Sprache > wird auf einem Controller höchstens langsamer laufen. Aha, das "vorgeshene C" läuft also immer am schnellsten. Interessant! > Norbert M. schrieb: >> Im Datenblatt steht jedenfalls nichts davon, daß er mit C besser läuft. > Da jeder weiß, dass C viel schneller&einfache zu programmieren ist als > Assembler... Achso, jeder weiß das. C ist also immer schneller und einfacher zu programmieren, das wusste ich nicht. Kann ja nicht ahnen, daß es da ein Wissen gibt, das zwar jeder kennt, aber nirgends wo nachzulesen ist. Ist also einfach so. > Da aber dort meistens die Mnemonics der Assembler-Instruktionen > drinstehen, ist offenbar die Programmierung in Maschinencode ("Hex") > gar nicht wirklich vorhergesehen, sondern wenn schon Assembler. Weswegen stehen dann - zumindest bei den Controllern, bei denen ich in's Datenblatt reingeguckt habe - neben den Mnemonics des Assemblers auch jeweils die durch den Befehl + Addressierungsart zu codierenden OpCodes drin? Wenn "Maschinencode" doch sowiso nicht vorgesehen ist? Ist das wieder so ein Geheimwissen, das jeder weiß? Ohne Witz jetzt: Ich wehre mich nur gegen die Behauptung, daß C besser und schneller als Assembler ist. Wobei ich nicht behaupten will, daß Assembler oder Hex "besser" als C sind. Ich find's ehrlich gesagt nur etwas ungerecht, was manchmal von der Seite der C-Verfechter gegen Assembler in's Feld geführt wird! > Norbert M. schrieb: >> Einen Mikrocontroller steckt man nicht in den PC, daher braucht man auch >> keine Treiber dafür. > Ach nicht, auch nicht die im Computer selbst (für zB ACPI) Mäusen, > Tastaturen, und Millionen anderer Zusatzgadgets? Wieder ein Versuch, das Wort im Munde umzudrehen, denn zum Erstellen von Programmen für Microcontroller braucht's keinen Treiber, genau darum gings. Anyway, ich klinke mich aus der Diskussion hier aus. Meine Kritik bezog sich wie gesagt auf die Behauptungen, daß C besser als eine andere Programmiersprache sei und daß "Microcontroller dafür vorgesehen wären, mit C programmiert zu werden". Beides ist meiner Meinung nach eine Zumutung und ich bleibe auch weiters bei dieser meiner eigenen Meinung. Dimitri Roschkowski schrieb: > Ob du jetzt Asm, C oder den Hexeditor verwendest... es ist egal... > Der Controller wird das ausführen, was programmiert wurde. Eben, genau meine Meinung.
Jetzt wirds lustig. Norbert M. schrieb: > Ich bin mir sicher, daß sich das nicht viel schenkt, falls man einen > guten Assemblerprogrammierer gegen einen guten C-Programmierer antreten > lässt. Dann zähle mal die Assembler-Programmierer die das können und die C-Programmierer die das können. Der entsprechende C-Code für diese Zeile (und viele ander Zeilen) funktioniert genauso unter jeder Architektur, der Assembler-Code überhaupt nicht. > Ich sehe da gar kein Argument. Im Controllerbereich ist Assmbler > ebenfalls "weit verbreitet" und es gibt ebenfalls "viele Leute, die das > können". Das ist dann aber auch kein Argument für Assembler, "traue keiner Statistik die..." etc. > Und das Argument, das es "fast überall läuft" ist ebenfalls nichtig, > denn > der Code ist auch in C plattformspezifisch (oder schon mal erfolgreich > Anwendung von Linux auf einen uC mit LCD zu portieren), Klar, die obige C-Zeile läuft quasi überall. Gleiches gilt für Algorithmen wie qsort() etc. > daß man mit > Wechsel der Architektur das Meiste neu schreiben muß. Nur das Hardware-Interface. Einen Sortieralgorithmus nicht. > Komisch, daß der Assembler immer den richtigen Opcode generiert, > unabhängig vom verwndeten Addressierungsmodus, die da zum Beispiel wären > absolut, indirekt, relativ, ... Stimmt, der Assembler schaut sich die Syntax der übegebenen Parameter an und generiert daraus den entsprechenden Opcode. Das bedeutet lediglich dass er nicht nur das "mov" einliest sondern auch das "[r4, #4]" o.ä. > Macht aber alles der Assembler, ganz automagisch[tm] Das ist auch gut so... "[r4, #4]" kann zumindest ich mir leichter merken als die entsprechende Binärfolge. > Und diese CPUs laufen mit Assembler schlechter? Natürlich nicht, es ist nur für viele (außer für dich, natürlich) einfacher/intuitiver/Entwicklungszeit-effizienter die entsprechende Logik in C auszudrücken > Pseudoargument, denn wenn es keinen Compiler kann ich ja gar nicht > compilieren. Auf eine Pseudo-Frage, denn wie soll denn bitte eine Programmiersprache an sich einen Controller zerstören können. > Aha, das "vorgeshene C" läuft also immer am schnellsten. Interessant! Es hat eine gewisse Tendenz effizienteren Code als Sprachen mit anderen Speichermodellen zu generieren, ja, da einige typische C-Merkmale wie der Stack, lokale Variablen, direkte/indirekte Offset-Adressierung direkt auf Maschineninstruktionen abgebildet werden können. > Achso, jeder weiß das. C ist also immer schneller und einfacher zu > programmieren, das wusste ich nicht. Wieder was gelernt. Das gilt natürlich nur für den durchschnittlichen Programmierer, für das Matrixbrain für das 20 Zeilen-Assembler genauso übersichtlich sind wie 1 Zeile C mit ein paar Operatoren, kann sich das anders verhalten; aber die ändern die Statistik kaum. > Kann ja nicht ahnen, daß es da ein > Wissen gibt, das zwar jeder kennt, aber nirgends wo nachzulesen ist. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html zB da; (mehr oder weniger) abstrakte Sprachen wie C, java, C++ sind auf Positionen 1-3, Assembler auf ... 27 (as of this writing). Das ist natürlich keine direkte harte Folgerung, aber man kann sich doch überlegen, dass die Hochsprachen vermutlich aufgrund ihrer größeren Intuitivität/Einfachheit ganz oben sind. > Weswegen stehen dann - zumindest bei den Controllern, bei denen ich in's > Datenblatt reingeguckt habe - neben den Mnemonics des Assemblers auch > jeweils die durch den Befehl + Addressierungsart zu codierenden OpCodes > drin? Für die Entwickler von Assemblern und Compilern. Aber interessante Ansicht, du findest ein "24 07" leichter lesbar als ein "mov r4, #7"? Ist vermutlich eine besondere Begabung, die aber nicht viele haben, für die es daher Assembler und Mnemonics gibt. > Ohne Witz jetzt: Ich wehre mich nur gegen die Behauptung, daß C besser > und schneller als Assembler ist. Das bezieht sich natürlich alles auf den allgemeinen Fall des Nicht-Übergenies, welches die perfekte Ausnutzung der Pipelines nicht im Kopf konstruieren kann und daher effizientern Code durch die Nutzung eines optimierenden Compilers bekommt, und außerdem C-Code mit der "natürlichen" mathematischen Notation zugänglicher findet als eine Schlange an Mnemonics/Maschinen-Instruktionen. In dieser Hinsicht ist das ein recht "subjektives"/"menschenbezogenes/nichttechnisches" Argument - aber wer programmiert denn Computer/Controller... > Wobei ich nicht behaupten will, daß > Assembler oder Hex "besser" als C sind. Ich find's ehrlich gesagt nur > etwas ungerecht, was manchmal von der Seite der C-Verfechter gegen > Assembler in's Feld geführt wird! Eigentlich ist ja auch C mies, interessant wirds bei C++. > Wieder ein Versuch, das Wort im Munde umzudrehen, denn zum Erstellen von > Programmen für Microcontroller braucht's keinen Treiber, genau darum > gings. Ach das war gemeint. Ja dann brauchts nur den Treiber für den Programmer. > und daß > "Microcontroller dafür vorgesehen wären, mit C programmiert zu werden". > Beides ist meiner Meinung nach eine Zumutung und ich bleibe auch weiters > bei dieser meiner eigenen Meinung. Wozu hat dann zB der ARM und der x86 diese ganze Stack/Register-relative Offsetadressiererei? Vielleicht weil man so effizient auf lokale Stackvariablen/Funktionsargumente, Array/struct-Elemente zugreifen kann? Andere Prozessoren haben das nicht, was es für C-Compiler schwerer macht, während Assembler-Programmierung da weniger Probleme mit hat.
Kindergärtner schrieb: > Norbert M. schrieb: >> Ich sehe da gar kein Argument. Im Controllerbereich ist Assmbler >> ebenfalls "weit verbreitet" und es gibt ebenfalls "viele Leute, die das >> können". Und das Argument, das es "fast überall läuft" ist ebenfalls >> nichtig, denn der Code ist auch in C plattformspezifisch (oder schon >> mal erfolgreich Anwendung von Linux auf einen uC mit LCD zu portieren), > Klar, die obige C-Zeile läuft quasi überall. Gleiches gilt für > Algorithmen wie qsort() etc. >> daß man mit Wechsel der Architektur das Meiste neu schreiben muß. > Nur das Hardware-Interface. Einen Sortieralgorithmus nicht. Das Argument, daß C plattformunabhängig wäre, wenn man denn nur plattformunabhängigen C-Code hätte ist doch Augenauswischerei. Bei C-Code muß ich doch genau so aufpassen, ob der Quellcode auf die Zielmaschine passt, da hilft mir auch kein generischer C-Code. Was mache ich zum Beispiel, wenn die Zielmaschine den C-Typ Integer gar nicht kennt, weil die Maschine zum Beispiel nur 8 Bit addressieren kann? Dann kann ich mir den Algorithmus in die Haare schmieren. Umgekehrt könnte ich aus der Assmblerperspektive genau so gut argumentieren, daß sich ein generischer Assemblercode für einen Sortieralgorithmus auch maschinenunabhängig schreiben lässt, solange die Zielmaschine vergleichen, lesen, speichern, etc kann. Meinetwegen schreibe ich den Assemblercode dann in Knuth'schem MIX und ein Zwischenlayer macht dann eben aus MOV z.B. ein LD. Ist Assembler deswegen plattformunabhängig? Wohl kaum, genausowenig wie C. >>> der macht praktisch nur eine dumme Textersetzung. >> Komisch, daß der Assembler immer den richtigen Opcode generiert, >> unabhängig vom verwndeten Addressierungsmodus, die da zum Beispiel wären >> absolut, indirekt, relativ, ... > Stimmt, der Assembler schaut sich die Syntax der übegebenen Parameter an > und generiert daraus den entsprechenden Opcode. Das bedeutet lediglich > dass er nicht nur das "mov" einliest sondern auch das "[r4, #4]" Ein guter Assembler weiß sogar, ob "#4" jetzt im nahem oder im fernem Speicher liegt, der macht nämlich aus 'MOV r4,#4' nicht stupide ein 240404, sondern, je nach Kontext kann das ein 240404 sein, oder ein 2404 oder beispielsweise einfach nur 44. Kann einen Unhterschied von 200% Codegrösse ausmachen. Also bitte den Assamble nicht einfach nur als "dummen Textersetzer" darstellen! >> Und diese CPUs laufen mit Assembler schlechter? > Natürlich nicht, es ist nur für viele (außer für dich, natürlich) > einfacher/intuitiver/Entwicklungszeit-effizienter die entsprechende > Logik in C auszudrücken Habe ich irgendwo mit "Intuition" argumentiert? Ich kann mir durchaus Fälle vorstellen, wo Assembler effizienter ist. Der Originalkontext lautete übrigens wie folgt: >>>>> besser ist es, sie - wie vorgesehen - in C zu programmieren. >>>> Von wem ist die Programmierung in C vorgesehen >>> Von Leuten, die C aus o.g. Gründen gut finden und sogar CPU's extra so >>> bauen, dass sie C/C++ effizient ausführen können, zB x86 oder ARM >> Und diese CPUs laufen mit Assembler schlechter? Hier wurde argumentiert, daß es besser und so vorhergesehen sei einen Mikrocontroller mit C zu programmieren, dagegen habe ich mich gewehrt. Ich finde das durchaus legitim! >>>>>>> besser ist es, sie - wie vorgesehen - in C zu programmieren. >>>>>> Von wem ist die Programmierung in C vorgesehen >>>>> Von Leuten, die C aus og. Gründen gut finden und sogar CPU's extra so >>>>> bauen, dass sie C/C++ effizient ausführen können, zB x86 oder ARM >>>> Und diese CPUs laufen mit Assembler schlechter? Wird er gar kaputt, >>>> wenn ich eine "nichtvorgesehene" Programmiersprache zu nutzen >>> Nein, du wirst eine nicht unterstützte Programmiersprache gar >>> nicht erst compiliert kriegen... >> Pseudoargument, denn wenn es keinen Compiler kann ich ja gar nicht >> compilieren. > Auf eine Pseudo-Frage, denn wie soll denn bitte eine Programmiersprache > an sich einen Controller zerstören können. Eben, es ist und bleibt ein Pseudoargument, daß C die vorgesehene Sprache wäre. Wenigstens sind wir uns hier einig! >> Aha, das "vorgeshene C" läuft also immer am schnellsten. Interessant! > Es hat eine gewisse Tendenz effizienteren Code als Sprachen mit anderen > Speichermodellen zu generieren, Welches Speichermodell denn bitte? Assembler kennt per se kein abstraktes Speichermodell, wiso soll C also "effizienter" sein als C? Das war es, was ich angeprangert habe, nicht mehr und nicht weniger. > da einige typische C-Merkmale wie der Stack, lokale Variablen, > direkte/indirekte Offset-Adressierung direkt auf Maschineninstruktionen > abgebildet werden können. Das kann Assembler inhärent :-p >> Achso, jeder weiß das. C ist also immer schneller und einfacher zu >> programmieren, das wusste ich nicht. > Wieder was gelernt. Das gilt natürlich nur für den durchschnittlichen > Programmierer, für das Matrixbrain für das 20 Zeilen-Assembler genauso > übersichtlich sind wie 1 Zeile C mit ein paar Operatoren, kann sich das > anders verhalten; aber die ändern die Statistik kaum. Das war nicht der Punkt! >> Kann ja nicht ahnen, daß es da ein >> Wissen gibt, das zwar jeder kennt, aber nirgends wo nachzulesen ist. > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html zB da; > (mehr oder weniger) abstrakte Sprachen wie C, java, C++ sind auf > Positionen 1-3, Assembler auf ... 27 (as of this writing). Das ist > natürlich keine direkte harte Folgerung, aber man kann sich doch > überlegen, dass die Hochsprachen vermutlich aufgrund ihrer größeren > Intuitivität/Einfachheit ganz oben sind. Hmm, ich hab' mal JavaScropt aktiviert, damit ich mir diesen Vergleich ansehen kann. Und da stehen Java, PHP, Python, VisualBasic.NET, Perl, Ruby, SQL, LISP, Matlab, COBOL, Fortran, etc. alle vor Assembler. Willst Du deswegen ernsthaft behaupten, es wäre besser/effizienter/gescheiter zu versuchen, einen Microcontoller in SQL, Python oder VisualBasic.NET denn als in Assembler zu programmieren? Kann ich nicht nachvollziehen! Ich lass mir jedenfalls nicht die Worte im Munde umdrehen. Gute Nacht!
Norbert M. schrieb: > Das Argument, daß C plattformunabhängig wäre, wenn man denn nur > plattformunabhängigen C-Code hätte ist doch Augenauswischerei. Kommt drauf an wie gut man das kann. > Bei C-Code muß ich doch genau so aufpassen, ob der Quellcode auf die > Zielmaschine passt, da hilft mir auch kein generischer C-Code. Aufpassen auf jeden Fall, aber möglich ist es. > Was mache > ich zum Beispiel, wenn die Zielmaschine den C-Typ Integer gar nicht > kennt, weil die Maschine zum Beispiel nur 8 Bit addressieren kann? Dann > kann ich mir den Algorithmus in die Haare schmieren. Obwohl der AVR ein 8bitter ist, kennt er 16, 32 und sogar 64bit-Integer, die man per (u)int16_t, etc nutzen kann. Ähnliches gilt vermutlich für alle anderen 8bitter, sofern sie Carry-Arithmetik beherrschen. Das ist also überhaupt kein Argument. > Umgekehrt könnte ich aus der Assmblerperspektive genau so gut > argumentieren, daß sich ein generischer Assemblercode für einen > Sortieralgorithmus auch maschinenunabhängig schreiben lässt, solange die > Zielmaschine vergleichen, lesen, speichern, etc kann. ... solange die Zielmaschine die gleiche Assemblersprache hat... > Meinetwegen schreibe ich den Assemblercode dann in Knuth'schem MIX und > ein Zwischenlayer macht dann eben aus MOV z.B. ein LD. Ist Assembler > deswegen plattformunabhängig? Wohl kaum, genausowenig wie C. Genau das geht, mit dem Java-Bytecode und der JVM. Interessant ist, dass eine Unzahl an C-Programmen sowohl unter ARM-Linux als auch x86-Linux läuft. So ganz unportabel scheint es nicht zu sein. Natürlich stellt C gewisse Anforderungen an die Hardware, die von manchem Prozessoren mehr (ARM, x86) und von anderen weniger (8051, AVR) erfüllt werden; aber dennoch sind allgemeine Algorithmen wie qsort oder sprintf dennoch auf all diese übertragbar, sofern bei deren Programmierung aufgepasst wurde. > Ein guter Assembler weiß sogar, ob "#4" jetzt im nahem oder im fernem > Speicher liegt, der macht nämlich aus 'MOV r4,#4' nicht stupide > ein 240404, sondern, je nach Kontext kann das ein 240404 sein, oder ein > 2404 oder beispielsweise einfach nur 44. Kann einen Unhterschied von > 200% Codegrösse ausmachen. Also bitte den Assamble nicht einfach nur als > "dummen Textersetzer" darstellen! In diesem Fall war #4 einfach nur ein Integer-Literal (ARM-UAL). Dort kann man für besonders optimierungsbedürftigen Code auch über "mov.n"/"mov.w" die Breite des Befehls erzwingen. Somit braucht man auch hier keinen Maschinencode zu schreiben um den Code von Hand auf die richtige Größe zu bringen. > Habe ich irgendwo mit "Intuition" argumentiert? Ich kann mir durchaus > Fälle vorstellen, wo Assembler effizienter ist. Die gibt es natürlich immer. Aber zwischen "Fälle" und "ganze Anwendungen" ist noch ein Unterschied. > Hier wurde argumentiert, daß es besser und so vorhergesehen sei einen > Mikrocontroller mit C zu programmieren, dagegen habe ich mich gewehrt. > Ich finde das durchaus legitim! Es ist natürlich nicht immer absolut besser, aber im Allgemeinen kann man schon sagen dass man Assembler nicht ohne guten Grund benutzen muss/sollte. > Welches Speichermodell denn bitte? Assembler kennt per se kein > abstraktes Speichermodell, wiso soll C also "effizienter" sein als C? > Das war es, was ich angeprangert habe, nicht mehr und nicht weniger. Das macht keinen Sinn. Das Speichermodell von C eben, lokale Variablen, Arrays, Structs etc. Da ASM kein Speichermodell kennt hat man in für ASM konzipierten Prozessoren keinen Support dafür vorgesehen (8051, AVR), aber in für C/C++ designten wie x86, ARM schon. > > Das kann Assembler inhärent :-p > Das war nicht der Punkt! Wenn dein Punkt ist dass man in Maschinencode alles machen/programmieren kann - ja, kann man. Das ist im Allgemeinen aber nicht effizient/wirtschaftlich. > Willst Du deswegen ernsthaft behaupten, es wäre > besser/effizienter/gescheiter zu versuchen, einen Microcontoller in SQL, SQL ist was völlig anderes > Python oder VisualBasic.NET denn als in Assembler zu programmieren? Python wird beim Raspberry PI intensiv verwendet, und .NET zeug bei diversen .netmf-verseuchten Plattformen. Beides ist entwicklungszeit-effizienter als Maschinencode,Assembler,C. Die Hardwarekosten&Energie-Effizienz könnte sich hier aber dann auch bemerkbar machen. > Kann ich nicht nachvollziehen! Vielleicht solltest du mal die 60er da lassen wo sie sind und moderne Programmiertechniken ansehen?
Angehängte Dateien:
-
Koffer.jpg
25 KB
Hi Womit wir wieder bei der Diskussion "Ich spreche die einzig wahre Sprache" sind. Leute, wann merkt ihr "Fachleute" mal, das die Sprache lediglich das Werkzeug ist. Programmieren läuft im Kopf ab und das "Können" liegt in der Fähigkeit, eine Aufgabe so zu formulieren, das ein Computer in der Lage ist, die Antwort zu liefern. Ich spreche (noch) kein C, aber Basic, Pascal und auch Assembler. Ich denke, da ist für jede Arbeit das Werkzeug vorhanden und wenn mir C fehlen sollte, wird ich mich auch damit befassen. Ob ich die Sprache noch lernen werde, steht in den Sternen... Niemals aber würde ich einem Anfänger sagen "lern C, Basic oder Assembler". Ich würd auf die verfügbare Lektüre hinweisen, z. B. die hier veröffentlichten Tutorials über Assembler und C. Das Assembler mehr Gefühl für die Elektronik vermittelt und C bei Eignung zum Programmierer schneller ein Ergebnis bringt ist doch eine schon so uralte Diskussion. Nun zum Thema. Ich arbeite mit den Eva.-Boards von Pollin und einem USBISP Stick von Diamex für 20 €. Der Bausatz vom Eva-Board liegt bei 15 € und ist auch schon viel in der Diskussion Thema "Pollin Board". Ich find es immer noch nicht schlecht, abgesehen von der Beschaltung der Taster, auf deren Bestückung man getrost verzichten kann. Aber bei dem Preis ist auch noch eine 40 pol. Textool-Fassung drin (muss zusätzlich bestellt und anstelle der 40pol. Fassung eingelötet werden) und wer ein wenig Geschick hat, kann auch einen Adapter mit einer 28 pol. dazu bauen. Die µC's sind damit einfach und leicht mal zu wechseln. Ein Steckernetzteil 12 V und ein Steckbrett für ca. 15 € runden den Arbeitsplatz ab. Auf Bauteile aus alter Elektronik kann man zwar zurückgreifen, aber es macht durchaus Sinn, sich ein kleines Depot an erforderlichen Teilen anzuschaffen. Anzeigen, Widerstände, Kondensatoren, Dioden und Transistoren. Vielleicht noch ein Billig Multimeter. Ich hab mir das Ganze in einen Koffer eingebaut. Die Teile sind einfach mit Klettband (Scotch selbstklebend) befestigt. Auch wenn das kein gutes Foto ist, aber so könnte es aussehen... Und nun viel Spaß bei diesem neuen Hobby Gruß oldmax
Ist schon lustig, wie schnell sich Assemblerprogrammierer auf den Schlips getreten fühlen und dann unsachlich werden. Ich hab >10 Jahre Assembler (8051) gemacht, mit C ist man wesentlich effektiver. Assembler ist für mich Diebstahl am Auftraggeber.
Peter Dannegger schrieb: > Assembler ist für mich Diebstahl am Auftraggeber. Naja, das ist IMHO Bloedsinn. Es gibt durchaus noch Szenarien wo Assembler notwendig ist. Z.B. wenn "harte" Timings erreicht werden sollen. Desweiteren gibt es ja durchaus mal "Compilerbugs" oder "Compiler Suboptimalitaeten" bei denen dann doch auf (Inline-)assembler zurueckgegriffen wird. Hier zunaechst den Compiler fixen, das waere "Diebstahl am Auftraggeber". MfG
Peter Dannegger schrieb: > Assembler ist für mich Diebstahl am Auftraggeber. Ob Assembler oder C besser sind, oder ob Assembler gar Diebstahl am Auftraggeber ist, kann man sicherlich so einfach nicht sagen. Denn es kommt vor allem auf den Auftrag bzw. die Aufgabe an. Wenn ich jetzt z.B. einen Airbag Controller programmiere, möchte ich genau unter Kontrolle haben, wann was wie passiert. => ASM oder gar Maschinensprache. Programmiere ich aber z.B. die Software fürs Autoradio, dann ist in meinen Augen alles andere angemesener. In meinen Augen!
Dimitri Roschkowski schrieb: > Wenn ich jetzt z.B. > einen Airbag Controller programmiere Die Algorithmen in Airbags sind sehr komplex. Ich glaube daher nicht, daß Dir da noch ein Hersteller ein Assemblerprogramm abnimmt. Allein schon aus Sicherheitsgründen. Der Prüfer in der Zulassungstelle muß das Programm nachvollziehen können. Stephan B. schrieb: > Z.B. wenn "harte" Timings erreicht werden sollen. Ich habe schon viele Jahre keine einzige Assemblerzeile mehr benötigt. Die "harten" Sachen kann man oft mit den PWM-Ausgängen auf den Zyklus genau ausführen. Oder man nimmt nen schnelleren MC oder einen mit Logik (PSoC). Man kann sich bestimmt Beispiele ausdenken, die Assembler benötigen. Aber das sind dann Ausnahmen und nicht die Regel.
Hi PeDa's Aussage "Diebstahl am Arbeitgeber" scheint (s)ein Lieblingsargument zu sein. Hab ich schon öfters gelesen, aber Wiederholungen machen keine Wahrheit draus. Ein Arbeitgeber gibt in der Regel schon bei der Einstellung die Bedingungen vor. Außerdem sehe ich hier keinen Arbeitgeber im Startpost. Daher ist es hier völlig irrelevant. Sorry, das ich damit noch mal anfange, aber die Diskussion ist Blödsinn. Warum lernen Kleinkinder erst mal mit Bauklötzen zu spielen und nicht gleich mit Ziegelsteinen umzugehen ? Ist natürlich auch ein bescheuerter Vergleich.... obwohl... Also, den Spaß nicht verderben lassen. Gruß oldmax
Peter Dannegger schrieb: > Die Algorithmen in Airbags sind sehr komplex. Ich glaube daher nicht, > daß Dir da noch ein Hersteller ein Assemblerprogramm abnimmt. In Airbags laufen keine Algorithmen, sondern im/in Mikrocontroller(n) des Airbag-Steuergerätes. > Allein schon aus Sicherheitsgründen. Der Prüfer in der Zulassungstelle > muß das Programm nachvollziehen können. Zugelassen wird kein Algorithmus, auch kein Programm und auch kein Mikrocontroller, sondern das Steuergerät. Also Hardware und Software. Für die Zulassung ist es dabei egal, ob ein Programm auf einem Mikrocontroller läuft oder sich fest im Silizium befindet. Eine Kleinigkeit möchte ich noch zu Algorithmen erwähnen. Es gibt keine komplexen Algorithmen. Ein Algorithmus ist einfach ein herumschieben von Zahlen und sehr gut nachvollziehbar, in jeder Sprache.
Dimitri Roschkowski schrieb: > Ein Algorithmus ist einfach ein herumschieben von > Zahlen und sehr gut nachvollziehbar, in jeder Sprache. Sorry, ich weis wie du es meinst, aber muss einfach sein: http://de.wikipedia.org/wiki/Brainf*ck (* = u) :-) MfG
Stephan B. schrieb: > Sorry, ich weis wie du es meinst, aber muss einfach sein: http://de.wikipedia.org/wiki/Whitespace_%28Programmiersprache%29
Dimitri Roschkowski schrieb: [Haarspaltermodus ein] > ... [Haarspaltermodus aus] Wie im Kindergarten.
Norbert M. schrieb: > Ich weiß, die Diskussion ist müßig und wahrscheinlich OT, aber erlaube > mir bitte zwei fragen: > 1.) Warum ist es besser, einen Mikrocontroller in C zu programmieren? Das muß präzisiert werden: Bei den Arduinos, wo ja so ein Atmel-AVR Controller drauf ist, ist es besser, das Teil in C zu programmieren als in Assembler, weil Assembler für diese Chip-Sorte nicht wirklich gut zu schreiben ist. Das gilt auch für diverse andere Architekturen, aber nicht für alle. Wenn man allerdings einen Basic-Interpreter für den Arduino hat, dann ist es genauso gut, diesen zu nehmen. Wahrscheinlich ist es sogar ein bissel besser für den Anfang, da man mit Basic erstmal leichter flottkommt. Was die o.g. Baugruppe betrifft, habe ich aber Zweifel, daß sowas ein wirklich guter Anfang ist. Man möchte gerade beim allerersten Basteln sicherlich erstmal auf dem Basteltisch zurechtkommen und sich nicht auch noch mit PC-Angelegenheiten, USB, Darstellprogrammen usw. befassen - sowas kommt später. Deshalb würde ich dir empfehlen, irgendein kleines Demo-Board zu besorgen, wo bereits ein Display mit drauf ist. Für den Anfang reicht ein Alpha-LCD aus, da kann man schon einiges drauf darstellen und hat das Ergebnis direkt ohne Umweg über den PC. W.S.
>... und sogar CPU's extra so >bauen, dass sie C/C++ effizient ausführen können, ........ >ARM zB ist kaum für manuelle Assembler-Programmierung vorgesehen, er ist >explizit für C/C++ gedacht. ......... Nur Marketinggequatsche. Jeder stinknormale ASM-Befehlssatz (sofern nicht zu kleiner Adressbereich, und es noch ein paar Indexregister und n Stack gibt) kann das.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.